Loading ToolBench
Decode and inspect JWT tokens without verification. Extracts header, payload, claims, expiry, and signature algorithm.
Single tool 'security_decode_jwt' has a well-structured description (340 chars, within 10-1024 range) with clear WHAT/WHEN/WHY guidance. Input schema is present with proper type and description. However, output schema is NOT formally documented in the tool definition, only described in prose within the description text. The description includes helpful anti-patterns (what NOT to use it for), which is good practice. Parameter naming is clear ('token'). No error handling guidance or recovery paths documented. Tool is READ_ONLY (safe), but lacks structured output schema definition that LLMs need for downstream chaining.
Use this when you need to decode and inspect a JWT token without verifying its signature. Returns the full header, payload, and expiration status. 1. header -- algorithm (RS256, HS256, etc.) and token type 2. payload -- all claims (sub, iss, aud, iat, exp, custom claims) 3. issuedAt -- human-readable issued date 4. expiresAt -- human-readable expiry date 5. isExpired -- boolean indicating if the token has expired Example output: {"header":{"alg":"RS256","typ":"JWT"},"payload":{"sub":"user123","exp":1720000000},"issuedAt":"2025-01-01T00:00:00Z","expiresAt":"2025-07-03T00:00:00Z","isExpired":false} Use this FOR debugging authentication issues, inspecting token claims before API calls, or verifying token expiry. Use this BEFORE making authenticated requests to check if a token needs refreshing. Do NOT use for hashing data -- use crypto_generate_hash instead. Do NOT use for base64 encoding/decoding -- use utility_encode_base64 instead. Do NOT use for password analysis -- use security_check_password instead.
Output schema not formally documented. Description includes example output JSON, but tool definition lacks explicit 'outputSchema' or return type specification. LLMs cannot reliably extract fields for downstream tool calls.
No error handling guidance. Tool description does not explain what happens on invalid JWT, malformed tokens, or decode failures. LLM has no recovery path if token is invalid.
Parameter 'token' lacks format constraint. Description says 'format: header.payload.signature' but this is not enforced in schema (no pattern, minLength, or enum). LLM may pass malformed tokens without validation.
Single tool server limits composability. JWT decoding is a narrow capability. No complementary tools for verification, encoding, or token refresh. Agents cannot build multi-step auth workflows.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2025-06-18+ | v2 |