2. Building Your First MCP Server

Goal

Set up a repeatable MCP development loop.

Install a supported runtime, choose an MCP SDK, create a server project, and run it locally through an inspector or compatible host.

Checklist

• Project initialized with dependency management.
• Server entry point runs locally.
• Configuration is separated from code.
• Inspector/client can list capabilities.
• Logs are readable during tool execution.

Deliverable

A repository skeleton ready for tools, resources, prompts, tests, and deployment configuration.

Goal

Implement a simple MCP tool end to end.

Build

Define a tool name, natural-language description, input schema, validation rules, handler function, and structured response. Keep the first tool deterministic and side-effect free.

Quality bar

• Clear tool name.
• Narrow purpose.
• Required and optional parameters are explicit.
• Errors are returned in a model-actionable way.

Exercise

Create a summarize_note or lookup_customer tool and test valid, invalid, and empty inputs.

Goal

Design tools that models can use reliably and safely.

Principles

• Prefer task-level operations over leaky low-level primitives.
• Make side effects obvious in names and descriptions.
• Use typed, constrained parameters.
• Return concise structured data plus human-readable summaries.
• Separate read, draft, and commit operations.

Anti-patterns

run_any_query, do_action, and tools with vague parameters such as data or options.

Assignment

Rewrite three vague tools into model-friendly MCP tool definitions.

Goal

Expose readable context through MCP resources.

Resources are named pieces of context, commonly represented with URIs. They are ideal for files, records, documents, settings, and current application state.

Design choices

• Static vs dynamic resources.
• URI naming conventions.
• Metadata and freshness indicators.
• Access checks before read.
• Summaries for large resources.

Exercise

Design resource URIs for a notes app, a CRM account, and a project ticket.

Goal

Package repeatable workflows as MCP prompts.

Prompts let a server publish reusable instruction templates that clients can invoke with arguments. They are useful for standardized analysis, onboarding flows, operational runbooks, and tool-guided tasks.

Good prompts

• Have a clear job.
• Accept named arguments.
• Reference available tools/resources.
• Encode team conventions.
• Are versioned when behavior changes.

Assignment

Create a prompt for investigating a customer support escalation.

Goal

Build a local knowledge MCP server.

Requirements

• Index or read a small folder of notes.
• Expose at least one resource type.
• Implement two tools, such as search_notes and get_note.
• Add one reusable prompt for synthesizing notes.
• Test discovery and execution in an MCP client or inspector.

Reflection

What context should be returned directly, summarized, or withheld? Document your decisions in the repository README.