Agents, APIs, and the Next Layer of the Internet

Half I: for Thought

Once in a while a easy thought rewires all the things. 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 info trade — 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 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 net’—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 instantly with real-world APIs at inference time — without 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 thought: that giant language fashions (LLMs) ought to be capable of discuss to one another — and that their interactions needs to 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 initiatives like OpenAgents and LangChain had already launched the thought of instruments: giving LLMs managed entry to capabilities. However MCP pushed the thought additional.

Somewhat than hardcoding instruments into particular person brokers, MCP proposed a normal — a shared grammar — that will 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 instrument, however brokers calling brokers, instruments calling instruments, and reasoning handed like a baton between fashions.

Launched by Anthropic in November 2024, MCP is just not a product. It’s a protocol. A social contract for a way brokers talk — very like HTTP was for net pages.

How MCP Works

At its core, MCP is a JSON-based interface description and name/response format. Every agent (or instrument, 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 trade has three elements:

1. Itemizing Capabilities
   An agent exposes a set of callable capabilities — their names, parameters, return varieties, 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 person) 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 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 follow. 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: Offers climate information.
• TripPlannerAgent: Plans a day journey, and makes use of the WeatherAgent through MCP to examine the climate.

On this situation, TripPlannerAgent has no hardcoded information of easy 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. Another agent can introspect this and know precisely easy methods to invoke the climate operate.

Step 2: TripPlannerAgent makes a structured name

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

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

Step 3: WeatherAgent responds with structured information

{
  "response": {
    "end result": {
      "temperature": "21°C",
      "situation": "Sunny"
    },
    "clarification": "It’s at present 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 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 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 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 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 depend upon any explicit runtime, framework, or mannequin. You need to use OpenAI, Claude, or your native LLM — if it may possibly interpret JSON, it may possibly 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 methods.

❌ 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 want to implement your personal 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 Pondering
LLMs love ambiguity. MCP doesn’t. It forces builders (and fashions) to be specific: right here’s a instrument, right here’s its schema, right here’s easy methods to name it. That’s nice for readability — however requires extra upfront considering 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 follow, builders usually cross 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 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, similar 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 in a different way:

• One instrument, many APIs
• One customary, infinite interfaces

Simply outline your endpoint — technique, 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 instrument 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 instrument definition (brokers.json) with:
   • technique, url, auth, parameters, and an instance.
2. Invoke parses that right into a callable operate for any mannequin that helps instrument use.
3. The mannequin sees the instrument, decides when to make use of it, and fills out the parameters.
4. Invoke handles the remainder — auth, formatting, execution — and returns the end result.

No customized wrappers. No chains. No scaffolding. Only one clear interface. And if one thing goes flawed? We don’t preprogram retries. We let the mannequin determine. 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’ instrument, 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, similar 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 allows you to 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 below a minute, your mannequin is fetching reside 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 like HTML allowed people to find web sites and companies on the fly, Invoke permits LLMs to find APIs at inference time.

Need 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 vital 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 circumstances: calendar assistants, e-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 instrument as soon as, use it in every single place. You don’t want a dozen Python wrappers or agent configs.
• Mannequin-agnostic. Invoke works with any mannequin that helps structured instrument 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 instrument metadata, examine auth necessities, and even determine when to discover new capabilities.
• Developer-focused. In contrast to agentic frameworks that require complicated 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 aren’t hard-wired at compile and aren’t restricted at setup.

However like several 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 follow, GPT-4 and Claude do that remarkably properly — nevertheless it’s nonetheless a philosophical selection.
• Statelessness. Instruments are evaluated per invocation. Whereas this retains issues clear and atomic, it could not go well with complicated, multi-step brokers with out extra scaffolding.

MCP vs. Invoke: Two Roads Into the Agentic Internet

Each MCP and Invoke goal to convey LLMs into contact with the true 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 net was constructed on human-readable pages (HTML) and programmatic endpoints (REST), the agentic net 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 net.
• Invoke is good if you want light-weight, one-shot instrument use with real-world APIs — the HTTP of the agentic net.

Neither is the resolution. Very like the early web wanted each TCP and HTTP, the agentic layer will probably be pluralistic. However historical past suggests one thing: the instruments that win are those which might be best to undertake.

Invoke is already proving helpful to builders who simply wish to join an LLM to the companies they already use. MCP is laying the groundwork for extra complicated agent methods. Collectively, they’re sketching the contours of what’s to come back.

The agentic net 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 not simply human-readable or machine-readable — it’s model-readable.

In regards to the creator
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