Skip to main content
Glama

JWT Decoder

dev_jwt_decoder

Decode a JSON Web Token's header and payload to readable JSON. Pure decoding: signatures are NOT verified and no secret is needed. Accepts standard and URL-safe base64 with or without padding; claims like exp and iat are rendered as dates. Use this when an agent needs to decode header and payload — no verification. x402 price $0.01/call (USDC, eip155:8453).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenYesheader.payload.signature

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that signatures are NOT verified, no secret is required, both standard and URL-safe base64 (with or without padding) are accepted, and exp/iat are rendered as dates. It also notes the x402 payment requirement. It omits error behavior (e.g., what happens on a malformed token), which keeps it just short of a 5.

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?

It is compact and front-loads the core purpose, with the most decision-relevant fact (no verification) stated early and the payment note at the end. The 'no verification' idea is repeated in the usage sentence, a minor redundancy that keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must describe returns, and it does: header and payload as readable JSON with date-rendered claims. Combined with the encoding and payment notes, an agent has nearly everything needed; only malformed-input behavior is unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning by specifying the accepted encodings (standard/URL-safe, padded or unpadded) and the token shape. These are format semantics the bare schema string does not convey.

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 (Decode) and resource (a JWT's header and payload) plus the exact output form (readable JSON). It also delineates itself from the adjacent 'verify' capability, so an agent knows precisely what this tool is and is not. No sibling performs JWT decoding, so there is no ambiguity to resolve.

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

Usage Guidelines4/5

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

Explicitly says 'Use this when an agent needs to decode header and payload — no verification,' which gives a clear trigger condition. It lacks an explicit when-not-to-use or a named alternative, but within this catalog no alternative exists, so the guidance is effectively complete.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources