REST vs GraphQL vs gRPC for AI agent tools: the 2026 token-cost decision

Summary. When an AI agent calls a tool, the API contract is not only network plumbing. Every tool's schema is injected into the model's context window, so the shape of your API is billed twice: once in network latency and once in tokens the model reads on every turn. That second cost is the one the classic REST-versus-gRPC debate misses. A single Model Context Protocol tool definition can consume around 1,000 tokens once you count field descriptions, type definitions, and nested structure, and a session with 20 to 30 registered tools loads roughly 15 to 30 KB of schema before the user types anything, according to an open issue on the MCP specification. A heavy configuration can burn about 66,000 tokens, nearly a third of Claude Sonnet's 200,000-token window, on tool definitions alone. Anthropic's own documentation puts each tool definition at roughly 100 to 300 input tokens, so 15 tools add 1,500 to 4,500 tokens to every request, and its token-efficient tool-use beta cuts output tokens by an average of 14 percent and up to 70 percent. At an illustrative $3 per million input tokens, 66,000 tokens of unused schema costs about $0.20 on every call, a 33 percent context tax before any work, and the 2026-07-28 MCP specification loads those schemas by default. On the network side, one 2026 benchmark measured gRPC at a 4 ms median against REST's 12 ms and GraphQL's 15 ms. This guide separates the two costs and gives a decision table for backend engineers exposing tools to agents.

The question "REST, GraphQL, or gRPC" has a settled answer for ordinary web backends. Agents change the inputs, because the model is now a client that pays per token to read your interface. The web platform developer guide covers the broader protocol landscape; here the lens is narrow: what should the tool your agent invokes actually speak.

The cost the API debate forgets: tokens in the context window

A model does not read your OpenAPI document at leisure. Whatever describes a tool, its name, its parameters, and their descriptions, is serialized and placed in the context window so the model can decide when and how to call it. That text is priced as input tokens on every request that carries the tool, whether the model uses it or not.

The numbers are not small. An issue on the Model Context Protocol repository documents that MCP tool definitions consume 5 to 15 times more tokens than the simplest possible schema for the same tool, with field descriptions adding about 400 tokens, type definitions about 300, and nested object structure about 300 more, totalling near 1,000 tokens for one tool. Anthropic's documentation is more conservative for direct function calling, at 100 to 300 tokens per definition, but the direction is identical: verbose, deeply nested schemas are expensive, and they are expensive on every turn of a multi-step agent run, not once.

That reframes protocol choice. A gRPC service defined in Protocol Buffers and a REST endpoint described in JSON Schema may perform identically on the wire, yet present very different token bills to the model depending on how their contracts are surfaced. The design goal for an agent-facing tool is a contract that is precise enough for the model to call correctly and terse enough not to flood the window.

The three protocols, on the terms that matter for agents

REST over HTTP with JSON is the universal default. It runs in every browser, caches over standard HTTP, and imposes no schema, which is exactly why it suits public, evolving, external-facing interfaces. GraphQL exposes a single endpoint and a typed schema, and it lets a client ask for precisely the fields it needs, which cuts over-fetching on complex reads. gRPC uses Protocol Buffers over HTTP/2: a binary, schema-first contract that is fast and compact for service-to-service traffic where you control both ends.

The catch for agent stacks is where the model and its client actually sit. gRPC cannot run natively in a browser, because browsers do not expose the HTTP/2 framing that gRPC's trailer-based status needs, so browser and many hosted-agent clients require gRPC-Web behind an Envoy proxy that translates the calls. AWS frames the split plainly: gRPC for internal microservices, REST for broad external access, with a gateway in front when a browser or third party has to reach a gRPC service.

The wire-performance gap is real for internal traffic. One 2026 benchmark reported a user-plus-five-orders response at 312 bytes over gRPC versus 1,247 bytes over REST, and GraphQL cutting payloads 40 to 70 percent on complex queries by removing over-fetching. Treat exact figures as directional, since they vary by workload, but the ordering, gRPC smallest and fastest, REST most compatible, GraphQL best at shaping reads, holds across the published tests.

How the tool reaches the model: MCP and function calling

Most agents do not call your API directly. They call a tool that a runtime exposes, and the runtime speaks either a provider's native function-calling format or the Model Context Protocol. MCP itself runs on JSON-RPC 2.0 and defines a tool as a name, a description, a JSON Schema for the input arguments, and an optional schema for the result. Whatever your backend speaks underneath, REST, GraphQL, or gRPC, it is wrapped into that tool contract, and the wrapping is where the token cost is decided.

Here is the same "get order status" tool as a lean hand-written schema and as the kind of auto-generated definition that inflates context.

            // Lean: ~40 tokens. One argument, one line of description.
{
  "name": "get_order_status",
  "description": "Return the status of an order by ID.",
  "input_schema": {
    "type": "object",
    "properties": { "order_id": { "type": "string" } },
    "required": ["order_id"]
  }
}
          

            // Auto-generated from a verbose backend model: hundreds of tokens.
{
  "name": "OrderService_GetOrderStatusById_v2",
  "description": "This operation retrieves the current fulfilment status ...",
  "input_schema": {
    "type": "object",
    "properties": {
      "orderIdentifier": { "type": "string", "description": "The globally unique ..." },
      "includeLineItems": { "type": "boolean", "description": "When true, ..." },
      "locale": { "type": "string", "description": "BCP-47 language tag ..." },
      "correlationContext": { "type": "object", "properties": { "traceId": {"type":"string"}, "spanId": {"type":"string"} } }
    },
    "required": ["orderIdentifier"]
  }
}
          

Both call the same backend. The second one, generated straight from an internal gRPC or REST model with every field and trace header exposed, costs the model far more to read, every turn. At an illustrative 3 dollars per million input tokens, 66,000 tokens of tool schema loaded but unused is about 20 cents on every single call, which multiplies fast across a long agent run.

Two levers reduce this. First, hand-curate the tool surface: expose a small set of task-shaped tools with short descriptions, not a one-to-one mirror of a sprawling internal API. Second, use the platform features built for it. Anthropic offers a token-efficient tool-use beta, enabled with the token-efficient-tools-2025-02-19 header, that saves an average of 14 percent of output tokens, and an automatic tool-result-clearing capability that drops old tool outputs as the context fills. The MCP server development approach treats this curation as the main design task, not an afterthought.

            # Anthropic token-efficient tool use (beta): a header, not a rewrite.
client.beta.messages.create(
    model="claude-sonnet-...",
    betas=["token-efficient-tools-2025-02-19"],
    tools=[get_order_status],   # keep the schema lean
    messages=[...],
)
          

Token cost by tool-surfacing strategy

The protocol underneath matters less than how many tools you load and how verbose each one is. The strategies below are ordered from cheapest to most expensive on context.

The pattern is clear: generate less, curate more. An MCP server that loads 30 tools on every turn can cost more in wasted context than the entire rest of the prompt, which is why on-demand tool discovery, where the model fetches a schema only when it needs it, is the direction the ecosystem is moving.

Where each protocol earns its place

Use REST with JSON when the tool is public, browser-reachable, or still changing, and when a hosted agent runtime has to call it without proxy infrastructure. It is also the easiest thing to wrap into an MCP tool, because the JSON request and response map directly onto a JSON Schema. Use GraphQL when the agent's job is to assemble a specific view from many fields and you want to let the model, or your wrapper, request exactly those fields and nothing more, keeping response tokens down. Use gRPC when the call is internal, high-frequency, and latency-sensitive, and both ends are yours: the binary Protobuf payload and HTTP/2 multiplexing pay off in service-to-service traffic, and you put a REST or GraphQL gateway in front for anything a browser or third-party agent must reach.

Most production agent stacks end up mixed: REST or GraphQL at the edge where the model-facing tool lives, gRPC between your own services behind it. The design work that actually moves cost is upstream of the protocol, in how few, how task-shaped, and how tersely described your tools are. Teams standardising this across services often fold it into a broader API integration and modernization effort, and the runtime choice underneath interacts with decisions like Bun versus Node.js for the backend.

India and global considerations

For teams building agent products for a global market from India, two things follow. Cross-region latency changes the gRPC calculus: the 4-to-12 ms gaps seen in same-datacenter benchmarks shrink in relative terms once a call crosses continents, so the token cost of the tool schema often outweighs the wire-time difference for a user-facing agent served from a distant model endpoint. And where a tool handles personal data, the protocol choice does not change your duties under the Digital Personal Data Protection Act 2023: minimise the fields the tool exposes, because a lean schema is also a smaller data-exposure surface, and redact before any personal data reaches a hosted model.

FAQ

How eCorpIT can help

eCorpIT designs the tool and API layer that AI agents call, so it is correct, fast, and cheap to run in tokens. We shape task-oriented tool surfaces over REST, GraphQL, or gRPC backends, wrap them cleanly as Model Context Protocol servers, and tune schemas and context strategy to cut the token overhead that inflates agent cost. As a Gurugram-based, CMMI Level 5 and ISO 27001:2022 certified engineering organisation, our senior-led teams build this as production infrastructure with observability and access control. To design an agent-ready API layer, contact us.

References

1. MCP specification: tool schema token overhead (issue 2808)

1. Model Context Protocol specification (2026-07-28)

1. Anthropic: token-efficient tool use

1. Claude API: implement tool use

1. AWS: the difference between gRPC and REST

1. Microsoft Learn: use gRPC in browser apps

1. REST vs GraphQL vs gRPC APIs 2026 (benchmarks)

1. gRPC (Protocol Buffers over HTTP/2)

1. GraphQL (query language and runtime)

1. Protocol Buffers documentation

1. JSON-RPC 2.0 specification

1. OpenAPI Initiative

_Last updated: 1 August 2026._