Skip to main content
Glama

diff

Compare hex payloads byte by byte to identify shared bytes, varying positions, length distribution, and possible block-cipher output during protocol analysis.

Instructions

compare hex payloads byte by byte.

returns how many payloads have each length, the byte at every position that is the same in all of them (over the shortest), the positions that vary, and whether the set looks like block-cipher output.

Input Schema

NameRequiredDescriptionDefault
payloads_hexYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully describes the analytical outputs and the block-cipher heuristic, but it does not explicitly state that the tool is read-only/side-effect-free or explain error handling for malformed hex inputs.

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?

The purpose is front-loaded in the first sentence, and the return details are compact. The second sentence is long but adds useful analytical context rather than filler.

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

Completeness3/5

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

The tool is relatively simple with one parameter and an output schema, and the description explains the analysis and outputs. However, it omits input constraints, minimum payload requirements, and malformed-input behavior, leaving gaps for correct invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should compensate. It only implies that the inputs are hex payloads and that lengths may vary ('over the shortest'), but it does not describe the array shape, minimum payload count, required format per item, or validation expectations.

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 description gives a specific verb and resource: 'compare hex payloads byte by byte.' It does not explicitly differentiate from any sibling tool, but none of the listed siblings appears to be a direct alternative.

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?

Usage is implied by the phrase 'compare hex payloads byte by byte,' but the description does not state when to use this tool versus alternatives, nor when not to use it. It provides no exclusions or routing guidance.

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