ToolSpec objects, and wraps each one in a FunctionTool — so MCP tools work just like native QitOS tools.
Step 1: Connecting to an MCP server
QitOS ships two transport implementations. For most local MCP servers that run as command-line processes, useMCPServerStdio:
MCPServerStreamableHttp:
connect(). After connecting, you can list available tools:
MCPToolInfo returned by list_tools() carries name, description, and input_schema.
Step 2: Bridging MCP tools into QitOS
Themcp_server_to_function_tools function converts every tool on a connected MCP server into a FunctionTool instance:
FunctionTool wraps a remote MCP call. When the tool is executed, QitOS sends a tools/call JSON-RPC request to the MCP server and returns the result.
You can add a name prefix to disambiguate tools when bridging multiple servers into the same registry:
ToolRegistry just like any other tool:
Step 3: Filtering tools
MCP servers often expose many tools, but your agent may only need a subset.ToolFilter controls which tools are bridged:
Allow only specific tools:
- If
filter_funcis set, its result is authoritative. - If
allowed_tool_namesis set, only names in the set pass. - If
blocked_tool_namesis set, names in the set are excluded. - Otherwise the name passes (no filtering).
Step 4: Async lifecycle
MCP server connections hold resources (subprocesses, HTTP clients) that must be cleaned up. Always pairconnect() with cleanup():
MCPServerStdio.cleanup() terminates the subprocess (first SIGTERM, then SIGKILL after a 5-second timeout). MCPServerStreamableHttp.cleanup() closes the HTTP client session.
For the full integration pattern with an agent, see the complete example:
await server.cleanup() when the agent session ends.
What’s next
@function_tool API
Learn the decorator-based way to create native QitOS tools from Python functions.
Build your first agent
Use bridged MCP tools inside an AgentModule with a real LLM loop.
