Building an MCP server means writing a small service that exposes tools, resources and prompts to AI clients such as Claude via the Model Context Protocol. You choose an SDK (Python or TypeScript), define at least one tool, select the transport (stdio or Streamable HTTP) and register the server in the client. The protocol is based on JSON-RPC 2.0 and, through the SDK, handles the entire message exchange for you - you only write your domain logic.

Three quick answers up front:

• For a first working server, an SDK, a runtime (Python or Node.js) and a single tool are enough - realistically achievable in around 30 minutes.
• For local development you use the stdio transport (no port, no auth); for remote servers you use Streamable HTTP with OAuth 2.1.
• MCP connects agents to tools and data. A2A, not MCP, is responsible for collaboration between autonomous agents.

What an MCP server actually is

Anthropic introduced the Model Context Protocol on 25 November 2024 as an open standard for connecting AI applications to external systems - file systems, databases, business systems, developer tools. The authors are David Soria Parra and Justin Spahr-Summers. Technically, MCP is a JSON-RPC 2.0 protocol over interchangeable transports. Instead of inventing a separate format for every tool integration, client and server speak the same language.

An MCP server exposes three primitives to the client:

• Tools: functions that the model can actively call (e.g. "look up weather", "write a record"). This is the most important and most common building block.
• Resources: readable data sources that the client can load into the context (files, database content, configurations).
• Prompts: predefined, parameterisable templates that the user can invoke in the client.

To get started, focus exclusively on a single tool. Resources and prompts can be added later.

Step 1: Choose a transport - stdio or HTTP

The first architectural decision concerns the transport. MCP supports several variants; in practice, two are relevant.

Recommendation: Start with stdio. The client launches your server as a local process and communicates via standard input/output. There is no port, no TLS configuration and no authentication to sort out. As soon as your server needs to run remotely, be used by multiple clients or sit behind access control, you migrate to Streamable HTTP. This variant was introduced with the April 2025 revision of the specification (together with OAuth 2.1 support, JSON-RPC batching and tool annotations) and replaced the original Server-Sent-Events-only model. The November 2025 revision added, among other things, asynchronous operations, statelessness and server identity.

Step 2: Choose an SDK - Python or TypeScript

Official SDKs exist for all major programming languages; the two most widely used are Python and TypeScript (together over 97 million monthly downloads, as of 2026). The choice simply follows your existing stack:

• Python: ideal for data/ML-oriented teams and rapid prototypes.
• TypeScript: ideal for Node.js/Next.js-oriented teams and web stacks.

Both SDKs handle the JSON-RPC processing, the capability negotiation and the transport binding. You declare a tool with a name, description and parameter schema and write the actual function.

Step 3: A minimal server with one tool (pseudocode)

The following pseudocode example shows a server with exactly one tool that performs a currency conversion. The logic is deliberately trivial - the point is the structure.

```

Pseudocode (modelled on the Python SDK style)

server = MCPServer(name="fx-tools")

@server.tool(
name="convert_currency",
description="Converts an amount from one currency into another. "
"Expects amount (number), from (ISO code), to (ISO code).",
input_schema={
"type": "object",
"properties": {
"amount": {"type": "number"},
"from": {"type": "string"},
"to": {"type": "string"}
},
"required": ["amount", "from", "to"]
}
)
def convert_currency(amount, from_, to):
rate = lookup_rate(from_, to) # your own domain logic
result = round(amount * rate, 2)
return {"result": result, "rate": rate}

IMPORTANT: log ONLY to stderr, never stdout (breaks JSON-RPC)

log_to_stderr("Server starting")

server.run(transport="stdio")
```

Three things are crucial here and are frequently overlooked:

1. The description is not decoration. The model decides solely on the basis of the name and description whether and how to call the tool. Vague descriptions lead to incorrect or missing calls.
2. The input_schema (JSON Schema) defines the parameters bindingly. Without a correct schema, the client cannot validate the arguments.
3. With the stdio transport, stdout is reserved for the protocol. Any logging must go to stderr - otherwise the JSON-RPC stream breaks.

Step 4: Register and test the server in the client

With stdio you register the server by telling the client the start command. In clients such as Claude Desktop this is done via a configuration file that looks roughly like this:

```
{
"mcpServers": {
"fx-tools": {
"command": "python",
"args": ["path/to/server.py"]
}
}
}
```

After restarting the client, your tool appears. Test it in this order:

1. Check discovery: Does convert_currency appear in the client's tool list? If not, the subprocess usually fails to start (wrong path, missing dependency).
2. Trigger a call: Ask a question that triggers the tool ("How much is 500 EUR in CHF?"). The client should call the tool with the correct arguments.
3. Check the response: Does the server return a well-formed result that the client embeds in its answer?

For troubleshooting independently of the model, the official MCP Inspector helps - a standalone tool from the MCP project with which you can call tools directly and follow the JSON-RPC protocol. This speeds up debugging considerably.

A concrete example with numbers

Suppose you connect an internal price list. The server exposes a tool get_product_price. An employee asks in the client: "How much does article A-204 cost in variant L?". Without MCP, the model would have to guess or hallucinate. With the tool, the model calls get_product_price(sku="A-204", variant="L"), the server returns {"price": 49.90, "currency": "EUR", "stock": 12}, and the model answers based on facts. The entire implementation effort for such a read-only tool amounts to one file and a few dozen lines - the bulk of the 30 minutes mentioned at the outset goes into connecting your existing data source, not into the protocol.

Common mistakes

• Logging to stdout: the most common beginner mistake with the stdio transport. Anything that is not JSON-RPC must go to stderr.
• Vague tool descriptions: the model does not call the tool, or calls it incorrectly. Write descriptions like API documentation for a colleague.
• Missing or incorrect JSON schema: required fields not marked, types imprecise - the client cannot validate arguments.
• Overly broad permissions: a tool that can do more than necessary is an attack surface. Least-privilege applies from the very first line.
• Security gaps from trust assumptions: documented in 2025/2026 are, among others, indirect prompt injection via tool descriptions, tool poisoning (Invariant Labs WhatsApp PoC, March 2025), look-alike server squatting, CyberArk's full-schema poisoning (every part of a tool schema can be an injection point) and the "toxic agent flow" via manipulated GitHub issues. The cause is MCP's fundamentally optimistic trust model, which equates syntactic correctness with semantic safety. Securing this is the operator's responsibility: sandboxing, scope-limited tokens, OAuth 2.1 for HTTP transports - and no automatic installation of MCP servers from untrusted registries.

Note as of 2026

In 2026, MCP is the established industry standard for agent-to-tool: on 9 December 2025 Anthropic handed the protocol over to the newly founded Agentic AI Foundation under the Linux Foundation - co-founded by Anthropic, Block and OpenAI, with Platinum support from AWS, Bloomberg, Cloudflare, Google and Microsoft. MCP is supported by, among others, OpenAI (since March 2025), Google DeepMind (April 2025), Microsoft Copilot Studio, SAP Joule, Salesforce Agentforce as well as n8n and LangGraph. Claude has a directory of more than 75 official MCP connectors. For collaboration between autonomous agents you do not rely on MCP but on A2A - the rule of thumb is: MCP for capabilities, A2A for collaboration.

For agencies and B2B

For DACH agencies, a dedicated MCP server is the direct route to making proprietary capabilities - a keyword research function, an internal CMS, a pricing API - usable across vendors, without having to build a bespoke integration for each client. An MCP server built cleanly once can be reused across product lines. For B2B decision-makers the message is: if you deploy agents in 2026, you will be consuming or writing MCP servers - whether planned or not. Treat every tool as relevant to permissions and auditing. At Blck Alpaca, we design MCP servers along the lines of least-privilege, clean schemas and traceable audit trails - get in touch if you would like to connect an internal data source to your AI agents in a GDPR-compliant way.