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

With no annotations, the description carries the full burden, and it does disclose two useful traits: the exact content returned (mode matrices, last probe, kill-switch) and that no credential values are ever exposed. However, it never states that the operation is read-only/side-effect-free, nor anything about ordering, pagination (none expected with zero params), or authorization requirements.

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 sentences with no filler: the payload is front-loaded, and the security assurance ('No credential values exist in this system') is stated immediately after. Every phrase earns its place.

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 and no annotations, the description is nearly sufficient: it enumerates the fields the caller will receive and rules out credential exposure. Minor gaps remain around whether results are ordered/complete and whether the call has any side effects, but not enough to prevent correct invocation.

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, so there is no parameter semantics to explain; the baseline for a zero-param schema is 4. The schema has an empty properties object and the description correctly implies no inputs are required.

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 resource is named precisely ('All registered accounts') and the payload is enumerated (declared + effective mode matrices, last probe, kill-switch state), which implicitly distinguishes it from the mutating sibling account_set. It stops short of a full verb-first statement like 'List accounts', but an agent can identify what the tool returns without opening anything.

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 statement of when to use this versus alternatives such as account_set or receipt_list, and no prerequisites, filters, or exclusions are given. The read-only intent is only inferable from the word 'inventory', which is the same gap seen in typical one-line update descriptions.

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?

With no annotations, the description carries the full burden and does meaningful work: it discloses that a FAILED probe downgrades effective modes (writes collapse to prep, reads flagged) and that this is evaluation-only with no platform contact or credentials. It omits permission/auth requirements and whether unspecified fields are preserved or replaced on update.

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?

Three tight clauses: verb+resource first, then field inventory, then the behavioral caveat. No filler, though the parenthetical field list is dense and slightly harder to scan than a structured enumeration would be.

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 nine-parameter tool with nested objects and no annotations or output schema, the description covers the important mechanics (probe downgrade, evaluation-only) but leaves the required key and two other properties unexplained, and gives no hint about what the call returns after a downgrade.

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 0%, so the description must compensate; it does explain platform, adapter, owner, role, modes (capability -> mode) and the probe sub-fields {status, at, terms_version}. But it never mentions account_id (the sole required parameter) or account_type and connection_state, leaving three of nine properties undocumented anywhere.

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 pair (register/update) and resource (authorized account), then enumerates the fields it carries. An agent can distinguish it from account_inventory, but the description never names that sibling or says how the two differ.

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?

'Register/update' implies the create-or-upsert context of use, and the probe-downgrade sentence hints at when you would re-set an account. However, there is no explicit when-not guidance and no named alternative (e.g. account_inventory for read-only lookups).

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 burden, yet it leaves out whether the call is read-only, whether it requires auth, and what happens if the variant is not built. The only behavioral claim – that substantive changes are flagged and never silent – is useful but narrow, and the meaning of 'substantive' is undefined.

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 and front-loaded, but the parenthetical category list is bulky and ends in '...', which signals incompleteness rather than precision. The two sentences do not waste words, but the first is jargon-heavy and the second is more slogan than specification.

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?

With no output schema, the description should convey the shape of the result – the category list hints at structure but not whether the diff is field-level, per-sentence, or aggregate. For a diff tool with an undocumented parameter and no annotations, this is under-specified.

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 single parameter is variant_id, and schema coverage is 0%, so the description should explain its expected format and semantics. It only weakly implies variant_id must identify a built variant; it says nothing about ID format, source, or error behavior for unknown IDs.

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?

It names the resource (a classified diff for a built variant) and lists the change categories, but never states the verb explicitly – whether it computes, retrieves, or previews the diff is left implicit. It does not distinguish itself from siblings such as adapt_preview or content_get, so an agent cannot tell from this text alone which tool to call.

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 use this tool versus adapt_preview, variant_revise, content_get, or policy_check, and no mention of prerequisites (e.g. the variant must already be built). The 'built variant' phrase implies one precondition but does not state whether to call this before or after approval.

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?

With no annotations, the description carries the full burden. It usefully discloses that writes freeze first and that drafts and receipts remain readable, but leaves major questions open: whether the action is reversible, what permissions are required, and what the `on` boolean actually does (re-enable vs. disable). These gaps matter for a capability-disabling 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?

Two short sentences, front-loaded with the core action and followed by the key behavioral consequences. No filler, no repetition of the title or name.

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 mutation tool with four undocumented parameters, no annotations, and no output schema, the description is insufficient. The agent still cannot tell how `on`, `adapter`, and `account_id` interact with `scope`, whether disabling is reversible, or what a successful response looks like.

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 should compensate. It adds one valuable hint—that `scope` takes values family | adapter | account—but says nothing about `on` (boolean toggle semantics), `adapter`, or `account_id`, leaving three of four parameters undocumented in both schema and description.

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 ('disable') and resource ('one capability scope') and names the three granularity levels (family | adapter | account). No sibling tool performs a similar disable operation, so differentiation is not needed, though the phrase 'Independently disable' is slightly awkward.

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 description implies the tool is used to disable a capability at a chosen scope, but it gives no explicit when-to-use guidance, no prerequisites, and no naming of alternatives or when-not to use it. Usage must be inferred from the verb and scope list.

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?

With no annotations, the description carries the burden and does add meaningful behavior: it specifies what is computed (geometry, copy limits, link placement, disclosures, element order) and that the variant is hash-bound. However, it does not clarify persistence, permissions, whether this is a pure preview or a write, or what happens on repeated builds.

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 compact and front-loads the action. The em-dash list is dense but purposeful, and the hash-binding note is a useful closing detail rather than filler.

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 tool with five parameters including a nested schedule object, no annotations, and no output schema, the description is incomplete. It explains the build outputs but omits parameter meaning, preview-vs-build semantics, and operational constraints.

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. It helps only with the adapter parameter by naming six accepted profile values, but says nothing about canonical_id, mode, schedule, or account_id, leaving most required and optional parameters unexplained.

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 ('Build one native variant for an adapter profile') and enumerates the adapter targets, which clearly separates it from generic content tools. The only friction is that the tool name says 'preview' while the description describes a build that is 'hash-bound', leaving a slight ambiguity about whether the artifact is durable.

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 explicit when-to-use or when-not-to-use guidance, and no mention of alternatives such as adaptation_diff, variant_revise, or approval_pack. The adapter list implies the tool is for surface adaptation, but an agent must infer the surrounding workflow.

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 present, so the description carries the full behavioral load. It does well on the core mechanism (hash recomputation, invalidation on any change), which implies a read-only comparison, but it never states that it has no side effects, does not say what happens when no approval record exists or the hash algorithm version changed, and does not describe the shape of the result beyond invalid/valid.

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 sentences, zero filler, with the verification mechanism front-loaded before the invalidation rule. Every sentence earns its place.

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?

With no output schema and no annotations, the description should say more about what is returned (a boolean? a mismatch detail? an error when unapproved). It covers the logic well but leaves the return contract and the no-approval-exists case undefined, which matters for an agent making a gating decision.

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% for the single required parameter variant_id, and the description only refers to 'a variant's approval' indirectly. It gives no guidance on the identifier's format, whether it is the variant ID from variant_revise/adapt_preview, or what happens with an unknown ID.

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 ('Verify') and object ('a variant's approval'), then explains the exact mechanism: recompute the hash from current fields and compare with the approved hash. That distinguishes it from approve_variant and approval_pack, though it does not name those siblings explicitly.

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 context is implied — check this when you need to confirm an approval hasn't been invalidated by later edits ('Any post-approval change = invalid'). There is no explicit statement of when to call it versus approve_variant or approval_pack, and no prerequisite or ordering guidance (for example, whether an approval must already exist).

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. It discloses the artifact's contents and approval purpose, but not whether the tool is read-only or mutating, what permissions are required, whether it creates a persistent artifact, or what invoking it changes.

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 compact and front-loads the artifact contents, but includes an opaque internal reference '(SS3.2 tool 6)' that does not help an agent. It is concise without being sufficiently action-oriented.

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?

With no annotations, no output schema, and an undocumented required parameter, the description should do more to explain what happens when the tool is called and what the return object represents. It names the artifact's components but leaves core invocation behavior incomplete.

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 one required string parameter with 0% description coverage, and the description does not explain canonical_id beyond loosely referencing a 'canonical item.' The parameter name is somewhat intuitive, but no real meaning, format, or lookup behavior is added.

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 identifies the artifact and enumerates its contents, which is useful, but it never states the action the tool performs (retrieve, assemble, preview, etc.). It also does not explicitly distinguish itself from siblings like approval_check, approve_variant, or adaptation_diff.

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 says the object is what the owner approves, implying a review context, but gives no explicit guidance on when to call it versus approval_check, approve_variant, or content_get. There are no exclusions, prerequisites, or alternative routing instructions.

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?

With no annotations, the description carries the full burden; it does add genuine behavioral context — the approval is owner-scoped and pinned to exact hashes, implying it is invalidated by any content change. But it omits whether the operation is idempotent, whether re-approval overwrites a prior approval, what permissions/identity 'owner' requires, and what the result is. The unexplained hash binding, with no corresponding parameters, weakens the disclosure.

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 with no filler. The hash clause is the only part that arguably does not earn its place given 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?

This is a mutation tool with no annotations, no output schema, and fully undocumented parameters, so the description must do the heavy lifting and does not: no prerequisites, no side effects, no confirmation/response behavior, and an unexplained hash-binding 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% and the description does not define either parameter: 'approver' could be a user ID, email, or role string, and 'variant_id' format is unstated. Worse, the description emphasizes binding to a canonical hash and variant hash that do not exist as parameters, so it adds ambiguity rather than compensating for the coverage 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?

Specific verb+resource combination ('Record the owner's approval of one variant') that is clearly distinct from siblings like approval_check or approval_pack. However, it does not explicitly name those siblings, and the 'bound to the exact canonical hash and exact variant hash' clause introduces concepts absent from the schema, slightly muddying what is actually being recorded.

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?

No guidance on when to call this versus approval_check, approval_pack, policy_check, or variant_revise. Nothing states prerequisites (e.g. must a policy check pass first?) or what to do when approval should be withheld.

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 disclosure burden. It hints at return contents (full record, hash, approval state) but says nothing about read-only vs mutating nature, permission or approval gating, behavior when canonical_id is unknown (error vs empty), or whether the record is versioned.

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 a single front-loaded sentence with no filler, which is good structure. However, the brevity shades into under-specification for a tool with no annotations and an undocumented parameter — the compactness is doing too little rather than too much.

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 simple one-parameter getter with no output schema, the description gives a rough picture of the return payload (full record plus hash and approval state). Missing pieces — error behavior, id format, permission requirements — leave it only minimally sufficient.

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 lone parameter canonical_id is undocumented in the schema. The description only echoes "canonical content record", which vaguely implies the id selects a canonical record, but gives no format, provenance, or how to obtain one (e.g., from content_ingest or receipt_list).

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?

"One canonical content record in full" states the resource (a single canonical content record) and the scope (single, complete record), and naming the included fields (hash, approval state) sharpens it. It stops short of naming a verb or distinguishing itself from siblings like adaptation_diff or approval_check, but the shape of the operation is unmistakable.

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 versus alternatives (e.g., approval_check for just approval state, or adaptation_diff for comparisons). The agent must infer that this is the fetch-by-id path from the name and the single required parameter alone.

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?

With no annotations provided, the description carries the behavioral burden and does a good job: it discloses validation, SHA-256 hash issuance, version bumping on changed re-ingestion, and named blockers for missing rights, claim sources, or alt-text. It stops short of describing authentication needs, exact failure modes, or the response shape.

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?

Three dense sentences are front-loaded with purpose, then behavioral traits, then blockers. Every sentence adds useful information without repetition or filler.

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 complex ingestion tool with a nested object, no annotations, and no output schema, the description provides substantial context about payload expectations, validation, hash versioning, and blockers. It could be more complete with permission requirements or response details, but it is sufficient for an agent to understand the core contract.

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%, and the sole parameter is an opaque required 'content' object. The description compensates well by enumerating the expected nested components: masters and provenance, copy, claims with sources, rights per asset, accessibility assets, disclosure record, surfaces, and schedule. It does not give exact field names or types, so it is not a 5.

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 specific verb and resource: ingest a canonical content object. It enumerates the payload components, making the tool's purpose clear. It does not explicitly position the tool against siblings such as content_get or variant_revise, so it falls short of a 5.

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 description explains what happens during ingestion and re-ingestion, but it gives no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or which sibling tool handles related tasks.

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?

With no annotations, the description carries the full burden. It usefully discloses that the log is 'append-only,' but it does not explain permissions, idempotency, error behavior, or what the tool returns after appending an entry.

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 definition is a single, front-loaded sentence that avoids filler. The parenthetical field list is dense but informative and does not obscure 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 an 11-parameter write tool with no annotations, no output schema, and no per-field schema descriptions, the description is too thin. It covers purpose and a rough field inventory but leaves behavioral details and parameter distinctions undocumented.

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. The parenthetical list maps many parameters to meaning (e.g., ts as timestamp, comment_text as full comment text, stop_or_warning as stop state), but it leaves gaps such as the distinction between target_url and target_account, and does not explain value formats or requiredness.

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 specific verb ('Append') and resource ('engagement action to the append-only log') and scopes it to 'executed or owner-completed' actions. It is distinguishable from read-oriented siblings like engagement_report and receipt_list, though it does not explicitly name those alternatives.

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 phrase 'executed or owner-completed engagement action' implies the tool should be used after an action has been carried out, not for planning or review. However, there are no explicit when-to-use/when-not instructions and no named alternatives for comparison.

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?

With no annotations provided, the description carries the full burden. 'View' implies read-only behavior and the contents are partially described, but there is no disclosure of permissions, pagination, default week behavior, date scoping, or response structure.

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 front-loaded sentence with no wasted words, and the colon-delimited list efficiently summarizes report contents. It is concise and readable, though the terseness contributes to gaps documented elsewhere.

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 tool has one undocumented parameter, no annotations, and no output schema, so the description must do more. It gives a useful sketch of report contents but omits the meaning and default of week and does not fully describe the returned report 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?

The input schema has a single integer parameter, week, with 0% description coverage, and the description does not explain it at all. 'The week's caps' hints at weekly context but does not clarify whether week is an ISO week number, offset, date, or defaulted value.

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 clearly identifies a report view over the engagement log and lists what it contains: every action, totals vs caps, and stop state. It is specific enough to distinguish the resource, but it never explicitly contrasts itself with the sibling engagement_log tool.

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 phrase 'Daily-report view' implies a reporting context, but the description gives no explicit guidance on when to call this instead of engagement_log or other sibling tools. There are no prerequisites, exclusions, or alternative-selection instructions.

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?

With no annotations, the description carries the behavioral burden. It usefully discloses policy caps, stop-signal finality, and that every check is receipted for ALLOW and DENY alike, but it does not clarify whether reset/report_stop mutate state, what permissions are needed, or how results are returned.

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 dense and front-loads the core purpose before policy details. It is a single long sentence, but nearly every clause carries substantive policy information rather than filler.

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?

This is a complex tool with 8 parameters, a nested object, no annotations, and no output schema. The description explains the policy domain and caps well, but it leaves key invocation details and return behavior under-specified, which is a significant gap for correct use.

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 0%, so the description must explain all 8 parameters. It clarifies the action values and implies the roles of week, counts, signal, and comment_text through policy rules, but adapter, account_id, owner_reset, and the nested counts object remain undocumented.

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 clearly identifies this as an engagement policy evaluator and lists the action values it handles (like, comment, report_stop, reset). It is specific about the policy domain, but it does not explicitly differentiate itself from nearby siblings such as approval_check or engagement_log.

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 action list implies the tool should be used to check engagement actions against policy before or during use. However, there is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternative for related checks such as approval_check.

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?

With no annotations provided, the description carries the full behavioral burden. It usefully discloses append-only storage, hash-chaining, and chain verification, but it does not clarify whether the tool lists entries, verifies integrity, returns a chain status, or has any authorization/rate-limit constraints.

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, waste-free sentence that front-loads the ledger's defining properties. It is concise, though its terseness contributes to the missing operational detail rather than compensating for it.

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 tool with no annotations and no output schema, the description is minimally adequate but incomplete. It explains the data domain but not the operation or return behavior, leaving the agent to infer what receipt_list actually does.

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, so there are no parameter semantics to explain. The empty schema is fully self-consistent, and the description does not need to compensate for missing parameter documentation.

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 identifies the resource as an append-only, hash-chained receipt ledger, but it does not state the tool's action (e.g., list or verify receipts). It is more specific than a tautology, yet it leaves the operation implicit and relies on the tool name.

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 description offers no explicit guidance on when to use this tool versus alternatives. Sibling tools are unrelated, but the agent is still not told the intended context or exclusions for invoking receipt_list.

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?

With no annotations, the description carries the full load and does disclose the defining side effect: the hash recomputes and any approval bound to the old hash is invalidated, returning the variant to review. That is exactly the kind of mutation consequence an agent needs before calling. It omits permission requirements and whether the changes object is a partial merge or a full replace.

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 sentences, zero filler, with the affected fields front-loaded and the consequence flagged. The "HASH LAW" label makes the critical constraint scannable rather than burying it mid-sentence.

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 mutation tool with no annotations and no output schema, the description covers the destructive side effect well but leaves gaps: no return value behavior, no error cases, and no clarification of the opaque nested changes object. Adequate to call correctly in the happy path, incomplete around the edges.

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 0% and the "changes" parameter is an untyped nested object with no declared properties, so the description's enumeration of copy/hashtags/schedule/destination/link/disclosures/order/media is the only documentation of that payload. Useful, but it gives no types, formats, or guidance on whether omitted keys are preserved, and variant_id is never explained.

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 pairs a specific verb ("Revise") with the exact resource (a variant) and enumerates the mutable surface: copy, hashtags, schedule, destination, link, disclosures, order, media. That is far more concrete than a restatement of the name. It stops short of naming a sibling it must not be confused with, even though approve_variant and approval_pack sit in the same family.

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 intended use is implied by "Revise a variant" but there is no explicit statement of when to choose this over approve_variant or approval_pack, nor any precondition such as requiring an unapproved variant. The hash rule hints that revising after approval has consequences, but the agent must infer the decision boundary itself.

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