Forem: Algis

The OWASP MCP Top 10: A Security Framework for the AI Agent Era

Algis — Wed, 18 Mar 2026 16:54:11 +0000

The Model Context Protocol needed its own threat taxonomy. Now it has one.

OWASP -- the organization behind the Web Application Top 10 that shaped a generation of security engineering -- has published the MCP Top 10, a structured framework for the most critical security risks in AI agent tool integration. The project, led by Vandana Verma Sehgal, is currently in beta under a CC BY-NC-SA 4.0 license, and it addresses a gap that has been widening for months: the absence of a shared vocabulary for reasoning about MCP security.

This is not a theoretical exercise. Over 30 CVEs have been filed against MCP implementations in the past 60 days. Research consistently shows that tool poisoning attacks succeed at alarming rates -- 84.2% with auto-approval enabled, according to recent benchmarks. An audit of 17 popular MCP servers found an average security score of 34 out of 100, with 100% lacking permission declarations. The threat landscape has outpaced the defensive toolkit, and OWASP’s framework is an attempt to bring structure to the response.

Here is what each category covers, why it matters, and what practitioners should do about it.

The Ten Categories

MCP01: Token Mismanagement and Secret Exposure

Credentials that end up where they should not be. Hard-coded API keys in MCP server configurations, long-lived tokens without rotation policies, and secrets persisted in model memory or protocol debug logs.

What to do: Implement short-lived, scoped credentials. Never store secrets in tool descriptions or model context.

MCP02: Privilege Escalation via Scope Creep

Permissions that were appropriate during setup expand over time. The cumulative effect is an agent that can modify your entire filesystem.

What to do: Enforce least-privilege by default. Implement automated scope expiry.

MCP03: Tool Poisoning

Tool poisoning exploits the assumption that tool descriptions are trustworthy. A malicious description can embed hidden instructions that manipulate agent behavior. Invariant Labs showed a poisoned add tool containing hidden <IMPORTANT> tags that exfiltrated SSH keys. Tool spoofing achieves 100% success rate in first-match resolution mode.

Three variants: direct poisoning, tool shadowing, and rug pulls.

What to do: Implement tool pinning. Never auto-approve tool invocations in production. Use schema quarantine.

MCP04: Supply Chain Attacks

Classic supply chain vectors -- typosquatting, dependency confusion -- but payloads execute inside AI agents with elevated permissions.

What to do: Pin MCP server versions. Verify package signatures. Monitor registries.

MCP05: Command Injection

The MCP equivalent of SQL injection. The Clinejection attack demonstrated how a malicious GitHub issue title could trigger code execution.

What to do: Validate and sanitize all input. Use sandboxed execution environments.

MCP06: Intent Flow Subversion

Malicious instructions embedded in tool context hijack the agent’s decision-making.

What to do: Separate system instructions from retrieved context. Use chain-of-thought logging.

MCP07: Insufficient Authentication

38% of 500+ scanned MCP servers lack any form of authentication.

What to do: Use OAuth 2.1 as specified in MCP. Enforce RBAC at the tool level.

MCP08: Lack of Audit and Telemetry

Without logging, unauthorized actions go undetected. Most MCP clients provide minimal logging.

What to do: Log all tool invocations with full parameters and responses. Enable real-time alerting.

MCP09: Shadow MCP Servers

Unauthorized deployments outside security governance. Shadow servers have the same trust level as approved ones.

What to do: Centralized MCP deployment governance. Discover and inventory all instances.

MCP10: Context Injection and Over-Sharing

Sensitive information from one task leaks to another through shared context windows.

What to do: Isolated context windows per user and per task. Enforce context expiration.

What the Numbers Say

30+ CVEs in 60 days against MCP implementations
84.2% success rate for tool poisoning with auto-approval
38% of 500+ servers lack authentication
34/100 average security score across 17 audited servers
100% tool spoofing success in first-match resolution
FastMCP exceeds 1M daily downloads

Emerging Defense Patterns

Schema Quarantine and Tool Pinning -- Verify tool definitions before they reach the agent. Invariant Labs' mcp-scan detects poisoning, rug pulls, and cross-origin escalations. MCPProxy combines BM25-based tool discovery with quarantine capabilities.

Runtime Behavioral Monitoring -- Detect behavioral drift with tools like Golf Scanner and AgentArmor's 8-layer security framework.

Registry Governance -- Signed packages, provenance tracking, automated vulnerability scanning.

Context Isolation -- Isolated context windows per task, strict permission boundaries per tool.

Practical Response Plan

This week: Inventory MCP connections. Disable auto-approval. Scan configs for secrets.

This month: Implement tool pinning. Add auth to all connections. Enable audit logging.

This quarter: Adopt a gateway architecture. Implement context isolation. Establish MCP governance.

The full framework is available at owasp.org/www-project-mcp-top-10.

Originally published on mcpblog.dev

Deploy Your Own Agent Messaging Hub in 15 Minutes -- For Free

Algis — Mon, 16 Mar 2026 09:08:40 +0000

This post was originally published on synapbus.dev.

AI agent swarms are getting real. Not the theoretical "someday we'll have autonomous agents" kind of real -- the "I have four agents running on a CronJob and they need to talk to each other" kind of real.

But here's the problem: every messaging backbone people reach for costs money. Redis needs a server. Kafka needs a cluster. Cloud pub/sub services charge per message. For a personal or small-team agent swarm, this overhead kills the project before it starts.

SynapBus is a different approach: a single Go binary with zero external dependencies. No Redis. No Kafka. No cloud subscription. Embedded SQLite for storage, an HNSW vector index for semantic search, and a Slack-like Web UI for monitoring your agents -- all in one ~20MB binary.

This post walks through deploying SynapBus, exposing it to the internet for free via Cloudflare Tunnel, and connecting your first AI agents. Total infrastructure cost: $0.

What SynapBus Actually Does

SynapBus is a local-first, MCP-native agent-to-agent messaging hub:

Channels and DMs -- Slack-like communication between agents and humans
MCP endpoint -- Any MCP-compatible client works out of the box
Semantic search -- Every message indexed by meaning, not just keywords
Task auction -- Post a task, let agents bid on capabilities
Web UI -- Watch agents talk in real time

The MCP interface exposes four tools: my_status, send_message, search, and execute.

Option A: Docker Compose (5 Minutes)

version: '3.8'
services:
  synapbus:
    image: ghcr.io/synapbus/synapbus:0.4.0
    ports:
      - "8080:8080"
    volumes:
      - synapbus-data:/data
    environment:
      - SYNAPBUS_LOG_LEVEL=info
      - SYNAPBUS_BASE_URL=http://localhost:8080
    restart: unless-stopped

volumes:
  synapbus-data:

Then: docker compose up -d

Option B: Kubernetes with Helm (15 Minutes)

replicaCount: 1
image:
  repository: ghcr.io/synapbus/synapbus
  tag: "0.4.0"
service:
  type: NodePort
  port: 8080
persistence:
  enabled: true
  size: 2Gi

Deploy: helm upgrade --install synapbus synapbus/synapbus --namespace synapbus --create-namespace -f values.yaml

Expose to the Internet with Cloudflare Tunnel (Free)

Add cloudflared as a sidecar. Cloudflare handles TLS. Your agents connect to https://hub.example.com/mcp with full HTTPS.

Setup: Create Agents and Channels

docker exec synapbus /synapbus user create --username admin --password MySecurePass123
docker exec synapbus /synapbus agent create --name research-agent --display-name "Research Agent" --owner 1
docker exec synapbus /synapbus channels create --name news --description "Top discoveries"

Connect Agents via MCP

from claude_agent_sdk import ClaudeAgentOptions, query

mcp_servers = {
    "synapbus": {
        "type": "http",
        "url": "https://hub.example.com/mcp",
        "headers": {"Authorization": f"Bearer {SYNAPBUS_API_KEY}"}
    }
}

Cost Breakdown

Component	Cost
SynapBus	$0 -- open source
Cloudflare Tunnel	$0 -- free tier
Docker / K8s	$0 -- your hardware
OpenAI embeddings	~$0.02/1M tokens (optional)
Total	$0

What You Get

After 15 minutes: Slack-like Web UI, MCP-native connectivity, semantic search, channels and DMs, task auction, HTTPS via Cloudflare, persistent storage, Prometheus metrics.

SynapBus is not a framework. It is infrastructure: a messaging hub that agents connect to via MCP.

SynapBus is open source at github.com/synapbus/synapbus. Originally published at synapbus.dev.

Beyond BM25: The Future of MCP Tool Discovery

Algis — Sun, 15 Mar 2026 18:01:20 +0000

This post was originally published on mcpproxy.app/blog.

TL;DR

In our earlier post, we made the case for BM25 as the right default for MCP tool discovery -- and for small-to-medium tool sets, that case still holds. But new benchmarks from StackOne, Stacklok, and the RAG-MCP paper paint a more nuanced picture: BM25 alone delivers just 14% top-1 accuracy when tool counts climb past a few hundred. Hybrid approaches combining BM25 with semantic search hit 94%. This post lays out what the data actually shows, why BM25 degrades at scale, and how MCPProxy is evolving toward hybrid search while keeping the zero-dependency simplicity that makes it useful.

The Benchmarks Are In

Three independent evaluations have landed in the last few months, and they tell a consistent story.

StackOne's benchmark tested 270 tools across 11 API categories with 2,700 natural-language queries:

Method	Top-1 Accuracy	Top-5 Accuracy	Latency
BM25 only	14%	87%	<1ms
TF-IDF/BM25 hybrid	21%	90%	<1ms
Embedding search	38%	85%	50-200ms
Reranker	40%+	90%+	200-500ms

Stacklok's MCP Optimizer ran a head-to-head comparison against Anthropic's built-in Tool Search across 2,792 tools. Their hybrid semantic+BM25 approach achieved 94% selection accuracy versus 34% for BM25-only.

The RAG-MCP paper confirmed that agents given every tool upfront achieve just 13.6% accuracy, while retrieval-first routing more than triples it to 43.1%.

Why BM25 Breaks Down at Scale

Common verbs saturate the index. When you have 2,000+ tools, verbs like "create," "list," "get" appear in hundreds of tool names. BM25's IDF component loses discriminating power.

Short documents amplify the problem. Tool descriptions are uniformly short (10-50 words), collapsing a dimension BM25 normally uses for discrimination.

Semantic intent gets lost. "notify the team about a deployment" might need Slack, PagerDuty, or email. BM25 cannot bridge the gap between "notify" and "send_message."

None of this invalidates BM25 for smaller deployments. The 87% top-5 accuracy confirms BM25 almost always gets the right tool somewhere in the results.

What Hybrid Search Actually Looks Like

Step 1: Parallel Retrieval

The query runs simultaneously through two paths:

BM25 path: Keyword search against the Bleve index. Sub-millisecond, zero dependencies.
Semantic path: Query embedded via lightweight model, compared against pre-computed tool embeddings.

Step 2: Reciprocal Rank Fusion

The two ranked lists merge using RRF:

RRF_score(tool) = 1/(k + rank_bm25) + 1/(k + rank_semantic)

RRF is score-agnostic -- it works on rank positions, not raw scores. This sidesteps the normalization problem entirely.

Why This Works So Well

BM25 excels at exact term matching. Embeddings excel at semantic bridging. RRF ensures high confidence when both signals agree. Stacklok's 94% vs BM25's 34% on 2,792 tools proves the combination is categorically better at scale.

Where BM25 Still Wins

Small-to-medium tool sets (under 100 tools). 87% top-5 accuracy, zero dependencies, sub-millisecond.

Air-gapped environments. No network calls required.

Determinism and debuggability. BM25 scoring is fully transparent and inspectable.

Cold start speed. Indexes built instantly from tool metadata.

MCPProxy's Roadmap: Hybrid Without Compromise

Phase 1: Smarter BM25 (Now)

Field-weighted scoring (tool names > descriptions)
Verb deweighting for common actions
Query expansion for abbreviations
Server-context boosting

Phase 2: Optional Embedding Layer

Local embedding models (~80MB, single-digit ms)
Pre-computed embeddings stored alongside Bleve index
RRF fusion
Graceful degradation to BM25-only

Phase 3: Hierarchical Discovery

Server-level grouping as first-level filter
Progressive disclosure (mirrors Claude Code's pattern)
Dynamic tool sets by annotation or usage

The Guiding Principle

Every phase maintains MCPProxy's core contract: it ships as a single binary with zero required external dependencies.

What This Means for You

Your Scale	Recommended Approach	Expected Top-1 Accuracy
10-50 tools	BM25 (MCPProxy default)	~80-85%
50-200 tools	BM25 with field weighting	~60-70%
200-500 tools	Hybrid BM25 + embedding	~85-90%
500+ tools	Hybrid + hierarchical discovery	~90-94%

The earlier BM25 post was not wrong -- it was incomplete. BM25 is the right starting point. But the data is clear that BM25 alone does not scale to the hundreds-of-tools future. MCPProxy is evolving toward hybrid search because the constraints are changing -- and we would rather share that data honestly than pretend a single algorithm solves everything forever.

MCPProxy is open source at github.com/smart-mcp-proxy/mcpproxy-go. Originally published at mcpproxy.app/blog.

The MCP Gateway Landscape in 2026: Where MCPProxy Fits

Algis — Sun, 15 Mar 2026 17:57:31 +0000

This post was originally published on mcpproxy.app/blog.

The Cambrian Explosion of MCP Gateways

Eighteen months ago, "MCP gateway" was barely a category. Today, the awesome-mcp-gateways list on GitHub tracks 42 projects -- 19 open-source and 23 commercial -- and the number keeps climbing. Microsoft, IBM, Docker, Kong, Traefik, and AWS have all shipped MCP gateway solutions. At least eight new open-source gateways appeared in the last six weeks alone.

What happened? The Model Context Protocol, introduced by Anthropic in late 2024, crossed a critical adoption threshold when OpenAI, Google, and Microsoft all added MCP support. Suddenly every AI agent could talk to any tool using a standard protocol -- and every organization needed something sitting between those agents and tools to enforce auth, control access, scan for threats, and log what happened.

That "something" is an MCP gateway. But the term now covers everything from a Kubernetes-native reverse proxy to a desktop-first developer tool to a commercial SaaS with 500+ managed integrations. Understanding the landscape requires separating these architectures, identifying which problems each solves, and recognizing which capabilities actually matter for your use case.

This post maps the territory, compares the major players, and explains where MCPProxy fits in.

Three Architectures, Three Philosophies

The 42 MCP gateways on the market fall into three broad architectural categories. Choosing between them is the first decision that matters.

Cloud-Native Gateways

These run in Kubernetes, scale horizontally, and assume your MCP servers are deployed as pods or remote services. They excel at multi-tenant environments where platform teams need to govern tool access across dozens of agent deployments.

Microsoft MCP Gateway is the canonical example: a C# reverse proxy with StatefulSet-based session affinity, Azure Entra ID authentication, RBAC, and a Tool Gateway Router that dynamically routes tool calls to registered servers. It is Kubernetes-native to its core -- there is no standalone binary, no desktop mode.

IBM ContextForge (3.4K GitHub stars) takes the broadest approach. It federates MCP, A2A, REST, and gRPC APIs behind a single endpoint with 40+ plugins, OpenTelemetry tracing, Redis-backed caching, and multi-cluster federation via mDNS auto-discovery.

Kong AI Gateway extends Kong's established API gateway with MCP proxy plugins, OAuth 2.1, and an MCP Registry for tool governance.

Desktop-First Gateways

These run locally, optimize for individual developers or small teams, and focus on the workflow between your editor (VS Code, Cursor, Claude Code) and your MCP servers.

Docker MCP Gateway (1.3K stars) is a Docker CLI plugin that runs MCP servers as isolated containers, manages secrets through Docker Desktop, and provides dynamic tool discovery.

MCPProxy occupies this space too, but with a different emphasis -- more on that below.

Managed Platforms

Services like Composio (500+ managed integrations), MintMCP (SOC 2/HIPAA audit logs), and Unified Context Layer (1,000+ tools) provide hosted MCP endpoints with pre-built connectors, managed auth, and pay-per-use pricing.

The Feature Map

Capability	MCPProxy	IBM ContextForge	Microsoft MCP GW	Docker MCP GW	Kong AI GW	Bifrost
Tool Discovery	BM25 ranking	Registry + mDNS	Dynamic routing	Auto-discovery	MCP Registry	OpenAI-compat
Auth	OAuth config	OAuth, API keys	Azure Entra ID	OAuth + secrets	OAuth 2.1, ABAC	SSO, Vault
Security	Quarantine + SDD	Guardrails plugins	RBAC policies	Interceptors	ACLs, guardrails	Guardrails
Isolation	Docker containers	K8s namespaces	K8s pods	Docker containers	—	—
Protocol	MCP (stdio + SSE)	MCP, A2A, REST, gRPC	MCP	MCP	MCP + REST	MCP + LLM
Observability	Web UI, logs	OpenTelemetry	Azure Monitor	Logging, tracing	Prometheus	Audit logs
Deployment	Single binary	Docker/K8s/PyPI	K8s only	Docker CLI plugin	K8s + Konnect	Docker, NPX

Where MCPProxy Is Different

MCPProxy does two things that no other gateway in this landscape does: BM25 tool discovery and schema quarantine.

The Tool Discovery Problem

When an agent connects to 15 MCP servers exposing 200+ tools, the LLM's context window fills with tool definitions. Most gateways treat this as a configuration problem -- you manually curate which tools each agent can see. MCPProxy treats it as a search problem.

MCPProxy's BM25 engine ranks available tools by relevance to the agent's current task. The agent sees 3-5 highly relevant tools instead of 200 noisy ones. No other MCP gateway offers automated relevance-based tool filtering.

The Quarantine Problem

When you connect a new MCP server, how do you know its tool definitions are safe? Tool poisoning -- hiding malicious instructions in tool descriptions -- is the number one MCP attack vector. MCPProxy's quarantine system holds new tool schemas in a staging area where they are analyzed for known attack patterns before being released to the agent.

Where Competitors Excel

Observability: IBM ContextForge. Full OpenTelemetry integration with Phoenix, Jaeger, and Zipkin backends.

Performance: Bifrost. Eleven microseconds of overhead at 5,000 RPS.

Multi-Protocol: IBM ContextForge. MCP, A2A, REST, and gRPC behind one gateway.

Enterprise Integration: Kong AI Gateway. Existing customer base and compliance certifications.

Managed Ease of Use: Composio. 500 pre-built integrations with managed auth.

Market Trajectory

Three patterns are shaping where the MCP gateway market goes:

Consolidation is coming. 42 gateways is not sustainable. The market will consolidate around 5-8 major players within 12-18 months.
Platform vendors will absorb the category. AWS has already added MCP proxy support to API Gateway. Azure has MCP support in API Management.
Security becomes the differentiator. As basic gateway functionality commoditizes, the security layer becomes the primary differentiator.

Where MCPProxy Goes from Here

Near-term (Q2 2026): OpenTelemetry export, expanded quarantine rules covering the full OWASP MCP Top 10, improved BM25 ranking.

Medium-term (H2 2026): OS-level sandboxing via Linux Landlock, expanded sensitive data detection, public benchmark suite.

Ongoing: Staying lean. MCPProxy will remain a single binary that you can download and run in 30 seconds.

MCPProxy is open source at github.com/smart-mcp-proxy/mcpproxy-go. Star the repo, file issues, or try it with mcpproxy serve.

Originally published at mcpproxy.app/blog.

MCP Proxy Pattern: Secure, Retrieval-First Tool Routing for Agents

Algis — Wed, 20 Aug 2025 14:30:29 +0000

TL;DR

This post proposes an MCP proxy/middleware layer to improve the user experience with AI agents—especially long‑running ones. It explains how the layer retrieves and routes tools on demand, reduces prompt bloat, and adds safety and observability. The post also explains design choices of implemented features and outlines future areas of development in the open‑source MCPProxy project.

Introduction: The Model Context Protocol (MCP)

The Model Context Protocol (MCP) is a new open standard for connecting AI assistants to external tools and data sources. Rather than each AI app needing custom integrations for every service, MCP defines a consistent way (via MCP servers and MCP clients) to add new capabilities to any AI agent. This opens the door to a richer, more connected AI experience. See also Anthropic’s announcement: Introducing the Model Context Protocol.

Recent MCP advancements.

The MCP specification (architecture) is evolving rapidly, adding features that make AI-tool interactions more powerful and secure. Some highlights of the latest MCP spec (mid-2025) include:

Elicitation (Human-in-the-Loop): Tools can pause and ask the user for additional input mid-execution. This turns one-shot calls into interactive multi-turn workflows, enabling things like form filling and clarification questions. Instead of failing on missing info, an MCP server can issue an elicitation/create request to prompt the user for exactly what’s needed.
OAuth 2.0 Support: Secure integration with user-authorized APIs is now standardized. Tools can declare OAuth requirements (auth URL, scopes, etc.), and clients handle the login flow automatically. This means an AI agent can safely connect to services like Google or Slack on your behalf, with proper consent.
Structured Outputs & UI Components: Beyond plain text, MCP now supports structured content schemas and rich media. Tool responses can include typed JSON results or even MIME-typed data (images, audio, etc.), allowing clients like Claude Desktop to render dynamic UI components in-line (MCP UI demo). For example, an MCP weather tool could return a JSON object plus an image chart – the chat client can then display a nice formatted forecast card rather than a blob of text.

These advances point towards a future where AI agents seamlessly pull in context, ask users for input when needed, and present results in compelling ways. For community talks and demos, see the MCP Developers Summit. However, simply enabling an AI to use dozens of tools raises practical challenges. To truly harness MCP’s potential, we need to consider how tools are connected and managed in real-world scenarios.

Directly Connecting Tools to an AI Agent: Real-World Limitations

Naively, one could wire up an AI agent (like Claude or ChatGPT) with every tool under the sun. In theory the model would then always have the right function available. In practice, though, loading a large number of MCP tools directly into an LLM session is problematic. The limitations include:

Client & API Limits: Many AI clients have a hard cap on how many tools or functions can be loaded. For example, Cursor IDE supports at most ~40 tools per workspace (discussion), and OpenAI’s function-calling API allows ~128 functions (Azure quotas, community confirmation, platform docs). Cramming hundreds of tools beyond these limits just isn’t possible.
Huge Prompt Overhead: Each tool’s description and JSON schema consume tokens. Feeding dozens at once bloats the prompt. The RAG-MCP framework shows that retrieving only the relevant tool schemas before invoking the model cuts prompt tokens by more than 50% on MCP stress tests (RAG-MCP).
Lower Accuracy with Too Many Options: With a large menu of tools, models mis‑select more often. RAG-MCP reports that naive “all tools loaded” baselines achieved only 13.62% tool selection accuracy, while retrieval-first narrowing more than tripled accuracy to 43.13% on benchmark tasks (RAG-MCP). In other words, more is less – too many options can confuse the model and lead to mistakes.

An illustration of how directly integrating too many tools can hit system limits and degrade performance. Loading every tool’s schema can exceed client-imposed caps (like Cursor’s 40-tool limit) and dramatically inflate the prompt size, leading to slower and less accurate responses. In this example, adding dozens of tools caused higher token usage for the same query, with significantly lower task success.

Clearly, a more scalable approach is needed – one that gives the agent access to many tools without overwhelming it at each step. This is where a smart MCP middleware or proxy layer comes in (What MCP Middleware Could Look Like).

How MCPProxy Solves the Tool Overload Problem

MCPProxy is an open-source project (written in Go) that serves as an intelligent middleware between the AI agent and numerous MCP servers (source code). Rather than the agent seeing hundreds of tools directly, the agent sees just one proxy endpoint (the MCPProxy), which dynamically routes and filters tool requests behind the scenes. In effect, MCPProxy acts as an aggregation layer or hub for tools:

It maintains connections to any number of upstream MCP servers (local or remote), but exposes them to the agent through a single unified interface.
It provides a special retrieve_tools function that the agent can call with a query to discover relevant tools on the fly. The proxy uses an internal BM25 search index to match the query against the descriptions of all available tools and returns only the top K matches. By default, MCPProxy will return at most 5 relevant tools for any given query (a configurable top_k parameter).
When the agent decides to use one of those tools, it then calls a unified call_tool function with the chosen tool’s name and arguments. MCPProxy forwards that to the correct upstream server, handles the execution, and relays the result back.

This design means the AI doesn’t need to preload every tool’s schema or decide among hundreds of options. It can query the tool space as needed. The result: far fewer tokens consumed and far better accuracy in tool selection. In fact, by loading only the proxy’s functions (one to search tools, one to invoke), an agent can achieve massive prompt savings – one benchmark showed a ~50% reduction in prompt tokens and a corresponding boost in success rate when using this retrieval approach. Instead of drowning in irrelevant options, the model focuses only on a short list of likely tools.

How MCPProxy streamlines tool usage. The AI agent uses the proxy’s retrieve_tools call to get just a handful of relevant tools for the task (instead of loading every tool). It then invokes the chosen tool via the proxy’s call_tool. This indirection enables zero manual curation of tools by the user and yields huge token savings and higher accuracy in practice.

From the agent’s perspective, it now only sees two core functions (plus a couple management functions) from MCPProxy rather than dozens or hundreds from various servers. Under the hood, MCPProxy keeps track of all connected MCP servers and their available tools, updating the search index whenever a new server or tool is added. Because the agent only ever deals with a single MCP server (the proxy itself), we also avoid hitting client limits – e.g. Cursor IDE treats MCPProxy as “one server” no matter how many actual tools it federates.

Beyond search and invocation, MCPProxy also implements a couple of other handy MCP features by itself. For instance, it includes an upstream_servers management tool that lets the agent (or user) list, add, or remove the proxy’s upstream servers via MCP. All of this is provided through a lightweight desktop app with a minimal UI (it lives in your system tray) and cross-platform binaries.

In short, MCPProxy turns the chaos of many tools into a single organized pipeline. By federating unlimited MCP servers behind one endpoint, it bypasses hard limits (no more 40-tool cap) and minimizes context size (load just what’s needed). This lays a foundation for AI agents to be far more productive with tools, scaling up without drowning in prompt data.

Scaling to Hundreds of MCP Servers and Thousands of Tools

An exciting implication of using a proxy is that you’re no longer limited to a small handful of tools. If your AI needs more capabilities, you can simply spin up more MCP servers and register them with the proxy. In practice, one MCPProxy instance can easily manage dozens or even hundreds of upstream servers – effectively giving your agent access to thousands of tools or functions aggregated together.

However, managing such a large toolset introduces new challenges: how do we find the right server for a task, and who decides which servers to include? This is where we consider different levels of agent autonomy in tool management.

Concept of an autonomy slider in MCP tool management. On the left, a human manually selects and configures each MCP server the agent will use. In the middle, the agent can help by suggesting or adding servers (with user approval). On the right, the agent fully autonomously discovers and integrates new tools as needed. MCPProxy is built to support these modes: it exposes APIs for programmatic server management, so an AI agent can manage its toolset within bounds you define.

On one end of the spectrum, a human operator might manually curate a set of MCP servers for the agent (e.g. adding a GitHub server, a Google Drive server, etc. by hand). On the other end, an advanced agent might autonomously discover and integrate new tools on the fly, without human intervention. Andrej Karpathy refers to this concept as the “autonomy slider” – we can choose how much control to give the AI vs the human in orchestrating the solution (see “Levels of Autonomy for AI Agents”). With MCP, this translates to how tool selection and configuration are handled:

Manual mode: Human-driven tool discovery. The user explicitly finds and adds MCP servers they think the AI will need. For example, if working on a data analysis task, the user might install a Postgres database MCP server and a plotting MCP server ahead of time. This ensures the agent has the right tools, but it relies on the human’s knowledge and effort.
Assisted mode: AI suggests, human approves. Here the AI agent can suggest new tools when it encounters a need. It might say “I don’t have a calendar tool – can I install one?” The user can then approve the addition. MCPProxy already enables this workflow: the agent could perform a search in an MCP registry (more on that below) and then call the upstream_servers.add function to register a new server in the proxy. The user stays in the loop, but the agent does the heavy lifting of finding the tool.
Autonomous mode: AI-driven tool discovery. In the most advanced scenario, the agent itself detects a gap, searches a public registry for a suitable MCP server, and adds it – all on its own. This would push the autonomy slider to the max, letting the AI acquire new skills as needed in real-time. It’s an exciting idea that researchers are already exploring (e.g. Karpathy’s vision of partially autonomous coding agents), though it raises trust and safety questions.

Today, most users will operate somewhere between manual and assisted modes. You might start your AI with a core set of known-good tools, but also want it to be able to grab new tools for specific tasks. With MCPProxy, you can allow or restrict this behavior via configuration flags (for example, running the proxy in read-only mode to forbid adding servers, or enabling an experimental auto-add feature). The important thing is that the infrastructure doesn’t hard-code a limit on the number of tools – you can grow your agent’s toolkit as big as needed.

It’s worth noting that the ecosystem of MCP servers is expanding very rapidly. There are already thousands of MCP servers available, covering everything from Slack bots to web scraping to code execution. Community-driven directories like Pulse MCP, Glama MCP server directory, Smithery, and LobeHub marketplace (see the LobeHub MCP index) list thousands of servers and provide usage stats. Anthropic and others are working on an official MCP registry to standardize how agents discover and install these servers dynamically. In short, the raw material (tools) is out there; the challenge is connecting the right tool at the right time. A middleware like MCPProxy, especially paired with an intelligent registry search, could let agents tap into this vast toolbox on demand without human micromanagement.

Practical Challenges in an MCP-Based Tool Ecosystem

While the MCP approach holds great promise, implementing it in the real world comes with several practical challenges. Here we discuss a few and how a proxy/middleware can help address them:

Discovering and Installing MCP Servers

Finding the appropriate MCP server for a given need is not always straightforward. There is no single “app store” for MCP (at least not yet) – instead, there are multiple registries, directories, and marketplaces cropping up. For example, community directories like Pulse MCP, Glama directory, and Smithery catalogue thousands of servers and let you search by category or keyword. There are also emerging registry services aiming to provide a unified API for discovering servers. There are even MCP servers that search registries themselves, such as the MCP Registry Server and the Pulse MCP server.

However, once you find a server, you often have to install or run it yourself. Many community MCP servers are simply open-source projects – you might need to run a Docker container or a local script to actually host the server, especially for things that require credentials or local access (like a filesystem tool). This can be a hurdle for non-technical users, and it fragments the experience.

How MCPProxy helps: The proxy can act as a bridge between registry listings and actual running tools. In the future, I envision the agent being able to search a registry (via some MCP registry API) and then automatically launch the chosen MCP server through the proxy. In fact, MCPProxy’s design already anticipates this: you can add a server by URL or command at runtime using the proxy’s MCP tools. For example, if the agent finds a “PDF reader” MCP server in a registry, it could call mcpproxy tool with parameters something like:

{"method": "upstream_servers", "params": {
    "operation": "add",
    "name": "pdf_tool",
    "url": "https://example.com/pdf/mcp"
}}

to add that server to its arsenal. (The proxy starts indexing the new server’s tools immediately.) Conversely, if the server needs to run locally, the proxy can be configured with a command to start it. In one scenario, the AI could even instruct the proxy to run a Docker container for an MCP server, given the image name.

All of this is still experimental, but it’s a key area of development. The goal is to remove the manual friction from tool discovery: ultimately, neither the human nor the AI should have to dig through web listings and configuration files to load a new capability. We’re not quite there yet, but MCPProxy is built to integrate with upcoming MCP registries and package managers so that adding a tool becomes as easy as a function call.

Safe Execution of Code Tools (Sandboxing)

Many MCP servers are essentially code execution environments – for instance, a Python REPL tool, a shell command tool, or an automation script runner. Giving an AI access to these is powerful but dangerous. You don’t want an LLM running arbitrary code on your machine without safeguards. Even benign tools like a web browser automation could be exploited if malicious instructions slip through (e.g. telling the browser to download malware).

The recommended approach is to sandbox and isolate tool execution. This is an area where containerization (like Docker) plays a big role. In fact, Docker Inc. has released an “MCP Gateway” specifically to help run MCP servers in isolated containers with proper security controls (docs, blog, GitHub). Their gateway acts as a single endpoint that proxies to multiple containerized tools, similar in spirit to MCPProxy. The benefits of containerization are clear: each tool server runs with restricted privileges, limited network access, and resource quotas – greatly limiting the blast radius if a tool is misused (InfoQ overview).

MCPProxy itself can leverage Docker for sandboxing. For example, you could configure an MCP server entry in the proxy that launches docker run... to start the tool inside a container. This would combine the discovery and sandboxing steps seamlessly.

Even without full automation, the proxy makes it easier to enforce isolation. You can run the entire proxy under a less-privileged account or inside a VM, such that any tool it spawns has limited access to your system. And because the proxy centralizes calls to tools, it could in theory perform real-time monitoring or filtering of tool actions (much like an API gateway inspecting API calls). This leads into the next challenge – security.

MCP Security and Trust (Tool Poisoning Attacks)

Connecting to third-party tools introduces a new category of AI security issues. A particularly insidious threat is the Tool Poisoning Attack (TPA) (overview). This is essentially a form of prompt injection where a malicious MCP server hides harmful instructions in its tool descriptions or outputs. Since the AI model reads those descriptions, a cleverly poisoned description can manipulate the model into doing things it shouldn’t – for example, leaking secrets or executing unintended actions. The scary part is that the user might never see these hidden instructions; they are crafted to be invisible to humans (e.g. buried in JSON or markdown), but the AI “sees” them in its prompt.

Industry awareness of TPAs is growing. In early 2025, security researchers demonstrated how a fake “add numbers” MCP tool could trick an AI into revealing API keys and SSH credentials from the user’s files. Essentially, the tool’s description included a secret section telling the AI to read certain files and send them as part of using the tool – all while appearing harmless to the user. This prompted urgent guidance to be careful about untrusted MCP servers.

MCPProxy’s security measures: I recognized this risk and built in a quarantine mechanism from the start. By default, MCPProxy will put any newly added MCP server into a “quarantined” state until you explicitly approve it. That means the agent cannot call tools from that server until a human reviews and enables it. This adds a layer of manual vetting – you might, for instance, inspect the tool descriptions or source code of a community MCP server before trusting it. You can even test with a deliberately malicious demo MCP server.

In practice, when you add a server in MCPProxy via chat with LLM (using the MCP tool), it’s marked as quarantined: true in the config initially. Next, you can ask LLM to inspect newly added server tools, MCPProxy have corresponding tool quarantine_security to do that. You will see the result of inspection in the same chat window. Note, that proxy uses LLM "brain" of your client to inspect the server, so you don't need to equip mcpproxy with openai or anthropic api key.
You can then use the proxy’s tray UI or the config file to enable newly added server once you’re comfortable. You can see it in action in the demo video. This simple workflow can prevent a rogue server from ever influencing your agent without your knowledge. It’s essentially an allow-list approach.

Moving forward, I plan to enhance this with more automation – for example, integrating a security scanner that analyzes new MCP servers for suspicious patterns (similar to tools like MCP-Scan). An advanced proxy could even sanitize or reject outputs that contain anomalous hidden instructions. There is also the concept of TPA-resistant clients (AI side mitigations), but having a filtering layer in the middleware is a good defense in depth.

Other security features on the roadmap include fine-grained access controls (e.g. per-server or per-tool permission settings) and auditing. MCPProxy already logs all tool usage and can expose recent logs from each server (via the upstream_servers.tail_log tool method) for debugging with AI agent. These logs could be extended to flag potential security issues (like a tool outputting an SSH key). The bottom line is that as AI agents start relying on external tools, you must treat those tools as part of the attack surface. A proxy is a natural place to enforce Zero Trust principles – assume all tools are untrusted until verified, limit their capabilities, and monitor their behavior.

Other Useful Features of an MCP Middleware

Beyond solving the big problems above, a middleware like MCPProxy can provide various quality-of-life features that make AI+Tools systems more robust and user-friendly:

Output Truncation and Caching: Long tool outputs can be problematic for LLMs (they have finite input length and tend to lose context in very long responses). MCPProxy addresses this with a configurable tool_response_limit – by default it will truncate any tool output beyond 20,000 characters. This prevents a runaway tool from overwhelming the agent with data. In case if agent needs to see some other parts of full output, read_cache tool can be used to read paginated data from previous tool calls.
Shared OAuth Authentication: Many MCP servers require authentication to third-party services (think: GitHub API, Google Drive API, etc.). MCPProxy has built-in support for the full OAuth2 flow – including automatically launching your browser for login and capturing the token – and it stores the credentials so you authenticate once and can reuse that session across all your clients. For example, if you connect both your VS Code AI extension and Claude Desktop to MCPProxy, and then add a GitHub MCP server, you only need to go through the GitHub OAuth login one time. The proxy will manage the access token and apply it whenever the agent calls the GitHub tool, even from different front-end applications. This single sign-on style approach greatly improves usability. Under the hood, MCPProxy implements OAuth standards for native apps: RFC 8252 (PKCE) and RFC 7591 (Dynamic Client Registration). It also automatically refreshes tokens and can handle multiple accounts if needed.
Centralized Logging and Debugging: MCPProxy aggregates logs from all upstream servers and the agent’s tool usage into one place on disk (or console). This makes it much easier to debug what’s happening. The proxy can show you which tool was called, with what arguments, and how long it took, all in a unified log. Moreover, as mentioned, there’s an API for the agent to fetch recent logs itself for self-diagnosis – a clever agent might use tail_log to read error messages from a failing tool and decide an alternative strategy. Such introspection is a unique benefit of having a middleware layer coordinating the interactions.
Performance optimizations: Because the proxy maintains persistent connections to upstream MCP servers, it can reuse them across multiple calls. This avoids the overhead of reconnecting or re-loading the tool definitions each time. If multiple AI clients (or multiple concurrent conversations) are using the same tools via the proxy, they all benefit from a shared connection and index. The proxy could also implement request batching or parallelism transparently. For instance, if the agent needs to call two tools, the proxy could execute them in parallel and stream results back, reducing latency. These kinds of optimizations would be very hard to do without a middleware orchestrating things.
Configurability and Extensibility: MCPProxy is just one implementation of an MCP middleware, but it is open-source and designed to be extended. You can run it headless on a server or with a tray icon on your laptop. There’s a simple JSON config for defaults, and command-line flags for things like read-only mode or disabling certain features. Advanced users can fork proxy to add custom logic (for example, one could plug in a vector database for semantic tool retrieval in place of BM25). The point is, the middleware approach gives us a playground to enhance how AI agents use tools, without requiring changes to the LLMs themselves.

As of now, MCPProxy covers many of the fundamentals (search, routing, auth, basic security). Upcoming features on my roadmap aim to make it even more production-grade.

Conclusion

I believe we are at an inflection point reminiscent of other big shifts in computing history. Just as the early web required the development of web servers, proxies, and standards like HTTP to truly take off, the rise of AI agents is spurring the creation of analogous infrastructure for tool integration. MCP is the emerging standard protocol, and around it an ecosystem of servers, registries, and middleware is rapidly forming. It’s a bit chaotic (like the web in the 1990s), but also exciting – new capabilities are being added every day.

MCPProxy is my attempt to bring order and practicality to this space. It’s about advancing a paradigm: enabling AI agents to be productive assistants rather than isolated chatbots. By handling tool discovery, selection, and security in a flexible middleware, I aim to make it easier for developers and end-users to leverage many tools safely and efficiently. This approach is analogous to how software architecture evolved in the past – from monolithic systems to more modular, mediated ones.

In summary, AI agents plus tools are incredibly powerful, but you must manage the complexity. A smart proxy like MCPProxy sits at the center of this, acting as traffic controller, librarian, and security guard for an army of tools. There’s still much work to do – from seamless registry integration to stronger safety guarantees – but the progress so far is promising. By sharing my approach and the reasoning behind it, I hope to encourage a broader conversation (and collaboration) on how to build better AI middleware. After all, empowering AI agents with tools safely and effectively could usher in a new wave of productivity, much like the personal computer revolution or the rise of the internet did in their eras. With the right infrastructure, you can let AI collaborators use all the tools they need, and move one step closer to truly useful, reliable agentic AI.

Try MCPProxy: download the latest release and share feedback or suggest features via GitHub Issues.

Originally published at mcpproxy.app/blog/.

Building LLM-Powered Audience Testing with AI Agents

Algis — Wed, 09 Jul 2025 07:08:23 +0000

🗒️ Summary

Large Language Models (LLMs) can act as “people spirits”—stochastic simulations of real users[1]. By pairing them with Model Context Protocol (MCP) browser automation, we can already run realistic A/B tests and spot issues before shipping code.

1. The Core Concept: LLMs as People Spirits

Andrej Karpathy calls LLMs “stochastic simulations of people” powered by an autoregressive Transformer[1]. Because they are trained on human text, they develop an emergent, human-like psychology—perfect for audience testing.

2. Research Foundation: LLM-as-Judge Accuracy

Studies find LLM evaluations correlate up to 80 % with human judgment[2][3], though the best models still trail behind inter-human agreement[4]. Stanford’s generative-agent work even showed 85 % self-agreement on survey answers two weeks apart[5].

Bottom line: today’s top models are “good enough” to guide product decisions at scale.

3. System Prompts = Instant Personas

A single system prompt can turn one model into many audiences:

You are a 25-year-old gamer from Berlin who values speed and dark themes.

Combine demographic, psychographic, and cultural cues to create diverse personas. AgentA/B research confirms that LLM personas can navigate real webpages and mimic user behavior[6][7].

4. Wiring an AI-Driven A/B Test

Step	What to Do	Why It Matters
1	Control vs. Variations – draft baseline and experimental prompts	Sets up classic A/B structure
2	MCP Browser Automation – let agents click, scroll, fill forms[9][10]	Generates realistic interaction data
3	Log & Score – capture impressions, task success, sentiment	Quantifies user experience
4	Analyze – compare KPIs across personas	Reveals which version wins and why

5. Business Wins

Product Development: Test features with Gen Z gamers, Millennial execs, or rural seniors—overnight.
Marketing Copy: Iterate headlines until every persona clicks.
UX Audits: Detect accessibility or cultural friction long before launch.

6. Tech Stack: Ready Today

LLMs: GPT-4-level or better for high alignment[11].
MCP: Standard bridge that lets agents control browsers and other tools[9][12].
Automation Servers: Browser MCP or Playwright MCP for GUI tasks[10].

7. Roll-Out Plan

Proof of Concept – spin up 3–5 key personas and test one flow.
Integrate – pipe results into existing A/B dashboards.
Scale – auto-generate new personas, add prompt-tuning loops, build reporting widgets.
Advance – predict reactions to unreleased features, run global localization checks, model competitor responses.

LLMs already let us see through our users’ eyes. Pair them with MCP automation, and you can iterate faster than ever—no waiting for live traffic.

References

[1] Karpathy A. “Software Is Changing (Again)” – YC AI Startup School

[2] Jung J. Trust or Escalate: LLM Judges with Provable Guarantees for Human Agreement

[3] Jung J. Trust or Escalate (companion study)

[4] Thakur A. S. Judging the Judges: Evaluating Alignment and Vulnerabilities in LLMs-as-Judges

[5] Park J. S. Simulating Human Behavior with AI Agents – Stanford HAI

[6] Park J. S. AgentA/B: Automated and Scalable Web A/B Testing with Interactive LLM Agents

[7] Park J. S. AgentA/B (v2)

[9] Anthropic. Introducing the Model Context Protocol

[10] Browser MCP. Automate your browser with AI

[11] MCP.so. Browser Automation MCP Server

[12] Microsoft. Model Context Protocol (MCP): Integrating Azure OpenAI

🔧 From Frustration to Success: How I Fixed a Stubborn Bug with AI Using Debug-Only Mode

Algis — Fri, 04 Jul 2025 16:47:56 +0000

Ever had an AI assistant confidently tell you “bug fixed!” several times… only to discover the bug is still alive and kicking? I sure did.

The Problem

I was fighting a stubborn UI glitch in the macOS tray menu of my side-project.

Using Cursor, I followed my normal routine: describe the bug in detail, list the steps to reproduce it, and spell out the expected behaviour.

My First Approach (That Failed)

I threw every model I had at the issue—Claude-4 Sonnet, Gemini 2.5 Pro, GPT-4.1 and even attached screenshots.

Each model rewrote different parts of the code and proudly announced “Fixed!”.

But when I ran the app, the bug was still there.

Worse, the AI sometimes got stuck in loops or removed unrelated features in its attempts to “help.” After a few hours, I realised I was spinning my wheels.

The Game-Changing Strategy: Debug-Only Mode

Instead of letting the AI rewrite code, I set one hard rule: the AI can only add debug logs—nothing else.

Here’s how it worked:

Restrict AI permissions – “Add log lines only.”
Get targeted grep commands – the AI supplies copy-ready commands after every change.
Feed real data back – run the app, reproduce the bug, paste the filtered logs into chat.
Repeat until breakthrough – short, focused iterations.

The Results

After 4–5 loops, we traced the culprit to bad cache invalidation in the data layer—nowhere near the UI. One tiny manual patch fixed everything.

Why This Works

Real data beats guesswork 📊
You stay in control 🎮
Fast feedback loops ⚡
Prevents scope creep 🎯

Your Turn

Have you tried limiting your AI assistant’s permissions?

What debugging tricks work best for you? Let me know in the comments!