2.5 KiB
2.5 KiB
Integration Targets
These are the main ways to integrate pyro-mcp into an LLM application.
Recommended Default
Use vm_run first.
That keeps the model-facing contract small:
- one tool
- one command
- one ephemeral VM
- automatic cleanup
Only move to lifecycle tools when the agent truly needs VM state across multiple calls.
OpenAI Responses API
Best when:
- your agent already uses OpenAI models directly
- you want a normal tool-calling loop instead of MCP transport
- you want the smallest amount of integration code
Recommended surface:
vm_run
Canonical example:
MCP Clients
Best when:
- your host application already supports MCP
- you want
pyroto run as an external stdio server - you want tool schemas to be discovered directly from the server
Recommended entrypoint:
pyro mcp serve
Starter config:
- examples/mcp_client_config.md
- examples/claude_desktop_mcp_config.json
- examples/cursor_mcp_config.json
Direct Python SDK
Best when:
- your application owns orchestration itself
- you do not need MCP transport
- you want direct access to
Pyro
Recommended default:
Pyro.run_in_vm(...)
Examples:
Agent Framework Wrappers
Examples:
- LangChain tools
- PydanticAI tools
- custom in-house orchestration layers
Best when:
- you already have an application framework that expects a Python callable tool
- you want to wrap
vm_runbehind framework-specific abstractions
Recommended pattern:
- keep the framework wrapper thin
- map framework tool input directly onto
vm_run - avoid exposing lifecycle tools unless the framework truly needs them
Concrete example:
Selection Rule
Choose the narrowest integration that matches the host environment:
- OpenAI Responses API if you want a direct provider tool loop.
- MCP if your host already speaks MCP.
- Python SDK if you own orchestration and do not need transport.
- Framework wrappers only as thin adapters over the same
vm_runcontract.