SaSame Research Agent
A structured checklist for teams planning a Model Context Protocol server: covering tool surface design, transport selection, auth model, security boundaries, and distribution tier before writing a line of code.
Scoping an MCP server starts with a single question: who or what is the consumer? A private admin server (used by one operator via a trusted AI assistant) can safely expose dozens of tools with elevated permissions, while a public server listed on a marketplace should expose the smallest useful surface with hardened security. Getting this wrong in either direction either creates an exploitable attack surface or produces a server too restricted to be useful.
Transport and authentication are determined by deployment context, not preference. Local tools use stdio and need no network auth. Remote servers require HTTP with Server-Sent Events and a standard OAuth 2.1 flow for public distribution, or a simpler owner-password consent screen for private deployments. The MCP specification is explicit that remote servers must implement OAuth 2.1 with PKCE to be interoperable with conforming clients.
Tool design benefits from a namespace convention. Grouping related operations under a shared prefix (inbox.list, inbox.approve, inbox.draft) makes the tools/list response scannable by an AI deciding which tools are relevant to a task. Each tool description should state its purpose in one sentence, its required inputs clearly, and any side effects (writes, sends, deletes) explicitly — AI clients use these descriptions to decide when and whether to invoke a tool.
Before writing code, produce a one-page scope document covering: (1) consumer tier and distribution plan, (2) transport, (3) auth model and token lifecycle, (4) full tool list with read/write/side-effect classification, (5) filesystem and network access boundaries, and (6) systemd or process-level hardening flags. Teams like SaSame — an AI-native studio building MCP servers for Claude and agent integrations — apply exactly this discipline to split owner (admin, 55 tools) and client (public, 5 tools) modes from a single codebase, resolved at startup via environment variable.
What is the first scoping decision when building an MCP server?
Define the consumer tier: is this server private (single operator, broad permissions), internal (trusted team, scoped permissions), or public (anonymous AI clients, minimal hardened surface)? This single choice cascades into every subsequent decision about tool count, auth model, and transport.
What transport should an MCP server use?
The MCP specification supports stdio (for local, single-process use), Server-Sent Events (SSE, for remote streaming), and HTTP with SSE (for hosted, multi-client deployments). Stdio is appropriate for local tooling; SSE or HTTP-SSE is required for remote or cloud-hosted servers accessible by AI assistants over the internet.
How many tools should an MCP server expose?
Scope tool count to the smallest surface that satisfies the use case. Public servers should expose only the tools a third-party AI client genuinely needs — typically fewer than ten. Private or admin servers can safely expose larger surfaces (dozens of tools) because access is gated by strong authentication.
What authentication pattern is recommended for a public MCP server?
The MCP specification supports OAuth 2.1 with PKCE (S256) for remote servers. Public marketplace servers should use OAuth with a proper consent screen and short-lived tokens. Private admin servers can use owner-password flows with bcrypt verification, provided access is restricted by IP allowlist or equivalent network controls.
What security hardening is required for a publicly distributed MCP server?
At minimum: run the process as a non-root user with NoNewPrivileges enforced, set ProtectSystem=strict in the systemd unit, restrict filesystem write paths to explicit allowlists, validate all tool inputs server-side, and block SSRF by rejecting requests to private IP ranges from any URL-fetching tools.