MCP Production & Built-in Tools — Detail & Examples

Part of Tool Design & MCP · overview: domain-2.html

In this page

A prototype-to-production checklist, and a worked example of deciding between a built-in tool and a custom MCP server.

2.3aPrototype vs. production checklist

What changes when a server goes live

Auth: a prototype might run with no credentials at all; a production server needs to authenticate the calling client and scope what it's allowed to touch.
Versioning: a schema change that breaks an older client should be introduced as a new version, not a silent breaking change to everyone.
Monitoring: track latency and failure rate per tool, not just "is the server up" — a tool that's technically responding but silently failing half its calls looks healthy on a basic uptime check.
Scaling: a server built for one developer's local testing may not hold up to many concurrent sessions calling it at once.

2.3bBuilt-in tool or custom MCP server?

WORKED EXAMPLE · MAKING THE CALL

TASK"Look up this week's exchange rate and also check our internal deal-approval queue."

The exchange-rate lookup is generic, public information — a built-in web search capability already covers this well.
The deal-approval queue lives in a private, organization-specific system with no generic equivalent — nothing built-in can reach it.
Only the second half of the task justifies building or connecting an MCP server; duplicating the first half as a custom integration would be wasted effort.

Rule of thumb:Built-in tool for generic/broadly-available capability. Custom MCP server for anything tied to private, proprietary, or organization-specific systems.

← 2.2 Building MCP Servers Tool Design & MCP Overview

Claude Certified Architect — Study NotesDWG 2.3