Tanod MCP server

utilpeek: encode or decode text (base64, hex, URL, ..., JWT decode)

text_encode

Read-onlyIdempotent

Encode or decode text into base64, hex, URL, punycode, or other formats; decode JWTs to inspect headers and payloads without verifying signatures.

Instructions

utilpeek: Encode or decode text: base64, hex, URL, punycode, JWT decode, ... For digests use hash_text; for a JWT's claims use decode_jwt. Returns the text encoded or decoded with codec: base64, base64url, base32, hex, url (percent), html (entities), quoted_printable, rot13, punycode, idna or jwt. Decoders are strict (bad input is a 422 decode_failed); bytes that are not UTF-8 come back as output_base64. jwt is decode only: the header and payload are decoded and the signature is NEVER verified (every reply says signature_verified: false), so a decoded token proves nothing about who issued it; the token is never echoed back. Typically under 0.3 s. Price: USD 0.001. Free: 10 utilpeek calls per IP per UTC day. The submitted text is never logged or stored.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`text`	Yes	At most 100,000 characters; never logged; a JWT is never echoed back.
`codec`	Yes	base64, base64url, base32, hex, url, html, quoted_printable, rot13, punycode, idna or jwt (decode only; the signature is never verified).
`direction`	No	encode (default) or decode; jwt is decode only.	encode

Output Schema

TableJSON Schema

Name	Required	Description
`bytes`	No
`codec`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`flags`	No
`binary`	No
`header`	No
`output`	No
`source`	No
`payload`	No
`warning`	No
`direction`	No
`output_base64`	No
`signature_verified`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds real operational detail the annotations cannot: strict decoders returning 422 decode_failed, non-UTF-8 output surfacing as output_base64, jwt signatures never verified (signature_verified: false), tokens never echoed, typical latency, price, free-tier quota, and no logging/storage. The JWT non-verification warning is genuinely high-value behavior disclosure.

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?

Information is front-loaded (purpose, alternative routing, codecs, then behavior), and each sentence is substantive. It is dense and verges on over-stuffed with pricing/quota/latency details, but those still aid tool selection and none are filler repeats.

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?

An output schema exists, so return-value shape need not be documented, yet the description still clarifies the ambiguous return cases (output_base64 for non-UTF-8, signature_verified: false). Combined with strict-decoder error behavior and privacy guarantees, an agent has everything needed to call this 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?

Schema description coverage is 100%, so the schema already documents text, codec, and direction, including 'jwt is decode only'. The description largely restates the codec list and the decode-only jwt rule rather than adding syntax, format, or edge-case guidance beyond the schema. Baseline 3 is appropriate.

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?

The description gives a precise verb pair (encode/decode), the resource (text), and the full codec set, then explicitly separates itself from hash_text and decode_jwt. An agent can distinguish it from siblings like convert_data or decode_jwt 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?

It names the alternatives directly ('For digests use hash_text; for a JWT's claims use decode_jwt'), which is the exact routing decision an agent faces among these text-utility siblings. The decode-only constraint on the jwt codec is stated as a usage rule, not 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