Connect tools once
MCP integration that is ready for real users
Register MCP servers, assign tools to the right agents, forward the user’s auth context, and execute every call on the server—without turning your frontend into an orchestrator.
- MCP integration
- MCP server
- MCP tools
- build MCP server
- Model Context Protocol
One protocol, every system
MCP integration: connect AI agents to any external service
The Model Context Protocol gives your agents a standard way to act on the outside world — CRMs, databases, ticketing systems, internal APIs. Register a server from the curated catalog or point at your own, assign its tools to the right agents, and the runtime executes every call server-side. Your frontend never becomes an orchestrator.
An agent that can only talk is a demo. An agent that can look up the order, update the record, and open the ticket — under your permissions — is a product.
Pick the right pipe
MCP server transports: HTTP, SSE, streamable-HTTP, and stdio
SyntheticBrew speaks all four MCP transports, so it connects to remote hosted servers and locally launched processes alike.
| Transport | What it is | When to use it |
|---|---|---|
| HTTP | Plain request/response tool calls. | Stateless tool servers and simple internal APIs. |
| SSE | Server-sent events transport from the earlier MCP spec. | Existing remote MCP servers built on the SSE generation. |
| streamable-HTTP | The current MCP streaming transport over standard HTTP. | The default for new remote MCP servers. |
| stdio | The server runs as a local process and speaks over stdin/stdout. | Packaged and community servers you run beside the engine — Docker-launched MCP servers run over stdio. |
Identity travels with the call
MCP tools that keep your auth context attached
Most agent stacks execute tools as an anonymous service account — which means someone rebuilds authorization inside the agent layer, badly. SyntheticBrew forwards the caller's Authorization, organization, user, and custom headers into every tool call, so your existing RBAC keeps enforcing itself and your tool server always knows who is really asking.
- Per-request forwarding — headers travel from the incoming request into the tool call, per user, per call.
- Confirmation gates — mark consequential tools
confirm_beforeand execution pauses until the user explicitly approves. - Per-agent scoping — each agent sees only the tools assigned to it through flow config, never the whole catalog.
Tool boundaries are the core of agent security — the full model is on the AI agent security page.
mcp_servers:
orders-api:
transport: streamable-http
url: https://internal.example.com/mcp
forward_headers: # per-request, into every tool call
- Authorization
- X-Org-Id
- X-User-Id
agents:
support-agent:
tools: [lookup_order, delete_devices, issue_refund]
confirm_before: # pause for explicit approval
- delete_devices
- issue_refund Bring your own tools
Build an MCP server in any language
Your most valuable tools are the ones only you can write — the ones that wrap your domain API. Because MCP is an open protocol, you can build a tool server in any language with an MCP SDK, run it over any of the four transports, and register it like any catalog server. Prefer to skip the protocol entirely? Plain HTTP tools are supported too: describe the endpoint and the agent can call it.
This is how ecommerce teams wire agents to order, inventory, and refund APIs — see SyntheticBrew for ecommerce, or compare integration approaches in SyntheticBrew vs Dify.
Built for bad days
Model Context Protocol in production: timeouts and circuit breakers
External services fail, and an agent platform has to assume they will. Every tool call gets a 30-second default timeout so a hung server cannot stall a conversation. A circuit breaker opens after 3 failures in a 60-second window and resets after 120 seconds, isolating the failing integration while everything else keeps working. Tool calls are tracked in the audit log — plus Prometheus metrics with an Enterprise Edition license — so you see the failure before your users report it.
Keep exploring
Related capabilities
Questions
MCP integration: common questions
What is MCP (Model Context Protocol)?
MCP is an open protocol that standardizes how AI agents call external tools. A tool server exposes typed operations — look up an order, query a database, create a ticket — and any MCP-capable runtime can use them. In SyntheticBrew you register a server once and assign its tools to exactly the agents that need them.
Which MCP transports does SyntheticBrew support?
Four: HTTP, SSE, streamable-HTTP, and stdio. That covers hosted remote servers on either MCP streaming generation, plus local servers launched as processes — including Docker-launched MCP servers, which run over stdio.
How do MCP tools respect my existing permissions?
Through header forwarding. SyntheticBrew forwards the Authorization header plus organization, user, and custom headers from the incoming request into every tool call, so your tool server sees the real end user and your existing RBAC keeps enforcing itself. The runtime never becomes a super-user.
What happens when an MCP server hangs or goes down?
Every tool call has a 30-second default timeout, and a circuit breaker opens after 3 failures within a 60-second window, then retries after a 120-second reset — so one failing integration degrades gracefully instead of stalling every conversation.
Connect the tools. Keep the permissions.
Register your first MCP server in Cloud or self-hosted and let agents act on your systems — with your RBAC still in charge.