This blog post is an exploration of the Model Context Protocol (MCP) and its ecosystem, including registry and agent integrations, from our practical point of view.
Model Context Protocol
Anthropic’s MCP is an open standard that defines how LLM can call external tools and data sources through a common interface. Think of it as a USB-C for AI agents.
The 3 main components are the host <-> client <-> server. An MCP server publishes tools, resources and prompts via HTTP or SSE. A client calls the server APIs, and the host, which can be an AI agent or a UI like Claude Desktop spins a client per each tool connection.
The reason to separate host from the client has to do with the legacy stateful implementation, so that each client can keep its own state. This cause some unnecessary confusion, so the easiest way to think of MCP is actually as a client <-> server, where the client is the AI agent.

Why the Need For Another Protocol?
Every AI integration is bespoke, engineers must handcraft an OpenAI spec, function schema, or JSON schema to wire the tools via API calls. OpenAI and other hyperscalers tried to standardize how we integrate with a tool.
IMO what made MCP standard stand out was the easy tutorial to create and integrate a tool in Claude Desktop and the promises of the open registries, to let anyone publish and share their tools; let me also tell you the quite part out loud, Anthropic invested heavily in the marketing of MCP, so a big reason for its traction was the well-timed, well-targeted marketing push, that landed with the right audience: engineers.
MCP aims to solve most problems in the AI agent ecosystems:
- Tools integration
- Agent-to-agent communication
- Authentication & authorization
- Payments
- Tools discovery
Turns out, these were problems we all had, we just didn’t have a common way to fix them, and MCP came at the right time.

Current State
In just 7 months since launch, MCP has gone from a draft spec to running code in the wild:
- Hundreds of open-source MCP servers are now live on GitHub.
- Platforms like Apify, Chakra, and Parsed ship MCP-first APIs, giving AI agents instant access to all their services with a single connection.
- Claude, Cursor, OpenAI and other AI platforms are rolling out built-in MCP adapters.
MCP has moved from concept to ecosystem, really fast.
Problems waiting to be solved
Most problems with MCP are caused by the inherent limitation of the LLMs, although some problems with MCP have to do with the lack of full implementation:
- Hallucination and context limits, the main problem with MCP is that agents hallucinate often, calling the wrong tools, this especially happens when you assign more than 10 tools to an agent.
- Security & auth, the spec leaves authentication up to each server; OAuth-style extension are still in draft.
- Versioning, there’s no formal way to tell a model that a tool schema changed.
- Trust and service discovery at scale, public registries exists but lack signed metadata, so trust and curation remain open questions.
- Latency, round trips over SSE/HTTP can bottleneck multistep agent plans.
- P2P Payments, the standard for how payment will be executed is yet to be defined.
Integrating MCP in Flow Any service behind an API can be turned into an MCP tool. We’ve integrated MCP across our entire platform so agents can both run behind an MCP server, act as an MCP host to connect with external tools, as well as running our tools as MCP servers. Partnering with other service provider thanks to MCP for us it becomes as easy as adding a row in our database, and for our partners has the advantage to prepare the integration only once.
Our MCP integrations
-
MCP Registry (flowai.xyz/tools) Browse and use all of our tools in one place so Claude Desktop and other agents can call them directly.
-
Flow MCP Server (Apify & Flow AI Agents) We can run Flow AI agents behind an MCP server, enabling you to call them from Claude Desktop or other agents. This enabled us to partner with Apify and to integrate Flow in their platform as an actor (apify.com/docs).
-
MCP Tools (Internal & External) Flow can use internal and external tools that are published via MCP. For example we integrated Chakra Parsed, and Coingecko via MCP
The Future of MCP: agent swarms, tools workflows, and RLHF/RFT
A swarm of agents can dynamically discover new tools, delegate work, and optimize results, exactly the kind of composability needed for autonomous, web scale tasks. Expect to see agents learning how to use tools dynamically (RLHF/RFT) and how to optimize agents to agents interactions.
When that happens, MCP won’t just be a protocol, it will be the connective tissue of the agent network.

Stay Updated
Get the latest AI insights delivered to your inbox. No spam, unsubscribe anytime.
About the Authors
Related Posts

OpenClaw & Moltbook: The Rise of the Agent Internet
This blog post was written by OpenClaw. It's a research of what OpenClaw and Moltbook are from the AI agent itself.
DeFAI Agents Stages — Part 2
DeFAI = DeFi + AI. Keep Web3 deterministic: intelligence sits above the app layer. Agentic workflows (DAGs) enable reproducible, debuggable DeFi transaction plans.

DeFAI Agents Primitives — Part 1
DeFAI = DeFi + AI, but agents shouldn’t replace deterministic infra. Web3 is a state machine: keep intelligence above the application layer. The right path is agentic workflows (DAGs) for reproducible, debuggable DeFi transaction plans—until wallet UX catches up.
