pyRPCpyRPC’s local MCP server introspects your code at runtime. That means it has to import your routers, which means it needs to know how your application starts. This post walks through adding MCP to FastAPI, Django, Flask, or any ASGI/WSGI application in five concrete steps.
Prerequisites
You need a pyrpc.json with backend.framework and backend.entrypoint set. These tell pyRPC how to discover your procedures. If you ran the setup wizard, these are already populated. If not, add them manually:
{
"backend": {
"framework": "fastapi",
"entrypoint": "app.main:app"
}
}Step 1: add the MCP dependency
The MCP SDK is an optional dependency. Add it with the mcp extra:
uv add "pyrpc-core[mcp]"This pulls in the MCP Python SDK alongside pyRPC core. No other packages are needed.
Step 2: register with your agent
Each agent has a different config format. The pyrpc mcp command handles this automatically, but here is what it writes so you understand the surface:
Claude Code gets an entry in .claude/settings.json under mcpServers. The command is pyrpc mcp and the transport is stdio.
Cursor gets an entry in .cursor/mcp.json with the same command shape.
VS Code gets an entry in .vscode/mcp.json with a type: "stdio" field.
Step 3: verify with introspect_project
Once the server is registered, ask your agent to introspect the project. It will call the introspect_project tool, which imports your routers and returns the full procedure tree. If the agent can describe your endpoints without you telling it anything, the integration is working.
Step 4: validate payloads with check_call
Before generating any RPC call, have the agent run check_call against a procedure. This validates the payload against the procedure’s pydantic schema without executing anything. It is the safety net that keeps the agent from guessing at types.
Step 5: regenerate clients with run_codegen
When you add or modify procedures, ask the agent to run run_codegen. This regenerates the TypeScript client, hooks, and types to match your current router surface. The agent sees the diff and can update any call sites automatically.
The setup flow
pyrpc.json
|
v
import entrypoint
|
v
registry discovers routers
|
v
MCP server exposes tools
|
v
agent reads procedure tree
Framework-specific gotchas
FastAPI is the simplest case. The entrypoint points to the module containing your app object. Routers are auto-discovered through FastAPI’s own router tree. If you use include_router, pyRPC follows the chain.
Django requires you to set types_module in pyrpc.json. This is the module whose import side-effects register your procedures with the pyRPC registry. Without it, the server imports the entrypoint but finds zero procedures.
Flask works the same way as Django: manual registration is required. Your entrypoint must import the module that calls @pyrpc.procedure decorators. If the registry is empty, check that your import chain actually reaches the decorated functions.
Troubleshooting
“No procedures found” means the entrypoint was imported but the registry is empty. For Django and Flask, verify that types_module is set and points to a module that actually imports your procedure decorators. For FastAPI, check that your routers are included in the app tree before the MCP server reads them.
“ModuleNotFoundError” means the entrypoint path is wrong or a dependency is missing. Run uv run python -c "import app.main" to verify the import works standalone.
“MCP SDK not installed” means you forgot the extra. Re-run uv add "pyrpc-core[mcp]" and check that uv pip list | grep mcp shows the SDK.
“Tool call failed” in the agent usually means the stdio process crashed. Check stderr from pyrpc mcp directly. Import errors and missing dependencies are the usual suspects.