Burs-IA Utils

HMAC-SHA256

hmac-sha256

Read-onlyIdempotent

Calcula el HMAC (RFC 2104) con SHA256. Cuándo: hay que firmar un mensaje, o comprobar una firma, con un secreto compartido que viene en la llamada. No para: comprobar una firma HMAC en tiempo constante (hmac-verify). 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: Computes the HMAC (RFC 2104) using SHA256 over text, hex or base64 data with a text, hex or base64 key. When: a message has to be signed, or a signature checked, with a shared secret supplied in the call. Not for: checking an HMAC signature in constant time (hmac-verify). 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.

Input Schema

Name	Required	Description	Default
`key`	Yes	Secret key (string; required; up to 4096 chars).
`data`	Yes	Input data (string; required).
`key_encoding`	No	Encoding of `key` (optional; one of: utf8, hex, base64; default "utf8").	utf8
`input_encoding`	No	How `data` is encoded (optional; one of: utf8, hex, base64; default "utf8").	utf8
`output_encoding`	No	Output encoding of the digest (optional; one of: hex, base64, base64url; default "hex").	hex

Output Schema

Name	Required	Description	Default
`mac`	No
`encoding`	No
`algorithm`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026
- addedInput schema / properties / data / examples
```
Added value: +[
+  "The quick brown fox jumps over the lazy dog"
+]
```
- addedInput schema / properties / key / examples
```
Added value: +[
+  "key"
+]
```
First observedNov 1, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description still adds genuinely new facts beyond the annotations: determinism, no network, no stored state, and hard limits (64 KB JSON input, 1 s per call, 1 MB result) that matter for batching decisions. It does not describe error behavior on oversized input, so not 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?

Each language block is front-loaded and tight: purpose, when, not-for, side effects, determinism, limits. The cost is that the entire paragraph is duplicated in Spanish and English, roughly doubling token count for the same information, which is a real (if deliberate) redundancy penalty.

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 explanation is not needed. Combined with annotations and a 100%-covered input schema, the description adds everything an agent needs before calling: scope, exclusions, determinism and size/time limits.

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% and all five parameters are documented with types, enums and defaults, so the schema carries the semantics. The description echoes the encoding flexibility (text/hex/base64 for both data and key) but adds no format rules or interaction notes beyond what the schema already states — baseline 3.

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+algorithm+resource: computes HMAC (RFC 2104) with SHA256 over data using a shared key, and names the accepted encodings. It explicitly contrasts itself with the nearest sibling (hmac-verify) so an agent can distinguish them without opening schemas.

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?

Has explicit 'When:' (signing a message or checking a signature with a secret supplied in the call) and explicit 'Not for:' routing to hmac-verify for constant-time verification. This is the when/when-not/alternative pattern at full strength.

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

All Burs-IA Utils tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?