Skip to main content
The Model Context Protocol (MCP) is a standardized protocol that enables AI agents to interact with external tools and services through MCP servers. Swarms provides first-class support for MCP integration, allowing your agents to dynamically discover and execute tools.

What is MCP?

MCP (Model Context Protocol) provides:
  • Standardized Tool Interface: Unified protocol for tool integration
  • Dynamic Discovery: Automatically discover available tools from MCP servers
  • Multi-Server Support: Connect to multiple MCP servers simultaneously
  • Type Safety: Automatic schema validation for tool calls
  • Flexible Transport: Support for HTTP, WebSocket, and stdio transports

Quick Start

Let the agent do it

The simplest integration: give the agent a URL and it discovers and calls the tools itself.
That is the whole integration. Behind it, the agent builds an MCPManager — reachable as agent.mcp_manager — which handles transport, auth, discovery, and routing.

Several servers at once

The agent sees the union of every server’s tools and each call is routed back to the server that owns it.

Without an agent

MCPManager works standalone when you want tools, not autonomy:
Every method has an async twin: aget_tools, acall_tool, aexecute_tool_calls.

Connection Configuration

Agent-level settings

Authentication and transport can be set directly on the agent and apply to every server it uses:

Per-server settings with MCPConnection

For different credentials per server, pass MCPConnection objects:

Secrets from the environment

Keep keys out of source — both env:NAME and ${NAME} are resolved when the connection is made:

Transport

Transport is auto-detected from the URL. Force it when you need to:
Valid values are streamable_http, sse, and stdio. Hyphenated forms such as streamable-http are normalized automatically.

OAuth 2.1

Full OAuth 2.1 is supported, including PKCE authorization-code flow with RFC 7591 dynamic client registration, headless client credentials, and pre-issued tokens.

Multi-Server Integration

One manager, many servers, automatic routing:
Servers can be added later; doing so invalidates the tool cache so the next fetch picks them up:

Tool Execution

Executing what a model asked for

When an LLM replies with tool calls, hand the response straight to the manager. Each call is routed and the results come back in order — this is the step an Agent performs between turns.
Each result is an envelope:
When a tool returns structured data, its payload arrives as a JSON string in result:

Calling one tool directly

Async

Real-World Example

The agent discovers the server’s tools on startup, decides which to call, executes them, and feeds results back into its own loop.

Error Handling

Failures raise the agent MCP exceptions, and operations retry with exponential backoff up to retry_attempts (default 3) before raising:
Per-result failures do not raise — check the envelope instead:

Inspecting Configuration

to_dict() gives a serializable, secret-redacted view — safe to log:

Caching

Tool schemas are cached per manager after the first fetch:
Build one manager and reuse it rather than constructing one per call.

Best Practices

Connection Pooling

Reuse MCP connections when fetching tools multiple times

Timeout Configuration

Set appropriate timeouts based on server response times

Error Recovery

Implement fallback strategies for MCP server failures

Verbose Logging

Enable verbose mode during development for debugging

Troubleshooting

Common Issues

Connection Timeouts
Authentication Failures
Tool Not Found
Agent Not Using the Tools

Next Steps

Model Providers

Configure different LLM providers

Custom Tools

Create your own tool integrations