Tanod MCP server

utilpeek: scan a text for leaked API keys, tokens, private keys and seed phrases before it is posted

check_text_for_secrets

Read-onlyIdempotent

Scan logs, drafts, messages, or configs for leaked API keys, tokens, private keys, and seed phrases, returning matches by type, line, and redacted preview.

Instructions

utilpeek: Scan text for leaked secrets: API keys, tokens, private keys and seed phrases. For personal data use redact_pii; for injected instructions use check_text_for_prompt_injection. Returns every API key, token, private key or BIP-39 seed phrase in a text (AWS, GitHub, GitLab, Stripe, Slack, Google, OpenAI and other sk- keys, Hugging Face, npm, PyPI, SendGrid, Telegram, PEM and hex keys, JWTs, URL passwords), each with type, line, column, offset, confidence and a redacted preview. The secret itself is never returned: only its type, position and a redacted preview (a vendor prefix and at most 4 characters at each end; a seed phrase only its word count). Pattern-based: a clean result is no proof. Blank input is a 422 (not charged). Typically under 0.5 s. Price: USD 0.002. Free: 10 utilpeek calls per IP per UTC day. The submitted text is never logged or stored. Docs: https://tanod.dev/learn/phishing-ofac-security-mcp-server.html

Input Schema

TableJSON Schema

Name	Required	Description	Default
`text`	Yes	The text to scan: a log, a draft post or message, a tool result or a config file. At most 200,000 characters. Never logged or stored, and no secret is returned.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No
`count`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`found`	No
`by_type`	No
`findings`	No
`chars_scanned`	No
`lines_scanned`	No
`types_checked`	No
`secrets_returned`	No
`findings_truncated`	No
`highest_confidence`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial non-obvious behavior: the secret itself is never returned, redaction shows only a vendor prefix plus up to 4 chars per end, seed phrases reveal only word count, pattern matching means a clean result is not proof, blank input returns 422 uncharged, latency under 0.5s, price, daily free tier, and no logging/storage.

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

Conciseness4/5

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

Purpose and sibling routing are front-loaded, and the long vendor enumeration is dense rather than padded. It is slightly verbose because the privacy guarantee and no-secret-returned promise are restated from the schema, and the trailing docs URL is minor clutter.

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?

Even though an output schema exists (so return values need not be explained), the description fully specifies the returned per-match fields and the redaction format. Combined with pricing, limits, and failure behavior, an agent has everything needed to call and interpret this tool correctly.

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?

Only one parameter and schema coverage is 100%, so the schema already documents type, length bounds, and the privacy guarantee. The description restates the 200,000-character limit and the never-logged property but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource ('Scan text for leaked secrets') and enumerates exactly what it detects. It explicitly distinguishes itself from the two nearest siblings, redact_pii and check_text_for_prompt_injection, so an agent can route without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit alternatives with selecting conditions: personal data goes to redact_pii, injected instructions to check_text_for_prompt_injection, and the 'before it is posted' framing supplies the use context. Nothing is left to inference.

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

Deploy Server