Show and tell: Hardening Custom TypeScript MCP Tools Alongside Chrome DevTools MCP — Stdio Isolation & Read-Only SQL Guardrails

[A7mdMe]

Context: Multi-Server MCP Stacks in Coding Agent Workflows

In modern AI-assisted engineering workflows (with Claude Code, Cursor, or Codex), developers frequently pair the official Chrome DevTools MCP Server with custom TypeScript backend servers and database tools in their workspace mcpServers configuration.

When running multiple MCP servers concurrently over standard I/O (stdio), two subtle stability risks emerge:

1. Stdio Stream Corruption Breaking JSON-RPC Framing:
   Desktop and CLI agents communicate with MCP servers using process.stdout strictly reserved for JSON-RPC 2.0 frames. If custom TypeScript tools or third-party dependencies log internal diagnostics via console.log(), stdout is corrupted, causing host parsers to drop the session or fail tool discovery across all active servers.

2. Accidental Mutations During Automated Agent Debugging:
   When coding agents inspect frontend DOM states via Chrome DevTools and cross-reference records against local or staging databases, prompt loops or unexpected LLM responses can attempt mutating queries (DROP TABLE, ALTER, multi-statement injections).

---

Production Hardening Patterns

The open-source MCP Production Kit demonstrates two architectural patterns designed to maintain rock-solid stability in multi-server development environments:

1. Dual-Stream Stdio Logging

Redirects all diagnostic, audit, and operational logging strictly to process.stderr, keeping process.stdout dedicated exclusively to JSON-RPC 2.0 protocol communication:

export class StdioTransportLogger {
  static info(message: string, meta?: Record<string, unknown>): void {
    process.stderr.write(JSON.stringify({ level: 'info', message, ...meta }) + '\n');
  }

  static error(message: string, error?: unknown): void {
    process.stderr.write(JSON.stringify({ level: 'error', message, err: String(error) }) + '\n');
  }
}

2. Application-Level Token & Regex SQL Inspection

Before an agent-generated SQL query reaches a persistent database pool, a token-based guardrail inspects the input:

• Comment Stripping: Removes -- and /* */ SQL comments commonly used to mask injection payloads.
• String Literal Masking: Replaces quoted strings so legitimate domain values (e.g. status = 'DROP_PENDING') don't trigger false alarms.
• Stacked Query Rejection: Semicolon splitting prevents executing multiple statements in a single call.
• Mutation Blacklist: Enforces starting with SELECT or WITH, and validates against 16 mutation keywords (DROP, DELETE, TRUNCATE, ALTER, UPDATE, INSERT, CREATE, REPLACE, etc.).

import { validateReadOnlyQuery } from './postgres_connector.ts';

// Intercepting an agent hallucination attempting a stacked statement
const query = "SELECT id, title FROM users; DROP TABLE sessions;--";
const result = validateReadOnlyQuery(query);

if (!result.safe) {
  // Returns actionable error to the host agent loop instead of corrupting database:
  console.error("Blocked:", result.reason);
  // => "Multiple SQL statements detected. Only a single query may be executed per request."
}

(Note: This application-level guardrail uses token & regex sanitization, not a full SQL AST compiler, and is engineered to work in tandem with database-level read-only permissions like GRANT SELECT).

---

Architecture Comparison: Open-Source Core vs. Pro Pack ($19 USD)

Component	Open-Source Core	Pro Pack ($19 Add-on)	DIY Custom Build
Dual-Stream Stdio Isolation	Built-in	Built-in	Prone to stdout corruption
SSRF-Guarded HTTP Fetch	Built-in (blocks private CIDRs)	Built-in	Exposes internal IPs / IMDS
Read-Only PostgreSQL Tool	Manual implementation	Pre-tested standalone module	Requires ~4-5 hrs engineering
Cloudflare Workers (SSE)	Manual setup	Pre-configured edge template	Requires ~4-6 hrs debugging
Non-Root Dockerfile	Standard	Multi-stage with USER node	Usually runs as root
Access	GitHub Repo	Whop Files App	Manual setup (~10-15 hrs)

---

Maintainer Disclosure & Community Discussion

Disclosure: I am the maintainer of MCP Production Kit and author of the commercial Pro Pack add-on on Whop.

We'd love feedback from the Chrome DevTools MCP community:

1. When configuring multi-server MCP setups for coding agents, what logging conventions have worked best to avoid stdio collisions?
2. Do you isolate database and backend mock tools in local containers or run them directly via Node.js?
3. How do you guard database states when autonomous coding agents execute end-to-end web testing?

[antropos17]

For the stdio question, I'd test the actual launch entry point, not only the logger class: capture stdout and stderr separately during startup, tool discovery, a tool error, and shutdown. Include a dependency that emits a harmless diagnostic during import. Validate stdout as newline-delimited MCP messages; the transport contract permits ordinary diagnostics on stderr.

I'd also keep a healthy second server running during that fixture. If noise from one process disrupts both sessions, inspect the wrapper/client's stream routing rather than treating multiple MCP servers as inherently sharing stdout. Record the exact launcher, package revision and selected config bytes for each result, using dummy environment values.

I maintain AEGIS at Escape Studio. Its offline review and saved inventory comparison of selected project MCP configuration files and optional tools/list exports can help track changes to those inputs. That is separate from testing runtime framing. It is an MIT Windows-first beta.

Local security UI: 27 October 2026 source UI with simulated data; no live blocking test.

[A7mdMe]

Thank you @antropos17 for this practical and rigorous recommendation!

Testing the actual process launch entry point rather than solely testing the logger class in unit tests is critical because third-party dependencies and runtime wrappers can easily introduce accidental console.log statements that pollute stdout.

Based on your feedback, we implemented an end-to-end integration test harness in tests/stdio_boundary.test.ts (committed in d4178d7):

1. Independent Stream Interception: Spawns the compiled server entry point as a real child process with piped stdio, capturing stdout and stderr independently.
2. Lifecycle Handshake: Dispatches initialize, notifications/initialized, and tools/list over stdin.
3. Error Trigger Verification: Dispatches an intentional tool-level security block to ensure that both successful tool results and security rejections are returned as valid JSON-RPC frames on stdout, while diagnostic traces remain on stderr.
4. Strict Protocol Invariant: Asserts that exactly 0 non-JSON or unescaped log characters ever leak onto stdout.

Also, thank you for sharing AEGIS — having static offline review and inventory comparison of mcpServers configurations is a great complement to runtime stream boundary verification!

[antropos17]

Thanks for following up and adding the real-process fixture. Keeping the handshake and the tool rejection in that test makes the stream boundary much easier to inspect than testing the logger alone. I have not run your fixture, so I cannot claim a validation result for it.

The distinction you made is the useful one for AEGIS too: reviewing selected configuration bytes is separate from proving that a launched server keeps stdout protocol-only. I appreciate you preserving that scope in the summary.

[rhkiswani]

On question 1, one convention that has held up for us in Mars (the browser we are building in Rust, with its own MCP surface): the rule is not "log to stderr", it is "stdout is the protocol and nothing else", and the thing that keeps it true is a test, not the logger. Our CLI tests run the binary, assert stderr is empty on the happy path and parse stdout as JSON; on the error path they assert stdout is empty and parse the one line on stderr as the structured error. A dependency that prints a diagnostic during import fails that test the day it is added, which is the moment you want to find out, not when a host drops the session. antropos17's point about testing the launch entry point rather than the logger class is the same point from the other side.

The other half for us was that mars mcp is only a stdio bridge. It copies stdin and stdout to a unix socket the running browser listens on, so the process a host spawns has nothing to log in the first place; the browser's own diagnostics go to the browser's stderr, a different process. Fewer things on the bridge, fewer things that can write to the wrong stream.

On question 3, we went the other way from a text filter. Reads (summary, find, diff, screenshot, network) need no grant at all. Anything that changes a page takes a control grant from the person, and the call carries the grant epoch, so a revoked grant fails the step in flight with a code and the rest of the batch never runs. The guard lives in the process that owns the resource and checks a fact it holds, not the shape of the request. Your regex layer is doing the right job for SQL, where the request text is all you have; I would just not let it be the only layer, as you say yourself with GRANT SELECT. The database-side grant is the one that holds when the regex misses a dialect-specific mutation.

[antropos17]

Agreed on putting the grant check in the process that owns the resource. A request carrying an old epoch should be tested both while queued and just before dispatch; those are different boundaries from a new request arriving after revocation. For a call whose effect already completed, I would retain an explicit completed/unknown outcome rather than implying that revocation rolled it back.

That is also why I keep AEGIS's selected configured routes separate from a general containment claim. Your bridge design sounds relevant to that separation, but I have not tested Mars or its revocation behavior.

[A7mdMe]

@rhkiswani Thank you for sharing these insights from Mars — this is one of the most practical real-world architectural perspectives on MCP transports I've seen.

1. "stdout is the protocol and nothing else"

Your phrasing captures the principle perfectly: the guarantee cannot be a convention or a logger abstraction; it has to be enforced by a process-level integration test.

Following @antropos17's advice earlier in this thread, we implemented an end-to-end integration test harness (tests/stdio_boundary.test.ts) that spawns the compiled server entrypoint as a child process. It sends JSON-RPC frames over stdin, validates that every single line on stdout is valid JSON-RPC 2.0 (during handshake, tools/list, and tool error triggers), and strictly asserts 0 non-JSON characters pollute stdout. That test catches rogue console.log emissions from imported libraries immediately in CI before a host client ever drops the connection.

2. The Bridge Pattern (Decoupling Transport from Business Logic)

Your approach in Mars of keeping mars mcp as a minimal stdio-to-socket bridge is brilliant. In Node/TypeScript, servers often bundle heavy SDKs or database drivers in the same process, which increases the likelihood of an unhandled diagnostic leaking to stdout. Moving towards a thin stdio proxy that forwards to an isolated worker process or socket keeps the transport surface completely clean.

3. State-Held Grants vs. Request Shape Inspection

Your point on capability epochs is spot on: for application-owned resources, the guard should live where the state lives, checking an authoritative grant rather than parsing request text.

For SQL databases, where the tool interface gives an LLM expressive query power over an entire schema, application-level text inspection is only an operational tripwire (e.g. blocking multi-statement semicolon attacks or catching accidental mutation keywords before spending a database connection). As you noted, the real authority must remain the database engine itself: combining least-privilege roles (GRANT SELECT) with runtime read-only transaction enforcement (BEGIN TRANSACTION READ ONLY / default_transaction_read_only = on) ensures dialect-specific side-effects or UDF mutations fail deterministically at the storage layer.

Really appreciate you sharing how Mars handles this in Rust!