Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-starter-kit fetch JSON from https://api.example.com/data"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A production-shaped starter for building a Model Context Protocol server in TypeScript.
Most MCP tutorials stop at "hello world" over stdio. The hard parts — the ones that actually break servers in the wild — start right after: authentication, transport choice, request timeouts, SSRF guards, and a deploy that survives cold starts. This kit ships those, small enough to read in one sitting.
The MCP protocol is the easy part. Everything around it is where servers die. This kit is that "everything around it," kept minimal and honest.
stdio + streamable HTTP, switched by one env var.
Bearer auth that fails closed — no token configured means every HTTP request is rejected, with a real 401 + WWW-Authenticate, constant-time comparison, and the token never logged.
Legible errors — a typed ToolError becomes a proper MCP error result (isError: true), so an agent sees [forbidden_host] ... instead of a silent hang or an opaque internal error.
A real example tool (http_get_json) with the guards every fetch tool needs and most omit: input validation, https-only, an SSRF host allowlist, and a hard timeout.
Stateless HTTP by design — the shape that survives serverless cold starts (see DEPLOYMENT.md).
Tests + typecheck out of the box (a drop-in GitHub Actions CI is in DEPLOYMENT.md).
git clone https://github.com/park11innyc-lgtm/mcp-server-starter-kit
cd mcp-server-starter-kit
npm install
cp .env.example .env
npm run dev # starts on stdio; logs "ready on stdio" to stderrPoint Claude Desktop / Cursor at it — claude_desktop_config.json:
{
"mcpServers": {
"starter-kit": {
"command": "npx",
"args": ["tsx", "/absolute/path/to/mcp-server-starter-kit/src/index.ts"]
}
}
}Restart the client and you'll have two tools: ping and http_get_json.
Related MCP server: MCP TypeScript Starter
# generate a token
node -e "console.log(require('crypto').randomBytes(24).toString('base64url'))"
# put it in .env -> MCP_BEARER_TOKENS=<that token>
npm run serve:http # POST http://localhost:3000/mcp (GET /healthz is open)Every request to /mcp now needs Authorization: Bearer <token>. With no token set, the server refuses everything — that "fail closed" default is the point.
Tool | What it shows |
| The minimum viable tool: zero input, structured JSON out. Use it as your liveness check. |
| The patterns a real outbound tool needs — zod input validation, an https-only rule, an SSRF allowlist ( |
Add your own in src/tools.ts and register it in src/server.ts. The try/catch → toToolResult wrapper there is what keeps your failures legible; keep using it.
Auth that fails closed → src/auth.ts. Bearer tokens are the correct first step; full delegated OAuth 2.1 is a deliberate non-goal of a starter — DEPLOYMENT.md points at where to add it.
stdout is sacred on stdio → src/index.ts. One stray console.log corrupts the JSON-RPC stream. Log to stderr only.
Cold starts → src/http.ts is stateless on purpose. DEPLOYMENT.md explains why and when to add sessions.
SSRF → an MCP tool that fetches URLs is an open proxy into your network unless you allowlist hosts. http_get_json does.
src/
index.ts entry — picks stdio vs http
server.ts builds the McpServer, registers tools, wraps handlers
tools.ts the example tools (add yours here)
auth.ts bearer auth for the HTTP transport (fail closed)
http.ts stateless streamable-HTTP server
errors.ts ToolError + toToolResult
test/
tools.test.tsnpm run dev # stdio, hot
npm run serve:http # http transport
npm run build # tsc -> dist/
npm start # run built server
npm test # vitest
npm run typecheck # tsc --noEmitMIT — do whatever you want with it. Attribution appreciated, not required.
Built as an honest reference, not a paywall. A production companion focused on ops automation (retry/dedup, cost caps, runbooks) is in the works — a link will land here when it ships.
GET an allowlisted https:// URL and return the JSON body. Enforces an https-only rule, an SSRF host allowlist, and a request timeout.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute https:// URL to GET. Host must be in ALLOWED_FETCH_HOSTS. | |
| timeout_ms | No | Abort the request after this many milliseconds. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the https-only rule, SSRF host allowlist, and request timeout, giving the agent important constraints. It does not describe error handling or response format beyond JSON, but the core safety behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the tool's purpose and key constraints without extraneous words. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter GET tool, the description covers the essential purpose, input constraints, and timeout, and it notes the return type (JSON body). It doesn't specify error handling or non-JSON responses, but given the lack of output schema and complexity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with descriptions (100% coverage), so the baseline is 3. The description adds some context about the URL being allowlisted and the timeout, but largely restates what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action 'GET an allowlisted https:// URL' and the result 'return the JSON body.' It clearly distinguishes from the only sibling 'ping' by focusing on fetching JSON content rather than connectivity checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when the tool is applicable: it works only on allowlisted https URLs and enforces a timeout. However, it does not explicitly contrast with 'ping' or list exclusions, so it lacks explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liveness check. Returns server name, version, and current time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the behavioral outcome ('Returns server name, version, and current time') and implies a read-only operation through 'Liveness check', which is transparent for a simple ping tool. It does not explicitly state lack of side effects, but that is inherent to the liveness check concept.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences with no unnecessary words. It front-loads the core purpose ('Liveness check') and then provides the key return details. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero params, no output schema), the description covers what is needed: it names the action and describes the exact response content. There is no ambiguity about what the tool does or returns, making it complete for its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to explain any. With no parameters, the baseline for this dimension is 4. The description appropriately focuses on the return value rather than params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Liveness check' and specifies exactly what it returns ('server name, version, and current time'). This distinguishes it from the sibling tool 'http_get_json', which is a generic HTTP GET, by indicating a specific health-check purpose with a defined response payload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Liveness check' implies usage for verifying server health or connectivity, but there is no explicit when/when-not guidance or mention of alternatives like 'http_get_json'. The context is implied rather than stated, so it falls short of a clear usage directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0http_get_jsonpingThe two tools are completely distinct: 'ping' provides a liveness check, while 'http_get_json' performs an HTTP request. No overlap or ambiguity exists between them.
The tool names are both lowercase but follow different patterns: 'ping' is a single verb, while 'http_get_json' uses a verb_noun structure with a prefix. The lack of a consistent pattern makes the set feel ad hoc.
With only two tools, the set is thin and borderline. For a starter kit, it is minimal but not entirely unreasonable, yet it still feels sparse for most practical purposes.
The server provides only a basic health check and a JSON GET utility. There are no other operations, and the domain is undefined, so it covers a minimal demo but lacks any meaningful workflow or lifecycle.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
A TypeScript MCP server for Home Assistant, enabling programmatic management of entities, automati…
An MCP server for Arcjet - the runtime security platform that ships with your AI code.
MCP server for interacting with the Supabase platform
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/operatorsheets/mcp-server-starter-kit'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
