Table of Contents
Why MCP Is the API Standard AI Development Has Been Missing
If you have spent any time building on top of AI models in the last two years, you have felt the integration friction. Every platform arrived with its own conventions. OpenAI had function calling. Anthropic had tool use. Cursor had its own plugin format. Each approach could work well inside its own ecosystem, but the practical cost was obvious: an integration written for one client was rarely an integration that could simply be carried to the next.
That is the mess the Model Context Protocol, or MCP, was designed to clean up. Building an MCP server in TypeScript takes about 30 minutes and requires no prior protocol experience. That does not mean every useful server will be finished in 30 minutes; connecting a real internal system, deciding what access is appropriate, and handling production concerns will naturally take longer. It does mean the first useful step is unusually small.
MCP is a wire-level standard that defines how AI models communicate with external tools and data sources. The model issues a structured request, your server handles it, and the result comes back in a format the model already understands. Write the server once, and any compliant client can call it — whether that is Claude Desktop, Cursor, or something you build yourself.
That portability is the important part. The protocol does not eliminate the need to design good tools, describe them clearly, or secure the data behind them. It removes a layer of client-specific glue. Instead of treating every AI client as a separate integration target, developers can treat the server as the durable boundary around their data and capabilities.
An MCP server in TypeScript lets AI models like Claude query real data without manual copy-pasting. That seemingly modest change matters. Copy-pasting is slow, error-prone, difficult to repeat, and often strips away the context that makes data meaningful. A server can present the same underlying information in a consistent shape whenever the model needs it.
For teams, MCP also encourages a healthier division of responsibility. The AI client handles the conversation and decides when a capability may be relevant. The server remains responsible for what data it exposes, what actions it permits, and what a returned result means. That is much easier to reason about than scattering bespoke integrations through every client an organisation happens to use.
via dev.to
The Three Primitives Every MCP Developer Needs to Know
Before touching any code, it helps to understand what MCP actually gives you to work with. The protocol is built around three core abstractions. They are simple enough to learn quickly, but choosing the right one is a design decision, not just a naming exercise.
- Resources are read-only data endpoints — think database rows, file contents, or API responses the model can fetch on demand.
- Tools are callable functions. The model reads the tool’s description and schema, decides when it is relevant, and calls it with structured arguments.
- Prompts are reusable prompt templates that clients can surface to users directly. They follow the same pattern as tools and resources, but most servers will not need them to start.
The distinction between Resources and Tools matters more than it might seem. Resources are pull-based: the model requests them when it decides it needs context. Tools are action-based: the model calls them to do something. Getting that mental model right early will save you from architectural headaches later.
A useful rule is to start with the least powerful primitive that expresses the job. If the model needs to inspect information, a Resource is usually the natural fit. If it needs to request an operation with arguments, that belongs in a Tool. Treating everything as a Tool can make a server harder to understand, while treating an action as passive data can blur what the model is actually asking the system to do.
Tool descriptions and input schemas deserve more care than their size suggests. The model uses those descriptions to judge relevance, and structured arguments reduce ambiguity. A vague tool creates vague behaviour: the client may not know when to use it, and the server may receive poorly framed requests. A narrow, clearly described tool is often more useful than a single catch-all endpoint that tries to anticipate every possible question.
Prompts are different again. They are not a substitute for the model’s ordinary conversational ability. They are a way to package repeatable starting points for users inside a client. For an initial server, they can wait. Resources and Tools cover almost every integration use case you will encounter, particularly when the goal is to connect a model to real data or a bounded workflow.
Setting Up Your MCP Server in TypeScript
You will need Node 18 or higher. Beyond that, the dependency list is intentionally minimal. The official SDK lives at @modelcontextprotocol/sdk on npm — version 1.11.x as of mid-2026 — and Zod handles input schema validation. That is it.
TypeScript is a sensible starting point because an MCP server is fundamentally an exercise in defining inputs and outputs. The types help make those boundaries visible while you are building, and Zod gives the server a way to validate the structured arguments it receives rather than assuming they are valid. The point is not to add ceremony. It is to make the contract between client and server explicit.
Start by scaffolding a new project and installing dependencies:
- Create a directory.
- Set up the TypeScript project so Node 18 or higher can run the server.
- Install @modelcontextprotocol/sdk and Zod.
- Create the server entry point and define one small capability before attempting a larger integration.
That final step is where many first attempts either become clear or become needlessly complicated. Do not begin by exposing every database row, every file, or every possible operation. Start with one focused Resource or one focused Tool. A small server gives you a fast way to test the full path: can the client discover the capability, understand its description, send structured arguments when needed, and receive a result it can use?
Once that path works, expand deliberately. Add another capability only when you can explain why it is distinct from the first one. If two actions have different purposes, different inputs, or different consequences, separating them will usually make the model’s choices easier to understand. If they are really variations of the same request, keep the interface coherent rather than multiplying endpoints for their own sake.
The broader appeal of MCP is not that it makes AI integrations magically simple. Real systems still have messy data, permissions, failure states, and business rules. Its appeal is that it gives those systems a shared interface with Claude Desktop, Cursor, and other AI clients. For developers who have been rewriting the same idea for multiple model platforms, that is a meaningful shift.
Build the smallest server that proves the connection, then make its boundaries sharper as it grows. That approach keeps the 30-minute setup honest: quick enough to learn from, but grounded in the design choices that make an MCP server useful beyond its first demo.
