Repository navigation
Show and tell: Enterprise TypeScript MCP Boilerplate — Dual-stream Stdio Logging & SSRF-hardened Tools #3537
A7mdMe
started this conversation in
Show and tell
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Disclosure: I am the maintainer of this open-source template. Posting in Show and tell to share production architectural patterns we developed for reliable MCP servers.
When building Model Context Protocol (MCP) servers in TypeScript for clients like Claude Desktop, Cursor, or Cline, developers frequently encounter three production hurdles that aren't addressed by basic "Hello World" examples:
1. The Stdio Framing Trap (Accidental
console.logcorruption)In the MCP stdio transport,
stdoutis strictly reserved for JSON-RPC message frames. A single rogueconsole.log()from a third-party library or debug statement corrupts the byte stream, causing clients to throwSyntaxError: Unexpected tokenand disconnect immediately.The Solution:
Route all diagnostic telemetry and logs strictly to
stderror rotating local file sinks, while leavingstdoutexclusively to the MCP transport protocol:2. Tool Hardening: SSRF Prevention & Read-Only SQL Sanitization
Giving an LLM agent tools to fetch URLs or query relational databases creates real security surfaces:
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,127.0.0.1,169.254.169.254).INSERT,UPDATE,DROP,ALTER).3. Production Docker Packaging for Claude Desktop
For reproducible containerized execution with Claude Desktop, the image should run unprivileged with minimal attack surface:
Claude Desktop configuration:
{ "mcpServers": { "production-kit": { "command": "docker", "args": ["run", "-i", "--rm", "mcp-production-kit:latest"] } } }Resources & Live Implementation
Would love feedback on how other teams are isolating stdio streams and handling SSRF validation in their MCP servers!
All reactions