In many production AI systems, model usage is charged by the token for both what you send to the model and what the model sends back. Cost climbs for a simple reason: the model receives more data than the task requires.

This often happens when an AI agent queries an enterprise system and receives a full response containing records, metadata, empty fields, logs, timestamps, and other details with little value for the task. You pay to carry all of that into the model’s context even when only a small portion contributes to the answer.

The problem grows in agent workflows, where completing one request may require several model and tool interactions. Unnecessary data introduced early can remain in the accumulated context and be included in later calls. As a result, the system may repeatedly process the same unhelpful information while completing a single task.

As AI moves from pilot to production, that waste compounds across users, requests, and workflow steps. The cost is real, and its source is architectural. A custom Model Context Protocol (MCP) server can address it at the source by controlling how agents access enterprise systems and shaping the responses returned for specific tasks before they enter model context.

This article explains how a custom MCP server can reduce token waste, where that approach creates lasting savings, and how to determine whether the engineering investment is justified.

Measure Before You Build

Before deciding whether to build a custom MCP server, measure where the workflow consumes tokens. Most teams that audit their token spend for the first time are surprised by the breakdown.

Instrument representative workflows and answer these questions:

• Which workflows and integrations account for the most input tokens?
• How much of each request consists of stable, repeated content, such as system prompts, tool definitions, and reference material, and how much changes with each request?
• How much of a typical tool or API response is relevant to completing the task?
• How many tool definitions are included in each model call, and how many does the workflow actually invoke?
• How many tokens does the system consume to complete the full workflow, including repeated context, retries, and follow-up tool calls?
• How long are the outputs compared with what the task requires?

The answers help identify the intervention most likely to reduce cost. Building a custom MCP server for a problem that prompt caching, output controls, or another simpler measure could solve creates unnecessary engineering and maintenance costs.

Token Optimization: Simple Measures First

Several methods reduce token use, and they differ enormously in effort. In our experience, the right order is from lowest effort to most involved.

Prompt caching. If a large share of your input tokens is stable content, such as system prompts, tool schemas, and policy documents, provider-side prompt caching can significantly reduce the cost of repeated content on cached reads, with little or no code change. For many teams, this can be one of the fastest wins available.

Output control. Shorter, structured outputs cost less and are often more useful downstream. Explicit length and format constraints in prompts are nearly free to implement.

Selective retrieval. Tightening retrieval to return fewer, more relevant passages reduces input on every request that uses it and usually requires tuning existing retrieval behavior rather than adding new infrastructure.

Model routing. Sending simple or high-volume steps to smaller, lower-cost models and reserving frontier models for the steps that need them changes the cost per token, not just the count.

Provider-native tool management. Some tool bloat problems are already solved at the platform level. Tool search and progressive discovery features load detailed tool schemas only when a task needs them, without any custom middleware.

These methods are part of the broader discipline of token optimization, which we cover in depth in a dedicated article. If your audit shows that most of your spend is stable repeated content or oversized outputs, start there. You may not need anything more.

When the Integration Layer Is the Problem

In an agentic AI system, the integration layer is the part of the architecture that connects agents with enterprise applications, APIs, data sources, and tools. In most architectures, every tool call and every system response crosses it.

The methods discussed in the previous section share a limitation: they optimize what happens around the model, not what enterprise systems send through the integration layer toward it. When your audit shows that the dominant cost is raw system responses, meaning oversized records, broad result sets, and full API payloads flowing into context on every tool call, the waste lives in the integration layer. A custom MCP server can be built to solve exactly that problem: it is an integration component engineered to shape that traffic before it reaches the model.

What a Custom MCP Server Does

Generic connectors often expose broad operations and standard system responses. A custom MCP server narrows that interface around the tasks agents need to perform, providing workflow-specific tools, resources, and response structures. Operating within the integration layer, it shapes enterprise system responses before they enter model context.

The following patterns reduce unnecessary context at different points in those exchanges.

It returns a task-specific view instead of a full record. Rather than passing a complete business object containing metadata, timestamps, empty fields, and nested data, the MCP server returns the fields required for the task, along with a reference to the source. The model receives a smaller, traceable input without losing the information needed to complete the request.

It exposes tools designed around the workflow. A custom MCP server can present a smaller, more relevant tool set instead of a broad catalog of general-purpose operations. When the client or agent framework supports progressive discovery, detailed tool schemas can also be loaded only when a task requires them. This reduces unnecessary definitions in model context and limits unproductive tool exploration.

It filters, aggregates, or transforms system data before passing it to the model. Deterministic processing can remove unused fields, combine related results, apply business rules, or calculate values in code, with only the relevant output entering model context. When summarization requires another model call, its token usage and cost should be included in the evaluation.

It serves curated resources on request. Stable reference material can remain available through the MCP server and be retrieved when needed instead of being included in every prompt.

Together, these patterns reduce unnecessary context before it is repeated across later model calls and workflow steps. The savings come from controlling what enters model context at the integration layer, rather than from repeatedly trimming individual prompts.

The Risks of Over-Filtering

A custom MCP server needs safeguards because aggressive filtering can create costs of its own.

If the server removes a field the model needs, the result may be an incorrect answer, a retry, or an additional tool call to recover the missing information. Any of these outcomes can cost more than the tokens originally saved. Filtering logic also encodes assumptions about what each task requires, and those assumptions become outdated as workflows evolve. A well-designed server therefore:

• Preserves source references and a path to retrieve the full record when the task-specific view is not sufficient.
• Respects user permissions so response shaping cannot bypass existing access controls.
• Manages freshness so curated or summarized views do not silently return outdated information.
• Is validated against task quality and end-to-end cost, not only the size of individual responses. Measure accuracy, task completion, retries, and total token use before and after filtering. If the server reduces the initial payload but produces more incorrect results or recovery calls, the outcome is a net loss.

Token reduction is a means to an end. The goal is reliable task completion at sustainable cost, and every filtering decision should be evaluated against both.

Weighing Build Cost Against Savings

A custom MCP server is real engineering: it must be designed, built, secured, monitored, and maintained as the systems behind it change. That investment is justified when three conditions hold:

1. The waste is measured and recurring. Your measurements show that oversized payloads or tool bloat at the integration layer are a dominant, ongoing cost rather than a one-time spike.
2. Simpler measures have been applied or ruled out. Prompt caching, output controls, selective retrieval, model routing, and provider-native tool management either are already in place or demonstrably cannot address the source of the waste.
3. The problem is specific to your business. Ranking tools by workflow, enforcing user permissions, aggregating data across systems, and applying workflow-specific controls are things a generic feature is unlikely to do for you. When shaping data requires knowledge of your systems and your tasks, a custom MCP server is where that knowledge belongs.

When all three hold, the savings are durable, because they are built into the structure of the workflow rather than bolted onto individual prompts. If your situation does not meet all three, our advice is to stay with the simpler measures.

Reduce Your Token Waste

Krasamo designs and builds custom MCP servers that cut token waste in the integration layer, where your agents meet your enterprise systems.

Contact Krasamo to review your AI workflow and identify practical opportunities to reduce token cost and latency.