Skip to main content
Glama

Firmar JWT (HMAC)

jwt-sign-hmac
Read-onlyIdempotent

Crea un JWT firmado con HS256/384/512 usando un secreto propio; las claims se firman tal cual. Cuándo: hay que leer, construir o revisar con exactitud una URL, una cabecera HTTP, un token, una versión, un rango de IP, un documento HTML o Markdown o un archivo para agentes. No para: comprobar sin conexión un JWT firmado con HMAC (jwt-verify-hmac). Efectos secundarios: ninguno (solo lectura, sin red, sin estado guardado). Determinista: la misma entrada da la misma salida. Límites: entrada JSON de hasta 64 KB, 1 s por llamada, resultado de hasta 1 MB.

EN: Creates a compact JWS/JWT signed with HS256, HS384 or HS512 using a provided secret, e.g. for test fixtures or service-to-service tokens. Claims are signed as given; no defaults are added. When: a URL, HTTP header, token, version string, IP range, HTML or Markdown document or agent-readiness file has to be parsed, built or checked exactly. Not for: checking an HMAC-signed JWT (jwt-verify-hmac). [EN completo / full EN: inputSchema.description]

Input Schema

NameRequiredDescriptionDefault
headerNoExtra header fields (object; optional; default {}).
secretYesHMAC secret (string; required; at least 1 chars; up to 4096 chars).
payloadYesClaims object (object; required).
algorithmNoAlgorithm (optional; one of: HS256, HS384, HS512; default "HS256").HS256

Output Schema

NameRequiredDescriptionDefault
tokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / payload / examples
      Added value: +[
      +  {
      +    "iat": 1516239022,
      +    "name": "John Doe",
      +    "sub": "1234567890"
      +  }
      +]
    • addedInput schema / properties / secret / examples
      Added value: +[
      +  "your-256-bit-secret"
      +]
  2. Changed1 schema field changed
    • addedInput schema / description
      Added value: +"EN: Creates a compact JWS/JWT signed with HS256, HS384 or HS512 using a provided secret, e.g. for test fixtures or service-to-service tokens. Claims are signed as given; no defaults are added. When: a URL, HTTP header, token, version string, IP range, HTML or Markdown document or agent-readiness file has to be parsed, built or checked exactly. Not for: checking an HMAC-signed JWT (jwt-verify-hmac). Side effects: none (read-only, no network access, no stored state). Deterministic: the same input gives the same output. Limits: JSON input up to 64 KB, 1 s per call, result up to 1 MB."
  3. First observed

TDQS

A3.7/5.0
Behavior4/5

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

No contradiction with annotations: 'solo lectura, sin red, sin estado guardado' matches readOnlyHint/openWorldHint=false. Beyond annotations it discloses concrete limits (64 KB input, 1 s per call, 1 MB result), determinism, and the important behavior that claims are signed verbatim with no defaults added.

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

Conciseness3/5

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

Front-loading is good and the limits/exclusion sentences earn their place, but the 'When: URL, HTTP header, version string, IP range, HTML/Markdown' clause is pure waste and directly hurts utility. The full bilingual duplication also roughly doubles length for the same content.

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?

With an output schema present, 100% schema coverage and rich annotations, the description covers purpose, exclusion, determinism, and size/time limits. Only the malformed 'When' clause keeps it from being fully complete, since an agent gets no real cue about the alternative to use for verification versus decoding.

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; the description earns a bump by stating 'las claims se firman tal cual' (no injected iat/exp/alg defaults), which the schema does not say, and by naming HS256/384/512 as the mode of the secret-based signing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening states a concrete verb+resource+algorithms: 'Crea un JWT firmado con HS256/384/512 usando un secreto propio', and the EN version adds the practical purpose (test fixtures, service-to-service tokens). The clarity is slightly diluted by the unrelated 'When: a URL, HTTP header, ... HTML or Markdown document' boilerplate that has nothing to do with signing JWTs.

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

Usage Guidelines3/5

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

The 'Not for: checking an HMAC-signed JWT (jwt-verify-hmac)' exclusion names the sibling and the condition that routes to it, which is genuinely useful. However the positive 'When' clause is generic copy-paste from a parsing-family tool and gives no actual guidance on when to choose signing over jwt-decode or jwt-verify-hmac; it is noise at best and misleading at worst.

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