Build Your First MCP Server: Tools, Boundaries and Testing

What MCP provides

MCP is an open protocol introduced by Anthropic that standardises how AI applications, called hosts, connect to external servers. A server can expose tools that the model may call, resources that provide data for context and prompts that offer reusable templates. Hosts connect through clients that speak the protocol, which is based on JSON-RPC 2.0 messages. Servers commonly run locally over standard input and output or remotely over HTTP. Because the interface is standard, one server can work with any compatible host.

Official SDKs are available for several languages, including TypeScript and Python. Check the current specification and SDK documentation for exact APIs, as the protocol continues to evolve.

Decide what the server should do

Start from the questions users will ask: 'Which beginner courses cover RAG?', 'What does the Docker micro course include?', 'When is the next Hinglish webinar?'. Each question suggests a narrow capability. For this catalogue, three tools are enough: search_courses with a text query and optional level, get_course with a course ID and list_upcoming_webinars with an optional language. Course pages could also be exposed as resources the host can attach as context.

Resist a single general tool such as run_sql. Narrow tools are easier for a model to use correctly and far easier to secure.

Design each tool's interface

• Name: a clear verb and noun, such as search_courses.
• Description: what it does, when to use it and what it returns, written for a reader who has never seen your system.
• Input schema: required fields, enumerations for fixed values such as level, formats for identifiers and a maximum for result limits.
• Output: compact, structured results containing only fields the model needs, such as title, level, path and a one-line summary.
• Errors: messages that explain how to recover, such as suggesting search_courses when an ID is unknown.

Implement with boundaries

Keep the MCP layer thin. Each tool handler validates its input, calls an ordinary function in your application's data layer and formats the result. That separation means the business logic is testable without MCP and the same functions can serve your website and the server. Apply the same permission checks you use elsewhere: if certain courses are unpublished, the data layer must exclude them regardless of what the model asks.

Treat everything the server returns as content the model will read. Do not include internal notes, personal data or instructions that could be mistaken for commands in results.

Test at three levels

First, unit-test the data functions directly. Second, test the server through the protocol: use the MCP Inspector, a developer tool for connecting to a server and calling its tools by hand, to confirm schemas, descriptions and errors look right. Third, test with a real host and a set of representative questions, and check that the model chooses the right tool with sensible arguments. Record failures; they usually point to an unclear description or an overly broad tool.

Operate it safely

• Log each tool call with its arguments and result size, excluding sensitive values.
• Set timeouts and result limits so one call cannot run indefinitely or return huge payloads.
• Authenticate remote servers and authorise each call based on the user, not the model.
• Require confirmation in the host for any tool that changes data or costs money.
• Version tool changes and keep descriptions accurate as behaviour evolves.

Checklist

• Tools map to real user questions
• Each tool is narrow, well described and strictly typed
• Handlers are thin and call testable application code
• Permissions are enforced on the server
• The server is tested with the Inspector and a real host
• Calls are logged, limited and safe to operate