Skip to main content
Glama
SekiroKenjii

MCP Server Boilerplate

by SekiroKenjii

MCP Server Boilerplate

A production-grade starting point for building Model Context Protocol (MCP) servers in native TypeScript. Clean enough for a weekend project, hardened enough for an enterprise deployment.

  • ⚡️ Native TypeScript, strict, ESM (NodeNext)

  • 🔌 Two transports out of the box — stdio (local clients) and Streamable HTTP (remote/hosted) with session management

  • 🧱 Modular structure — one file per tool / resource / prompt, aggregated automatically

  • Zod-validated tool I/O and environment config

  • 🪵 Structured logging (pino) to stderr only, so stdio JSON-RPC stays clean

  • 🛡️ DNS-rebinding protection (Host-header validation) + CORS + optional bearer auth

  • 🧪 Vitest with fast in-memory client↔server tests

  • 🧹 ESLint (type-checked) + Prettier + Husky pre-commit hooks

  • 🐳 Multi-stage Dockerfile for the HTTP transport

  • 🤖 Claude Code toolingCLAUDE.md, skills, and slash commands baked in

Requirements

  • Node.js >= 22.13 (required by pnpm 11)

  • pnpm >= 11 (corepack enable will provide it)

Related MCP server: MCP Server Starter

Quick start

pnpm install
cp .env.example .env

# Local (stdio) development with hot reload
pnpm dev

# Remote (Streamable HTTP) development with hot reload
pnpm dev:http

Then build and run the compiled server:

pnpm build
pnpm start        # stdio
pnpm start:http   # Streamable HTTP on http://127.0.0.1:3000/mcp

Transports

The transport is chosen by the --transport CLI flag (which overrides the MCP_TRANSPORT env var), defaulting to stdio:

  • stdio — the client spawns the server and speaks JSON-RPC over stdin/stdout. Use this for Claude Desktop, IDEs, and other local integrations.

  • Streamable HTTP — an Express server at POST/GET/DELETE /mcp with per-session transports and a GET /healthz liveness endpoint. Use this for remote/hosted deployments.

Connect from Claude Desktop (stdio)

{
  "mcpServers": {
    "mcp-boilerplate": {
      "command": "node",
      "args": ["/absolute/path/to/dist/index.js"],
    },
  },
}

Authentication (HTTP)

The HTTP transport is unauthenticated by default (protected by ALLOWED_HOSTS). To require a bearer token, set AUTH_ENABLED=true and provide AUTH_TOKENS:

AUTH_ENABLED=true AUTH_TOKENS=my-secret-token pnpm start:http
# Requests to /mcp without "Authorization: Bearer my-secret-token" get 401.

The bundled verifier in src/core/auth.ts checks a static token allowlist — replace verifyAccessToken with real JWT verification or OAuth token introspection for production. The validated AuthInfo is available to tool handlers via extra.authInfo.

Configuration

All configuration is environment-based and validated at startup (see .env.example):

Variable

Default

Description

MCP_TRANSPORT

stdio

stdio or http (CLI --transport wins)

HOST

127.0.0.1

HTTP bind address

PORT

3000

HTTP port

ALLOWED_HOSTS

127.0.0.1,localhost

Allowed Host hostnames (port-agnostic). Empty disables protection.

CORS_ORIGINS

(empty)

Comma-separated CORS origins for browser clients. Empty disables CORS.

AUTH_ENABLED

false

Require a bearer token on /mcp (HTTP transport).

AUTH_TOKENS

(empty)

Comma-separated tokens accepted by the example verifier.

AUTH_REQUIRED_SCOPES

(empty)

Comma-separated scopes every token must carry.

AUTH_RESOURCE_METADATA_URL

(empty)

Protected Resource Metadata URL advertised in 401 responses.

LOG_LEVEL

info

fataltrace/silent

NODE_ENV

development

production emits plain JSON logs

Project structure

src/
  index.ts          Entrypoint: transport resolution + graceful shutdown
  server.ts         createServer(): builds McpServer, registers everything
  config/env.ts     Zod-validated environment configuration
  core/             logger (stderr), errors (AppError + toToolError), pkg (name/version)
  transports/       stdio.ts, http.ts (Express + Streamable HTTP)
  tools/            echo.tool.ts + index.ts aggregator
  resources/        system-info.resource.ts + index.ts aggregator
  prompts/          summarize.prompt.ts + index.ts aggregator
tests/              Vitest, in-memory client↔server (helpers/connect.ts)

Adding features

Adding a feature is always: new file + one import line in the folder's index.ts.

# With Claude Code:
/new-tool weather "get the forecast for a city"
/new-resource changelog "expose CHANGELOG.md"
/new-prompt review "ask the model to review a diff"

Or by hand — copy src/tools/echo.tool.ts, define Zod schemas, register it in src/tools/index.ts, and add a test. See CLAUDE.md for the full conventions.

Testing & inspecting

pnpm test            # run once
pnpm test:watch      # watch mode
pnpm test:coverage   # coverage report
pnpm inspector       # launch the MCP Inspector against the server over stdio

Docker (HTTP transport)

docker build -t mcp-boilerplate .
docker run --rm -p 3000:3000 \
  -e ALLOWED_HOSTS=localhost,127.0.0.1 \
  mcp-boilerplate

# or with Docker Compose (includes a healthcheck):
docker compose up --build

Commits & releases

  • Conventional Commits are enforced by a commit-msg hook (commitlint). Use feat:, fix:, chore:, docs:, etc. — e.g. feat(tools): add weather tool.

  • Versioning uses changesets: pnpm changeset to record a change, pnpm changeset:version to bump + update the changelog, pnpm changeset:release to publish.

Claude Code tooling

This repo ships agent tooling under .claude/ and CLAUDE.md:

  • karpathy-guidelines skill — behavioral guardrails (think first, stay simple, surgical changes, verify) vendored from multica-ai/andrej-karpathy-skills.

  • mcp-add-tool / mcp-add-resource / mcp-add-prompt skills — encode this repo's exact patterns so new features stay consistent.

  • /new-tool / /new-resource / /new-prompt slash commands.

  • settings.json — a permission allowlist for the common project commands.

Scripts

Script

Description

pnpm dev / pnpm dev:http

Watch-mode dev (stdio / HTTP)

pnpm build

Transpile src/dist/ with tsup

pnpm start / pnpm start:http

Run the built server

pnpm typecheck

tsc --noEmit

pnpm lint / pnpm lint:fix

ESLint (type-checked)

pnpm format / pnpm format:check

Prettier

pnpm test / pnpm test:watch / pnpm test:coverage

Vitest

pnpm inspector

MCP Inspector over stdio

License

MIT

Available Tools

1 tool
echoEchoA
Read-onlyIdempotent

Echo a message back to the caller, optionally upper-cased.

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesThe text to echo back
uppercaseNoReturn the message in upper case

Output Schema

ParametersJSON Schema
NameRequiredDescription
echoedYesThe (optionally transformed) message
lengthYesCharacter count of the echoed message

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and idempotency. The description adds the optional uppercase behavior, which is extra context beyond the annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 9 words, front-loading the core purpose. Every word adds value; no redundancy. It is an exemplar of conciseness for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the description, combined with the output schema and annotations, provides all necessary information. The agent can reliably invoke the tool without confusion. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions. The description summarizes the effect (echo message, optionally uppercase) but adds minimal new meaning. Baseline of 3 is appropriate given the schema already documents parameters well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action (echo a message) and the main resource (the message). It distinguishes the optional feature (uppercase) and has no sibling tools to differentiate, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly indicates usage: when you need to echo a message. With no sibling tools, explicit alternatives are unnecessary. However, it does not provide explicit when-to-use or when-not-to-use guidelines, but the simplicity and lack of alternatives make this acceptable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.0
    • First observedecho

TDQS

A4.1/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of ambiguity between tools.

Naming Consistency5/5

With a single tool named 'echo', naming is consistent by default; it follows a simple verb pattern.

Tool Count1/5

A single trivial 'echo' tool is an extreme mismatch for a server implied to be a boilerplate; it provides minimal functionality.

Completeness3/5

For the simple task of echoing messages, the tool is sufficient, but the server lacks any additional features that might be expected from a functional MCP server.

Maintenance

ActivityStale
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    A minimal, production-ready TypeScript starter template for building Model Context Protocol (MCP) servers with auto-loading architecture for tools, resources, and prompts. Provides boilerplate code, generators, and examples to quickly create MCP servers that can connect AI applications to any data source or tool.
    -
  • F
    license
    B
    quality
    D
    maintenance
    A minimal TypeScript starter template for building Model Context Protocol (MCP) servers with auto-loading architecture for tools, resources, and prompts. Includes code generators, dual transport support (stdio/HTTP), and production-ready structure.
    3
    -
  • F
    license
    Not graded
    quality
    Not graded
    maintenance
    A minimal, production-ready TypeScript template for building Model Context Protocol servers with auto-loading architecture for tools, resources, and prompts, supporting both stdio and HTTP transports.
    -