Connect Claude to your own systems via MCP

What is Model Context Protocol?

Model Context Protocol, abbreviated MCP, is an open standard Anthropic published in 2024. It describes how an AI model like Claude can communicate in a structured way with external tools and data sources. Claude sends a tool call with parameters, the MCP server executes it and returns the result. This allows Claude to run a SQL query, call a REST endpoint or read a file without the user having to supply the raw data themselves.

The protocol runs via a separate server process. That server runs locally alongside Claude Desktop, or on a machine in your own network, depending on the architecture. Claude communicates with the server via a standardised JSON-RPC interface over stdin/stdout or over an SSE connection. The MCP server translates the tool calls into actions on your system.

MCP is not a chatbot plugin or a SaaS connector. It is a low-level protocol that provides full control over what Claude can do and what it cannot. The server defines the schema of available tools: names, parameters and descriptions. Claude decides which tool is most appropriate based on those schemas and the user's question.

How does MCP differ from function calling and ChatGPT plugins?

OpenAI's function calling and ChatGPT plugins work in a similar way, but there are key architectural differences:

• ▸MCP is an open standard. The spec is published on GitHub and any party can implement a client or server. There is no vendor lock-in to a specific cloud platform.
• ▸MCP servers run as their own processes. That means the server can run on-premise, behind a firewall, without any data leaving to an external service.
• ▸Authentication is a first-class concept in the MCP spec. OAuth 2.1 is the recommended flow for servers reachable over the network. For local servers, an API key via environment variables is sufficient.
• ▸Both Claude Code and Claude Desktop are MCP clients. That means an MCP server I build works in Claude Desktop for end users and in Claude Code for developers.
• ▸Tool descriptions are machine-readable schemas. Claude uses those schemas to reason about which tool best fits a question. This makes MCP integrations more reliable than hard-coded prompts.

ChatGPT plugins have since been replaced by GPT Actions, but those only work within the OpenAI platform. MCP servers are model-agnostic in the spec, although Claude is currently the most complete MCP client.

What I build with MCP

The scope varies per project. These are the most common MCP server types I implement:

• ▸Database query MCP servers: Claude asks questions in natural language, the server translates them into SQL and returns the result. Read-only queries, with an explicit allowlist of permitted tables and columns.
• ▸REST API MCP servers: a wrapper around your internal or external API. Claude can call endpoints, fill in parameters and interpret the response. More useful than reading documentation for developers using internal tools.
• ▸File system MCP servers: controlled read and write access to files at a specific location. Useful for teams wanting Claude to work with local project files.
• ▸Internal tool MCP servers: connection to business software that has no public API. Built via a headless scraper or internal SDK, with rate limiting and error handling.
• ▸Knowledge base MCP servers: vector database or document store as a tool. Claude searches for relevant passages and cites the source. Suitable as an alternative to RAG pipelines you want to manage yourself.

For each MCP server I define the tool schema, the validation layer, error handling and logging. The server is fully stateless or has minimal state: the protocol allows this and it makes deployment simpler.

My stack and deployment

I write MCP servers primarily in TypeScript using Anthropic's official MCP TypeScript SDK. For data science or internal use, sometimes in Python using the Python SDK. The choice depends on what best fits your existing technology.

• ▸TypeScript SDK: type-safe tool definition, automatic parameter validation via Zod schemas, and a strong developer experience. Works well for REST API wrappers and database connections.
• ▸Python SDK: useful when your internal tooling is already written in Python or when working with data science libraries. Same MCP spec, different runtime.
• ▸Docker deployment: the MCP server is packaged into a Docker container. This makes the environment reproducible and allows you to test the server locally before going to production.
• ▸Auth via OAuth 2.1 or API key: for servers reachable over the network I use OAuth 2.1 with PKCE. For local servers, an API key via a .env file is the simplest solution.
• ▸Transport layer: stdio for local servers, SSE or HTTP for servers accessed from a network. The choice depends on the client type.

I deliver the server as a fully documented project: a README with setup instructions, schema documentation for every tool, and a configuration file that goes straight into the Claude Desktop config.

Concrete use cases

These are scenarios where MCP integrations add direct value:

• ▸Claude Desktop connected to your internal database: employees ask questions like 'how many open orders do we have today?' and get an answer directly from the system, without having to export a report.
• ▸Claude Code connected to internal tooling: developers can run commands on internal systems, query documentation or trigger deploys via Claude Code, without switching out of the IDE.
• ▸In-house support assistant: Claude connected to a knowledge base of products, procedures or FAQ. Employees ask in plain language, Claude finds the relevant passage and gives an answer with a source reference.
• ▸Automated reporting: Claude queries data via an MCP server, aggregates it and writes a report in the desired format. Can be run periodically via a scheduler.
• ▸Development environment with internal API: developers who want to experiment with your internal API without having the documentation constantly open. Claude understands the tool schemas and suggests the right endpoints.

The common pattern is that Claude acts as an interface for systems that normally require a separate frontend or query tool. That lowers the barrier for both technical and non-technical users.

What I do not do

There are limits to what I build, and they are deliberate:

• ▸No MCP servers without a security review. An MCP server that runs SQL queries without an allowlist or parameterisation is a direct attack vector. Every server I build has explicit limits on what is possible.
• ▸No public MCP endpoints without rate limiting and authentication. An MCP server reachable from outside the network without auth is not an MCP server, it is an open API. I do not build that.
• ▸No MCP integrations without a clear business case. If a simple Zapier workflow or a direct API integration solves the problem better, I will say so.
• ▸No write actions to production databases without an explicit confirmation step. Read-only is the default. Write actions require a tool schema with a confirmation parameter and logging.
• ▸No MCP servers for systems I do not have or cannot get access to. I need API documentation or direct access to the system to build a good server.

Security is not an afterthought with MCP. The protocol gives Claude direct access to systems, and that requires every tool definition to be thoroughly considered.

Read more