💡 The Model Context Protocol — What It Is and When to Reach for It

With MCP now donated to the Linux Foundation and 10,000+ public servers in existence, it is increasingly the default choice for connecting Claude to external data sources and tools. But many developers still reach for bare API tool definitions when MCP would serve them better — or vice versa. The key distinction is scope: if you are building a one-off integration for a single application, raw tool definitions in your API call are simpler. If you are building a data connector that should be reusable across multiple models, applications, or teams, MCP is the right level of abstraction. MCP servers are independently deployable services that expose a standard interface; any MCP-compatible client can consume them without modification.

When MCP is the right choice

• Reusable connectors: If you want the same database, API, or file-system access to be available to Claude Desktop, your custom Claude application, and a future agentic tool, write it as an MCP server once.
• Sharing within a team: An MCP server can be hosted on a shared endpoint. Every developer on the team connects their Claude environment to it without each maintaining their own integration code.
• Standardised authentication: MCP handles transport and auth negotiation at the protocol level, so individual tools within a server do not each need to re-implement OAuth or API key management.
• Managed remote servers: Cloud providers are beginning to offer fully managed MCP servers (Google launched Maps and BigQuery MCP servers this week). Consuming one is as simple as adding the endpoint to your MCP configuration — no hosting required.

💡 Writing Your First MCP Server — Structure, Tools, and Resources

The MCP TypeScript and Python SDKs make standing up a basic server straightforward. An MCP server exposes three kinds of primitives: tools (functions the model can call), resources (data the model can read), and prompts (template prompt fragments the host can surface to users). Most integrations start with tools alone and add resources only when there is genuinely useful contextual data to expose. A minimal server needs a name, a version, and at least one tool or resource definition.

Anatomy of a minimal MCP tool

// TypeScript example
server.tool(
  "get_customer",
  "Fetch a customer record by ID",
  { customer_id: z.string().describe("The customer's UUID") },
  async ({ customer_id }) => {
    const record = await db.customers.findById(customer_id);
    return { content: [{ type: "text", text: JSON.stringify(record) }] };
  }
);

• Name: short, snake_case, descriptive — this is what Claude calls when invoking the tool.
• Description: the single most important field; Claude reads this to decide when to use the tool. Write it as a one-sentence answer to "what does this tool do and when should I use it?"
• Input schema: Zod (TypeScript) or Pydantic (Python) schemas are automatically converted to JSON Schema. Be precise — Claude uses field descriptions to understand what values are expected.
• Return format: Return structured JSON where possible; Claude handles unstructured text but performs better with predictable output shapes.