Building an MCP Server: Connect Claude to Your Internal Systems

Summary — In Part 1 we touched on MCP (Model Context Protocol) only briefly, as “the standard interface that lets an agent connect to outside tools and data.” This article goes further and actually builds an MCP server, so that Claude can reach into your internal systems — internal APIs, databases, files. If you’ve already read our guide to connecting Claude to an Ontology with OMCP, this article is what’s running under the hood.

Why You Need an MCP Server

There are broadly two ways to let an agent like Claude reference data from your internal systems.

Copy-paste every time — a person looks up the data and pastes it into the prompt. Fine for one-off tasks, but it doesn’t scale to repeated work or anything that needs fresh data.
Connect directly with an MCP server — the agent calls a tool itself whenever it needs data. Build it once, and every future conversation and task can reuse it.

MCP is the protocol that standardizes this “direct connection.” Instead of building a bespoke integration for every internal system, you build one server that follows the MCP spec, and it works identically across every MCP-capable client — Claude Code, Claude Desktop, and others.

What an MCP Server Can Expose

An MCP server can expose three broad categories of capability to a client like Claude.

Component	Role	Example
Tool	A function the agent can call and execute	“Look up a ticket in the internal ticketing system”
Resource	Data the agent can read	“Today’s sales report file”
Prompt	A predefined prompt template	“Summarize the weekly report in this format”

In practice, Tools are almost always where people start. The fastest path is a single function that “calls an internal API and returns the result.”

A Working Example — A Minimal Server Exposing One Tool

Using the Python MCP SDK, here’s a server with a single Tool that calls an internal inventory-lookup API.

from mcp.server.fastmcp import FastMCP
import requests

mcp = FastMCP("inventory-server")

@mcp.tool()
def get_stock(sku: str) -> str:
    """Look up internal stock quantity by SKU."""
    resp = requests.get(f"https://internal-api.example.com/stock/{sku}")
    resp.raise_for_status()
    data = resp.json()
    return f"{sku} stock: {data['quantity']} units"

if __name__ == "__main__":
    mcp.run()

To connect this server to Claude Code, register the launch command in your config file.

claude mcp add inventory-server -- python inventory_server.py

Once connected, Claude answers questions like “how much stock is left for SKU A123?” by calling the get_stock tool on its own. From this point on, nobody has to query the API by hand.

What to Watch For — Permissions and Side Effects

Before connecting an MCP server to internal systems, check these two things first.

Separate reads from writes — mixing read-only tools and data-mutating tools on the same server raises the risk that the agent calls a “write” tool by accident while intending a lookup. Keep write operations as clearly distinct tools, and add a confirmation step wherever possible.
Handle authentication on the server side — never pass API keys or tokens to Claude through the prompt. The MCP server itself should manage credentials via environment variables or its own config, while the agent only ever deals with tool names and parameters.

Tools with write operations connect directly to the agent-autonomy problem covered in Part 1. For anything hard to undo — deletion, payment, sending — it’s safer to either not build the Tool at all, or design it to always require human confirmation.

Wrapping Up

MCP is the protocol that standardizes how an agent connects to outside systems.
A server can expose three things — Tool (execute), Resource (read), and Prompt (template) — and in practice, teams usually start with Tools.
A minimal setup is just one function wrapped with the MCP SDK and registered with a client.
Separating reads from writes, and handling authentication server-side, should be part of the design from day one.

AI Agent Series — Full Table of Contents

This article isn’t a direct sequel to that 6-part series, but it pairs well with it: What Is a Multi-Agent System? Getting Agents to Collaborate

Frequently Asked Questions

Q. Do I need to use Python?

No. Official MCP SDKs also exist for TypeScript and other languages — pick whichever fits your existing stack.

Q. Does this replace OMCP?

No — OMCP is a specific implementation built for connecting Claude to a Palantir Ontology. This article covers the general pattern for building any MCP server, of which OMCP is one example.