Revise title and description for adk SDK

Updated title and description for the adk documentation.

docs/en/sdks/JS-sdk/_index.md

@@ -1,12 +1,11 @@
 ---
-title: "JS SDK"
+title: "Javascript"
 type: docs
 weight: 7
 description: >
-  JS SDKs to connect to the MCP Toolbox server.
+  Javascript SDKs to connect to the MCP Toolbox server.
 ---
 
-
 ## Overview
 
 The MCP Toolbox service provides a centralized way to manage and expose tools
@@ -22,4 +21,48 @@ These JS SDKs act as clients for that service. They handle the communication nee
 By using these SDKs, you can easily leverage your Toolbox-managed tools directly
 within your JS applications or AI orchestration frameworks.
 
-[Github](https://github.com/googleapis/mcp-toolbox-sdk-js)
+## Which Package Should I Use?
+
+Choosing the right package depends on how you are building your application:
+
+- [`@toolbox-sdk/core`](https://github.com/googleapis/mcp-toolbox-sdk-js/tree/main/packages/toolbox-core):
+  This is a framework agnostic way to connect the tools to popular frameworks
+  like Langchain, LlamaIndex and Genkit.
+- [`@toolbox-sdk/adk`](https://github.com/googleapis/mcp-toolbox-sdk-js/tree/main/packages/toolbox-adk):
+  This package provides a seamless way to connect to [Google ADK TS](https://github.com/google/adk-js).
+
+## Available Packages
+
+This repository hosts the following TS packages. See the package-specific
+README for detailed installation and usage instructions:
+
+| Package | Target Use Case | Integration | Path | Details (README) | Npm Version |
+| :------ | :---------- | :---------- | :---------------------- | :---------- | :--------- 
+| `toolbox-core` | Framework-agnostic / Custom applications | Use directly / Custom | `packages/toolbox-core/` | 📄 [View README](https://github.com/googleapis/mcp-toolbox-sdk-js/blob/main/packages/toolbox-core/README.md) | ![npm](https://img.shields.io/npm/v/@toolbox-sdk/core) |
+| `toolbox-adk` | ADK applications | ADK | `packages/toolbox-adk/` | 📄 [View README](https://github.com/googleapis/mcp-toolbox-sdk-js/blob/main/packages/toolbox-adk/README.md) | ![npm](https://img.shields.io/npm/v/@toolbox-sdk/adk) |
+
+
+## Getting Started
+
+To get started using Toolbox tools with an application, follow these general steps:
+
+1. **Set up and Run the Toolbox Service:**
+
+    Before using the SDKs, you need the main MCP Toolbox service running. Follow
+    the instructions here: [**Toolbox Getting Started
+    Guide**](https://github.com/googleapis/genai-toolbox?tab=readme-ov-file#getting-started)
+
+2. **Install the Appropriate SDK:**
+
+    Choose the package based on your needs (see "[Which Package Should I Use?](#which-package-should-i-use)" above) and install it:
+
+    ```bash
+    # For the core, framework-agnostic SDK
+    npm install @toolbox-sdk/core
+    ```
+
+
+
+{{< notice note >}}
+Source code for [js-sdk](https://github.com/googleapis/mcp-toolbox-sdk-js)
+{{< /notice >}}

docs/en/sdks/JS-sdk/adk/index.md

@@ -0,0 +1,472 @@
+---
+title: "Adk"
+type: docs
+weight: 8
+description: >
+  MCP Toolbox ADK SDK for integrating functionalities of MCP Toolbox into your apps.
+---
+
+## Overview
+
+The `@toolbox-sdk/adk` package provides a Javascript interface to the MCP Toolbox service, enabling you to load and invoke tools from your own applications.
+
+## Supported Environments
+
+This SDK is a standard Node.js package built with TypeScript, ensuring broad compatibility with the modern JavaScript ecosystem.
+
+- Node.js: Actively supported on Node.js v18.x and higher. The package is compatible with both modern ES Module (import) and legacy CommonJS (require).
+- TypeScript: The SDK is written in TypeScript and ships with its own type declarations, providing a first-class development experience with autocompletion and type-checking out of the box.
+- JavaScript: Fully supports modern JavaScript in Node.js environments.
+
+## Installation
+
+```bash
+npm install @toolbox-sdk/adk
+```
+
+## Quickstart
+
+
+1. **Start the Toolbox Service**
+   - Make sure the MCP Toolbox service is running. See the [Toolbox Getting Started Guide](/getting-started/introduction/#getting-started).
+
+2. **Minimal Example**
+
+Here's a minimal example to get you started. Ensure your Toolbox service is running and accessible.
+
+```javascript
+
+import { ToolboxClient } from '@toolbox-sdk/adk';  
+const client = new ToolboxClient(URL);  
+
+async function quickstart() {  
+  try {  
+      const tools = await client.loadToolset();  
+      // Use tools  
+  } catch (error) {  
+      console.error("unable to load toolset:", error.message);  
+  }  
+}  
+quickstart();  
+```
+
+{{< notice note>}}
+ This guide uses modern ES Module (`import`) syntax. If your project uses CommonJS, you can import the library using require: `const { ToolboxClient } = require('@toolbox-sdk/adk')`;.
+{{< /notice >}}
+
+## Usage
+
+Import and initialize a Toolbox client, pointing it to the URL of your running Toolbox service.
+
+```javascript
+import { ToolboxClient } from '@toolbox-sdk/adk';
+
+// Replace with the actual URL where your Toolbox service is running
+const URL = 'http://127.0.0.1:5000';
+
+let client = new ToolboxClient(URL);
+const tools = await client.loadToolset();
+
+// Use the client and tools as per requirement
+```
+
+All interactions for loading and invoking tools happen through this client.
+
+{{< notice note>}}
+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 >}}
+
+{{< notice note>}}
+For advanced use cases, you can provide an external `AxiosInstance` during initialization (e.g., `ToolboxClient(url, my_session)`).
+{{< /notice >}}
+
+## Transport Protocols
+
+The SDK supports multiple transport protocols to communicate with the Toolbox server. You can specify the protocol version during client initialization.
+
+### Available Protocols
+
+- `Protocol.MCP`: The default protocol version (currently aliases to `MCP_v20250618`).
+- `Protocol.MCP_v20241105`: Use this for compatibility with older MCP servers (November 2024 version).
+- `Protocol.MCP_v20250326`: March 2025 version.
+- `Protocol.MCP_v20250618`: June 2025 version.
+- `Protocol.MCP_v20251125`: November 2025 version.
+- `Protocol.TOOLBOX`: Legacy Toolbox protocol.
+
+### Specifying a Protocol
+
+You can explicitly set the protocol by passing the `protocol` argument to the `ToolboxClient` constructor.
+
+```javascript
+import { ToolboxClient, Protocol } from '@toolbox-sdk/adk';
+
+const URL = 'http://127.0.0.1:5000';
+
+// Initialize with a specific protocol version
+const client = new ToolboxClient(URL, null, null, Protocol.MCP_v20241105);
+
+const tools = await client.loadToolset();
+```
+
+## Loading Tools
+
+You can load tools individually or in groups (toolsets) as defined in your Toolbox service configuration. Loading a toolset is convenient when working with multiple related functions, while loading a single tool offers more granular control.
+
+### Load a toolset
+
+A toolset is a collection of related tools. You can load all tools in a toolset or a specific one:
+
+```javascript
+// Load all tools
+const tools = await toolbox.loadToolset()
+
+// Load a specific toolset
+const tools = await toolbox.loadToolset("my-toolset")
+```
+
+### Load a single tool
+
+Loads a specific tool by its unique name. This provides fine-grained control.
+
+```javascript
+const tool = await toolbox.loadTool("my-tool")
+```
+
+## Invoking Tools
+
+Once loaded, tools behave like awaitable JS functions. You invoke them using `await` and pass arguments corresponding to the parameters defined in the tool's configuration within the Toolbox service.
+
+```javascript
+const tool = await toolbox.loadTool("my-tool")
+const result = await tool.runAsync(args: {a: 5, b: 2})
+```
+
+{{< notice tip>}}
+For a more comprehensive guide on setting up the Toolbox service itself, which you'll need running to use this SDK, please refer to the [Toolbox Quickstart Guide](getting-started/local_quickstart).
+{{< /notice >}}
+
+## Client to Server Authentication
+
+This section describes how to authenticate the ToolboxClient itself when
+connecting to a Toolbox server instance that requires authentication. This is
+crucial for securing your Toolbox server endpoint, especially when deployed on
+platforms like Cloud Run, GKE,  or any environment where unauthenticated access is restricted.
+
+This client-to-server authentication ensures that the Toolbox server can verify
+the identity of the client making the request before any tool is loaded or
+called. It is different from [Authenticating Tools](#authenticating-tools),
+which deals with providing credentials for specific tools within an already
+connected Toolbox session.
+
+### When is Client-to-Server Authentication Needed?
+
+You'll need this type of authentication if your Toolbox server is configured to
+deny unauthenticated requests. For example:
+
+- Your Toolbox server is deployed on Cloud Run and configured to "Require authentication."
+- Your server is behind an Identity-Aware Proxy (IAP) or a similar
+  authentication layer.
+- You have custom authentication middleware on your self-hosted Toolbox server.
+
+Without proper client authentication in these scenarios, attempts to connect or
+make calls (like `load_tool`) will likely fail with `Unauthorized` errors.
+
+### How it works
+
+The `ToolboxClient` allows you to specify functions that dynamically generate
+HTTP headers for every request sent to the Toolbox server. The most common use
+case is to add an [Authorization
+header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization)
+with a bearer token (e.g., a Google ID token).
+
+These header-generating functions are called just before each request, ensuring
+that fresh credentials or header values can be used.
+
+### Configuration
+
+You can configure these dynamic headers as seen below:
+
+```javascript
+import { ToolboxClient } from '@toolbox-sdk/adk';
+import {getGoogleIdToken} from '@toolbox-sdk/core/auth'
+
+const URL = 'http://127.0.0.1:5000';
+const getGoogleIdTokenGetter = () => getGoogleIdToken(URL);
+const client = new ToolboxClient(URL, null, {"Authorization": getGoogleIdTokenGetter});
+
+// Use the client as usual
+```
+
+### Authenticating with Google Cloud Servers
+
+For Toolbox servers hosted on Google Cloud (e.g., Cloud Run) and requiring
+`Google ID token` authentication, the helper module
+[auth_methods](src/toolbox_core/authMethods.ts) provides utility functions.
+
+### Step by Step Guide for Cloud Run
+
+1. **Configure Permissions**: [Grant](https://cloud.google.com/run/docs/securing/managing-access#service-add-principals) the `roles/run.invoker` IAM role on the Cloud
+   Run service to the principal. This could be your `user account email` or a
+   `service account`.
+2. **Configure Credentials**
+    - Local Development: Set up
+   [ADC](https://cloud.google.com/docs/authentication/set-up-adc-local-dev-environment).
+    - Google Cloud Environments: When running within Google Cloud (e.g., Compute
+      Engine, GKE, another Cloud Run service, Cloud Functions), ADC is typically
+      configured automatically, using the environment's default service account.
+3. **Connect to the Toolbox Server**
+
+    ```javascript
+    import { ToolboxClient } from '@toolbox-sdk/adk';
+    import {getGoogleIdToken} from '@toolbox-sdk/core/auth'
+
+    const URL = 'http://127.0.0.1:5000';
+    const getGoogleIdTokenGetter = () => getGoogleIdToken(URL);
+    const client = new ToolboxClient(URL, null, {"Authorization": getGoogleIdTokenGetter});
+
+    // Use the client as usual
+    ```
+
+## Authenticating Tools
+
+{{< notice note>}}
+**Always use HTTPS** to connect your application with the Toolbox service, especially in **production environments** or whenever the communication involves **sensitive data** (including scenarios where tools require authentication tokens). Using plain HTTP lacks encryption and exposes your application and data to significant security risks, such as eavesdropping and tampering.
+{{< /notice >}}
+
+Tools can be configured within the Toolbox service to require authentication,
+ensuring only authorized users or applications can invoke them, especially when
+accessing sensitive data.
+
+### When is Authentication Needed?
+
+Authentication is configured per-tool within the Toolbox service itself. If a
+tool you intend to use is marked as requiring authentication in the service, you
+must configure the SDK client to provide the necessary credentials (currently
+Oauth2 tokens) when invoking that specific tool.
+
+### Supported Authentication Mechanisms
+
+The Toolbox service enables secure tool usage through **Authenticated Parameters**. For detailed information on how these mechanisms work within the Toolbox service and how to configure them, please refer to [Toolbox Service Documentation - Authenticated Parameters](resources/tools/#authenticated-parameters)
+
+### Step 1: Configure Tools in Toolbox Service
+
+First, ensure the target tool(s) are configured correctly in the Toolbox service
+to require authentication. Refer to the [Toolbox Service Documentation -
+Authenticated
+Parameters](resources/tools/#authenticated-parameters)
+for instructions.
+
+### Step 2: Configure SDK Client
+
+Your application needs a way to obtain the required Oauth2 token for the
+authenticated user. The SDK requires you to provide a function capable of
+retrieving this token *when the tool is invoked*.
+
+#### Provide an ID Token Retriever Function
+
+You must provide the SDK with a function (sync or async) that returns the
+necessary token when called. The implementation depends on your application's
+authentication flow (e.g., retrieving a stored token, initiating an OAuth flow).
+
+{{< notice note>}}
+The name used when registering the getter function with the SDK (e.g., `"my_api_token"`) must exactly match the `name` of the corresponding `authServices` defined in the tool's configuration within the Toolbox service.
+{{< /notice >}}
+
+```javascript
+
+async function getAuthToken() {
+    // ... Logic to retrieve ID token (e.g., from local storage, OAuth flow)
+    // This example just returns a placeholder. Replace with your actual token retrieval.
+    return "YOUR_ID_TOKEN" // Placeholder
+}    
+```
+{{< notice tip>}}
+Your token retriever function is invoked every time an authenticated parameter requires a token for a tool call. Consider implementing caching logic within this function to avoid redundant token fetching or generation, especially for tokens with longer validity periods or if the retrieval process is resource-intensive.
+{{< /notice >}}
+
+#### Option A: Add Authentication to a Loaded Tool
+
+You can add the token retriever function to a tool object *after* it has been
+loaded. This modifies the specific tool instance.
+
+```javascript
+const URL = 'http://127.0.0.1:5000';
+let client = new ToolboxClient(URL);
+let tool = await client.loadTool("my-tool")
+
+const authTool = tool.addAuthTokenGetter("my_auth", get_auth_token)  // Single token
+
+// OR
+
+const multiAuthTool = tool.addAuthTokenGetters({
+    "my_auth_1": getAuthToken1,
+    "my_auth_2": getAuthToken2,
+})  // Multiple tokens
+```
+
+#### Option B: Add Authentication While Loading Tools
+
+You can provide the token retriever(s) directly during the `loadTool` or
+`loadToolset` calls. This applies the authentication configuration only to the
+tools loaded in that specific call, without modifying the original tool objects
+if they were loaded previously.
+
+```javascript
+const authTool = await toolbox.loadTool("toolName", {"myAuth": getAuthToken})
+
+// OR
+
+const authTools = await toolbox.loadToolset({"myAuth": getAuthToken})
+```
+
+{{< notice note>}}
+Adding auth tokens during loading only affect the tools loaded within that call.
+{{< /notice >}}
+
+### Complete Authentication Example
+
+```javascript
+import { ToolboxClient } from '@toolbox-sdk/adk';
+
+async function getAuthToken() {
+    // ... Logic to retrieve ID token (e.g., from local storage, OAuth flow)
+    // This example just returns a placeholder. Replace with your actual token retrieval.
+    return "YOUR_ID_TOKEN" // Placeholder
+}
+
+const URL = 'http://127.0.0.1:5000';
+let client = new ToolboxClient(URL);
+const tool = await client.loadTool("my-tool");
+const authTool = tool.addAuthTokenGetters({"my_auth": getAuthToken});
+const result = await authTool.runAsync(args: {input:"some input"});
+console.log(result);
+```
+
+## Binding Parameter Values
+
+The SDK allows you to pre-set, or "bind", values for specific tool parameters
+before the tool is invoked or even passed to an LLM. These bound values are
+fixed and will not be requested or modified by the LLM during tool use.
+
+### Why Bind Parameters?
+
+- **Protecting sensitive information:**  API keys, secrets, etc.
+- **Enforcing consistency:** Ensuring specific values for certain parameters.
+- **Pre-filling known data:**  Providing defaults or context.
+
+{{< notice note>}}
+The parameter names used for binding (e.g., `"api_key"`) must exactly match the parameter names defined in the tool's configuration within the Toolbox service.
+{{< /notice >}}
+
+{{< notice note>}}
+You do not need to modify the tool's configuration in the Toolbox service to
+> bind parameter values using the SDK.
+{{< /notice >}}
+
+### Option A: Binding Parameters to a Loaded Tool
+
+Bind values to a tool object *after* it has been loaded. This modifies the
+specific tool instance.
+
+```javascript
+
+import { ToolboxClient } from '@toolbox-sdk/adk';
+
+const URL = 'http://127.0.0.1:5000';
+let client = new ToolboxClient(URL);
+const tool = await client.loadTool("my-tool");
+
+const boundTool = tool.bindParam("param", "value");
+
+// OR
+
+const boundTool = tool.bindParams({"param": "value"});
+```
+
+### Option B: Binding Parameters While Loading Tools
+
+Specify bound parameters directly when loading tools. This applies the binding
+only to the tools loaded in that specific call.
+
+```javascript
+const boundTool = await client.loadTool("my-tool", null, {"param": "value"})
+
+// OR
+
+const boundTools = await client.loadToolset(null, {"param": "value"})
+```
+
+{{< notice note>}}
+Bound values during loading only affect the tools loaded in that call.
+{{< /notice >}}
+
+### Binding Dynamic Values
+
+Instead of a static value, you can bind a parameter to a synchronous or
+asynchronous function. This function will be called *each time* the tool is
+invoked to dynamically determine the parameter's value at runtime.
+
+```javascript
+
+async function getDynamicValue() {
+    // Logic to determine the value
+    return "dynamicValue";
+}
+
+const dynamicBoundTool = tool.bindParam("param", getDynamicValue)
+```
+
+{{< notice note>}}
+You don't need to modify tool configurations to bind parameter values.
+{{< /notice >}}
+
+# Using with ADK
+
+ADK JS:
+
+```javascript
+import {FunctionTool, InMemoryRunner, LlmAgent} from '@google/adk';
+import {Content} from '@google/genai';
+import {ToolboxClient} from '@toolbox-sdk/core'
+
+const toolboxClient = new ToolboxClient("http://127.0.0.1:5000");
+const loadedTools = await toolboxClient.loadToolset();
+
+export const rootAgent = new LlmAgent({
+  name: 'weather_time_agent',
+  model: 'gemini-2.5-flash',
+  description:
+    'Agent to answer questions about the time and weather in a city.',
+  instruction:
+    'You are a helpful agent who can answer user questions about the time and weather in a city.',
+  tools: loadedTools,
+});
+
+async function main() {
+  const userId = 'test_user';
+  const appName = rootAgent.name;
+  const runner = new InMemoryRunner({agent: rootAgent, appName});
+  const session = await runner.sessionService.createSession({
+    appName,
+    userId,
+  });
+
+  const prompt = 'What is the weather in New York? And the time?';
+  const content: Content = {
+    role: 'user',
+    parts: [{text: prompt}],
+  };
+  console.log(content);
+  for await (const e of runner.runAsync({
+    userId,
+    sessionId: session.id,
+    newMessage: content,
+  })) {
+    if (e.content?.parts?.[0]?.text) {
+      console.log(`${e.author}: ${JSON.stringify(e.content, null, 2)}`);
+    }
+  }
+}
+
+main().catch(console.error);
+```

docs/en/sdks/python-sdk/_index.md

@@ -22,36 +22,4 @@ These Python SDKs act as clients for that service. They handle the communication
 By using these SDKs, you can easily leverage your Toolbox-managed tools directly
 within your Python applications or AI orchestration frameworks.
 
-## Which Package Should I Use?
-
-Choosing the right package depends on how you are building your application:
-
-* [`toolbox-langchain`](langchain):
-  Use this package if you are building your application using the LangChain or
-  LangGraph frameworks. It provides tools that are directly compatible with the
-  LangChain ecosystem (`BaseTool` interface), simplifying integration.
-* [`toolbox-llamaindex`](llamaindex):
-  Use this package if you are building your application using the LlamaIndex framework.
-  It provides tools that are directly compatible with the
-  LlamaIndex ecosystem (`BaseTool` interface), simplifying integration.
-* [`toolbox-core`](core):
-  Use this package if you are not using LangChain/LangGraph or any other
-  orchestration framework, or if you need a framework-agnostic way to interact
-  with Toolbox tools (e.g., for custom orchestration logic or direct use in
-  Python scripts).
-
-## Available Packages
-
-This repository hosts the following Python packages. See the package-specific
-README for detailed installation and usage instructions:
-
-| Package | Target Use Case | Integration | Path | Details (README) | PyPI Status |
-| :------ | :---------- | :---------- | :---------------------- | :---------- | :--------- 
-| `toolbox-core` | Framework-agnostic / Custom applications | Use directly / Custom | `packages/toolbox-core/` | 📄 [View README](https://github.com/googleapis/mcp-toolbox-sdk-python/blob/main/packages/toolbox-core/README.md) | ![pypi version](https://img.shields.io/pypi/v/toolbox-core.svg) |
-| `toolbox-langchain` | LangChain / LangGraph applications | LangChain / LangGraph | `packages/toolbox-langchain/` | 📄 [View README](https://github.com/googleapis/mcp-toolbox-sdk-python/blob/main/packages/toolbox-langchain/README.md) | ![pypi version](https://img.shields.io/pypi/v/toolbox-langchain.svg) |
-| `toolbox-llamaindex` | LlamaIndex applications | LlamaIndex | `packages/toolbox-llamaindex/` | 📄 [View README](https://github.com/googleapis/mcp-toolbox-sdk-python/blob/main/packages/toolbox-llamaindex/README.md) | ![pypi version](https://img.shields.io/pypi/v/toolbox-llamaindex.svg) |
-
-
-{{< notice note >}}
-Source code for [python-sdk](https://github.com/googleapis/mcp-toolbox-sdk-python)
-{{< /notice >}}
+[Github](https://github.com/googleapis/mcp-toolbox-sdk-python)

docs/en/sdks/python-sdk/adk/index.md

@@ -1,279 +0,0 @@
----
-title: "Adk"
-type: docs
-weight: 8
-description: >
-  MCP Toolbox ADK SDK for integrating functionalities of MCP Toolbox into your apps.
----
-
-## Overview
-
-The `toolbox-adk` package provides a Python interface to the MCP Toolbox service, enabling you to load and invoke tools from your own applications.
-
-## Installation
-
-```bash
-pip install toolbox-adk
-```
-
-## Usage
-
-The primary entry point is the `ToolboxToolset`, which loads tools from a remote Toolbox server and adapts them for use with ADK agents.
-
-{{< notice note>}}
-The `ToolboxToolset` in this package mirrors the `ToolboxToolset` in the [`adk-python`](https://github.com/google/adk-python) package. The `adk-python` version is a shim that delegates all functionality to this implementation.
-{{< /notice >}}
-
-```python
-from toolbox_adk import ToolboxToolset
-from google.adk.agents import Agent
-
-# Create the Toolset
-toolset = ToolboxToolset(
-    server_url="http://127.0.0.1:5000" 
-)
-
-# Use in your ADK Agent
-agent = Agent(tools=[toolset])
-```
-
-## Transport Protocols
-
-The SDK supports multiple transport protocols for communicating with the Toolbox server. By default, the client uses the latest supported version of the **Model Context Protocol (MCP)**.
-
-You can explicitly select a protocol using the `protocol` option during toolset initialization. This is useful if you need to use the native Toolbox HTTP protocol or pin the client to a specific legacy version of MCP.
-
-{{< notice note>}}
-* **Native Toolbox Transport**: This uses the service's native **REST over HTTP** API.
-* **MCP Transports**: These options use the **Model Context Protocol over HTTP**.
-{{< /notice >}}
-
-### Supported Protocols
-
-| Constant | Description |
-| :--- | :--- |
-| `Protocol.MCP` | **(Default)** Alias for the default MCP version (currently `2025-06-18`). |
-| `Protocol.TOOLBOX` | The native Toolbox HTTP protocol. |
-| `Protocol.MCP_v20251125` | MCP Protocol version 2025-11-25. |
-| `Protocol.MCP_v20250618` | MCP Protocol version 2025-06-18. |
-| `Protocol.MCP_v20250326` | MCP Protocol version 2025-03-26. |
-| `Protocol.MCP_v20241105` | MCP Protocol version 2024-11-05. |
-
-### Example
-
-If you wish to use the native Toolbox protocol:
-
-```python
-from toolbox_adk import ToolboxToolset
-from toolbox_core.protocol import Protocol
-
-toolset = ToolboxToolset(
-    server_url="http://127.0.0.1:5000",
-    protocol=Protocol.TOOLBOX
-)
-```
-
-If you want to pin the MCP Version 2025-03-26:
-
-```python
-from toolbox_adk import ToolboxToolset
-from toolbox_core.protocol import Protocol
-
-toolset = ToolboxToolset(
-    server_url="http://127.0.0.1:5000",
-    protocol=Protocol.MCP_v20250326
-)
-```
-
-{{< notice tip>}}
-By default, it uses **Toolbox Identity** (no authentication), which is suitable for local development.
-
-For production environments (Cloud Run, GKE) or accessing protected resources, see the [Authentication](#authentication) section for strategies like Workload Identity or OAuth2.
-{{< /notice >}}
-
-## Authentication
-
-The `ToolboxToolset` requires credentials to authenticate with the Toolbox server. You can configure these credentials using the `CredentialStrategy` factory methods.
-
-The strategies handle two main types of authentication:
-*   **Client-to-Server**: Securing the connection to the Toolbox server (e.g., Workload Identity, API keys).
-*   **User Identity**: Authenticating the end-user for specific tools (e.g., 3-legged OAuth).
-
-### 1. Workload Identity (ADC)
-*Recommended for Cloud Run, GKE, or local development with `gcloud auth login`.*
-
-Uses the agent's Application Default Credentials (ADC) to generate an OIDC token. This is the standard way for one service to authenticate to another on Google Cloud.
-
-```python
-from toolbox_adk import CredentialStrategy, ToolboxToolset
-
-# target_audience: The URL of your Toolbox server
-creds = CredentialStrategy.workload_identity(target_audience="https://my-toolbox-service.run.app")
-
-toolset = ToolboxToolset(
-    server_url="https://my-toolbox-service.run.app",
-    credentials=creds
-)
-```
-
-### 2. User Identity (OAuth2)
-*Recommended for tools that act on behalf of the user.*
-
-Configures the ADK-native interactive 3-legged OAuth flow to get consent and credentials from the end-user at runtime. This strategy is passed to the `ToolboxToolset` just like any other credential strategy.
-
-```python
-from toolbox_adk import CredentialStrategy, ToolboxToolset
-
-creds = CredentialStrategy.user_identity(
-    client_id="YOUR_CLIENT_ID",
-    client_secret="YOUR_CLIENT_SECRET",
-    scopes=["https://www.googleapis.com/auth/cloud-platform"]
-)
-
-# The toolset will now initiate OAuth flows when required by tools
-toolset = ToolboxToolset(
-    server_url="...",
-    credentials=creds
-)
-```
-
-### 3. API Key
-*Use a static API key passed in a specific header (default: `X-API-Key`).*
-
-```python
-from toolbox_adk import CredentialStrategy
-
-# Default header: X-API-Key
-creds = CredentialStrategy.api_key(key="my-secret-key")
-
-# Custom header
-creds = CredentialStrategy.api_key(key="my-secret-key", header_name="X-My-Header")
-```
-
-### 4. HTTP Bearer Token
-*Manually supply a static bearer token.*
-
-```python
-from toolbox_adk import CredentialStrategy
-
-creds = CredentialStrategy.manual_token(token="your-static-bearer-token")
-```
-
-### 5. Manual Google Credentials
-*Use an existing `google.auth.credentials.Credentials` object.*
-
-```python
-from toolbox_adk import CredentialStrategy
-import google.auth
-
-creds_obj, _ = google.auth.default()
-creds = CredentialStrategy.manual_credentials(credentials=creds_obj)
-```
-
-### 6. Toolbox Identity (No Auth)
-*Use this if your Toolbox server does not require authentication (e.g., local development).*
-
-```python
-from toolbox_adk import CredentialStrategy
-
-creds = CredentialStrategy.toolbox_identity()
-```
-
-### 7. Native ADK Integration
-*Convert ADK-native `AuthConfig` or `AuthCredential` objects.*
-
-```python
-from toolbox_adk import CredentialStrategy
-
-# From AuthConfig
-creds = CredentialStrategy.from_adk_auth_config(auth_config)
-
-# From AuthCredential + AuthScheme
-creds = CredentialStrategy.from_adk_credentials(auth_credential, scheme)
-```
-
-### 8. Tool-Specific Authentication
-*Resolve authentication tokens dynamically for specific tools.*
-
-Some tools may define their own authentication requirements (e.g., Salesforce OAuth, GitHub PAT) via `authSources` in their schema. You can provide a mapping of getters to resolve these tokens at runtime.
-
-```python
-async def get_salesforce_token():
-    # Fetch token from secret manager or reliable source
-    return "sf-access-token"
-
-toolset = ToolboxToolset(
-    server_url="...",
-    auth_token_getters={
-        "salesforce-auth": get_salesforce_token,   # Async callable
-        "github-pat": lambda: "my-pat-token"       # Sync callable or static lambda
-    }
-)
-```
-
-## Advanced Configuration
-
-### Additional Headers
-
-You can inject custom headers into every request made to the Toolbox server. This is useful for passing tracing IDs, API keys, or other metadata.
-
-```python
-toolset = ToolboxToolset(
-    server_url="...",
-    additional_headers={
-        "X-Trace-ID": "12345",
-        "X-My-Header": lambda: get_dynamic_header_value() # Can be a callable
-    }
-)
-```
-
-### Global Parameter Binding
-
-Bind values to tool parameters globally across all loaded tools. These values will be **fixed** and **hidden** from the LLM.
-
-*   **Schema Hiding**: The bound parameters are removed from the tool schema sent to the model, simplifying the context window.
-*   **Auto-Injection**: The values are automatically injected into the tool arguments during execution.
-
-```python
-toolset = ToolboxToolset(
-    server_url="...",
-    bound_params={
-        # 'region' will be removed from the LLM schema and injected automatically
-        "region": "us-central1",
-        "api_key": lambda: get_api_key() # Can be a callable
-    }
-)
-```
-
-### Usage with Hooks
-
-You can attach `pre_hook` and `post_hook` functions to execute logic before and after every tool invocation.
-
-{{< notice note>}}
- The `pre_hook` can modify `context.arguments` to dynamically alter the inputs passed to the tool.
-{{< /notice >}}
-
-```python
-from google.adk.tools.tool_context import ToolContext
-from typing import Any, Dict, Optional
-
-async def log_start(context: ToolContext, args: Dict[str, Any]):
-    print(f"Starting tool with args: {args}")
-    # context is the ADK ToolContext
-    # Example: Inject or modify arguments
-    # args["user_id"] = "123"
-
-async def log_end(context: ToolContext, args: Dict[str, Any], result: Optional[Any], error: Optional[Exception]):
-    print("Finished tool execution")
-    # Inspect result or error
-    if error:
-        print(f"Tool failed: {error}")
-    else:
-        print(f"Tool succeeded with result: {result}")
-
-toolset = ToolboxToolset(
-    server_url="...",
-    pre_hook=log_start,
-    post_hook=log_end
-)
-```