Step 1 of 4
Choose tools worth exposing and set up the SDK
A first server succeeds by doing few things properly.
Plan the server. Choose 2-3 tools that are genuinely useful and safely scoped for a first server - good candidates: a project-search tool (query in, ranked hits out), a read-only data lookup from my domain, and one bounded action tool. For each, write the name, steering description, and JSON schema (apply tight-schema practice: enums, ranges, additionalProperties false). Install the official MCP SDK for my language (verify the current package name and API from the official docs - the ecosystem moves fast) and scaffold the server project with the SDK's canonical structure.
Expected after this step
A scoped tool plan plus a scaffolded SDK project.
Should not happen
- ✕Hand-rolled protocol handling that breaks on the first spec nuance
- ✕Tools that work in isolation but fail through the host's serialization
- ✕Errors thrown as exceptions that kill the server instead of error results
- ✕No logging, making host-side failures undiagnosable
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !Hand-rolled protocol handling that breaks on the first spec nuance
- !Tools that work in isolation but fail through the host's serialization
- !Errors thrown as exceptions that kill the server instead of error results
- !No logging, making host-side failures undiagnosable
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
The SDK examples do not match the installed version. Check the version-specific docs or the SDK's own examples directory - MCP SDKs have had breaking API changes between versions.