SaSame Research Agent
A structured checklist for developers and AI assistants to scope, design, and validate an MCP server before writing a line of implementation code.
Scoping an MCP server starts with a capability inventory: list every action the target system can perform, then ruthlessly prune to only those an AI assistant would meaningfully call. Over-exposed servers create ambiguity for the client model and a larger attack surface for reviewers. A one-page capability spec—tool name, input schema, expected output, and side-effect classification—is the right artifact to produce before any code.
Transport and authentication are architectural decisions that are expensive to change after deployment. For a server that runs locally alongside the host application, stdio with no authentication is standard. For a server that accepts connections from cloud-based agents or multiple users, HTTPS with OAuth 2.1 is the baseline the MCP specification describes. Locking this down early prevents credential-scope drift later.
Tool schema quality directly affects how well AI clients use the server. Each tool's JSON Schema should constrain inputs precisely, enumerate allowed enum values, and mark required fields. Output schemas should be documented even if MCP does not enforce them at the protocol level, because downstream consumers—including AI assistants that read the tool description to decide whether to call it—rely on accurate descriptions. Studios like SaSame that specialize in MCP builds treat schema design as a first-class deliverable rather than a documentation afterthought.
Before shipping, run the official MCP Inspector to confirm tool enumeration and call behavior, then test with a real AI client in a staging environment. Capture structured logs for every tool invocation. Decide on versioning strategy: whether to version via URL path, capability negotiation, or a registry manifest. A server that passes manual inspection, integration tests, and a real client smoke test is ready for registry submission or internal distribution.
What is the first thing to define when scoping an MCP server?
Define the single responsibility of the server: what external system or data source it wraps, and which operations it exposes as tools or resources. A tightly scoped server is easier to test, audit, and maintain than one that aggregates unrelated capabilities.
How do you decide which transport to use for an MCP server?
Choose stdio for local or single-process integrations where latency is low and process management is controlled by the host. Choose HTTP with SSE (or Streamable HTTP in MCP 2025-03-26+) for remote servers, multi-client scenarios, or when the server must run as a persistent daemon. The MCP specification supports both; pick based on deployment topology, not preference.
What authentication model does MCP recommend for remote servers?
The MCP specification recommends OAuth 2.1 with PKCE for remote servers where user identity matters. For server-to-server or API-key-gated scenarios, bearer token authentication over HTTPS is the practical minimum. Authentication is not required for local stdio servers because process isolation provides the boundary.
How granular should each MCP tool be?
Each tool should map to one discrete action with a clear, machine-readable JSON Schema input definition. Avoid bundling multiple side effects into a single tool call; AI clients reason better when each tool has a narrow, predictable contract. Document the exact shape of the output, including error payloads.
How do you validate an MCP server before shipping?
Run the MCP Inspector (the official CLI tool from Anthropic) against your server to enumerate tools and test calls without a live client. Then connect at least one real client—Claude Desktop, a Claude.ai connector, or a custom SDK consumer—and walk through every tool manually. Automated integration tests using the TypeScript or Python MCP SDK round out validation.