Business data
CRM, ERP, orders, documents, analytics, and internal knowledge.
Model Context Protocol · rmcp 2.2
Connect your agents to the systems where work happens.
MCP lets another program publish tools, information, and reusable prompts through a standard contract. ADK-Rust turns those capabilities into typed agent tools, exposes the wider protocol, and can manage a changing fleet of local MCP servers while your product is running.
ToolsResourcesPromptsCompletionSubscriptionsElicitationTasksStdioStreamable HTTP
ADK-Rust MCP architecture
Add or remove MCP capabilities from your agent.
Your agent uses MCP capabilities just like any other ADK-Rust tool. MCP connects it to each server, while every server remains responsible for its own data, rules, and actions.
01
Agent product
The experience asking for work.
Agent or workflow
Chooses a capability from the tools it has been allowed to see.
ADK policy
Applies approval, authorization, guardrails, and audit around the call.
Toolset
02
ADK-Rust MCP client
The typed adapter inside the runtime.
McpToolset
Discovers tools and preserves the server's schemas and result content.
Protocol APIs
Resources, prompts, completion, subscriptions, elicitation, and tasks.
Server manager
Changes and supervises a registry of local stdio connections.
MCP
03
Connection boundary
Choose the transport that matches ownership.
Local stdio
ADK-Rust starts a native binary or other child process and owns its session.
Streamable HTTP
Connect to an independently hosted service with headers, auth, and timeouts.
Contract
04
MCP servers
Each server publishes only what it owns.
Tools
Actions
Resources
Context
Prompts
Templates
Tasks
Long work
each server remains responsible for its own credentials, data access, side effects, and service health
Developer systems
Source control, build tools, browsers, sandboxes, and coding environments.
External services
Payments, communications, search, maps, and partner APIs.
Specialist runtimes
Media generation, spreadsheets, computer use, and domain-specific services.
Start with the problem
Why do we need MCP?
An AI agent becomes useful when it can reach the systems that hold real information and perform real work. Without a shared protocol, every database, SaaS product, browser tool, internal service, and specialist runtime needs a custom adapter. Those adapters repeat discovery, schemas, transport, errors, authentication, and lifecycle code.
MCP puts a stable contract around that boundary. A server describes what it offers and how to call it. A client discovers that catalog at runtime. The agent application can then select a reviewed capability without importing the server's implementation or receiving its private credentials.
ADK-Rust connects that contract to the same Tool and Toolset abstractions used by native Rust tools. The model can work with MCP capabilities through its normal agent loop, while the application keeps provider-specific schema conversion, approval, sessions, telemetry, and operating policy around the call.
Tool
Something the agent can ask a server to do
A tool has a name, a useful description, an input schema, and optionally an output schema. Examples include reading an order, searching a repository, updating a ticket, or generating a spreadsheet.
Resource
Context the agent or product can read
A resource gives information a stable URI. It can represent a document, policy, database record, catalog, or generated result without pretending that reading data is an action.
Prompt
A reusable message template published by the server
A prompt can capture the right instructions and inputs for a task owned by the server's domain, such as investigating an order or reviewing a deployment.
Elicitation
A request for missing human input
During a tool call, a server can ask the client to present a form or open an approved URL. The application remains responsible for consent and for validating the answer.
Dynamic MCP management
Capabilities can change while the product keeps running.
An agent product may serve several tenants, workspaces, or operating modes. The useful MCP servers can change when a workspace opens, an administrator enables an integration, a credential rotates, or a specialist process is upgraded.
`McpServerManager` keeps that lifecycle in the application instead of forcing every server definition into startup code. It is designed for local stdio child processes; independently hosted HTTP services remain application-owned connections.
01
Load the registry
Read mcp.json-compatible definitions or construct them in Rust. Disabled servers stay registered without starting.
02
Start and negotiate
Spawn each enabled child and complete the MCP handshake before its capabilities become visible.
03
Discover safely
List tools from running servers, filter the published surface, and prefix only names that collide.
04
Change it live
Add, update, enable, disable, or remove a server without rebuilding the agent application.
05
Supervise the session
Detect a closed connection and apply the server's bounded exponential-backoff restart policy.
06
Save and close
Persist the current registry atomically, cancel MCP sessions, wait for the grace period, and drop child transports.
Practical sequence
Resolve a damaged order with three independently owned capabilities.
The model does not receive database credentials or private API clients. It receives a reviewed catalog of tools and resources. ADK-Rust keeps approval around the consequential replacement call.
Support agent01Discover approved CRM, order, and policy toolsMCP client
MCP client02tools/list over the negotiated connectionsThree MCP servers
Support agent03read_order { order_id: ORD-1042 }Orders server
Orders server04Structured order and delivery evidenceSupport agent
Support agent05Read the current damaged-goods policy resourcePolicy server
Support agent06request_replacement after ADK approvalCRM server
CRM server07Replacement ID, status, and audit evidenceSupport agent
Current protocol surface
ADK-Rust uses the wider MCP protocol, not only tool calls.
The direct ADK-Rust APIs cover the capabilities an agent product most often needs: discover and call tools, read resources, resolve prompts, request argument suggestions, subscribe to changing resources, answer elicitation requests, and follow a negotiated long-running tool task.
For advanced server authoring, custom client handlers, notifications, transports, authorization work, and protocol extensions, adk_tool::mcp::rmcp re-exports the exact official SDK version used inside the framework. This avoids mixing incompatible protocol types in one application.
01
Agent-facing adapters
Use MCP capabilities inside ordinary ADK-Rust agent and tool flows.
tools/list + tools/call
raw input/output schemas
text, image, audio, resources
tool filters
provider normalization
02
Context and guidance
Read the rest of the catalog instead of reducing MCP to tool calls.
resources + templates
prompts/list + get
prompt completion
resource completion
resource subscriptions
03
Interactive and long work
Support protocol conversations that continue beyond one immediate response.
form elicitation
URL elicitation
negotiated tool tasks
tasks/get + result
bounded cancellation
04
Connections
Choose local process ownership or a separately hosted service.
local stdio
Streamable HTTP
custom headers
bearer + API key
expired-session recovery
A deliberate compatibility boundary: MCP sampling, roots, and logging are deprecated upstream through SEP-2577. ADK-Rust keeps sampling behind an opt-in compatibility feature; it is not presented as the recommended architecture for a new product.
Working example
Manage MCP servers from startup to shutdown.
An application may need different MCP capabilities for each workspace, customer, or task. Hard-coding every server at startup makes those changes difficult. McpServerManager gives the application one place to start local MCP servers, combine their tools, change their configuration, monitor their connections, and close them cleanly.
This example begins with one configured server named local-tools. The agent can discover and call its echo tool. The application then adds a second server, enables it, replaces its running configuration, saves the updated registry, and removes it again. Every change uses the same APIs available to an administration screen or configuration service.
The example runs entirely on your machine. The Rust executable starts a copy of itself as the MCP child server, so the handshake, tool discovery, tool call, restart, persistence, and shutdown are real. No model, Node.js package, API key, or internet connection is required.
Start one server
Load local-tools from an mcp.json-compatible configuration, start its child process, complete the MCP handshake, and discover its echo tool.
Add another server
Register standby-tools as disabled, then enable and start it when the application decides that capability should become available.
Replace it safely
Update the running server definition. The manager restarts it with the new configuration and can restore the previous definition if replacement startup fails.
Save and shut down
Write the live registry back to JSON, disable and remove the extra server, then close every MCP session and child process cleanly.
manager.rsRUST
let manager = McpServerManager::from_json(&config)?
.with_health_check_interval(Duration::from_secs(15));
manager.start_server("local-tools").await?;
manager.start_monitoring();
manager
.add_server("standby-tools".into(), standby)
.await?;
manager.enable_server("standby-tools").await?;
manager.start_server("standby-tools").await?;
manager
.update_server("standby-tools", replacement)
.await?;
manager.save_json_file("mcp.json").await?;
manager.shutdown().await?;terminalREAL OUTPUT
$ cargo run --manifest-path examples/mcp_manager/Cargo.toml
1. Loaded local-tools from mcp.json-compatible configuration
status: Running
2. Discovered 1 tool: echo
3. Called the real child server
response: {"output":"MCP server replied: dynamic MCP is running"}
4. Added standby-tools at runtime: Disabled
enabled and started: Running
5. Reconfigured the running server and restarted it safely
6. Saved the live registry
7. Disabled, removed, and shut down every child serverClient, manager, or server
Choose the ADK-Rust MCP capability you need.
Most agent applications are MCP clients. They connect to an existing server and make selected tools available to an agent. Products that allow workspace or administrator integrations can place local stdio connections behind the manager. Teams publishing a new capability use the re-exported rmcp server APIs and then test the server from an ADK-Rust client.
Your situation
Use
Why
One known MCP service
McpToolset
One initialized connection, filters, tools, resources, prompts, completion, subscriptions, elicitation, and tasks.
A changing set of local integrations
McpServerManager
Runtime add, update, enable, disable, remove, save, monitor, restart, aggregation, and collision-safe names.
A separately hosted MCP service
McpHttpClientBuilder
Streamable HTTP with request timeout, headers, bearer or API-key injection, and expired-session recovery.
You own the capability being published
adk_tool::mcp::rmcp
Build the MCP server with the official SDK version already aligned with ADK-Rust.
Production design
Deploy MCP safely.
MCP makes discovery and communication consistent. It does not decide which systems an agent should reach, which actions require approval, how credentials are issued, or what should happen when a dependency fails. Those remain product and platform decisions.
Choose the server boundary
Create a server around a coherent capability owned by one team or system. Avoid one enormous server whose tools span unrelated credentials and risk levels.
Publish a small surface
Filter tools before the model sees them. Keep read operations distinct from writes, payments, deletion, deployment, and other consequential actions.
Keep approval in ADK-Rust
mcp.json autoApprove is preserved for compatibility; it does not bypass the framework's authorization, confirmation handlers, or application policy.
Match transport to ownership
Use stdio when your application owns the local child process. Use Streamable HTTP when another deployment owns availability, identity, and scaling.
Treat content as untrusted
Tool descriptions, schemas, resource content, and results cross a system boundary. Validate arguments, bound result sizes, and protect model context from hostile instructions.
Operate the dependencies
Set connection and task timeouts, record lifecycle changes, probe the business dependency separately, and decide how the product behaves when one server is unavailable.
Authentication detail: the HTTP builder supports bearer tokens, custom API-key headers, and a fixed OAuth 2.0 client-credentials token endpoint. Full MCP authorization discovery, browser authorization, PKCE, and resource-indicator negotiation should use the official rmcp authorization APIs or your identity layer.
Connect the useful systems
Give one agent one carefully chosen capability, then grow the network.
Begin with a server you understand, filter its catalog, call one read-only tool, and inspect the complete result. Add write actions, dynamic management, remote services, elicitation, and long-running tasks when the product has a clear reason for each one.