Delta Signal

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and network access are covered; the description adds real value by disclosing that SSTV output is PNG and that the watermark layer depends on the original seed. However, with no output schema, it never says how the non-image layers are returned or what the default 'all layers' behavior does when `layers` is omitted.

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

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

A single front-loaded sentence led by the verb and resource, with the layer inventory and the two critical caveats in compact parentheticals. Every clause carries information; nothing is padded.

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

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

For a no-output-schema, open-world decoding tool with one undocumented schema parameter, the description covers inputs and layer meaning but leaves the return shape (non-image layers) and the cost/latency of decoding every layer unstated. An agent can call it, but cannot predict the response structure.

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

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

Schema coverage is only 33% – `seed` has no description and `layers` items carry no per-value docs – and the description compensates by explaining that seed is 'the seed used to render' for the watermark and by mapping each layer name to its meaning (spectral glyph, prime count, modem text). It still does not state what happens when `layers` is omitted versus passed.

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

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

Specific verb (Decode) plus the exact resource (Delta Signal layers from a WAV/MP3/M4A file) and an enumeration of the layers produced: heartbeat, glyph, primes, watermark, ggwave, modem, SSTV. An agent can immediately separate this from the sibling tools (describe_engine, preview_card, render_signature, verify_signature), which are all signature/card oriented.

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

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

States the input precondition clearly (https URL, WAV/MP3/M4A only, 'convert other formats first') and notes the watermark layer requires the render seed, which tells the agent when this tool is callable and when a prerequisite is missing. It stops short of naming an alternative tool or an explicit 'do not use this for X' case.

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

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds the cost trait ('Free') and the content domains the call returns (layers, stings, defaults, limits, prices), which is context beyond the annotation. It does not describe output format or freshness, 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.

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

Two short sentences, front-loaded with the cost signal, then the scope. Every clause earns its place and nothing is redundant with the schema.

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

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

For a zero-parameter read tool with no output schema, the description should say what comes back, and it lists the content domains. Adequate; only the return shape/nesting is unspecified.

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

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

The tool takes zero parameters and the schema has full coverage, so there is nothing for the description to disambiguate. Baseline 4 applies.

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

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

The description gives a specific verb ('Describe') and names the resource ('Delta Signal') and enumerates the content returned: layers, stings, defaults, limits and prices. That distinguishes it clearly from the siblings (audio decoding, card previewing, signature rendering/verification). It stops short of 5 only because 'Delta Signal' and 'stings' are domain jargon an outsider agent may not decode.

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

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

'Free' signals there is no cost barrier, implying it is a safe discovery call, and none of the siblings offer an overlapping capability. But there is no explicit when-to-use, no stated prerequisite for the other engine-related calls, and no exclusion of any alternative.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds a genuinely extra trait — 'Free' — plus the PNG output format, but says nothing about whether anything is written to disk, idempotency, or what happens at the 38-character boundary.

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

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

One sentence, front-loaded with the cost signal and then the action, with zero filler. The only quibble is that 'Free.' is a marketing prefix rather than the core action.

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

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

For a one-parameter, no-output-schema tool this is close to adequate — format and cost are covered. The unresolved question is how it differs from render_signature, which an agent needs in order to route correctly among four siblings.

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

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

Schema coverage is 100% and the single 'text' parameter already documents the 38-character limit. The description adds only the loose framing 'for a message', which does not materially enrich the parameter's meaning. Baseline 3 applies.

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

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

Specific verb+resource: 'Render the SSTV signature card image for a message (PNG)' tells the agent exactly what it produces and in what format. It does not, however, distinguish itself from the sibling render_signature, which sounds like it does nearly the same thing.

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

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

'so you can see what the picture sting will carry' implies a preview/inspection use case, but the description never states when to choose this over render_signature or verify_signature. Usage is only inferable, not stated.

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

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

Annotations already establish that this is a non-read-only, closed-world operation. The description adds useful context beyond that: it returns a download link retained for 7 days, a manifest, and the output survives AAC/Opus transcoding. It does not discuss resource cost, rate limits, or whether rendering is synchronous, but the disclosure is stronger than annotations alone.

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

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

The description is front-loaded with the main action and output format, then efficiently lists optional layers and return details. It is dense but every clause contributes either capability or output behavior; minor marketing phrasing like 'Delta Signal' and 'YouTube-grade' does not obscure the content.

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

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

There is no output schema, and the description compensates by explaining the download link, its 7-day retention, and the manifest. Combined with the schema for nested layers and stings, an agent has enough to invoke the tool correctly. It could be more complete by noting synchronous behavior or verification workflow, but the core is covered.

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

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

Schema description coverage is 80%, so the schema already documents message limits, seed purpose, duration range, layers, and stings. The description adds conceptual meaning by naming heartbeat, spectrogram text, watermark, SSTV, ggwave, and modem tones, but it does not explain parameter syntax or constraints beyond what the schema provides. With high schema coverage, a baseline 3 is appropriate.

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

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

The description gives a specific verb and resource: 'Render a Delta Signal audio signature (WAV, 48 kHz).' It also names the payload ('hides your message') and the encoding layers, which makes it clearly distinguishable from decode_audio and verify_signature without needing to open the schema.

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

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

The use case is implied by 'hides your message' and the optional layer types, but the description never says when to choose this over siblings like verify_signature or preview_card, nor does it state prerequisites such as needing to keep the seed for later verification. Usage is adequate but left to inference.

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

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

Adds real context beyond the annotations: it discloses the return shape (found_layers, matches), the null semantics for matches when expected_message is absent, and the cost tradeoff versus full decode. The readOnly/openWorld annotations already cover safety, so this is a strong complement rather than a redundancy.

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

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

A single tight sentence front-loads the action and input, then the return fields, then the usage tradeoff. Every clause carries information; nothing is repeated from the name or annotations.

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

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

No output schema exists, and the description compensates by naming the key return fields and their null behavior. For a read-only, three-parameter tool this is nearly complete; only the seed parameter's role is left entirely to the schema, which is acceptable at 100% coverage.

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

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

Schema coverage is 100%, so baseline is 3. The description earns extra credit by explaining the downstream behavior of expected_message: matches is null when it's omitted, which goes beyond the schema's 'omit to discover what is present' and tells the agent what the response will look like in each branch.

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

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

States a specific verb and resource ('verify a Delta Signal audio signature') plus the input type (https WAV URL), and explicitly contrasts with 'full decode', which separates it from the decode_audio sibling. Return fields (found_layers, matches) are named, so an agent knows exactly what it gets.

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

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

Gives a clear selection rule: 'Cheaper than full decode — use it when you only need to confirm presence or identity.' The alternative (decode_audio) is named implicitly via 'full decode'. No explicit when-not conditions are stated, so it falls just short of a 5.

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