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
MCPServerSpec.stdio / MCPServerSpec.http. Fault isolation, listChanged auto-refresh, conflict resolution.Server specs + registrylist_resources / read_resource · list_prompts / get_prompt · sampling_handler= for server-initiated completions.Resources, prompts + samplingWhat 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.