Half I: for Thought
Once in a while a easy concept rewires the whole lot. The delivery container didn’t simply optimise logistics; it flattened the globe, collapsed time zones, and rewrote the economics of commerce. In its geometric austerity was a quiet revolution: standardisation.
Equally, HTML and HTTP didn’t invent info alternate — any greater than the delivery crate invented commerce — however by imposing order on chaos, they remodeled it.
RESTful APIs, for his or her half, standardised software-web interplay, and made providers programmable. The net turned not simply browsable, however buildable — a basis for automation, orchestration, and integration, and whole industries sprang up round that concept.
Now, the ‘agentic internet’—the place AI brokers name APIs and different AI brokers—wants its personal requirements.
This isn’t simply an extension of the final period — it’s a shift in how computation works.
Two promising approaches have emerged for agent-web interplay: Mannequin Context Protocol (MCP) and Invoke Community.
- Model Context Protocol (MCP): a communication customary designed for chaining reasoning throughout a number of brokers, instruments, and fashions.
- Invoke Network: a light-weight, open-source framework that lets fashions work together straight with real-world APIs at inference time — with no need orchestration, backends, or agent registries.
This essay compares these two paradigms — MCP and Invoke Community (disclosure: I’m a contributor to Invoke Community) — and argues that agentic interoperability would require not simply schemas and requirements, however simplicity, statelessness, and runtime discovery.
Half II: Mannequin Context Protocol: Brokers That Converse the Identical Language
Origins: From Native Instruments to Shared Language
Model Context Protocol (MCP) emerged from a easy, highly effective concept: that giant language fashions (LLMs) ought to have the ability to speak to one another — and that their interactions must be modular, composable, and inspectable.
It started as a part of the AI Engineer group on GitHub and Twitter — a free however vibrant collective of builders exploring what occurs when fashions acquire company. Early tasks like OpenAgents and LangChain had already launched the thought of instruments: giving LLMs managed entry to capabilities. However MCP pushed the thought additional.
Fairly than hardcoding instruments into particular person brokers, MCP proposed a normal — a shared grammar — that might permit any agent to dynamically expose capabilities and obtain structured, interpretable requests. The objective: make brokers composable and interoperable. Not only one agent utilizing a software, however brokers calling brokers, instruments calling instruments, and reasoning handed like a baton between fashions.
Launched by Anthropic in November 2024, MCP isn’t a product. It’s a protocol. A social contract for the way brokers talk — very like HTTP was for internet pages.
How MCP Works
At its core, MCP is a JSON-based interface description and name/response format. Every agent (or software, or mannequin) advertises its capabilities by returning a set of structured capabilities — much like an OpenAPI schema, however tailor-made for LLM interpretation.
A typical MCP alternate has three elements:
- Itemizing Capabilities
An agent exposes a set of callable capabilities — their names, parameters, return sorts, and descriptions. These might be actual instruments (like get_weather) or delegations to different brokers (like research_topic). - Issuing a Name
One other mannequin (or the consumer) sends a request to that agent utilizing the outlined format. MCP retains the payloads structured and minimal, avoiding ambiguous pure language the place it issues. - Dealing with the Response
The receiving agent executes the operate (or prompts one other mannequin), and returns a structured response, usually annotated with rationale or follow-up context.
This sounds summary, nevertheless it’s surprisingly elegant in observe. Let’s have a look at an actual instance — and use it to attract out the strengths and limits of MCP.
A Labored MCP Instance: Brokers That Name Every Different
Let’s think about two brokers:
- WeatherAgent: Supplies climate information.
- TripPlannerAgent: Plans a day journey, and makes use of the WeatherAgent by way of MCP to test the climate.
On this state of affairs, TripPlannerAgent has no hardcoded information of tips on how to fetch climate. It merely asks one other agent that speaks MCP.
Step 1: WeatherAgent describes its capabilities
{
"capabilities": [
{
"name": "get_weather",
"description": "Returns the current weather in a given city",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "The city to get weather for"
}
},
"required": ["city"]
}
}
]
}
This JSON schema is MCP-compliant. Some other agent can introspect this and know precisely tips on how to invoke the climate operate.
Step 2: TripPlannerAgent makes a structured name
{
"name": {
"operate": "get_weather",
"arguments": {
"metropolis": "San Francisco"
}
}
}
The agent doesn’t have to understand how the climate is fetched — it simply must observe the protocol.
Step 3: WeatherAgent responds with structured information
{
"response": {
"outcome": {
"temperature": "21°C",
"situation": "Sunny"
},
"rationalization": "It’s presently sunny and 21°C in San Francisco."
}
}
TripPlannerAgent can now use that lead to its personal logic — perhaps suggesting a picnic or a museum day based mostly on the climate.
What This Allows
This tiny instance demonstrates a number of highly effective capabilities:
✅ Agent Composition — brokers can name different brokers as instruments
✅ Inspectability — capabilities are outlined in schemas, not prose
✅ Reusability — brokers can serve many purchasers
✅ LLM-native design — responses are nonetheless interpretable by fashions
However MCP has its limits — which we’ll discover subsequent.
When to Use MCP (And When Not To)
Mannequin Context Protocol (MCP) is elegant in its simplicity: a protocol for describing instruments and delegating duties between brokers. However, like all protocols, it shines in some contexts and struggles in others.
✅ The place MCP Excels
1. LLM-to-LLM Communication
MCP was designed from the bottom as much as help inter-agent calls. Should you’re constructing a community of AI brokers that may name, question, or seek the advice of each other, MCP is good. Every agent turns into a service endpoint, with a schema that different brokers can cause about.
2. Decentralised, Mannequin-Agnostic Techniques
As a result of MCP is only a schema conference, it doesn’t rely upon any specific runtime, framework, or mannequin. You should utilize OpenAI, Claude, or your native LLM — if it may interpret JSON, it may converse MCP.
3. Multi-Hop Planning
MCP is very highly effective when mixed with a planner agent. Think about a central planner that orchestrates workflows by dynamically deciding on brokers based mostly on their schemas. This permits extremely modular, dynamic programs.
❌ The place MCP Struggles
1. No Actual “Runtime”
MCP is a protocol — not a framework. It defines the interface, however not the execution engine. Meaning you should implement your individual glue logic for:
- Auth
- Enter/output mapping
- Routing
- Error dealing with
- Retries
- Charge limits
MCP doesn’t handle that for you — it’s simply the language brokers use to speak.
2. Requires Structured Considering
LLMs love ambiguity. MCP doesn’t. It forces builders (and fashions) to be express: right here’s a software, right here’s its schema, right here’s tips on how to name it. That’s nice for readability — however requires extra upfront pondering than, say, slapping .instruments = […] on an OpenAI agent.
3. Device Discovery and Versioning
MCP continues to be early — there’s no central registry of brokers, no actual system for versioning or namespacing. In observe, builders usually cross round schemas manually or hardcode references.
Use Case | Ought to You Use MCP? |
Agent calling one other agent | ✅ Excellent match |
Constructing a big, modular agent community | ✅ Best |
Name a REST API or webhook | ❌ Overkill |
Want built-in routing, OAuth, retries | ❌ Use a framework |
Device discovery at inference time | ❌ Use Invoke Community |
And that is the place Invoke Community enters — not as a competitor, however as a counterpart. If MCP is like WebSockets for brokers (peer-to-peer, structured, low-level), then Invoke is like HTTP — a fire-and-forget API floor for LLMs.
Half III: Invoke Community
HTTP for LLMs
Whereas MCP emerged to coordinate brokers, Invoke was born from a less complicated, sharper ache: the chasm between LLMs and the true world.
Language fashions can cause, write, and plan — however with out instruments, they’re sealed in a sandbox. Invoke started with a query:
What if any LLM may uncover and use any real-world API, identical to a human browses the net?
Present approaches — MCP, OpenAI capabilities, AgentOps — whereas highly effective, had been both bloated, too inflexible, or fragile for the imaginative and prescient. Device use felt like duct-taping SDKs to pure language. Fashions needed to be pre-wired to scattered instruments, every with their very own quirks.
Invoke approached it otherwise:
- One software, many APIs
- One customary, infinite interfaces
Simply outline your endpoint — methodology, URL, parameters, auth, instance — in clear, readable JSON. That’s it. Now any mannequin (GPT, Claude, Mistral) can name it naturally, securely, and repeatedly.
⚙️ How Invoke Works
At its core, Invoke is a software router constructed for LLMs. It’s like openapi.json, however leaner — constructed for inference, not engineering.
Right here’s the way it works:
- You write a structured software definition (brokers.json) with:
- methodology, url, auth, parameters, and an instance.
- Invoke parses that right into a callable operate for any mannequin that helps software use.
- The mannequin sees the software, decides when to make use of it, and fills out the parameters.
- Invoke handles the remaining — auth, formatting, execution — and returns the outcome.
No customized wrappers. No chains. No scaffolding. Only one clear interface. And if one thing goes improper? We don’t preprogram retries. We let the mannequin resolve. Seems: it’s fairly good at it.
Right here’s an actual instance:
{
"agent": "openweathermap",
"label": "🌤 OpenWeatherMap API",
"base_url": "https://api.openweathermap.org",
"auth": {
"kind": "question",
"format": "appid",
"code": "i"
},
"endpoints": [
{
"name": "current_weather",
"label": "☀️ Current Weather Data",
"description": "Retrieve current weather data for a specific city.",
"method": "GET",
"path": "/data/2.5/weather",
"query_params": {
"q": "City name to retrieve weather for (string, required)."
},
"examples": [
{
"url": "https://api.openweathermap.org/data/2.5/weather?q=London"
}
]
}
]
}
From the mannequin’s viewpoint, that is one use of the ‘Invoke’ software, not a brand new one for every added endpoint. Not a customized plugin. Only one discoverable interface. This implies the mannequin can uncover APIs on the fly, identical to people browse the net. To make use of the delivery container analogy, if MCP permits extremely coordinated workflows with tightly orchestrated infrastructure between choose ports, Invoke lets you ship any package deal, anyplace, any time.
Now we are able to use:
# 1. Set up dependencies:
# pip set up langchain-openai invoke-agent
from langchain_openai import ChatOpenAI
from invoke_agent.agent import InvokeAgent
# 2. Initialize your LLM and Invoke agent
llm = ChatOpenAI(mannequin="gpt-4.1")
invoke = InvokeAgent(llm, brokers=["path-or-url/agents.json"])
# 3. Chat loop—any natural-language question that matches your brokers.json
user_input = enter("📝 You: ").strip()
response = invoke.chat(user_input)
print("🤖 Agent:", response)
In below a minute, your mannequin is fetching dwell information—no wrappers, no boilerplate.
You’ll say: “Test climate in London.”
The agent will go to openweathermap.org/brokers.json, learn the file, and simply… do it.
Simply as robots.txt
let crawlers safely navigate the net, brokers.json lets LLMs safely act on it. Invoke turns the net into an LLM-readable ecosystem of APIs. Very similar to HTML allowed people to find web sites and providers on the fly, Invoke permits LLMs to find APIs at inference time.
Wish to see this in motion? Try the Invoke repo’s example notebooks, see how to define an brokers.json
, wire up auth, and name APIs from any LLM in below a minute. (Full “community”-style discovery is on the roadmap as soon as adoption reaches essential mass.)
When to Use Invoke: Strengths and Tradeoffs
Invoke shines brightest in the true world.
Its core premise — {that a} mannequin can name any API, securely and precisely, from a single schema — unlocks a staggering vary of use instances: calendar assistants, e mail triage, climate bots, automation interfaces, buyer help brokers, enterprise copilots, even full-stack LLM-powered workflows. And it really works out of the field with OpenAI, Claude, LangChain, and extra.
Strengths:
- Simplicity. Outline a software as soon as, use it all over the place. You don’t want a dozen Python wrappers or agent configs.
- Mannequin-agnostic. Invoke works with any mannequin that helps structured software use — together with open-source LLMs.
- Open & extensible. Serve instruments from native config, hosted registries, or future public endpoints (instance.com/brokers.json).
- Composable. Fashions can cause over software metadata, examine auth necessities, and even resolve when to discover new capabilities.
- Developer-focused. In contrast to agentic frameworks that require advanced orchestration, Invoke slots neatly into current stacks — frontends, backends, workflows, RAG pipelines, and extra.
- Context-efficient. API configurations are outlined within the execution chain and don’t use treasured context.
- Discoverable at runtime. Invoke connections usually are not hard-wired at compile and usually are not restricted at setup.
However like every system, Invoke has tradeoffs.
Limitations:
- No central reminiscence or state. It doesn’t handle long-term plans, context home windows, or recursive subtasks. That’s left to you — or to different frameworks layered on high.
- No retries, timeouts, or multi-step workflows baked in. Invoke trusts the mannequin to deal with partial failure. In observe, GPT-4 and Claude do that remarkably properly — nevertheless it’s nonetheless a philosophical alternative.
- Statelessness. Instruments are evaluated per invocation. Whereas this retains issues clear and atomic, it could not go well with advanced, multi-step brokers with out further scaffolding.
MCP vs. Invoke: Two Roads Into the Agentic Internet
Each MCP and Invoke purpose to carry LLMs into contact with the true world — however they method it from reverse instructions.
Function | Mannequin Context Protocol (MCP) | Invoke |
Core Objective | Agent-to-agent coordination by way of message passing | LLM-to-API integration by way of structured software use |
Design Origin | Corresponding to protocols like WebSockets and JSON-RPC | Impressed by REST/HTTP and OpenAPI |
Major Use Case | Composing multi-agent workflows and message pipelines | Connecting LLMs on to real-world APIs |
Communication Fashion | Stateful periods and messages exchanged between brokers | Stateless, schema-driven software calls |
Device Discovery | Brokers have to be pre-wired with capabilities | Device schemas might be found at runtime (brokers.json) |
Error Dealing with | Delegated to agent frameworks or orchestration layers | Dealt with by the mannequin, optionally guided by context |
Dependencies | Requires MCP-compatible infra and brokers | Simply wants mannequin + JSON software definition |
Composable With | AutoGPT-style ecosystems, customized agent graphs | LangChain, OpenAI software use, customized scripts |
Strengths | Effective-grained management, extensible routing, agent reminiscence | Simplicity, developer ergonomics, real-world compatibility |
Limitations | Heavier to implement, requires full stack, context bloat, software overload | Stateless by design, no agent reminiscence or recursion |
Conclusion: The Form of the Agentic Internet
We’re witnessing the emergence of a brand new layer of the web — one outlined not by human clicks or software program calls, however by autonomous brokers that cause, plan, and act.
If the early internet was constructed on human-readable pages (HTML) and programmatic endpoints (REST), the agentic internet calls for a brand new basis: requirements and frameworks that allow fashions work together with the world as fluidly as people as soon as did with hyperlinks.
Two approaches — Mannequin Context Protocol and Invoke — supply totally different visions of how this interplay ought to work:
- MCP is good if you want coordination between a number of brokers, session state, or recursive reasoning — the WebSockets of the agentic internet.
- Invoke is good if you want light-weight, one-shot software use with real-world APIs — the HTTP of the agentic internet.
Neither is the resolution. Very similar to the early web wanted each TCP and HTTP, the agentic layer can be pluralistic. However historical past suggests one thing: the instruments that win are those which are best to undertake.
Invoke is already proving helpful to builders who simply wish to join an LLM to the providers they already use. MCP is laying the groundwork for extra advanced agent programs. Collectively, they’re sketching the contours of what’s to return.
The agentic internet gained’t be inbuilt a single day, and it gained’t be constructed by a single firm. However one factor is obvious: the way forward for the net is now not simply human-readable or machine-readable — it’s model-readable.
In regards to the writer
I’m a lead researcher at Commonwealth Financial institution AI Labs and contributor to Invoke Community, an open-source agentic-web framework. Suggestions and forks welcome: https://github.com/mercury0100/invoke