--- title: "Adding MCP to Bifrost: Letting AI Models Use External Tools" url: https://daily.dev/posts/adding-mcp-to-bifrost-letting-ai-models-use-external-tools-g2uzzqaro source_url: https://daily.dev/posts/adding-mcp-to-bifrost-letting-ai-models-use-external-tools-g2uzzqaro type: freeform source: "MCP: Model Context Protocol" author: "Pranay Batta" published: 2026-01-19T21:30:14.243Z updated: 2026-01-20T10:16:09.686Z tags: ["ai", "security", "architecture", "golang"] reading_time: 6 upvotes: 0 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Adding MCP to Bifrost: Letting AI Models Use External Tools **[MCP: Model Context Protocol](https://daily.dev/sources/mcp)** · [@pranaybatta](https://daily.dev/pranaybatta) · 6 min read · 0 upvotes · 0 comments ## Summary Model Context Protocol (MCP) standardizes how AI models interact with external tools like databases, filesystems, and APIs. Bifrost implements MCP with a security-first approach, requiring explicit approval for tool execution by default. It supports four connection types (InProcess, STDIO, HTTP, SSE) with varying latency profiles, offers request-level filtering to control tool access, and provides two execution patterns: agent mode for step-by-step oversight and code mode for batch operations. The implementation includes comprehensive observability with audit trails, metrics, and distributed tracing. ## Content We shipped Model Context Protocol (MCP) support in [Bifrost](https://github.com/maximhq/bifrost) a few weeks ago, and I wanted to walk through why we built it and how it works under the hood. ## The Problem We Were Solving AI models are great at reasoning and generating text, but they hit a wall when you need them to actually *do* things. Want your agent to search a database? Read files? Query an API? You'd traditionally write custom code for each integration, which gets messy fast. MCP standardizes this. Instead of building one-off integrations, you connect MCP servers that expose tools - filesystem access, web search, database queries, whatever you need. The AI model discovers these tools at runtime and uses them to complete tasks. But here's what nobody talks about: running MCP servers directly in production is a security nightmare. You're giving AI models access to your infrastructure with minimal oversight. And debugging failures when you can't see what tools are being called? Good luck. That's why we built MCP support directly into Bifrost. It's not just a passthrough - it's a complete control plane. ## How It Works Bifrost acts as both an MCP client (connecting to tool servers) and optionally as an MCP server (exposing tools to external clients like Claude Desktop). We support four connection types, each optimized for different scenarios: **InProcess connections** run tools directly in Bifrost's memory. If you're hosting tools in Go, this gives you sub-millisecond latency (around 0.1ms) with compile-time type safety. Perfect for internal business logic. **STDIO connections** launch external processes and communicate via stdin/stdout. Great for local scripts, filesystem operations, or Python/Node.js MCP servers. Latency is typically 1-10ms. **HTTP connections** talk to remote MCP servers over HTTP. Use this for microservices, cloud-hosted tools, or third-party services. Latency is network-dependent, usually 10-500ms. **SSE (Server-Sent Events) connections** maintain persistent connections for streaming data. Think real-time monitoring, market data feeds, or live event streams. ## The Security Model By default, Bifrost does NOT automatically execute tool calls. This is critical. When an AI model wants to use a tool, it returns a suggestion - you have to explicitly approve execution. This prevents your agent from accidentally nuking a database or charging a credit card. But we also support "agent mode" where specific tools can be auto-executed. You configure which tools are safe to run automatically, and Bifrost handles the rest. This is great for read-only operations or low-risk actions where you trust the model's judgment. Here's what a request-level filter looks like: ```bash curl -X POST http://localhost:8080/v1/chat/completions \ -H "x-bf-mcp-include-clients: filesystem,websearch" \ -H "x-bf-mcp-include-tools: filesystem/read_file,websearch/search" \ -d '{"model": "gpt-4o-mini", "messages": [...]}' ``` You can filter by client (which MCP servers are available) or by specific tools. This gives you granular control per request. Financial apps might restrict agents to read-only database tools. Customer-facing chatbots might only access approved external APIs. ## Code Mode vs Agent Mode We shipped two execution patterns: **Agent mode** has the AI model call one tool at a time. It sees the result, thinks about what to do next, calls another tool. This works well for interactive agents where you want human oversight at each step. **Code mode** lets the AI write TypeScript that orchestrates multiple tools in a single execution. Instead of multiple round-trips, the model writes code like: ```typescript const files = await listFiles("/project"); const results = await Promise.all( files.map(file => analyzeFile(file)) ); return summarize(results); ``` The code runs atomically. This is way faster for batch operations or complex workflows where you don't need per-tool approval. ## Tool Discovery Tools are discovered dynamically at runtime. When you connect an MCP server, Bifrost: 1. Establishes the connection 2. Gets the list of available tools and their schemas 3. Validates everything 4. Registers tools in the internal registry 5. Makes them available to AI models No hardcoded tool definitions. No config files. The AI model just asks "what tools are available?" and gets the full list with schemas. ## Real-World Use Cases **Filesystem operations**: We're using this ourselves for code analysis. The agent reads files, looks for patterns, and writes reports. STDIO connection to a Node.js MCP server, latency under 5ms. **Database queries**: Customer support agents query user data, pull order history, check account status. HTTP connection to a microservice with proper authentication. Read-only access by default. **Web search**: Research assistants search the web, extract content, and summarize findings. HTTP connection to an external API, cached responses for repeated queries. **Real-time monitoring**: System health checks, log analysis, metric tracking. SSE connection for live updates without polling. ## Observability Every tool call gets logged. Full audit trail of what the agent did, which tools it used, what data it accessed, and what happened. Prometheus metrics track latency, success rates, and error patterns per tool. Distributed tracing shows the full request flow from the AI model through Bifrost to the MCP server and back. We also expose MCP metrics - connection health, tool availability, execution times. If an MCP server goes down, you see it immediately. ## What We Learned **Security can't be optional.** Default-deny tool execution prevents so many production disasters. Even with agent mode, limiting auto-execution to specific tools keeps things contained. **Latency matters more than you think.** When an agent is calling 20 tools to complete a task, every millisecond of overhead adds up. InProcess connections at 0.1ms feel instant. HTTP at 200ms starts to drag. **Type safety is underrated.** InProcess tools with Go structs caught so many bugs at compile time. No runtime surprises about parameter types or missing fields. **Filtering is critical.** Request-level control over which tools are available prevents privilege escalation. Customer-facing agents don't need access to admin tools, period. ## Performance Numbers We ran benchmarks with a filesystem MCP server (STDIO) and a custom database server (HTTP): - **STDIO connection overhead**: 1.2ms average - **HTTP connection overhead**: 15ms average (local network) - **InProcess tool calls**: 0.08ms average - **Tool discovery**: <100ms for 50 tools - **Memory usage**: ~2MB per active STDIO connection These numbers are with Go's runtime. Your mileage will vary with Python or Node.js servers, but the relative differences hold. ## Try It Yourself MCP support is available in Bifrost now. Start with STDIO connections if you're prototyping - they're the easiest to set up. Point Bifrost at an existing MCP server, configure which tools to enable, and you're running. For production, HTTP connections scale better. You can run multiple instances of your MCP server behind a load balancer, handle failures gracefully, and isolate tool execution from your gateway. The docs cover setup for all four connection types, agent mode configuration, and request-level filtering. We also have examples for common use cases - filesystem, database, web APIs. If you're building agents that need to interact with your infrastructure, MCP makes this way cleaner. And Bifrost gives you the control plane to actually run it in production without melting down. --- Built with Bifrost - https://docs.getbifrost.ai/features/mcp --- Tags: [#ai](https://daily.dev/tags/ai), [#security](https://daily.dev/tags/security), [#architecture](https://daily.dev/tags/architecture), [#golang](https://daily.dev/tags/golang) [View this post on daily.dev](https://daily.dev/posts/adding-mcp-to-bifrost-letting-ai-models-use-external-tools-g2uzzqaro)