Part I: for Thought<\/p>\n
Every so often a simple idea rewires everything. The shipping container didn\u2019t just optimise logistics; it flattened the globe, collapsed time zones, and rewrote the economics of trade. In its geometric austerity was a quiet revolution: standardisation.<\/p>\n
Similarly, HTML and HTTP didn\u2019t invent information exchange \u2014 any more than the shipping crate invented trade \u2014 but by imposing order on chaos, they transformed it.<\/p>\n
RESTful APIs, for their part, standardised software-web interaction, and made services programmable. The web became not just browsable, but buildable \u2014 a foundation for automation, orchestration, and integration, and entire industries sprang up around that idea.<\/p>\n
Now, the \u2018agentic web\u2019\u2014where AI agents call APIs and other AI agents\u2014needs its own standards.<\/p>\n
This isn\u2019t just an extension of the last era \u2014 it\u2019s a shift in how computation works.<\/p>\n
Two promising approaches have emerged for agent-web interaction: Model Context Protocol (MCP) and Invoke Network.<\/p>\n
This essay compares these two paradigms \u2014 MCP and Invoke Network (disclosure: I\u2019m a contributor to Invoke Network) \u2014 and argues that agentic interoperability will require not just schemas and standards, but simplicity, statelessness, and runtime discovery.<\/p>\n
Part II: Model Context Protocol: Agents That Speak the Same Language<\/p>\n
Origins: From Local Tools to Shared Language<\/p>\n
Model Context Protocol<\/strong> <\/a>(MCP) emerged from a simple, powerful idea: that large language models (LLMs) should be able to talk to each other \u2014 and that their interactions should be modular, composable, and inspectable.<\/p>\n It began as part of the AI Engineer community on GitHub and Twitter \u2014 a loose but vibrant collective of developers exploring what happens when models gain agency. Early projects like OpenAgents and LangChain had already introduced the idea of tools: giving LLMs controlled access to functions. But MCP pushed the idea further.<\/p>\n Rather than hardcoding tools into individual agents, MCP proposed a standard \u2014 a shared grammar \u2014 that would allow any agent to dynamically expose capabilities and receive structured, interpretable requests. The goal: make agents composable and interoperable. Not just one agent using a tool, but agents calling agents, tools calling tools, and reasoning passed like a baton between models.<\/p>\n Introduced by Anthropic in November 2024, MCP is not a product. It\u2019s a protocol. A social contract for how agents communicate \u2014 much like HTTP was for web pages.<\/p>\n How MCP Works<\/p>\n At its core, MCP is a JSON-based interface description and call\/response format. Each agent (or tool, or model) advertises its capabilities by returning a set of structured functions \u2014 similar to an OpenAPI schema, but tailored for LLM interpretation.<\/p>\n A typical MCP exchange has three parts:<\/p>\n This sounds abstract, but it\u2019s surprisingly elegant in practice. Let\u2019s look at a real example \u2014 and use it to draw out the strengths and limits of MCP.<\/p>\n A Worked MCP Example: Agents That Call Each Other<\/p>\n Let\u2019s imagine two agents:<\/p>\n In this scenario, TripPlannerAgent has no hardcoded knowledge of how to fetch weather. It simply asks another agent that speaks MCP.<\/p>\n Step 1: WeatherAgent describes its capabilities<\/p>\n { This JSON schema is MCP-compliant. Any other agent can introspect this and know exactly how to invoke the weather function.<\/p>\n Step 2: TripPlannerAgent makes a structured call<\/p>\n { The agent doesn\u2019t need to know how the weather is fetched \u2014 it just needs to follow the protocol.<\/p>\n Step 3: WeatherAgent responds with structured data<\/p>\n { TripPlannerAgent can now use that result in its own logic \u2014 maybe suggesting a picnic or a museum day based on the weather.<\/p>\n What This Enables<\/p>\n This tiny example demonstrates several powerful capabilities:<\/p>\n \u2705 Agent Composition<\/strong> \u2014 agents can call other agents as tools But MCP has its limits \u2014 which we\u2019ll explore next.<\/p>\n When to Use MCP (And When Not To)<\/strong><\/p>\n Model Context Protocol (MCP) is elegant in its simplicity: a protocol for describing tools and delegating tasks between agents. But, like all protocols, it shines in some contexts and struggles in others.<\/p>\n \u2705 Where MCP Excels<\/p>\n 1. LLM-to-LLM Communication<\/strong> 2. Decentralised, Model-Agnostic Systems<\/strong> 3. Multi-Hop Planning<\/strong> \u274c Where MCP Struggles<\/p>\n 1. No Real \u201cRuntime\u201d<\/strong> MCP doesn\u2019t manage that for you \u2014 it\u2019s just the language agents use to communicate.<\/p>\n 2. Requires Structured Thinking<\/strong> 3. Tool Discovery and Versioning<\/strong><\/p>\n MCP is still early \u2014 there\u2019s no central registry of agents, no real system for versioning or namespacing. In practice, developers often pass around schemas manually or hardcode references.<\/p>\n And this is where Invoke Network<\/strong> enters \u2014 not as a competitor, but as a counterpart. If MCP is like WebSockets<\/strong> for agents (peer-to-peer, structured, low-level), then Invoke is like HTTP<\/strong> \u2014 a fire-and-forget API surface for LLMs.<\/p>\n Part III: Invoke Network<\/p>\n HTTP for LLMs<\/p>\n While MCP emerged to coordinate agents, Invoke<\/a> <\/strong>was born from a simpler, sharper pain: the chasm between LLMs and the real world.<\/p>\n Language models can reason, write, and plan \u2014 but without tools, they\u2019re sealed in a sandbox. Invoke began with a question:<\/p>\n What if any LLM could discover and use any real-world API, just like a human browses the web?<\/p>\n Existing approaches \u2014 MCP, OpenAI functions, AgentOps \u2014 while powerful, were either bloated, too rigid, or fragile for the vision. Tool use felt like duct-taping SDKs to natural language. Models had to be pre-wired to scattered tools, each with their own quirks.<\/p>\n Invoke approached it differently:<\/p>\n Just define your endpoint \u2014 method, URL, parameters, auth, example \u2014 in clean, readable JSON. That\u2019s it. Now any model<\/strong> (GPT, Claude, Mistral) can call it naturally, securely, and repeatedly.<\/p>\n \u2699\ufe0f How Invoke Works<\/p>\n At its core, Invoke is a tool router built for LLMs<\/strong>. It\u2019s like openapi.json, but leaner \u2014 built for inference, not engineering.<\/p>\n Here\u2019s how it works:<\/p>\n No custom wrappers. No chains. No scaffolding. Just one clean interface. And if something goes wrong? <\/strong>We don\u2019t preprogram retries. We let the model decide. Turns out: it\u2019s pretty good at it.<\/p>\n Here\u2019s a real example:<\/p>\n { From the model\u2019s point of view, this is one use of the \u2018Invoke\u2019 tool, not a new one for each added endpoint. Not a custom plugin. Just one discoverable interface. This means the model can discover APIs on the fly, just like humans browse the web. To use the shipping container analogy, if MCP allows highly coordinated workflows with tightly orchestrated infrastructure between select ports, Invoke enables you to send any package, anywhere, any time.<\/p>\n Now we can use:<\/p>\n # 1. Install dependencies: from langchain_openai import ChatOpenAI # 2. Initialize your LLM and Invoke agent # 3. Chat loop\u2014any natural-language query that matches your agents.json print(“\ud83e\udd16 Agent:”, response)<\/p>\n In under a minute, your model is fetching live data\u2014no wrappers, no boilerplate.<\/p>\n You\u2019ll say: \u201cCheck weather in London.\u201d Just as robots.txt let crawlers safely navigate the web, agents.json lets LLMs safely act on it. Invoke turns the web into an LLM-readable ecosystem of APIs. Much like HTML allowed humans to discover websites and services on the fly, Invoke allows LLMs to discover APIs at inference time.<\/p>\n Want to see this in action? Check out the Invoke repo\u2019s example notebooks<\/a>, see how to define<\/a> an agents.json, wire up auth, and call APIs from any LLM in under a minute. (Full \u201cnetwork\u201d-style discovery is on the roadmap once adoption reaches critical mass.)<\/p>\n When to Use Invoke: Strengths and Tradeoffs<\/p>\n Invoke shines brightest in the real world.<\/p>\n Its core premise \u2014 that a model can call any API, securely and accurately, from a single schema \u2014 unlocks a staggering range of use cases: calendar assistants, email triage, weather bots, automation interfaces, customer support agents, enterprise copilots, even full-stack LLM-powered workflows. And it works out of the box with OpenAI, Claude, LangChain, and more.<\/p>\n Strengths:<\/strong><\/p>\n But like any system, Invoke has tradeoffs.<\/p>\n Limitations:<\/strong><\/p>\n MCP vs. Invoke: Two Roads Into the Agentic Web<\/p>\n Both MCP and Invoke aim to bring LLMs into contact with the real world \u2014 but they approach it from opposite directions.<\/p>\n Conclusion: The Shape of the Agentic Web<\/p>\n We are witnessing the emergence of a new layer of the internet \u2014 one defined not by human clicks or software calls, but by autonomous agents that reason, plan, and act.<\/p>\n If the early web was built on human-readable pages (HTML) and programmatic endpoints (REST), the agentic web demands a new foundation: standards and frameworks that let models interact with the world as fluidly as humans once did with hyperlinks.<\/p>\n Two approaches \u2014 Model Context Protocol<\/strong> and Invoke<\/strong> \u2014 offer different visions of how this interaction should work:<\/p>\n Neither is the solution. Much like the early internet needed both TCP and HTTP, the agentic layer will be pluralistic. But history suggests something: the tools that win are the ones that are easiest to adopt<\/strong>.<\/p>\n Invoke is already proving useful to developers who just want to connect an LLM to the services they already use. MCP is laying the groundwork for more complex agent systems. Together, they\u2019re sketching the contours of what\u2019s to come.<\/p>\n The agentic web won\u2019t be built in a single day, and it won\u2019t be built by a single company. But one thing is clear: the future of the web is no longer just human-readable or machine-readable \u2014 it\u2019s model-readable.<\/p>\n\n
<\/strong> An agent exposes a set of callable functions \u2014 their names, parameters, return types, and descriptions. These can be real tools (like get_weather) or delegations to other agents (like research_topic).<\/li>\n
<\/strong> Another model (or the user) sends a request to that agent using the defined format. MCP keeps the payloads structured and minimal, avoiding ambiguous natural language where it matters.<\/li>\n
<\/strong> The receiving agent executes the function (or prompts another model), and returns a structured response, often annotated with rationale or follow-up context.<\/li>\n<\/ol>\n\n
\n\u00a0\u00a0“functions”: [
\n\u00a0\u00a0\u00a0\u00a0{
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“name”: “get_weather”,
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“description”: “Returns the current weather in a given city”,
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“parameters”: {
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“type”: “object”,
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“properties”: {
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“city”: {
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“type”: “string”,
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“description”: “The city to get weather for”
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0},
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“required”: [“city”]
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}
\n\u00a0\u00a0\u00a0\u00a0}
\n\u00a0\u00a0]
\n}<\/p>\n
\n\u00a0\u00a0“call”: {
\n\u00a0\u00a0\u00a0\u00a0“function”: “get_weather”,
\n\u00a0\u00a0\u00a0\u00a0“arguments”: {
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“city”: “San Francisco”
\n\u00a0\u00a0\u00a0\u00a0}
\n\u00a0\u00a0}
\n}<\/p>\n
\n\u00a0\u00a0“response”: {
\n\u00a0\u00a0\u00a0\u00a0“result”: {
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“temperature”: “21\u00b0C”,
\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0“condition”: “Sunny”
\n\u00a0\u00a0\u00a0\u00a0},
\n\u00a0\u00a0\u00a0\u00a0“explanation”: “It\u2019s currently sunny and 21\u00b0C in San Francisco.”
\n\u00a0\u00a0}
\n}<\/p>\n
\u2705 Inspectability<\/strong> \u2014 capabilities are defined in schemas, not prose
\u2705 Reusability<\/strong> \u2014 agents can serve many clients
\u2705 LLM-native design<\/strong> \u2014 responses are still interpretable by models<\/p>\n
<\/strong> MCP was designed from the ground up to support inter-agent calls. If you\u2019re building a network of AI agents that can call, query, or consult one another, MCP is ideal. Each agent becomes a service endpoint, with a schema that other agents can reason about.<\/p>\n
<\/strong> Because MCP is just a schema convention, it doesn\u2019t depend on any particular runtime, framework, or model. You can use OpenAI, Claude, or your local LLM \u2014 if it can interpret JSON, it can speak MCP.<\/p>\n
<\/strong> MCP is especially powerful when combined with a planner agent. Imagine a central planner that orchestrates workflows by dynamically selecting agents based on their schemas. This enables highly modular, dynamic systems.<\/p>\n
<\/strong>MCP is a protocol \u2014 not a framework. It defines the interface, but not the execution engine. That means you need to implement your own glue logic for:<\/p>\n\n
<\/strong>LLMs love ambiguity. MCP doesn\u2019t. It forces developers (and models) to be explicit: here\u2019s a tool, here\u2019s its schema, here\u2019s how to call it. That\u2019s great for clarity \u2014 but requires more upfront thinking than, say, slapping .tools = [\u2026] on an OpenAI agent.<\/p>\n\n Use Case<\/strong><\/td>\n Should You Use MCP?<\/strong><\/td>\n<\/tr>\n \n Agent calling another agent<\/td>\n \u2705 Perfect fit<\/td>\n<\/tr>\n \n Building a large, modular agent network<\/td>\n \u2705 Ideal<\/td>\n<\/tr>\n \n Call a REST API or webhook<\/td>\n \u274c Overkill<\/td>\n<\/tr>\n \n Need built-in routing, OAuth, retries<\/td>\n \u274c Use a framework<\/td>\n<\/tr>\n \n Tool discovery at inference time<\/td>\n \u274c Use Invoke Network<\/td>\n<\/tr>\n \n
\n
\n
\n “agent”: “openweathermap”,
\n “label”: “\ud83c\udf24 OpenWeatherMap API”,
\n “base_url”: “https:\/\/api.openweathermap.org”,
\n “auth”: {
\n “type”: “query”,
\n “format”: “appid”,
\n “code”: “i”
\n },
\n “endpoints”: [
\n {
\n “name”: “current_weather”,
\n “label”: “\u2600\ufe0f Current Weather Data”,
\n “description”: “Retrieve current weather data for a specific city.”,
\n “method”: “GET”,
\n “path”: “\/data\/2.5\/weather”,
\n “query_params”: {
\n “q”: “City name to retrieve weather for (string, required).”
\n },
\n “examples”: [
\n {
\n “url”: “https:\/\/api.openweathermap.org\/data\/2.5\/weather?q=London”
\n }
\n ]
\n }
\n ]
\n}<\/p>\n
\n# pip install langchain-openai invoke-agent<\/p>\n
\nfrom invoke_agent.agent import InvokeAgent<\/p>\n
\nllm = ChatOpenAI(model=”gpt-4.1″)
\ninvoke = InvokeAgent(llm, agents=[“path-or-url\/agents.json”])<\/p>\n
\nuser_input = input(“\ud83d\udcdd You: “).strip()
\nresponse = invoke.chat(user_input)<\/p>\n
The agent will go to openweathermap.org\/agents.json, read the file, and just\u2026 do it.<\/p>\n\n
\n
\n Feature<\/strong><\/td>\n Model Context Protocol (MCP)<\/strong><\/td>\n Invoke<\/strong><\/td>\n<\/tr>\n \n Core Goal<\/strong><\/td>\n Agent-to-agent coordination via message passing<\/td>\n LLM-to-API integration via structured tool use<\/td>\n<\/tr>\n \n Design Origin<\/strong><\/td>\n Comparable to protocols like WebSockets and JSON-RPC<\/td>\n Inspired by REST\/HTTP and OpenAPI<\/td>\n<\/tr>\n \n Primary Use Case<\/strong><\/td>\n Composing multi-agent workflows and message pipelines<\/td>\n Connecting LLMs directly to real-world APIs<\/td>\n<\/tr>\n \n Communication Style<\/strong><\/td>\n Stateful sessions and messages exchanged between agents<\/td>\n Stateless, schema-driven tool calls<\/td>\n<\/tr>\n \n Tool Discovery<\/strong><\/td>\n Agents must be pre-wired with capabilities<\/td>\n Tool schemas can be discovered at runtime (agents.json)<\/td>\n<\/tr>\n \n Error Handling<\/strong><\/td>\n Delegated to agent frameworks or orchestration layers<\/td>\n Handled by the model, optionally guided by context<\/td>\n<\/tr>\n \n Dependencies<\/strong><\/td>\n Requires MCP-compatible infra and agents<\/td>\n Just needs model + JSON tool definition<\/td>\n<\/tr>\n \n Composable With<\/strong><\/td>\n AutoGPT-style ecosystems, custom agent graphs<\/td>\n LangChain, OpenAI tool use, custom scripts<\/td>\n<\/tr>\n \n Strengths<\/strong><\/td>\n Fine-grained control, extensible routing, agent memory<\/td>\n Simplicity, developer ergonomics, real-world compatibility<\/td>\n<\/tr>\n \n Limitations<\/strong><\/td>\n Heavier to implement, requires full stack, context bloat, tool overload<\/td>\n Stateless by design, no agent memory or recursion<\/td>\n<\/tr>\n \n