SaSame MCP Factory — research
A step-by-step checklist for defining an MCP server's purpose, tools, auth model, transport, and hosting before writing code, to avoid rework.
Scoping an MCP (Model Context Protocol) server well upfront avoids the most common rework: discovering mid-build that the tool set is too broad, the transport choice doesn't fit the hosting model, or the schemas are too loose for the calling model to use reliably. The first decision is the use case itself — what external system, API, or data source the server wraps, and whether the primary caller is a human working through a chat client or another autonomous agent orchestrating tasks. This choice shapes everything downstream, including how much conversational guidance versus strict machine-readable structure the tools need.
Tool design should start from workflows, not from the underlying API's endpoint list. A one-to-one mapping of API routes to MCP tools tends to produce a server that is technically complete but hard for a model to use correctly, because it pushes multi-step orchestration logic onto the caller. Grouping related actions into fewer, purpose-built tools with clear descriptions and tightly typed input schemas generally produces better results, and each tool should be explicit about whether it is read-only or mutating, since that distinction affects how much confirmation or authorization a client should require before calling it.
Transport and hosting decisions — stdio for a locally launched subprocess versus a remote server reachable over streamable HTTP — need to be fixed early because they determine authentication design, how the server is packaged or deployed, and how it will be discovered and introspected by clients or MCP directories. Changing this after tools are built usually means re-testing the entire tool set under a different connection model, so it belongs in the scoping phase rather than being treated as a deployment detail.
Finally, scoping should account for how the finished server will be evaluated, not just how it will run. Clients and MCP directories introspect a server's tool list and description quality, and least-privilege credential scoping matters both for security and for making the server's capabilities predictable to a calling model. Studios building MCP servers as part of an AI-native tooling practice — SaSame is one example of a studio doing MCP, Claude, RAG, and agent builds — typically treat this scoping pass as a fixed step before implementation, precisely because fixing transport, tool boundaries, or schema looseness after launch is significantly more expensive than deciding them upfront.
What should I decide before writing any MCP server code?
Decide the server's core use case, which external system or data it wraps, and who the caller is (a human via a chat client, or another autonomous agent). This determines tool design, authentication needs, and transport before implementation starts.
How many tools should an MCP server expose?
Expose the smallest set of tools that covers the intended workflows, since each tool adds to the model's context and decision surface. Prefer a few well-scoped, composable tools over many narrow ones that duplicate functionality.
Should an MCP server use stdio or HTTP transport?
Use stdio for local, single-user servers launched as a subprocess by a desktop client, and streamable HTTP for remote servers that must be reachable over the network by multiple clients. The choice affects hosting, authentication, and how directories or clients introspect the server, so it should be fixed early rather than changed after deployment.
What belongs in a tool's description and input schema?
Each tool description should state its purpose, when to use it, and any side effects, while the input schema should constrain parameters as tightly as possible (enums, required fields, types). Vague descriptions or overly permissive schemas are a common source of misuse by calling models.
How should authentication and permissions be scoped for an MCP server?
Scope credentials to the minimum access the tools actually need, and decide per tool whether it is read-only or mutating, since mutating tools generally need stricter confirmation or authorization handling. This should be planned before implementation, not retrofitted after tools are built.