Clear logo

MCP Integration Patterns

26 Sep 2025
Ankit Solanki
Co-founder at Clear. Exploring all possibilities of AI.
Engineering

We're building an agent system and I have been evaluating adding support for MCP.

We really care about our tool design to an unreasonable degree. I have personally spent days thinking about the right design for some of our tools.

I couldn't help but over-think exactly how MCP should be exposed to our agents. At a high level, I felt that there could be two integration patterns — I would name them the 'meta tool pattern' and 'materialised tools pattern'.

Meta Tool Pattern

Meta Tool Pattern

The meta tool pattern: the agent sees a few meta tools like 'list available MCP servers', 'describe MCP server', 'invoke MCP tool'.

The agent can decide to explore the capabilities of an MCP server and invoke its tools, when necessary. This design is flexible and efficient, but also requires a more capable agent:

  • This pattern uses less context by default. Tool definitions are lazily loaded only when required.
  • The 'discovery' calls for individual MCP servers need to happen only once in a given chat thread.
  • There's no guarantee that the agent will decide to explore the installed MCP servers though.

Materialised Tools Pattern

Materialised Tools Pattern

Here, whenever a MCP server is enabled – the system will automatically discover all available tools in the specific MCP server and eagerly copy them to the list of tools available to the agent. The agent sees all of these tools by default. Calling an MCP tool is just like calling any other tool.

  • This pattern makes tools really explicit to the agent.
  • This comes at the cost of using additional context, even when it's not necessary.
  • If multiple MCPs are installed, you may fast run out of context space.

Evaluating these patterns

If you were designing an agentic platform, which option would you choose? I did a survey of some existing open source systems and here's what I found:

  • codex-cli also uses the materialised tools pattern
  • opencode uses the materialised tools pattern
  • Cline uses a hybrid
    • All tools exposed by enabled MCP servers are copied to the system prompt
    • A single use_mcp_tool tool is used to invoke them
  • OpenManus also uses the materialised tools pattern.

This was a surprise. I'm not sure why the existing implementations are so heavily skewed towards materialised tools!

Our Decision

At this point I'm inclined to go with the meta tool pattern — it seems to make sense the system we're building.

What I have noticed is that:

  • Most MCP servers don't have a great agent interface.
  • They expose too many fine grained tools with overlapping responsibilities.
  • They are really wasteful of context tokens.

Most importantly: the meta tool pattern just intuitively feels like the right solution to me.

There are 100s of small details like this that go into building great products – and I have a feeling that these details are actually what differentiates your product when everyone is building on the same foundation models.