How custom MCP servers built in Celigo can lower AI token costs

At a glance

• AI agents use tokens for tool definitions, tool results, and extra model steps, not only the question and the answer.
• Celigo MCP Server lets you expose only the tools an agent needs, return only the fields a task requires, and combine multi-system lookups into one composite tool.
• Celigo MCP Gateway puts vendor MCP servers behind one Celigo URL so you can switch off tools, then applies access control, traffic limits, and request history.
• Celigo governs MCP traffic. Your AI provider meters the tokens, so measure savings there.

Custom Model Context Protocol (MCP) servers built in Celigo reduce the tokens an agent processes by controlling what it sees. The model reads fewer tool definitions and shorter responses, and makes fewer calls. Celigo still makes the backend API requests, so the savings come from less model-facing context. Measure them on your own workloads.

What is MCP?

The Model Context Protocol (MCP) is an open standard that connects AI assistants and agents, such as Claude and ChatGPT, to external tools and data. An MCP server offers an AI client a list of tools, such as looking up a customer or updating an order. The client picks a tool, sends the parameters, and receives the result.

Why can MCP increase AI token costs?

Model providers generally charge by the tokens a model processes and generates. With MCP, usage includes more than the question and the answer.

Tool definitions consume context

Models need each tool’s name, description, and parameter schema to choose one. In one Anthropic example, five MCP servers with 58 tools used about 55,000 tokens on definitions before the conversation started. Some clients now support tool search, which loads definitions on demand. A short, well-defined tool list helps in any client.

Tool responses can be larger than the task needs

A tool may return an entire customer record when the agent needs only the account status. Raw API responses often carry nested objects, internal IDs, and metadata that do not improve the answer but still enter the model’s context.

Multi-step work adds model interactions

An agent answering a cross-system question may call several tools, read each result, and reconcile the records. Wrong tool picks, missing parameters, and retries add more. Anthropic names wrong tool selection and incorrect parameters among the most common failures.

An MCP tool call is not itself a billable token. Savings come from reducing what the model reads and how many times it is called, not from reducing backend API requests.

What is the difference between single-system tools and composite tools?

Many vendors ship a native MCP server. It is an efficient way to connect an assistant to a single application, but business questions often span several applications. “What’s going on with this account?” can need CRM details, ERP invoices, and open help desk tickets.

Using separate tools, the agent queries each system, reads each response, and determines how the records relate. A composite tool handles that behind one interface. In Celigo, a team builds the tool in Tool Builder, which supports lookups, imports, mappings, transformations, and branching. The tool looks up the account in the CRM, checks ERP records, retrieves support issues, combines the results, and returns a concise summary. Its output schema controls what comes back, including removing unneeded fields. The agent makes one call. Celigo still runs the backend API requests, but the model no longer orchestrates each step.

How does a vendor’s native MCP server compare with one managed in Celigo?

A vendor’s native server is not inherently inefficient or insecure, and some expose carefully designed tools with strong access controls.

The difference is how much control you have over what agents see and do.

How does Celigo help manage MCP servers?

Celigo MCP Management has three parts.

1. MCP Server builds governed tools from your integrations and connectors.
2. MCP Gateway controls access to any MCP server, including vendor servers, through one Celigo URL.
3. MCP Registry gives you a single inventory of the MCP servers your agents reach, the clients that connect to them, and who has access to them.

Build focused tools

Replace a general API query with a tool such as “check customer payment status” that accepts an account identifier and returns only what the task needs. Celigo’s 1,000+ app connections let you build tools for applications without an MCP server.

Proxy vendor servers

An MCP proxy connects an external MCP server to your Celigo MCP server. You choose which tools, prompts, and resources to expose and can rewrite their names, descriptions, and annotations. You cannot change a proxied tool’s input schema. Fewer tool definitions reach the client, and agents cannot call operations you left out.

Apply access controls

End-user groups and capability sets control who can call which tools. For proxied servers, the external server receives requests under the credentials configured on the MCP connection, so it sees one identity for every user. Celigo’s request history still identifies the end user or access token behind each call. Configure the connection with only the permissions your users should collectively have. If each user must reach the application under their own identity, connect to the vendor’s server directly.

Tools built in Celigo can run under each end user’s identity when you turn on end-user credentials for the connection, and the MCP server uses Celigo as its identity provider.

Control traffic and monitor activity

Traffic limits cap how many calls reach a server: a server rate limit, a per-user rate limit for users who sign in with OAuth, and a usage quota by day, week, or month. A call over a limit gets an HTTP 429 response with a Retry-After header. Request history records the time, user or access token, capability, method, and status of each call.

Celigo governs MCP traffic. Your AI provider or model management layer meters tokens. Use Celigo’s request history to count calls and your provider’s usage records to count tokens.

Example: Will order 45231 arrive on time?

This example is illustrative. The answer sits in three systems: the commerce platform knows the order and payment, the warehouse knows the shipment, and the carrier knows where the package is.

• Separate tools: the agent loads the tool lists from three servers, calls each system, reads the three raw responses, and matches the order number to a shipment ID and a tracking number before deciding whether delivery is late. That is at least three calls and three payloads.
• Celigo composite tool: a team builds one “order delivery status” tool. The agent calls it with the order number, and Celigo checks all three systems, matches the records, and returns a few lines (illustrative values): Order 45231, status Shipped, estimated delivery November 3, late delivery risk Low, last carrier update In transit.

The support group gets only that tool. Refund, payment, and order edit tools stay outside its capability set.

How much can composite tools save?

There is no universal percentage. Savings depend on the model, MCP client, tool schemas, response sizes, workflow complexity, caching, and the frequency with which the agent uses the tools. Compare the same representative tasks before and after the change, and track total model cost per successfully completed task.

A workflow that uses fewer tokens but answers less reliably is not an improvement, and a composite tool can shift cost to integration execution. Judge both.

Give AI agents the freedom to act without giving up control

The principle of least agency means using AI only where it adds value. Celigo handles repeatable integration tasks through governed tools, allowing AI agents to focus on decisions that require reasoning and judgment.

This reduces unnecessary data processing, limits what agents can access and do, and gives IT teams visibility into who is using each tool and how.