Skip to Content
DocsMCPOverview

MCP

The framework speaks the Model Context Protocol  natively. Plug stdio or HTTP MCP servers in directly; the agent loop treats them like any other ToolHost.

from loomflow import Agent from loomflow.mcp import MCPRegistry, MCPServerSpec registry = MCPRegistry([ MCPServerSpec.stdio( name="git", command="uvx", args=["mcp-server-git", "--repo", "/Users/me/code/myrepo"], ), MCPServerSpec.http( name="hosted", url="https://example.com/mcp/", headers={"Authorization": "Bearer ..."}, ), ]) agent = Agent( "You are a coding assistant.", model="claude-opus-4-7", tools=registry, )

Tool name conflicts across servers are auto-disambiguated: git.commit and github.commit if both servers expose commit; just commit if only one does. Either form is accepted at call time.

Read more

What MCP gets you

  • Language-agnostic tools. MCP servers can be Python, Node, Rust. Anything. The framework launches them as subprocesses (stdio) or talks to them over HTTP.
  • Reusable tool servers. The MCP ecosystem already ships servers for git, filesystem, GitHub, Slack, browser, Figma. You don’t re-implement what already exists.
  • The full protocol surface. Beyond tools, the registry aggregates resources and prompts across servers, refreshes tool lists automatically when a server announces listChanged, and can answer server-initiated sampling requests with a model you choose.
  • Fault isolation. One dead server never takes down the others — its tools are skipped, its name lands in registry.unavailable, and it heals on the next refresh. See Server specs + registry.
  • Auth and rate limiting on the server. Hosted MCP servers authenticate the framework via headers; the agent never sees the underlying credentials.

Install

pip install 'loomflow[mcp]'

Pulls in the official mcp SDK + httpx.

Compose with built-in tools

MCPRegistry is just a ToolHost. Mix MCP servers with regular @tool functions by wrapping the registry with ExtendedToolHost, which combines a base host with extra in-process tools:

from loomflow import Agent, tool from loomflow.mcp import MCPRegistry, MCPServerSpec from loomflow.architecture.tool_host_wrappers import ExtendedToolHost @tool async def custom_search(q: str) -> str: """My custom search tool.""" ... mcp_registry = MCPRegistry([ MCPServerSpec.stdio("git", "uvx", ["mcp-server-git"]), MCPServerSpec.stdio("fs", "uvx", ["mcp-server-filesystem", "--root", "."]), ]) # Combine the MCP registry with the custom tool into one host agent = Agent( "...", model="claude-opus-4-7", tools=ExtendedToolHost(mcp_registry, [custom_search]), )

MCP vs in-process tools. Use MCP when you want a third-party server, language-agnostic tooling, or a tool that runs in a separate process for isolation. Use in-process @tool when the tool is yours and shares the agent’s runtime. Usually faster and simpler.

Many servers = heavy context. Every server’s tool schemas ship on every model call; a handful of typical servers can add tens of thousands of tokens per turn. Enable tool search to stub rarely-used definitions and hydrate them on first use.

Last updated on