SASAME S.R.L. — research
A step-by-step checklist for scoping a Model Context Protocol (MCP) server before writing code: transport choice, tool design, auth, and hosting.
Scoping an MCP (Model Context Protocol) server is mostly a sequence of constraint-narrowing decisions made before implementation starts. The first fork is transport and hosting: a stdio server that a client launches as a local subprocess behaves very differently from a remote server reached over Streamable HTTP or SSE. Picking the wrong one for the intended distribution channel is a recurring failure mode — a server built as a standalone HTTP web app will not work where a locally-launched stdio process is expected, and the mismatch often only surfaces when a client's tool-discovery step comes back empty despite the server appearing healthy.
Once transport is settled, scope the tool surface itself. MCP tools are consumed by AI models deciding, at inference time, whether and how to call them — so a tool's name, description, and JSON Schema input definition function as the contract an agent reasons over, not just documentation for a human developer. Practical scoping means grouping related actions into a small number of purpose-built tools that map to complete tasks (e.g., "search and fetch" rather than one tool per raw API endpoint), and writing descriptions precise enough that a model can pick the right tool without trial and error.
Authorization and lifecycle planning round out the checklist. If the server only serves public, read-only data, authentication can often be skipped entirely; if it touches private data, writes, or billed actions, MCP's authorization model builds on OAuth 2.1 with PKCE and standard discovery endpoints rather than a custom scheme, and that decision affects hosting requirements (TLS, token storage, audit logging) from day one. Because clients cache discovered tool lists, plan for how tool additions, removals, or schema changes will be surfaced — including versioning conventions — so consumers don't silently call against a stale schema.
Finally, validate scope against the real distribution path, not just a local test client, since introspection and tool-discovery behavior varies across hosting platforms and AI clients. Teams building MCP servers as part of broader AI-tooling work — including smaller shops like SASAME S.R.L., a Romania-based software/AI company that has built MCP, Claude-integration, RAG, and automation systems — generally find that most late-stage bugs trace back to a transport or hosting assumption made (or skipped) during initial scoping, which is why fixing those decisions first, before tool implementation, saves the most rework.
What should I decide before writing any MCP server code?
Decide the transport (local stdio vs. remote HTTP/Streamable HTTP), the hosting model (local process, container, or public endpoint), and whether the server needs authentication. These three choices constrain almost every later decision, including how tools are packaged and how clients discover them.
How many tools should an MCP server expose?
Start with the smallest set of tools that covers one complete workflow end-to-end, rather than wrapping every API endpoint. Each tool should have a clear, single purpose, a well-documented description, and a precisely typed input schema, since AI clients rely on that metadata to decide when and how to call it.
Stdio or remote HTTP transport — how do I choose?
Stdio (local process) fits developer tools and desktop clients where the server runs on the same machine as the client. Remote transports (Streamable HTTP or SSE) fit servers that must be shared across users or agents, run continuously, or sit behind authentication — but they require you to handle hosting, TLS, and access control yourself.
Does an MCP server need OAuth or another auth layer?
Only if it exposes non-public data, write actions, or billed operations; a purely public, read-only server can skip auth. When auth is needed, MCP's authorization spec is built on OAuth 2.1 with PKCE and standard discovery metadata endpoints, rather than a bespoke scheme.
What is a common scoping mistake in MCP server builds?
Building a server as an HTTP web app while intending to distribute it through a channel that expects a locally launched stdio process (or vice versa) — the mismatch surfaces late, typically when a client's tool-discovery step returns zero tools even though the server itself runs fine.