Two Tiny MCP Servers That Reduced Prompt Waste This Week

This week I kept hitting the same two problems while running an agent-heavy workflow.

First, structured outputs drifted. A model would mostly follow the schema, then miss one required field or return the wrong shape under pressure.

Second, tool lists kept getting bloated. Agents were carrying too many MCP tools into the prompt, which made selection noisy and expensive.

So I turned both pain points into tiny MCP servers and shipped them as separate packages:

• schema-pin-mcp
• tool-router-mcp

They are small, but the pattern matters more than the code size.

1. Schema pinning is a better default than post-hoc cleanup

Most teams still treat structured output failures as a retry problem.

That works until the system becomes agentic. Then malformed JSON stops being a minor annoyance and starts breaking whole chains.

The better default is to pin the active JSON Schema for the session and validate every output against it before the next step runs.

That is the point of schema-pin-mcp.

Instead of hoping the model remembers the format, the server keeps the schema in context and makes validation explicit.

Typical flow:

pin schema -> generate output -> validate -> repair if needed -> explain mismatch

That gives you three practical wins:

• fewer silent failures
• cleaner receipts for debugging
• less prompt repetition because the contract is centralized

For multi-step agents, this is closer to how production systems should behave.

2. Tool routing matters once your MCP catalog gets crowded

The second issue was tool overload.

If you keep adding MCP servers, eventually every agent gets a giant tool catalog. At that point the model spends tokens evaluating irrelevant tools before it does useful work.

tool-router-mcp is a small fix for that exact problem.

Given a user intent, it returns the smaller subset of tools that actually matter. The goal is not perfect ranking. The goal is to reduce prompt weight and improve first-pass tool selection.

That matters for two reasons:

• lower token cost
• less agent hesitation when multiple tools look similar

In practice, even a rough routing layer is better than dumping every tool into every task.

3. Small MCP utilities are useful because they are composable

Neither of these packages is a giant platform product.

That is the point.

Small MCP utilities are easy to test, easy to publish, and easy to compose into bigger loops:

• schema enforcement
• tool selection
• prompt budget control
• audit and receipts

This is the pattern I keep trusting more:

1. Find the friction inside the agent loop.
2. Extract it into one narrow server.
3. Publish it fast.
4. Reuse it across other workflows.

A lot of "AI infrastructure" can be built this way instead of waiting for a perfect unified framework.

4. The publish loop is part of product discovery

Shipping tiny infrastructure pieces does something useful beyond distribution.

It forces clarity.

If a tool is worth publishing, it should be explainable in one paragraph:

• what problem it removes
• where it sits in the workflow
• why a developer would install it instead of hand-rolling the same logic

That pressure is healthy. It cuts vague roadmap language and exposes whether the tool is actually distinct.

5. What I am keeping from this week

Three operating rules survived contact with reality:

• validate structure as early as possible
• route tools before the prompt gets heavy
• prefer tiny publishable utilities over abstract architecture decks

This is not a grand theory of agents. It is a practical loop:

find friction, isolate it, package it, publish it, repeat.

That loop is still one of the fastest ways I know to improve a real AI toolchain.