Build an MCP server

An MCP server lets any MCP client (coding agents, chat apps, IDEs) call your tools and read your resources. The model decides the arguments, so every input is untrusted, including inputs that came from a prompt injection in some document the model read earlier. Servers commonly break in a few ways: on stdio, anything written to stdout that is not a protocol message corrupts the session; handlers throw raw exceptions, so the model sees a generic failure and retries blindly; file tools accept ../ paths; database tools accept raw SQL; HTTP servers listen on every interface without checking origin or authentication; and one broad admin token is shared by every tool.

Implement an MCP server in typescript over stdio for: [TOOLS_SPEC]

1. Restate each tool and resource as a table: name, inputs, output, side effects, the external system and the credential it uses. If the spec is ambiguous in a way that changes behaviour or privileges (which directory, which database role, whether writes are allowed), ask before writing code.
2. Use the official MCP SDK for typescript at its current major version. If you are not sure of an exact API in that version, check the SDK's README or type definitions rather than guessing, and list what you assumed.
3. For every tool:

• declare the input schema with types, enums, bounds and descriptions written for the model;
• set the tool annotations honestly (read-only, destructive, idempotent, open-world);
• validate beyond the schema in the handler: resolve paths and reject anything outside the allowed root, use parameterised queries, check identifiers against allowlists, and cap sizes and counts;
• return results as concise text or structured content, truncating large outputs and saying how to get the rest;
• on failure, return a tool result marked as an error, with a message that tells the model what to change, for example "path must be inside notes/; got ../etc/passwd". Never return stack traces, secrets or internal hostnames.

1. Expose resources with stable URIs if the spec includes read-only data.
2. Apply least privilege: read configuration and secrets from environment variables, use read-only credentials for read-only tools, allowlist roots, hosts and tables, and put timeouts on every outbound call.
3. Transport. stdio: write logs to stderr only. http: use Streamable HTTP, bind to 127.0.0.1 by default, validate the Origin header, require authentication for anything that is not strictly local, and note that the MCP specification defines OAuth-based authorization for remote servers.
4. Write tests for input validation and error paths at minimum, a README with the environment variables and a client configuration snippet, and how to try the server with the MCP Inspector.
5. If you can run commands, install, build and run the tests, and report the real output. If you cannot, say that nothing was run.

• Implement only the tools and resources in the spec. Suggest extra ones in one line under Assumptions.
• No shell execution with interpolated input. If the spec asks for arbitrary command execution, raw SQL or unrestricted file writes, explain the risk and propose a narrower tool (an allowlist of commands, named queries, a sandboxed directory) before implementing anything broader.
• Pin the SDK's major version in the manifest.
• Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
• Keep the change as small as it can be while still being correct.

Plan

The tools and resources table, with the privilege each one needs.

Files

Each file in its own fenced block, preceded by its path.

Run and test

Commands to install, build, test and connect a client, plus the real test output or "Not run".

Security notes

What each tool can reach, what the validation blocks, and the remaining risks.

Assumptions

SDK details, spec interpretations and suggested additions.