Skip to content

Conversation

@AnmolShukla2002
Copy link
Contributor

@AnmolShukla2002 AnmolShukla2002 commented Jan 19, 2026

This PR migrates the Go SDK documentation and core technical samples from the [mcp-toolbox-sdk-go] repository to the main genai-toolbox documentation site. This consolidation ensures that conceptual guides, package overviews, and interactive code examples are available in a centralized "one-stop-shop".

@AnmolShukla2002 AnmolShukla2002 requested a review from a team as a code owner January 19, 2026 09:20
@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @AnmolShukla2002, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the documentation for the MCP Toolbox Go SDK's core package. It provides developers with a centralized and comprehensive resource for understanding the SDK's capabilities, from basic setup and tool interaction to advanced topics like secure authentication mechanisms and flexible parameter binding. Furthermore, it offers ready-to-use integration samples for leading AI orchestration frameworks, streamlining the development of intelligent applications using the Toolbox.

Highlights

  • Comprehensive Go SDK Documentation: Introduces a new, detailed documentation page for the MCP Toolbox Go SDK's core package, covering installation, usage, and advanced features.
  • Authentication Guides: Provides in-depth guidance on both client-to-server authentication (e.g., for Cloud Run deployments) and tool-level authentication, including token retrieval and configuration options.
  • Parameter Binding Functionality: Explains how to bind static or dynamic values to tool parameters, enhancing security and control over tool invocation.
  • Orchestration Framework Integration Samples: Includes practical code examples demonstrating how to integrate the Go SDK with popular AI orchestration frameworks like Google GenAI, LangChain Go, and OpenAI Go.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request adds extensive documentation and samples for the Go SDK core package. The documentation is comprehensive, but I've found several issues in the code samples, including incomplete examples, incorrect API usage, unhandled errors, and typos. These issues could confuse users or cause their code to fail if they copy the examples. I've left specific comments with suggestions for fixes. Addressing these will greatly improve the quality and usability of the documentation.



```go
import "github.com/googleapis/mcp-toolbox-sdk-go/core"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This code example is incomplete as it uses the oauth2 package without importing it. Please add the import for golang.org/x/oauth2 to make the example runnable.

Suggested change
import "github.com/googleapis/mcp-toolbox-sdk-go/core"
import (
"github.com/googleapis/mcp-toolbox-sdk-go/core"
"golang.org/x/oauth2"
)

Comment on lines +311 to +315
token, err := core.GetGoogleIDToken(ctx, URL)

client, err := core.NewToolboxClient(
URL,
core.WithClientHeaderString("Authorization", token),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This code snippet has a couple of issues:

  1. The URL variable is used but not defined. It should be replaced with a placeholder to make it clear to the user.
  2. The Authorization header for a bearer token should be in the format "Bearer <token>". The current example is missing the "Bearer " prefix, which will lead to authentication failures.
Suggested change
token, err := core.GetGoogleIDToken(ctx, URL)
client, err := core.NewToolboxClient(
URL,
core.WithClientHeaderString("Authorization", token),
token, err := core.GetGoogleIDToken(ctx, "your-cloud-run-url")
client, err := core.NewToolboxClient(
"your-cloud-run-url",
core.WithClientHeaderString("Authorization", "Bearer "+token),

tool, err := client.LoadTool("my-tool", ctx)

AuthTool, err := tool.ToolFrom(
core.WithAuthTokenSource("my-auth", headerTokenSource),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This code example is incomplete. The headerTokenSource variable is used in core.WithAuthTokenSource but it is not defined anywhere in the snippet. Please define it to make the example complete and runnable for users.

log.Fatal("Could not invoke tool", err)
}

params.Messages = append(params.Messages, openai.ToolMessage(result.(string), toolCall.ID))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

The type assertion result.(string) is unsafe and will cause a panic if the result from tool.Invoke is not a string. The Invoke method returns any, so its type is not guaranteed. It's safer to convert the result to a string using fmt.Sprintf to avoid a panic.

Suggested change
params.Messages = append(params.Messages, openai.ToolMessage(result.(string), toolCall.ID))
params.Messages = append(params.Messages, openai.ToolMessage(fmt.Sprintf("%v", result), toolCall.ID))

// Make initial chat completion request
completion, err := openAIClient.Chat.Completions.New(ctx, params)
if err != nil {
panic(err)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

This example uses panic(err) for error handling, which is generally discouraged in Go applications unless it's a truly unrecoverable state during initialization. It's also inconsistent with other parts of the example that use log.Fatal. Using log.Fatalf would be more idiomatic and consistent for a main function.

Suggested change
panic(err)
log.Fatalf("Chat completion failed: %v", err)

@github-actions
Copy link
Contributor

Copy link
Contributor

@anubhav756 anubhav756 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we have major sections added as separate pages under the SDKs' sections?

@anubhav756
Copy link
Contributor

There seem to be links to the READMEs of individual packages in the top-level doc (screenshot). Can we have them linked to this docsite?

@github-actions
Copy link
Contributor

@github-actions
Copy link
Contributor

@AnmolShukla2002
Copy link
Contributor Author

There seem to be links to the READMEs of individual packages in the top-level doc (screenshot). Can we have them linked to this docsite?

I guess docs reorganization strategy states that we will "treat each SDK repository as the source of truth for its own API reference". While the docsite serves as the "one-stop-shop" for conceptual guides, the github links serve as the technical reference point until our auto-generated API subdomains are fully live. I am not sure on this, let me know your thoughts?

@anubhav756
Copy link
Contributor

anubhav756 commented Jan 29, 2026

There seem to be links to the READMEs of individual packages in the top-level doc (screenshot). Can we have them linked to this docsite?

I guess docs reorganization strategy states that we will "treat each SDK repository as the source of truth for its own API reference". While the docsite serves as the "one-stop-shop" for conceptual guides, the github links serve as the technical reference point until our auto-generated API subdomains are fully live. I am not sure on this, let me know your thoughts?

Sounds good! Let’s link directly to the github source files until we have the API ref docsite up.

However for links like those under “Which package should I use?”, I guess I was assuming the links from core, tbadk and tbgenkit could be linked to the packages’ respective pages to the guidance docs that I assume we would be adding to the main docsite (just like we have done for the core package). Currently they seem to link to the github source code (unless it’s intentional because I see the core package guidance page is linked at the bottom of that page, but just thinking what if we also link the guidance pages in that section as well). Thoughts?

Copy link
Contributor

@anubhav756 anubhav756 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, given we address the bot comments and link checker error as well. Optionally, adding a PR description might help as well.

Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
@github-actions
Copy link
Contributor

@AnmolShukla2002
Copy link
Contributor Author

There seem to be links to the READMEs of individual packages in the top-level doc (screenshot). Can we have them linked to this docsite?

I guess docs reorganization strategy states that we will "treat each SDK repository as the source of truth for its own API reference". While the docsite serves as the "one-stop-shop" for conceptual guides, the github links serve as the technical reference point until our auto-generated API subdomains are fully live. I am not sure on this, let me know your thoughts?

Sounds good! Let’s link directly to the github source files until we have the API ref docsite up.

However for links like those under “Which package should I use?”, I guess I was assuming the links from core, tbadk and tbgenkit could be linked to the packages’ respective pages to the guidance docs that I assume we would be adding to the main docsite (just like we have done for the core package). Currently they seem to link to the github source code (unless it’s intentional because I see the core package guidance page is linked at the bottom of that page, but just thinking what if we also link the guidance pages in that section as well). Thoughts?

yes made these changes!

@AnmolShukla2002
Copy link
Contributor Author

LGTM, given we address the bot comments and link checker error as well. Optionally, adding a PR description might help as well.

Bot's comments are mostly regarding the sample...I am not sure If I should make these changes as it would then defer from the sample in the Sdk repos?

@github-actions
Copy link
Contributor


Before using the SDKs, you need the MCP Toolbox server running. Follow
the instructions here: [**Toolbox Getting Started
Guide**](https://github.com/googleapis/genai-toolbox?tab=readme-ov-file#getting-started)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we update links like these to also point to the main docsite now that we have migrated all the SDKs guidance as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once these sub branches are merged I will update all the links

@anubhav756 anubhav756 self-requested a review February 2, 2026 12:30
Closing the `ToolboxClient` also closes the underlying network session shared by all tools loaded from that client. As a result, any tool instances you have loaded will cease to function and will raise an error if you attempt to invoke them after the client is closed.
{{< /notice >}}

## Transport Protocols
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to my comment from some of the previous PRs, can we have all the major sections from this guide broken into multiple pages in the menu?

This might make the docs a bit more intuitive and easier to read and share.

WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest we maintain the single-page structure to make sure a cohesive experience for developers during the setup phase. Breaking down these readmes into separate pages for every minor technical section would create content fragments that lack the necessary "big-picture" context.....requiring a user to read 17 other documents just to understand a single proposal. This approach keeps the navigation sidebar clean and focused on our three core package offerings Core, TBADK, and TBGenkit rather than cluttering the menu with excessive sub-levels that can overwhelm both developers and reviewers. By making this sure we are allowing readers to scan through the document quickly to understand what the package represents and how to use it efficiently.

@github-actions
Copy link
Contributor

github-actions bot commented Feb 3, 2026

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants