pyRPCpyRPC started with a simple observation: the tools developers use to build APIs were designed for humans, and agents are not humans. That observation led to MCP support, structured introspection, and validation-without-execution. But those are local decisions. The bigger picture is where the entire ecosystem is heading.
Protocol convergence
MCP is becoming the standard interface between AI agents and developer tools. Prisma added MCP for database schema access. Better Auth added MCP for authentication flows. Neon, Vercel, Cloudflare, and dozens of other platforms now expose MCP servers. The pattern is consistent: instead of building custom integrations for every agent framework, platforms expose a single protocol that every agent understands. pyRPC fits naturally into this trend. The local MCP server for your procedures sits alongside Prisma's server for your database and Vercel's server for your deployments.
The two-server pattern
The emerging architecture is two MCP servers working together: a local server for your code and a remote server for knowledge. The local server imports your project, returns your schemas, validates your calls. The remote server provides documentation, examples, best practices, and community knowledge. pyRPC supports both. The local server runs in your process, trusts your code, and never executes. The remote server provides the docs, answers questions about pyRPC itself, and helps agents understand patterns. Together they give an agent everything it needs without custom glue code.
Agent
|
+--> Local MCP Server (pyrpc-core[mcp])
| - imports YOUR code
| - returns YOUR procedures
| - validates YOUR calls
| - runs in YOUR process
|
+--> Remote MCP Server (pyrpc-mcp)
- serves pyRPC documentation
- answers "how do I" questions
- provides examples and patterns
- runs on pyrpc.comAgent-first design
Tools designed for agents share three properties: they are read-only by default, they return structured data, and they compose. pyRPC's MCP tools follow all three. introspect_project returns JSON. check_call returns JSON with per-parameter errors. run_codegen defaults to dry_run, which is read-only until explicitly approved. Each tool does one thing, and agents chain them together: discover, validate, generate, verify. This composability is what makes agents effective. They do not need a single tool that does everything. They need small tools that do one thing correctly and return data they can reason about.
The registry future
The next step after protocol convergence is discoverability. MCP servers will be registered in a central directory using a standard format, like server.json. An agent will be able to say "I need a server for this project" and find the right MCP server automatically. pyRPC already produces the metadata for this: the MCP server declares its capabilities, its tools, and its requirements. When directories exist, pyRPC projects will register automatically.
The evolution timeline
2023 2024 2025 2026+
| | | |
Custom MCP Protocol Two-Server Registry
Integrations Emerges Pattern Ecosystem
| | | |
Per-agent Standard Local + Central
code for tool Remote directory
each tool interface servers of servers
| | | |
Brittle, Better, Composable, Discoverable,
hard to but still trustworthy, composable,
maintain manual setup auto-discover auto-configureWhat is missing
Three pieces are not yet solved. Authentication is the first: MCP's spec includes OAuth 2.0 support, but most implementations have not shipped it. Streaming is the second: agents need incremental results, not one-shot responses, and MCP does not yet standardize that. Multi-modal is the third: agents increasingly work with images, audio, and video, and the protocol does not carry those payloads yet. Each of these will be solved as adoption grows.
The developer experience shift
The role of the developer is changing. Instead of writing every line of code, you review agent-generated code. Instead of debugging by reading logs, you debug by reading structured validation errors. Instead of maintaining API documentation, you register an MCP server that returns live schemas. The work shifts from creation to curation, from authoring to reviewing, from "did I type this correctly" to "did the agent understand my intent." This is not less work. It is different work, and the tools need to support it.
The trust infrastructure
As agents become more capable, the trust requirements grow. Verified servers that prove their identity, signed manifests that prove their contents, audit logs that prove what happened. pyRPC's design aligns with this future: the local server runs in your process with your permissions, the validation is deterministic, and every tool call is logged. When the ecosystem demands signed manifests and audit trails, the architecture is ready. The trust infrastructure is not a feature to add later. It is the foundation everything else is built on.