HTTP Connectors vs MCP: A Better Way to Connect Agents to the World

Quick take: MCP standardized how AI agents discover and call tools, which was a meaningful step forward. But it carries protocol overhead that makes it harder to build, deploy, and scale connectors in production. Agentblit's HTTP connectors offer the same tool discovery and execution contract over plain HTTP — stateless, SDK-free, and with a richer setup experience for connecting real applications.

---

What MCP solved

Before the Model Context Protocol, every tool integration was custom. If you wanted your agent to query a database or send a Slack message, you wrote a function, wrapped it in whatever abstraction your framework used, and hardcoded the wiring. Multiply that across tools, models, and teams, and you get a fragmented mess of one-off integrations.

MCP changed that. It gave tool builders a standard interface:

• Implement a server with a tools/list endpoint to declare available tools
• Handle tools/call to execute them
• Any MCP-compatible client can now discover and use your tools without custom integration code

The underlying approach — standardized discovery, JSON Schema tool definitions, structured results — is sound and worth preserving. Where MCP adds friction is in the protocol layer sitting between your tool server and the agent.

---

The MCP protocol tax

MCP is built on JSON-RPC 2.0 and requires a stateful session between client and server. Before any tool can be called, there is a mandatory handshake:

Client → Server: initialize (protocol version, capabilities)
Server → Client: capabilities acknowledgment
Client → Server: initialized notification
Client → Server: tools/list
Server → Client: tool schemas
— now tool calls can begin —
Client → Server: tools/call
Server → Client: result

That's multiple round trips before a single tool runs. For local integrations over stdio this is invisible. For remote connectors running over the network, it is latency that compounds as you add more connectors to an agent.

Beyond latency, the stateful model creates operational cost:

You need an MCP SDK to build a server. MCP's JSON-RPC framing, capability negotiation, and session lifecycle are non-trivial to implement by hand. In practice, builders use official SDKs in Python or TypeScript. If your team works in Go, Ruby, PHP, or any other language, the options are thinner.

Connections must be maintained. An MCP client holds a persistent connection to each server for the duration of a session. Under load, with many concurrent agents and connectors, this becomes a resource management problem.

Scaling is awkward. Because session state ties a client to a specific server instance, routing requests across a load-balanced fleet requires sticky sessions or shared session state. Horizontal scaling is not free.

Authentication options are limited. MCP's standard configuration surface is essentially OAuth — a redirect-based flow where you authorize the connector to access a third-party service. That covers integrations like Slack or Google Calendar. It does not cover the common case of a connector that needs to be configured for the first time: picking timezone and availability windows for a booking tool, entering API credentials for a custom service, or running a multi-step setup wizard.

---

HTTP connectors: the same contract, without the overhead

HTTP connectors in Agentblit expose tools over plain REST with two required endpoints:

That is the entire protocol for tool discovery and execution. The response shapes follow the same OpenAI-compatible function-calling format that MCP uses, so the semantics are familiar:

tools/list response:

{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "book_appointment",
        "description": "Book an appointment for a user.",
        "parameters": {
          "type": "object",
          "properties": {
            "entity_id": { "type": "string" },
            "slot_start": { "type": "string", "format": "date-time" },
            "booker_email": { "type": "string" }
          },
          "required": ["entity_id", "slot_start", "booker_email"]
        }
      },
      "permission_mode": "needs_approval"
    }
  ]
}

tools/call request:

{
  "tool_calls": [
    {
      "id": "call_abc123",
      "type": "function",
      "function": {
        "name": "book_appointment",
        "arguments": "{\"entity_id\":\"room_1\",\"slot_start\":\"2026-08-01T10:00:00Z\",\"booker_email\":\"alice@example.com\"}"
      }
    }
  ]
}

No initialization handshake. No session negotiation. No SDK required on the server side. A connector is any HTTP service that answers these two requests — built in whatever language or framework you prefer.

---

No SDK required

Building an MCP server without an official SDK means implementing the JSON-RPC 2.0 framing, capability negotiation, and lifecycle notifications by hand. Most teams don't bother — they use Python or TypeScript and accept the constraint.

An HTTP connector has no such requirement. The tools/list endpoint returns JSON. The tools/call endpoint reads a JSON body and returns JSON. Any HTTP framework in any language can implement this in an afternoon.

Here's what a minimal connector looks like in TypeScript:

// GET /api/1.0/tools/list
app.get("/api/1.0/tools/list", (req, res) => {
  res.json({
    tools: [
      {
        type: "function",
        function: {
          name: "get_order_status",
          description: "Get the current status of a customer order.",
          parameters: {
            type: "object",
            properties: {
              order_id: { type: "string" },
            },
            required: ["order_id"],
          },
        },
        permission_mode: "always_allow",
      },
    ],
  });
});

// POST /api/1.0/tools/call
app.post("/api/1.0/tools/call", async (req, res) => {
  const { tool_calls } = req.body;
  const results = await Promise.all(
    tool_calls.map(async (call) => {
      if (call.function.name === "get_order_status") {
        const { order_id } = JSON.parse(call.function.arguments);
        const order = await db.orders.find(order_id);
        return { id: call.id, result: JSON.stringify(order) };
      }
    })
  );
  res.json({ results });
});

The same logic in Python, Go, or a serverless function works equally well. The platform is irrelevant — only the contract matters.

---

Stateless by design

Every HTTP connector request is independent. Agentblit passes agent context through standard headers (X-Agentblit-Agent-Id, X-Agentblit-Workspace-Id) so the connector knows who is calling, without requiring a session.

This has direct operational consequences:

Scaling is straightforward. Any instance of your connector service can handle any request. Deploy behind a load balancer, autoscale based on traffic, spin down idle instances — no sticky sessions, no shared session state, no coordination overhead.

Fewer resources per agent. MCP maintains persistent connections between the client and every connected server for the lifetime of a session. A busy Agentblit workspace with many concurrent agents and connectors would require holding that connection multiplied across every active session. HTTP connectors do not: a request arrives, the tool runs, the connection closes.

Cold paths are cheaper. When an agent doesn't call a particular connector during a run, no resources were held waiting. With MCP, the session is established at initialization regardless of whether every tool is actually invoked.

---

Setup UI: beyond OAuth

The biggest gap between MCP and HTTP connectors is first-time configuration.

MCP's standard connection model is OAuth: the user authorizes the connector to access a third-party account, and the platform stores the resulting token. This works well for integrations that authenticate into existing services. It doesn't work for connectors that need to be configured before they can do anything useful.

Consider an appointment booking connector. Before it can return available slots or accept bookings, someone needs to:

1. Define the bookable entities (rooms, staff, resources)
2. Set availability rules for each entity
3. Configure timezone, slot duration, and reminder windows

OAuth can't express any of this. A form can.

HTTP connectors support a setup wizard through two additional endpoints:

When a user adds a connector in the Agentblit console and the connector reports setup_required, the platform redirects to the connector's configuration_url. The connector hosts its own multi-step setup UI — which can collect anything: API keys, business preferences, entity definitions, availability rules, rate limits, feature flags. Once setup completes, the connector redirects back to Agentblit with a confirmation parameter and the tools become available.

This is fundamentally different from OAuth. The connector owns its setup experience. It can validate configuration at each step, surface contextual help, and progressively disclose complexity. The platform facilitates the handoff without constraining what the setup looks like.

---

Building connectors that actually do things

The combination of a simple protocol, no SDK requirement, and a rich setup flow changes what kinds of connectors are practical to build.

MCP connectors tend toward thin API wrappers: search the web, query a database, post a message. The initialization overhead and authentication model steer builders toward integrations that are straightforward to authorize and stateless to call.

HTTP connectors make it practical to build connectors that are applications in their own right — with their own database, their own business logic, and their own user-facing configuration.

Agentblit's appointment connector is an example. It maintains its own schema of bookable entities, availability rules, and appointments. Its setup wizard collects this configuration from the agent owner. Its tools — check available slots, book, reschedule, cancel — operate on that configured state. The agent calls the same six tools regardless of the business's specific configuration; the connector handles the rest.

The same pattern applies to other domains:

• An e-commerce connector configured with a product catalog, pricing rules, and order management integrations — exposing tools for inventory lookup, checkout, and order status
• A support connector wired to a customer's ticketing system, knowledge base, and escalation rules — giving agents the ability to read, create, and update tickets with business-specific logic
• A scheduling connector for a services business — mapping staff, locations, and service types to bookable appointments with its own availability logic

These are not thin API wrappers. They are domain-specific tools with their own persistence and configuration surface. The HTTP connector protocol makes them possible without forcing them into a one-size-fits-all integration pattern.

---

Comparison

---

When MCP still makes sense

MCP has a large and growing ecosystem of pre-built servers covering services like Slack, Notion, Linear, GitHub, and many others. If the connector you need already exists as an MCP server, connecting it in Agentblit is one configuration step — no building required.

For integrations that fit the OAuth-authorize-and-call pattern, MCP servers are a reasonable choice. The ecosystem value is real.

HTTP connectors become the right choice when you are building something that doesn't yet exist, when your team works outside the Python/TypeScript ecosystem, when you need configuration depth that OAuth can't express, or when the scale and resource characteristics of stateful connections matter.

---

Summary

MCP solved the fragmentation problem: tools became discoverable, composable, and portable across models and platforms. That was a meaningful step.

HTTP connectors extend that foundation by removing protocol overhead — no handshake, no persistent session, no SDK — and adding a setup model that can express real application configuration, not just token authorization.

The result is a lower barrier to building connectors, more predictable behavior under load, and the ability to ship domain-specific tools that are applications in their own right.

Agentblit supports both. MCP servers are a fast path to the existing connector ecosystem. HTTP connectors are the right choice when you want to build something of your own.