Synth as an MCP Server: Bridging Synthesis and Protocol
MCP — the Model Context Protocol — defines how AI agents communicate with external tools. Our open-source core generates tools on demand from natural language intent. These two capabilities are complementary by design: MCP provides the universal connector, and our open-source core provides the governed tool factory. Combining them means any MCP-compatible AI client can request tool synthesis through a standard protocol, with human oversight and risk-based approval at every step.
Our open-source core ships with a built-in MCP server implementation. This is not a third-party integration or a community plugin — it is a first-class feature of the open-source core package. When you run the open-source core as an MCP server, it exposes its synthesis capabilities through the standard JSON-RPC 2.0 interface that MCP defines, communicating over stdin/stdout as MCP specifies for local server connections.
The MCP Server Interface
The open-source core's MCP server exposes two tools through the standard MCP tool discovery mechanism. When an MCP client connects and requests the server's capabilities, it receives descriptions of these tools along with their parameter schemas.
synth_synthesize
The primary tool. synth_synthesize accepts three parameters: an intent string describing what the tool should do in natural language, an optional capabilities array specifying what permissions the synthesized tool is allowed to use (network access, filesystem access, shell execution), and an optional dry_run boolean that, when true, generates and returns the tool code without executing it.
When called, the open-source core synthesizes a tool from the intent, evaluates its risk level (LOW, MEDIUM, or HIGH based on the capabilities it requires and the operations it performs), and either returns the code for review (dry run) or proceeds through the approval flow before execution (live run).
synth_list_capabilities
A discovery tool that returns the list of capabilities the open-source core recognizes and can constrain. This allows MCP clients to understand what permission scopes are available before constructing synthesis requests. The returned capabilities include their names, descriptions, and risk classifications.
Configuration: The.mcp.json File
MCP clients discover and launch MCP servers through configuration files. For Claude Code, the configuration lives in .mcp.json in your project root. For other MCP-compatible clients, the configuration format may vary, but the server specification is the same.
A typical MCP server configuration for the open-source core looks like this:
{
"mcpServers": {
"synth": {
"command": "synth",
"args": ["mcp-server"],
"env": {
"ANTHROPIC_API_KEY": "your-key-here",
"SYNTH_PROVIDER": "anthropic"
}
}
}
}The command field specifies the synth binary. The args field tells it to start in MCP server mode. The env field passes configuration through environment variables: the LLM provider and API key for synthesis.
For local development with Ollama, the configuration changes minimally:
{
"mcpServers": {
"synth": {
"command": "synth",
"args": ["mcp-server"],
"env": {
"SYNTH_PROVIDER": "ollama",
"SYNTH_MODEL": "llama3.2"
}
}
}
}No API key needed. The synthesis engine runs locally through Ollama. Everything else — the MCP interface, the approval flow, the risk assessment — works identically.
The Approval Strategy
The SYNTH_APPROVAL_STRATEGY environment variable controls how the MCP server handles synthesized tools before execution. The risk-based strategy implements tiered approval based on the synthesized tool's risk assessment.
LOW risk tools — those that use only standard library functions, perform no I/O, and have no side effects — are auto-approved and executed immediately. The MCP client receives the result without interruption. A tool that calculates a date, formats a string, or performs arithmetic falls into this category.
MEDIUM risk tools — those that require network access or filesystem reads — return their synthesized code and risk assessment as informational content to the MCP client. The client (and the human using it) can review the code, understand what it will do, and decide whether to approve execution through a follow-up request. This is the default behavior for tools that fetch data from APIs, read configuration files, or query databases.
HIGH risk tools — those that write to the filesystem, execute shell commands, modify external state, or handle credentials — follow the same review flow as MEDIUM but with additional warnings and a stronger recommendation for manual review. The synthesized code is presented with highlighted risk factors and an explicit description of the potential impact.
Using the Open-Source Core in Claude Code
With the .mcp.json configuration in place, Claude Code automatically discovers the open-source core's MCP server and makes its tools available. When you interact with Claude Code, it can decide to use the open-source core's synthesis capabilities just as it would use any other MCP tool.
In practice, this means you can ask Claude Code to perform tasks that require capabilities beyond its built-in tools, and the open-source core will synthesize the appropriate tool on the fly. Need to fetch data from a specific API? The open-source core synthesizes the HTTP client. Need to parse a proprietary file format? The open-source core generates the parser. Need to query a database with a specific schema? The open-source core constructs the query client.
The key difference from using Claude Code's built-in capabilities is governance. Every tool the open-source core synthesizes goes through the risk assessment and approval flow. You see exactly what code will run. You see what capabilities it requires. You approve or reject before execution. This governance layer applies regardless of which MCP client triggers the synthesis — Claude Code, Cursor, or any other MCP-compatible tool.
Combining MCP's Reach with the Open-Source Core's Governance
The MCP ecosystem is growing rapidly. Thousands of MCP servers cover databases, SaaS platforms, cloud providers, developer tools, and internal services. Each of these servers is a pre-built, persistent integration. The open-source core complements this ecosystem by handling the cases where a pre-built MCP server does not exist for what you need.
The two approaches are not competing alternatives — they are complementary layers. Use pre-built MCP servers for well-known integrations with established packages (Postgres, Slack, GitHub). Use the open-source core's synthesis for the long tail of integrations that do not have pre-built servers, for one-off tasks that do not justify a permanent server, and for any scenario where you want human review of the exact code that will execute.
The MCP protocol makes both approaches composable. An MCP client can have connections to pre-built MCP servers and to the open-source core simultaneously. The AI agent decides which to use based on the task at hand. Pre-built servers handle the routine. The open-source core handles the novel. And every synthesized tool goes through governed approval before touching any system.
The Protocol and the Factory
MCP solved the universal connector problem: one protocol for AI-to-tool communication, supported by every major AI lab and tooling vendor. The open-source core solves the tool creation problem: generate purpose-built tools on demand instead of maintaining an ever-growing catalog of pre-built integrations. Running the open-source core as an MCP server brings these two solutions together through the protocol that the ecosystem has standardized on.
The configuration takes five minutes. The .mcp.json file is a few lines. The result is governed tool synthesis available inside whatever MCP-compatible development environment you already use. No new tools to learn. No new interfaces to adapt to. Just a new MCP server that happens to synthesize other tools on demand, with risk-based approval at every step.
The Open-Source Core Within the Broader Platform
The open-source core as an MCP server is one piece of the platform's MCP ecosystem. MCP Workshop provides a full development environment for creating, testing, and deploying MCP servers with hot-reload and zero-downtime deployment — so you can build custom MCP servers for your internal systems alongside the open-source core's synthesis. CodeMode gives you VS Code in the browser with AI pair programming and K8s sandbox isolation, making MCP server development a first-class workflow rather than a local-only experience.
For teams that need to integrate the open-source core and custom MCP servers into automated pipelines, the agenticode-cli provides CI/CD integration that lets you test, validate, and deploy MCP servers as part of your existing build process. The result is a complete MCP development lifecycle — from prototyping in MCP Workshop, to coding in CodeMode, to deploying through agenticode-cli — with the open-source core providing governed tool synthesis wherever a pre-built server does not exist.