Guide · Tools & MCP

What is MCP, and what is an MCP server?

Published 1 August 2026 · revised 10 August 2026

An MCP server is how Claude reaches outside the conversation — it exposes tools, resources and prompts over a standard protocol, so one integration works in any MCP client. More in the Tools & MCP track.

MCP — the Model Context Protocol — is how Claude reaches outside the conversation, and an MCP server is the thing on the other end: it exposes tools, resources and prompts over one standard interface, so a single integration works in any MCP client. This is the build order for a Claude MCP server that survives production.

What does an MCP server actually do?

The Model Context Protocol is an open JSON-RPC spec for how AI clients talk to external capabilities. A server exposes three primitives:

Tools — invokable functions; side effects allowed.
Resources — readable content: files, records, URLs.
Prompts — reusable templates the client can offer the user.

If a capability only reads, expose it as a resource. Reaching for a tool first is the most common early mistake — it puts read paths behind a model decision that did not need to be made.

Which MCP transport should you use?

Pick by where the process runs, not by what looks modern:

stdio — local processes launched by a desktop client.
Streamable HTTP — remote servers; the current default.
SSE — legacy remote transport, still supported.

Remote clients POST JSON-RPC and must send Accept: application/json, text/event-stream. A server that does not enforce that returns confusing partial failures; the spec answer is HTTP 406. The longer version of this decision is in which MCP transport to use — stdio, SSE or Streamable HTTP.

A minimal MCP tool

import { defineTool } from "@lovable.dev/mcp-js";
import { z } from "zod";

export default defineTool({
  name: "echo",
  title: "Echo",
  description: "Echo the input text back to the caller.",
  inputSchema: { text: z.string().min(1) },
  annotations: { readOnlyHint: true, idempotentHint: true },
  handler: ({ text }) => ({ content: [{ type: "text", text }] }),
});

How do you secure an MCP server?

Default to OAuth 2.1. If tools read or write per-user data, each caller signs in. Never put that behind an unauthenticated endpoint.
Validate every input at the tool boundary with Zod or equivalent. Treat the model as untrusted input, because it is.
Never take user_id from tool input. Derive identity from the verified token and forward it to the data layer so row-level security runs as that user.
Keep handlers fast. MCP calls are synchronous with a client-side timeout. OCR, video, large scrapes belong in your app, queued — not inside a tool call.

MCP tool design checklist

Clear title and a one-sentence description — clients pick tools by these strings.
Accurate annotations: readOnlyHint, destructiveHint, idempotentHint.
Narrow, orthogonal tools beat one god-tool with a mode flag.
Return structured content when the client can consume it.
Surface provider errors verbatim — do not collapse them into "500".

How do you deploy an MCP server?

Bundle the server as a single edge function (Supabase, Cloudflare Workers, Vercel, Deno Deploy). Publish a stable HTTPS URL and, if you offer OAuth, expose /.well-known/oauth-protected-resource. Then register the URL in the target client — Claude Desktop, ChatGPT connectors, Cursor.

References

Related guides

Keep going

the Tools & MCP track — the full module list this guide belongs to.
Practise this with the coach — a Socratic session with Tools & MCP preselected.