"Model Context Protocol" sounds heavy. It is not. An MCP server is a tiny service that does three things: it lists the tools it offers, it accepts JSON calls to those tools, it returns JSON results. Everything else in the spec is plumbing.
The interesting question is not what MCP is. It is: what is the shortest path from "I have data" to "Claude can call my data"? This article walks the shortest path. We use AppElixir as the example because we built it that way; the steps generalize.
The five-minute build
Minute 1: pick the data source
Three sources cover 90% of useful MCP servers:
- A spreadsheet — Google Sheets, Excel, Airtable. Best for lookup tools the agent uses sporadically.
- A SQL table — Postgres, MySQL, SQLite. Best when the data is already in your app.
- A REST endpoint — your own API, a third-party API, a webhook. Best when the action is "do something" rather than "look something up".
Pick one. If your data lives in two places, build two servers — not one server that proxies two sources. MCP servers compose well; megaservers do not.
Minute 2: name the tool, write the description
This is the part everyone underweights. The agent picks tools by reading their description. A tool named lookup_customer with description "returns the customer record for a given email" is callable. A tool named customer_v2_handler with description "internal endpoint" is not callable; the agent will skip it and hallucinate.
Rule of thumb: the description should answer "when would I, an AI agent, want to call this?" in one sentence, with concrete nouns from your domain.
Minute 3: define the inputs as a form
This is where the AppElixir bet pays off. We already had a form builder for human apps. The same schema becomes the MCP inputSchema. Required text becomes required string. Numeric range becomes integer with min/max. Dropdown becomes enum. The form you would have built anyway is the contract the agent reads.
Two field types deserve attention:
- Enums. If the input has a finite set of valid values, enumerate them. Agents respect enums. Agents hallucinate free-text fields.
- Descriptions per field. The field description is also exposed in the MCP schema. Use it. "Customer email, lowercase, no whitespace" reduces tool-call retries.
Minute 4: map the output to a collection
The output side mirrors the input side. AppElixir collections already define the shape of records they hold: customer collections have email, plan, signup_date; ticket collections have id, status, priority. That shape becomes the MCP tool's output type.
For lookup tools, the output is one record. For list tools, an array. For "do something" tools (create-ticket, send-email), the output is the resulting record plus a status field. Same shape every time; the agent learns the pattern after two calls.
Minute 5: deploy and test
One button. AppElixir generates an HTTPS endpoint, an API token, and an MCP config snippet for Claude Desktop, ChatGPT, and Cursor. Paste the snippet into the client of your choice, restart it, watch the tool appear in the agent's tool list.
The built-in MCP inspector is the part that should not be skipped. It lets you call your tool from a fake-agent UI with the same JSON shape the real agent will send. Three test calls — empty input, valid input, malformed input — catch 80% of the bugs before the agent does.
What gets built for you
Five minutes is fast because four things you would otherwise build are built once and reused for every server:
Auth
Per-server API tokens, per-agent revocation. The token rides in the Authorization header. The agent's MCP client adds it automatically once you paste the config; you never type the token into a chat.
Rate limits
Per-tenant, per-tool, per-minute. The defaults match what most agents need (60 calls/min/tool on the free tier, higher on paid). Hit the limit and the tool returns a structured error the agent can reason about — not a 429 the agent gets confused by.
Audit log
Every tool call gets a row: who called, which tool, with what arguments, what the result was, how long it took. This is the most-overlooked production requirement of MCP servers. When the agent does something weird and the customer asks why, the audit log is the only honest answer.
Schema validation
Bad inputs bounce before they reach your data source. JSON Schema lives in the protocol; we enforce it on the server too. The agent sees a clean validation error and retries with corrected arguments.
What other MCP servers exist
Worth knowing the landscape before you build:
- Anthropic's reference servers — filesystem, GitHub, Slack, Postgres, Puppeteer, fetch. Source-available, well-maintained, good starting point if your need overlaps.
- Community catalog — 200+ servers as of mid-2026. Linear, Jira, Notion, Figma, Supabase, Stripe, Sentry, and dozens of niche tools. Worth a search before you build a duplicate.
- Memory servers — a busy sub-category because every agent eventually needs persistent memory. Four or five dedicated services compete here, and a key-value store is usually wrong for agent memory because it loses lineage and fact-deduplication.
- Vendor-owned servers — OpenAI's MCP listing in ChatGPT, Google's MCP-compatible ADK tools. These are growing fast; check for an official one before you wrap a vendor's REST API yourself.
The strategic question is not "should I use a no-code builder or build it myself" — it is "what part of the MCP server is differentiated, and what part is plumbing I shouldn't be writing twice." Auth, rate-limits, audit log, and schema validation are plumbing. The data and the tool design are differentiated. Pay attention to the second; outsource the first.
Three rules for the first MCP server you ship
- Start with one tool, not five. One tool, one data source, one happy path. Add tools after the first one survives a week with a real agent calling it.
- Read-only by default. The first version of every MCP server should be lookup-only. Write tools come after you have an audit log you trust.
- The tool description is product. Treat it like microcopy. The agent's tool-choice quality is downstream of how well you wrote the description.
Five minutes is not a marketing number. It is the time it takes when the plumbing is solved and the only thing you are doing is naming a tool and pointing it at data. That is the whole point.