Guide · MCP Launch Readiness Audit
MCP server launch readiness checklist
All 48 checks the MCP Launch Readiness Audit runs before an MCP server ships, published in full: what each check looks for, and the fix when it fires. Start with the free mini-scan below: it runs 12 of the 48 checks on a pasted tool list or configuration, in your browser.
Mini-scan: 12 of the 48 checks, in your browser
Paste a tools list (the JSON your server returns for tools/list), a server.json, or your tool definitions. Nothing is uploaded. The scan covers the description and tool-structure checks: TP-001, TP-002, TP-004, TP-005, TP-008, TP-009, TP-012, TP-013, PV-001, PV-005, PV-006, PV-007. The other 36 checks need your source code; the results say so too.
From checklist to audit
The full audit runs all 48 checks against your source code locally, and every finding comes with its evidence and a concrete remediation. Read a sample audit report (PDF) to see the format.
Tool poisoning (14 checks)
TP-001 HIGH Instruction override phrase in tool description (in the mini-scan)
Rewrite the description as a pure capability statement. Move all behavioral instructions into your own agent's system prompt, which you control.
TP-002 HIGH Identity hijack / role reassignment in tool description (in the mini-scan)
Remove role-playing language. A tool description must describe what the tool does, never who the assistant is.
TP-003 HIGH Jailbreak phrase in tool description
Remove jailbreak language immediately. Treat any third-party tool manifest containing these phrases as untrusted input.
TP-004 HIGH Data exfiltration instruction in tool description (in the mini-scan)
Remove any instruction that moves data off the user's machine. Tools should return data to the agent; the agent decides what leaves the session.
TP-005 HIGH Conceal-from-user directive in tool description (in the mini-scan)
Delete secrecy directives. Legitimate tools never instruct the agent to hide behavior from the user.
TP-006 MEDIUM Safety override instruction in tool description
Remove language that weakens the agent's safety behavior. Tool descriptions are untrusted third-party text and must not set policy.
TP-007 MEDIUM Hidden instruction tags in tool description
Strip pseudo-system tags. Agents may parse these as privileged instructions; they do not belong in tool metadata.
TP-008 MEDIUM Invisible / steganographic characters in tool description (in the mini-scan)
Remove zero-width and bidi-override characters. They are a known technique for hiding instructions from human reviewers.
TP-009 MEDIUM Encoded payload (base64/hex blob) in tool description (in the mini-scan)
Decode and inspect any opaque blob before shipping. Encoded content in a description is a smuggling vector.
TP-010 LOW Imperative control language in tool description
Prefer neutral capability language ('Returns X given Y') over commands addressed to the agent ('You must...').
TP-011 MEDIUM Credential-harvesting phrasing in tool description
Tools must never ask the agent to collect secrets. Remove the phrasing or move credential handling into your own controlled auth flow.
TP-012 MEDIUM External URL embedded in tool description (in the mini-scan)
Audit every outbound URL in tool metadata. If the URL is not essential documentation, remove it; never let a tool description direct the agent to an unvetted endpoint.
TP-013 LOW Overlong tool description (instruction-smuggling risk) (in the mini-scan)
Keep descriptions under ~800 characters. Long descriptions are where smuggled instructions hide; split detail into docs.
TP-014 MEDIUM Read-then-exfiltrate pattern in tool description
Break the read-then-send chain: tools should return data to the agent and never combine local reads with network sends in one instruction.
Hardcoded credentials (11 checks)
CR-001 HIGH AWS access key ID in source
Revoke the key, move it to an environment variable or secret manager, and rotate anything it touched.
CR-002 HIGH Probable AWS secret key assignment in source
Revoke and move to a secret manager. Never commit secrets next to the code that uses them.
CR-003 HIGH GitHub token in source
Revoke the token immediately and reissue via environment variables.
CR-004 HIGH OpenAI API key in source
Revoke the key in the provider dashboard and move it to env config.
CR-005 HIGH Anthropic API key in source
Revoke the key in the provider dashboard and move it to env config.
CR-006 HIGH Stripe secret key in source
Roll the key in the Stripe dashboard. Publishable keys are fine in source; secret keys never are.
CR-007 MEDIUM Hardcoded password assignment in source
Move to environment variables or a secret manager. If this shipped, rotate the credential.
CR-008 MEDIUM Private key material in source
Remove the key block from source control history and rotate the keypair. Keys live in a secret manager, not in repos.
CR-009 MEDIUM Database URL with embedded credentials in source
Split credentials out of the connection string into env vars or a secret manager.
CR-010 MEDIUM JWT embedded in source
Tokens are runtime data. Issue them at deploy time and pass via env, never commit them.
CR-011 LOW Hardcoded bearer token in source
Move static tokens to environment configuration.
Server exposure (7 checks)
EX-001 HIGH Server binds all network interfaces (0.0.0.0)
Bind to 127.0.0.1 for local servers. If remote access is needed, put authentication in front and bind behind a reverse proxy.
EX-002 MEDIUM Debug mode enabled in server source
Debug mode leaks stack traces and enables reloader backdoors. Gate it behind an env var that defaults to off in production.
EX-003 MEDIUM CORS allows any origin
Restrict CORS to the exact origins of your clients. Wildcard CORS on an authenticated API lets any site ride the session.
EX-004 MEDIUM Stack traces returned to clients
Log full tracebacks server-side; return a generic error id to clients. Tracebacks leak paths, versions, and internals.
EX-005 HIGH Network transport with no authentication mechanism
Any MCP server reachable over a network must authenticate every caller. Add OAuth 2.1 / bearer-token auth before exposing the transport — see templates/python and templates/typescript.
EX-006 MEDIUM Cloud metadata endpoint referenced (SSRF target)
Block 169.254.169.254 and metadata.google.internal in any URL handling. These endpoints yield cloud IAM credentials.
EX-007 LOW Sensitive route path exposed
Remove or protect /admin, /debug, and /.env routes. They are probed within minutes of exposure.
Over-privileged tools (8 checks)
PV-001 HIGH Dangerously powerful tool name (in the mini-scan)
Rename or remove. Tools named like shell primitives invite the agent to treat your server as a remote shell.
PV-002 HIGH Raw SQL execution tool
Replace with parameterized, allowlisted queries. A raw SQL tool is full database access behind one prompt injection.
PV-003 MEDIUM Filesystem write/delete tool
Scope file tools to an allowlisted directory, require per-call confirmation for deletes, and audit every write.
PV-004 MEDIUM Network fetch tool with no URL allowlist
Add a domain allowlist and block private/metadata IPs, or any prompt injection becomes SSRF.
PV-005 MEDIUM Wildcard tool name (in the mini-scan)
Give every tool an explicit, narrowly-scoped name. Wildcards make audit logs and scopes meaningless.
PV-006 MEDIUM Tool without input schema (in the mini-scan)
Define an inputSchema for every tool. Missing schemas disable client-side validation and hide the tool's true surface.
PV-007 LOW Overly broad input schema (additionalProperties: true) (in the mini-scan)
Enumerate allowed properties explicitly. Open schemas let callers smuggle unexpected fields into your handler.
PV-008 MEDIUM Sensitive path referenced in tool definition
Tools must not reference credential paths. If a tool needs config, pass values via env, not paths to secret files.
SSRF (2 checks)
SS-001 HIGH URL parameter with no SSRF protection
Validate URLs against an allowlist, block private/loopback/link-local ranges and metadata endpoints, and disable redirect-following or revalidate after each hop.
SS-002 MEDIUM Redirect-following fetch without revalidation
Revalidate the final URL after every redirect against the same allowlist; attackers launder SSRF through open redirects.
Authentication and hardening (6 checks)
AU-001 HIGH No authentication mechanism found
Add caller authentication (OAuth 2.1 bearer tokens in the templates). MCP servers ship without auth by design — yours must not.
AU-002 MEDIUM No per-tool authorization scopes
Issue tokens with per-tool scopes and enforce them on every call, so a compromised token cannot reach every tool.
AU-003 MEDIUM No rate limiting
Add per-tenant rate limits (see templates). Unbounded tools are a cost and abuse vector once agents call them in loops.
AU-004 LOW No audit logging
Log every tool call with timestamp, tenant, tool, and outcome. Without an audit trail you cannot reconstruct an incident.
AU-005 MEDIUM No input validation
Validate and sanitize every argument server-side (types, lengths, formats). Client-side schemas are advisory only.
AU-006 LOW No tenant isolation
If you serve multiple users, isolate state per tenant and enforce it on every call — never trust a tenant id from the client alone.
Questions
Is the mini-scan the full audit?
No, and it says so on the results. The mini-scan runs 12 of the 48 checks, the ones that can be evaluated honestly from a pasted tool list or configuration in a browser. The other 36 checks, including every credential, exposure, SSRF, and authentication rule, need your source code, which is what the audit scans locally.
Does the mini-scan upload my configuration?
No. It runs entirely in this page, in your browser. That is also the audit's model: the scanner is a local CLI and your code never leaves your machine.
Why publish all 48 checks?
The checks are the standard, and a standard you cannot read is hard to trust. What the audit sells is the automation: running all 48 against a real codebase, the evidence for each finding, a remediation for every one, hardened templates, and a regression suite so the findings stay fixed.