Skip to main content
Glama
Sign In

Presend MCP Server

by io.github.presendapp
OverviewDiscussionsAdmin

JWT signature verification

jwt_verify
Read-onlyIdempotent

Cryptographically verifies a JWT signature (HS256/384/512, RS/PS256/384/512, ES256/384/512) and checks exp/nbf claims. Provide a secret for HS*, or a JWK or JWKS URL for RS/PS/ES. Use instead of jwt_decode whenever authenticity matters.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "token": "<token>"
    },
    "name": "jwt_verify"
  }
}

Input Schema

NameRequiredDescriptionDefault
jwkNoPublic key in JWK format, for RS/PS/ES algorithms.
tokenYesThe JWT to verify. Checks the cryptographic signature -- use /jwt-decode if you only need to read the header and payload.
secretNoRequired for HS256/384/512.
jwks_urlNoURL to a JWKS document; the key is matched by the token's "kid" header.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / token / description
      Previous value: -""New value: +"The JWT to verify. Checks the cryptographic signature -- use /jwt-decode if you only need to read the header and payload."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered; the description adds genuinely new behavior by disclosing that exp/nbf claims are validated in addition to the signature, and that key material selection depends on the algorithm family. It stops short of saying what a failure looks like (expired vs bad signature vs unknown kid), which is the one remaining gap for a verification tool with no output schema.

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

Conciseness5/5

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

Two dense sentences: capability and algorithm coverage first, credential requirements second, sibling routing last. No filler, and the most decision-relevant information is front-loaded.

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?

For a four-parameter, nested-object tool with no output schema, the description covers algorithms, credentials, claim checks and sibling routing, which is nearly everything needed to invoke it correctly. The missing piece is the shape of the result (valid/invalid plus failure reason), which is not derivable from any structured field.

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 description coverage is 100%, so baseline is 3, but the description adds the conditional selection logic across the four parameters ('secret for HS*, JWK or JWKS URL for RS/PS/ES'), grouping jwk and jwks_url as alternatives that the schema documents separately. That is real added meaning beyond the per-field text.

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 (cryptographically verifies), resource (JWT signature), the exact algorithm families supported (HS/RS/PS/ES 256/384/512), and the additional exp/nbf claim check. It explicitly names the sibling jwt_decode as the thing it is not, so an agent can separate the two without opening either 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 an explicit routing rule: 'Use instead of jwt_decode whenever authenticity matters,' which names the alternative and the condition that selects it. It also states the credential-selection rule (secret for HS*, JWK or JWKS URL for RS/PS/ES), removing the main ambiguity in how to invoke it.

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

All Presend MCP Server toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources