Pre-dispatch rejection ledger

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

With no annotations, the description carries the full transparency burden, and it discloses only cost and scope ('$4.99/server up to 25 tools'). It says nothing about whether the tool is read-only, whether it contacts an external service, authentication needs, or what the scan produces — all material for an agent deciding to call a paid operation.

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?

It is short, but the brevity comes from ellipsis rather than efficiency: the fragment 'Enum schema-vs-upstream differ scan' omits the article, verb framing, and object needed to parse it, and the pricing clause is tacked on without connecting to behavior.

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 paid, no-annotation tool with two entirely undocumented parameters and no output schema, the description leaves an agent unable to predict what it will receive or how to populate arguments. The only genuinely useful information is the cost model.

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 0%, so the description must explain the two parameters, but it never mentions server_id or the tools array. The phrase 'up to 25 tools' hints at the tools parameter's bounds without stating that it is a parameter or what its elements are.

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 phrase 'schema-vs-upstream differ scan' does name a specific computation (diffing a local schema against an upstream source), but it is compressed into jargon-heavy shorthand with the verb reduced to 'Enum'. It never says what the scan returns or what 'enum' enumerates, so the purpose is inferable but not stated plainly.

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?

There is no guidance on when to run this scan, what prerequisites exist, or how it relates to siblings like receipt_query and record_rejection. The pricing clause is the only context given and it does not help an agent decide whether to invoke the tool.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. It usefully discloses pricing and a one-free-query-per-operator limit, but omits auth requirements, return shape, error behavior, and whether billing applies on failed queries.

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 concise and front-loads the core purpose, followed by relevant cost information. There is little wasted text, though the combined sentence is dense.

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?

The description covers what the query answers and its pricing, but with no annotations, no output schema, and 0% parameter description coverage, it leaves critical gaps around parameter usage and full behavioral expectations.

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 schema has two parameters, tool and field, with 0% description coverage. The description never explains what these parameters mean or how to populate them, so it does not compensate for the schema gap.

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 states a clear query purpose: asking whether a call was rejected pre-dispatch, which constraint caused it, and whether substitution is forbidden. It does not explicitly contrast with the sibling tools differ_scan and record_rejection, but the operation is specific enough to distinguish from a generic query.

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?

It describes the information available and mentions a price and a lifetime free query, but gives no explicit guidance on when to use this tool rather than differ_scan or record_rejection. The cost note is useful context but not alternative-selection guidance.

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?

No annotations are provided, so the description carries the full behavioral burden. The phrase 'value hashed only' usefully discloses a privacy behavior, but the description does not state whether this is a write that persists, whether it is idempotent, what permissions are required, or what happens to the recorded data.

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 a single short sentence with no wasted words, but it is under-specified for a five-parameter mutation tool. Conciseness is achieved at the cost of necessary detail rather than through efficient structure.

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?

Given no annotations, no output schema, and 0% schema description coverage across five parameters, the description is far too thin. It mentions only one behavioral detail (hashing) and omits the semantics of the required fields and the expected effect of recording a rejection.

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 0%, so the description must compensate for five undocumented parameters. It only indirectly explains that the 'value' parameter is hashed, while saying nothing about 'tool', 'field', 'constraint', or 'intent_bearing'.

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 names a specific verb and resource: recording a validator rejection. However, it does not clarify what a 'rejection' means in this system, how it relates to validation workflows, or how it differs from sibling tools like differ_scan and receipt_query.

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?

There is no guidance on when to call this tool, when not to call it, or which alternative to use. The agent must infer that this is for logging validator failures, but no prerequisites, triggers, or exclusions are stated.

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