Agents, APIs, and the Next Layer of the Internet

Half I: for Thought

Once in a while a easy concept rewires every little thing. The transport 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 data change — any greater than the transport 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 companies programmable. The online grew to become not simply browsable, however buildable — a basis for automation, orchestration, and integration, and full 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 normal 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 immediately with real-world APIs at inference time — while not having 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 Similar 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 be capable to speak to one another — and that their interactions must be modular, composable, and inspectable.

It started as a part of the AI Engineer neighborhood on GitHub and Twitter — a unfastened however vibrant collective of builders exploring what occurs when fashions acquire company. Early tasks like OpenAgents and LangChain had already launched the concept of instruments: giving LLMs managed entry to capabilities. However MCP pushed the concept additional.

Moderately than hardcoding instruments into particular person brokers, MCP proposed an ordinary — a shared grammar — that may permit any agent to dynamically expose capabilities and obtain structured, interpretable requests. The aim: 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 will not be a product. It’s a protocol. A social contract for the way brokers talk — very similar to 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 — just like an OpenAPI schema, however tailor-made for LLM interpretation.

A typical MCP change has three components:

1. Itemizing Capabilities
   An agent exposes a set of callable capabilities — their names, parameters, return sorts, and descriptions. These could be actual instruments (like get_weather) or delegations to different brokers (like research_topic).
2. 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.
3. Dealing with the Response
   The receiving agent executes the perform (or prompts one other mannequin), and returns a structured response, typically annotated with rationale or follow-up context.

This sounds summary, but it surely’s surprisingly elegant in observe. Let’s take 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: Gives climate knowledge.
• TripPlannerAgent: Plans a day journey, and makes use of the WeatherAgent through MCP to verify the climate.

On this situation, TripPlannerAgent has no hardcoded data of methods 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. Every other agent can introspect this and know precisely methods to invoke the climate perform.

Step 2: TripPlannerAgent makes a structured name

{
  "name": {
    "perform": "get_weather",
    "arguments": {
      "metropolis": "San Francisco"
    }
  }
}

The agent doesn’t must know the way the climate is fetched — it simply must comply with the protocol.

Step 3: WeatherAgent responds with structured knowledge

{
  "response": {
    "end result": {
      "temperature": "21°C",
      "situation": "Sunny"
    },
    "rationalization": "It’s at the moment sunny and 21°C in San Francisco."
  }
}

TripPlannerAgent can now use that lead to its personal logic — possibly suggesting a picnic or a museum day based mostly on the climate.

What This Permits

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 consumers
✅ 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 assist 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 right. Every agent turns into a service endpoint, with a schema that different brokers can cause about.

2. Decentralised, Mannequin-Agnostic Methods
As a result of MCP is only a schema conference, it doesn’t rely upon any specific runtime, framework, or mannequin. You need to use OpenAI, Claude, or your native LLM — if it will probably interpret JSON, it will probably converse MCP.

3. Multi-Hop Planning
MCP is particularly 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. Which means you must implement your personal glue logic for:

• Auth
• Enter/output mapping
• Routing
• Error dealing with
• Retries
• Price limits

MCP doesn’t handle that for you — it’s simply the language brokers use to speak.

2. Requires Structured Pondering
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 methods to name it. That’s nice for readability — however requires extra upfront pondering than, say, slapping .instruments = […] on an OpenAI agent.

3. Software Discovery and Versioning

MCP remains to be early — there’s no central registry of brokers, no actual system for versioning or namespacing. In observe, builders typically go round schemas manually or hardcode references.

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 actual 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 might 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. Software 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 normal, 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:

1. You write a structured software definition (brokers.json) with:
   • methodology, url, auth, parameters, and an instance.
2. Invoke parses that right into a callable perform for any mannequin that helps software use.
3. The mannequin sees the software, decides when to make use of it, and fills out the parameters.
4. Invoke handles the remaining — auth, formatting, execution — and returns the end result.

No customized wrappers. No chains. No scaffolding. Only one clear interface. And if one thing goes fallacious? 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": {
    "sort": "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 perspective, 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 transport container analogy, if MCP permits extremely coordinated workflows with tightly orchestrated infrastructure between choose ports, Invoke lets you ship any bundle, wherever, 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 beneath a minute, your mannequin is fetching dwell knowledge—no wrappers, no boilerplate.

You’ll say: “Examine 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 companies on the fly, Invoke permits LLMs to find APIs at inference time.

Wish to see this in motion? Take a look at the Invoke repo’s example notebooks, see how to define an brokers.json, wire up auth, and name APIs from any LLM in beneath 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 actual world.

Its core premise — {that a} mannequin can name any API, securely and precisely, from a single schema — unlocks a staggering vary of use circumstances: calendar assistants, electronic mail triage, climate bots, automation interfaces, buyer assist 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 in all places. 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 present stacks — frontends, backends, workflows, RAG pipelines, and extra.
• Context-efficient. API configurations are outlined within the execution chain and don’t use valuable context.
• Discoverable at runtime. Invoke connections are usually not hard-wired at compile and are usually not restricted at setup.

However like all 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 prime.
• 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 effectively — but it surely’s nonetheless a philosophical selection.
• Statelessness. Instruments are evaluated per invocation. Whereas this retains issues clear and atomic, it could not swimsuit advanced, multi-step brokers with out further scaffolding.

MCP vs. Invoke: Two Roads Into the Agentic Internet

Each MCP and Invoke intention to convey LLMs into contact with the actual world — however they method it from reverse instructions.

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 permit fashions work together with the world as fluidly as people as soon as did with hyperlinks.

Two approaches — Mannequin Context Protocol and Invoke — provide completely different visions of how this interplay ought to work:

• MCP is right once you want coordination between a number of brokers, session state, or recursive reasoning — the WebSockets of the agentic internet.
• Invoke is right once you want light-weight, one-shot software use with real-world APIs — the HTTP of the agentic internet.

Neither is the answer. Very similar to the early web wanted each TCP and HTTP, the agentic layer shall 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 need to join an LLM to the companies 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 received’t be inbuilt a single day, and it received’t be constructed by a single firm. However one factor is evident: 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