The Check-Before-Build MCP Tool Pattern: How Agents Stop Reimplementing Free Capabilities

Every week we watched AI agents reimplement the same five tools: email senders, web scrapers, SMS dispatchers, Stripe charge wrappers, and CRON schedulers. Not new code - existing tools in our own inventory, reimplemented from scratch because the agent did not know they existed.

The rule that stopped it is one sentence we paste into every agent system prompt: the most expensive line of code reimplements something free. The mechanism behind that rule is an RPC called check_before_build. It is the single biggest productivity improvement we have shipped to any agent fleet. This article is the full pattern: what it is, why it works, and how to build one.

The Failure Mode This Pattern Prevents

A typical agent failure looks like this. User says: "Send the pricing quote to the client by email." Agent reasoning:

1. I need to send email.
2. I have a Node runtime. I will write an SMTP client.
3. Requires a provider. I will add nodemailer.
4. Requires credentials. I will prompt the user for SMTP host.
5. Requires a sender domain. DKIM. SPF records. Rate limiting.
6. ...35 minutes later, the email is half working.

Meanwhile, a resendMCP tool was already registered in our capability registry, authenticated, rate-limited, and tested. One call and done. The agent did not know. It had no reason to look.

Scale this across an 8-session, 17-company fleet and the waste compounds. We measured one week and found 47 reimplementation attempts for tools that already existed, costing an estimated 28 agent-hours.

The Pattern in Three Parts

Part 1: A Capability Registry

Not an MCP server registry. A capability registry. The difference matters:

Each capability entry stores at minimum: a natural language description, the tool and operation that provides it, success rate, average cost per call, latency, and last-used timestamp. Ours lives in a Supabase toolstable with 87 capabilities across 14 categories. Each entry is embedded with OpenAI text-embedding-3-smallinto a pgvector column for semantic search.

Part 2: The check_before_build RPC

An RPC that takes a capability description and returns ranked matches. In Supabase pseudocode:

create function check_before_build(
  p_capability text,
  p_max_results int default 5
)
returns table (
  tool_slug text,
  operation text,
  description text,
  similarity float,
  success_rate float,
  avg_cost_credits numeric,
  champion_in_category boolean
)
language sql stable
as $$
  with q_embedding as (
    select openai_embed(p_capability) as emb
  )
  select
    t.slug,
    t.operation,
    t.description,
    1 - (t.embedding <=> (select emb from q_embedding)) as similarity,
    t.success_rate,
    t.avg_cost_credits,
    t.is_category_champion
  from tools t
  where t.status = 'active'
  order by t.embedding <=> (select emb from q_embedding)
  limit p_max_results;
$$;

Call it with:

select * from check_before_build(
  'send transactional email with tracking'
);

-- Returns:
-- resend | send | "Transactional email API, 99.9% deliverability" | 0.89 | 0.997 | 2 | true
-- sendgrid | mail | "Email API, legacy" | 0.82 | 0.94 | 3 | false
-- mailgun | send | "Email API, rate limit aware" | 0.79 | 0.96 | 2 | false

The agent reads the top result, checks similarity threshold (we use 0.75), and if above, uses the existing tool. If below, the agent has legitimate grounds to build and should register the new capability on completion.

Part 3: The Belief Rule

The RPC is inert if agents do not call it. The rule that makes them call it is one line in the system prompt, written as a hard constraint:

We tested removing that line. Reimplementation attempts jumped 4x within the first day. The rule is load-bearing.

How the Pattern Composes With Other Infrastructure

With an MCP Gateway

Check-before-build works best when the matched tool is trivially callable. If the agent has to set up auth, install SDKs, and learn a new API schema, the cost of "use existing" starts rivaling the cost of reimplementing. An MCP gateway flattens the activation cost to one HTTP call with a shared API key. That is why we built ToolRoute: the gateway and the registry are the same system.

With Auto-Routing

The next step beyond check-before-build is auto-routing: instead of returning a ranked list for the agent to evaluate, the gateway just picks the best tool and executes. Agents describe what they need; the gateway decides how. This is safe only once the registry is well-populated and the similarity signal is reliable - which is usually after a few thousand successful calls with explicit check-before-build.

With Usage-Based Learning

Every executed tool call should write back to the registry: success or failure, latency, cost, and a short outcome note. After a few thousand calls per capability, the registry has enough data to rank champions and demote brittle tools. Check-before-build then returns the tools that actually work, not just the ones that exist.

The Numbers: Before vs After

Build Your Own in a Weekend

The entire pattern is implementable in a few hundred lines. Here is the minimum viable version:

1. Supabase table tools with columns: slug, operation, description, embedding, success_rate, avg_cost, last_used_at.
2. pgvector extension + HNSW index on embedding.
3. Seed with 10-20 of your most-used internal capabilities. Generate embeddings with text-embedding-3-small.
4. Write the RPC above.
5. Expose it as an MCP tool (stdio or HTTP, your choice - see our transport guide).
6. Add the system-prompt rule: "Before building any new capability, call check_before_build and evaluate the top match."
7. Wire usage-write-back: every executed tool call updates last_used_at and success_rate.

Start with 10 capabilities. Measure reimplementation attempts for a week. Add the capabilities that got reimplemented anyway. Iterate. Within a month you will have a registry that prevents 80%+ of the waste.

The ToolRoute Reference Implementation

ToolRoute is our open reference implementation of this pattern. It currently catalogs 87 tools across 14 categories with full check_before_build support, usage tracking, and category champion identification. You can use it directly as an MCP gateway, fork the schema for your own registry, or just borrow the pattern.

• Browse the 87-tool catalog
• Read the check_before_build docs
• Browse skills (higher-level composites)
• Glossary of registry terms

Frequently Asked Questions