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

No annotations are present, so the description carries the behavioral burden. It clearly discloses the state transition and the required approval precondition. However, it does not mention failure behavior, idempotency, or whether acceptance is reversible, stopping at adequate rather than thorough.

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 sentence that front-loads the key state transition and immediately states the necessary decision condition. Every word earns its place with no clutter or repetition.

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 state-transition tool with an output schema, the description covers the core workflow context and prerequisites. It could add explicit guidance about accepted_by semantics or when not to use this tool, but nothing critical is missing for an agent to invoke it correctly.

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 0% description coverage, so the description must compensate. It adds useful meaning for slice_id and approval_id by tying them to a VERIFIED slice and an approved ACCEPT_SLICE decision. It does not explain accepted_by, leaving one parameter semantically underexplained.

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 ('Move'), resource ('slice'), and lifecycle transition (VERIFIED to ACCEPTED). The requirement for an approved ACCEPT_SLICE decision also distinguishes it from sibling tools like verify_slice.

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 gives clear preconditions for use: the slice must already be VERIFIED and the ACCEPT_SLICE decision must be approved. It does not explicitly name alternatives or say when not to use it, but the context is strong enough.

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 must disclose behavioral traits, but it only says 'Authentication remains the MCP host's responsibility.' It does not disclose side effects, state changes, irreversibility, idempotency, or what happens to the associated approval record. This is a thin amount of behavioral context, though it does at least clarify that the tool does not handle authentication.

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 very short and front-loads the core purpose in the first sentence. The authentication note is a real piece of context and not filler, so there is no wasted wording; it is concise, though very sparse overall.

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 three-parameter mutation tool with no annotations, an agent still needs to know when to use it, what the optional decision_ref means, and what consequence recording an approval has. The output schema exists and covers return shape, but the missing usage guidance and parameter semantics leave the description incomplete for reliable 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?

Input schema description coverage is 0%, and the description does not explain approval_id, decided_by, or decision_ref. The phrase 'Record an explicit approval decision' loosely implies a decision identifier and decider, but decision_ref remains entirely unexplained, so the description does not compensate for the missing schema 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 clearly identifies the action ('Record') and the resource ('an explicit approval decision'), so an agent can tell this tool records approval decisions. It does not explicitly differentiate itself from sibling tools like reject_override or request_override, though the phrase 'approval decision' and the tool name make the general intent fairly clear.

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 provides no guidance on when to use approve_override versus reject_override, request_override or list_approvals. The only additional sentence is about authentication responsibility, which is a prerequisite, not a usage condition or alternative selection guideline.

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?

The description discloses a key behavioral trait: the operation registers without changing external storage, which helps an agent understand it is metadata-only and not a file-moving or storage-mutating action. However, with no annotations, the description still leaves gaps around idempotency, error behavior, checksum validation, and permissions.

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, focused sentence with no filler; it front-loads the core purpose. It is concise and easy to parse, though its brevity does not allow room for sibling differentiation or usage guidance.

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 seven parameters, no annotations, no schema descriptions, and a large set of sibling tools, the description is too sparse for an agent to confidently select and correctly invoke the tool. The output schema reduces the need to describe return values, but key context about when to use this versus registers, models, or links is missing.

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 the schema's lack of parameter explanations. The description does not define or clarify any of the seven parameters, leaving the agent to infer meaning from names like logical_name, physical_location, and belongs_to without details on formats, constraints, or relationships.

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 the action ('Register') and the resource ('a physical artifact/reference'), and adds a meaningful qualifier ('without changing its external storage'). However, it does not explicitly distinguish itself from sibling tools like register_contract or register_model, so the differentiation is left to inference from the resource type.

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 is provided about when to use this tool versus alternatives such as register_contract, register_model, link_entities, or record_execution_receipt. The description gives a general sense of the operation but no conditions, exclusions, or explicit scenarios.

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 of disclosing side effects and behavior. It usefully states the operation is 'non-destructively' and that it 'never auto-canonicalizes ambiguous contracts,' which are meaningful behavioral traits. However, it does not disclose potential errors, prerequisites, or return behavior beyond what an output schema would provide.

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, front-loaded with the primary purpose, and contains no filler. Every phrase contributes meaning, including the non-destructive qualifier and the canonicalization caveat.

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 scan tool, the core behavior is stated, and the output schema exists to explain return values. However, the description is missing practical context such as when to use this tool, how to interpret 'ambiguous contracts,' and what constraints apply to the roots. This leaves an agent with some uncertainty about 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?

Schema description coverage is 0%, so the description must compensate for parameter documentation, but it does not. It only mentions 'configured filesystem roots,' which loosely maps to the 'roots' parameter, but it does not clarify string formats, expected paths, or how ambiguous roots are handled. This is minimal added meaning beyond the property name and type.

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 states a specific action and resource: 'non-destructively inventory configured filesystem roots.' It goes beyond the tool name by explaining what is scanned and adding a safety qualifier. However, it does not explicitly differentiate itself from sibling tools by name or scenario.

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 for scanning filesystem roots, but it provides no guidance on when to prefer this tool over alternatives, nor any exclusions or prerequisites. There are many sibling tools, and this description does not help route an agent among them.

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. It discloses a critical post-condition—the slice remains open/unverified until gates are verified—which is helpful. But it does not mention other behavioral aspects such as permissions, reversibility, or side effects on related entities, making it only partially transparent.

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 exceptionally concise—two short sentences with zero fluff. It front-loads the purpose and adds only the key behavioral detail, making it efficient and easy to parse.

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 the tool's simplicity and the presence of an output schema, the description provides the essential context (what it does and a key post-condition). However, it does not elaborate on when to use it versus other state-changing tools (e.g., start_slice, accept_slice) beyond the verification note, leaving some ambiguity about the full state machine.

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 parameter meaning, but it does not. The parameter names (slice_id, actor_id, summary) are self-explanatory, yet the description adds no detail about their roles or constraints, leaving the agent to rely solely on the schema.

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 an explicit action ('Record DONE_CLAIMED') and a specific resource/status, making the tool's function unambiguous. It also differentiates from verification by noting the slice remains open/unverified, which distinguishes it from sibling tools like verify_slice.

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 when to use this tool by contrasting it with the later verification step ('until its gates are verified'), giving clear context that this is a claim action, not a finalization. However, it does not explicitly name alternative tools like 'accept_slice' or 'verify_slice', leaving some inference to the agent.

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. It discloses one behavioral trait: 'prevents stale collision traffic', which implies a state change. However, it does not mention whether closing is reversible, what happens to associated data (e.g., slices or submissions), or any permission requirements. This is a minimal but partial 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?

The description is a single, front-loaded sentence with no waste. It states the action, the condition, and the benefit. Every word contributes to the core meaning, making it highly efficient.

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?

While the tool has an output schema (which may cover return values), the description lacks behavioral details that an agent would need to use it correctly. It doesn't mention side effects beyond preventing stale collision traffic, nor does it explain prerequisites or what happens after closing. Given the simplicity of the tool and the presence of an output schema, this is not critically incomplete, but it could be more thorough.

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 mention plan_id or actor_id at all. The parameter names are somewhat self-explanatory (plan_id is an identifier, actor_id identifies an actor), but no additional meaning, constraints, or formats are provided. The description fails to compensate for the lack of schema descriptions.

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 states the action: 'Close a plan' with a specific resource and purpose. It distinguishes itself from siblings like submit_plan and start_slice by describing a closing action. The condition 'when that actor no longer intends to execute it' clarifies the scope. This is a specific verb+resource with clear intent.

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 provides a clear when-to-use condition: 'when that actor no longer intends to execute it'. It does not explicitly name alternatives or give when-not-to-use guidance, but the condition is unambiguous and actionable. It lacks explicit exclusions but the context is sufficient.

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 zero annotations, the description carries the full burden of behavioral disclosure but only reveals output characteristics ('compact deterministic'), not operational behavior. It doesn't state whether producing the package has side effects (persistence, upload, caching), requires permissions, or fails when inputs are absent. An agent cannot predict the consequences of invoking it.

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 efficient sentence with the verb front-loaded and zero filler words. The brevity, however, comes at the cost of needed context: 'IntakeGov/CogC' is unexplained jargon and 'execution package' is underspecified. Well-structured but too sparse.

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 output schema exists so return values don't need coverage, but with 0% parameter description, no annotations, and a jargon-heavy domain with 31 siblings, the description should explain what an execution package consists of and what 'deterministic' means operationally. It leaves critical gaps for an agent deciding whether and how to call the tool.

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, yet it never mentions family_id or slice_id. An agent is left to infer from the tool name and sibling names (create_family, start_slice) that family_id identifies the family and slice_id optionally selects a slice. That inference is exactly the compensation the description should have provided.

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 ('Produce'), a resource ('execution package'), and distinguishing qualifiers ('compact deterministic'), plus a target ('IntakeGov/CogC or a worker'). However, it doesn't explicitly differentiate from siblings like read_context, which could plausibly serve an overlapping need, and the 'IntakeGov/CogC' jargon is unexplained. Clear on the verb+resource but short of full sibling differentiation.

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 use this tool versus the 31 siblings. There is no 'use this when...' or 'use X instead' language, and no prerequisites are mentioned (e.g., whether a family must exist or a slice must be active). The phrase 'for IntakeGov/CogC or a worker' hints at a use case, but nothing is explicit.

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 does disclose two meaningful traits: idempotency ('or return') and durability ('durable'). However, it omits other relevant behavior such as permission requirements, side effects, or what happens on duplicate creation, so it is only partially transparent.

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 filler. It is concise and easy to parse, though the brevity contributes to under-specification in other dimensions.

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 4 parameters, no annotations, and many related sibling tools, this description is incomplete. It lacks usage guidance, parameter semantics, and differentiation from alternatives. The presence of an output schema helps with return values, but not with selection or 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?

Schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not mention family_key, title, scope_ids, or project_ids at all, leaving their semantics entirely to their names and schema titles.

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 uses a specific verb ('Create or return') and names a concrete resource ('durable contract/work family'), making the tool's basic function clear. It does not explicitly differentiate from siblings like register_contract or create_project, but the resource type is distinct enough to avoid immediate confusion.

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 is provided about when to use this tool versus alternatives such as register_contract or create_project. The phrase 'durable contract/work family' implies a use case, but there are no explicit conditions, prerequisites, or exclusions.

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?

The description discloses an idempotent behavior ('or return'), which is a useful trait. However, with no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects, permissions, error handling, or what happens on conflict. The single behavioral hint is insufficient for a mutation tool.

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, which is concise in length, but it is severely under-specified. For a tool with three parameters and no other documentation, the brevity reflects lack of content rather than efficient writing. It does not front-load any critical usage details.

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 creates or returns a project, but the description doesn't explain what happens if the project already exists, what the response looks like, or any constraints on the parameters. Despite having an output schema, the description provides no guidance on return values or side effects. With no annotations, the tool is fundamentally incomplete for 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 input schema has no descriptions for any of the three parameters, and the tool description provides no additional meaning about project_key, title, or description. With 0% schema description coverage, the description must compensate but does not, leaving parameter semantics entirely 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 states a clear verb ('create or return') and a specific resource ('project container'). It distinguishes itself from generic operations, though it doesn't explicitly differentiate from sibling create tools like create_family or create_spec. The phrase 'project container' is somewhat vague but sufficient to convey the core purpose.

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 is given on when to use this tool versus alternatives. There is no mention of prerequisites, conditions, or exclusions. The description simply states the function without any context about selection criteria, leaving the agent to infer when this tool is appropriate.

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 must carry the full behavioral disclosure burden. The word 'immutable' is a useful, non-obvious behavioral trait indicating append-only semantics and that prior versions are not overwritten, and 'Append' reinforces additive behavior. However, the description does not cover error conditions, idempotency, or side effects, so disclosure remains thin.

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 filler, repetition, or wasted words. It efficiently communicates the verb, resource, and scope. It could be longer to add behavioral detail, but as a concise structure it is well structured.

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 9 parameters, 2 required, no annotations, and 0% schema coverage, so the description is far too thin for an agent to construct a valid call. It does not explain required parameters, optional field semantics, or how the appended spec version relates to the family lifecycle. The presence of an output schema does not compensate for this absence of input context.

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 by clarifying parameter meanings. The description only hints at family_id by saying 'for a family' and says nothing about objective, constraints, contract_ids, deliverables, out_of_scope, required_evidence, supersedes_spec_id, or acceptance_criteria. An agent gets almost no parameter-level guidance beyond the schema's property names.

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 concrete action ('Append') and resource ('an immutable specification version') scoped to a family, which broadly distinguishes it from siblings like create_family or create_project. It is clear enough for an agent to understand the core intent, though it does not explicitly call out any sibling 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?

There is no guidance about when to use this tool versus alternatives such as create_family, submit_plan, or submit_evidence. It only implies use for a family, but does not state that the family must already exist or that a spec version is being added to an existing family. An agent is left to infer the workflow context.

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 of behavioral disclosure. It adds meaningful nuance by mentioning 'confirmed/suggested' and 'incoming and outgoing' edge types, which go beyond the schema. However, it does not state whether this is a read-only operation, how confirmation status is determined, or any side effects or access 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?

The description is a single, front-loaded sentence that states the action, resource, and key distinctions with no wasted words. Every element contributes to understanding what the tool does.

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 only one parameter and an output schema, so return-value documentation is not required in the description. However, the description lacks guidance on entity_id semantics and when to choose this tool over graph-related siblings, making it minimally viable but not fully complete for an agent navigating a large sibling set.

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 only says 'for an entity,' which essentially restates the entity_id field title without clarifying accepted values, ID format, or what counts as an entity in this graph context. The description adds no meaningful semantic value beyond the schema.

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 uses a specific verb and resource: 'Return confirmed/suggested incoming and outgoing graph edges for an entity.' It clearly communicates what the tool returns and includes distinguishing detail about edge direction and confirmation status. It does not explicitly differentiate from sibling tools, but the scope is specific enough that it is unlikely to be confused with most siblings.

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 is provided about when to use this tool versus alternatives such as link_entities or read_context. The description implies use when graph edges are needed, but it does not state exclusions, prerequisites, or conditions that would route an agent to a different 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 full burden. It mentions 'one explicit operation' implying atomicity but doesn't disclose side effects: does it create a family, contract, and slices all at once? Are there any side effects like triggering workflows or validation? The description vaguely says 'onboard' but doesn't specify what changes to the system state occur.

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 short and to the point, with a single sentence that is front-loaded with the key concept of onboarding an existing contract plus slices. No filler. However, its conciseness comes at the cost of completeness.

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 the tool's complexity (11 params, nested slices array with free-form objects, no annotations, no output schema details), the description is grossly insufficient. An agent would not know what slices should contain, what the relationship between family and contract is, or what the output represents. The description needs to explain the structure of slices and the overall operation flow.

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 adds no parameter-level detail. With 11 parameters and 6 required, the agent needs to understand the meaning of family_key, declared_id, slices, etc., but the description gives no hint. The schema only provides titles and types, not semantics.

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 the verb 'Onboard' and the resource 'existing contract plus its existing slices', and 'in one explicit operation' implying atomicity. But it doesn't distinguish from siblings like register_contract or start_slice, and the term 'onboard' is vague (could mean create, import, link).

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 use this tool vs alternatives. With siblings like register_contract, start_slice, create_family, the description doesn't explain what distinguishes this operation from those, nor does it mention prerequisites or context such as existing contract data.

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 of behavioral disclosure. It says the tool 'persists' data, implying a write operation, but doesn't disclose whether it's idempotent, whether it can be called multiple times for the same assignment, what happens on duplicate requests, or what the response contains. The mention of 'categorize' hints at classification behavior but doesn't explain how classification is used or what happens if it's absent.

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 core action is front-loaded, and the classification guidance is a useful addition. It earns its place, though it could be slightly more informative without becoming verbose.

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 5 parameters, no annotations, no schema descriptions, and an output schema that isn't explained. The description is too thin to guide an agent on how to construct a correct call, especially for optional parameters like family_id and source_ref. It also doesn't clarify the relationship to sibling tools like create_family or create_project, which is important given the large sibling set.

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 the schema's lack of parameter documentation. It only clarifies the purpose of 'classification' ('IntakeGov should pass its classification when available'), leaving family_id, source_ref, and classification_source unexplained. With 5 parameters and zero schema descriptions, this is a significant 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 specific verb ('Persist and categorize') and resource ('a new assignment'), which clearly distinguishes it from execution-oriented siblings like start_slice or resolve. It doesn't explicitly name a sibling, but the phrase 'before execution' positions it as an intake/pre-execution step, which is enough to differentiate it from the many other tools.

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 when to use it ('before execution') and mentions that IntakeGov should pass its classification when available, which gives some context about a specific caller. However, it doesn't explicitly state when not to use it or name alternatives like create_project or create_family, leaving the agent to infer the boundary between intake and project/family creation.

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 of disclosing behavior. It only says 'Create' and gives relation examples, without mentioning whether the operation is idempotent, requires existing entities, has side effects, or how status and confidence defaults behave. This is a significant gap for a graph-mutation tool.

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 succinct, front-loaded sentence with no filler. The action, object, and representative relation examples all earn their 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 tool with 8 parameters, no annotations, and zero schema description coverage, this one-line description is not enough to support correct invocation. It lacks guidance on valid relation values beyond examples, endpoint semantics, required entity requirements, and operational behavior. The output schema helps with return values, but the description still leaves major contextual gaps.

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 the 8 parameters, but it only offers the relation examples. It does not clarify semantics for from_id, to_id, from_type, to_type, status, confidence, or source_actor_id beyond what their names already suggest. Some meaning is added by the typed-relation framing, but not enough given the low coverage.

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 action ('Create') and a specific resource ('typed MangoMe graph relation'), with concrete relation examples like ADDS_TO and AMENDS. This clearly distinguishes it from sibling creation tools such as create_project or create_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 description implies the tool is used when creating a typed relation between entities, but it does not explicitly state when to use it versus alternatives, when not to use it, or any prerequisites. The relation examples provide some situational context but no exclusionary 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?

With no annotations, the description carries the burden of behavioral disclosure. It states the read/list behavior and the optional filtering dimensions, but does not disclose possible status values, default behavior when filters are omitted, or pagination/return behavior beyond what the output schema already supplies.

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, efficient sentence that front-loads the primary action and then specifies the optional filters. No filler or redundant wording is present.

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 two-parameter read tool with an output schema, the description is minimally adequate. However, the absence of annotations and the lack of status-value guidance or filter behavior leave meaningful gaps in what an agent needs to call it correctly without external domain knowledge.

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 parameter semantics. It only names 'status and subject' without explaining valid statuses, what subject_id refers to, or how the filters interact with each other, leaving the agent without semantic guidance beyond property names.

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 the resource ('approval requests') and the specific action ('List'), with optional filtering by status and subject. The verb and resource set it apart from mutation-oriented siblings like approve_override and reject_override.

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 this tool is for retrieving approval requests and supports optional filtering, which gives reasonable context. However, it does not explicitly state when to use this tool versus alternatives or mention any exclusions or alternatives among the sibling workflow tools.

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 must carry the behavioral burden. 'Return' implies a read operation, but the description does not disclose side-effect freedom, aggregation behavior, filtering semantics, or any operational caveats.

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. It communicates the core action and resource efficiently.

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 the absence of annotations, 0% parameter coverage, and no usage guidance, the description is too sparse. The output schema exists, but the description does not clarify filter semantics, what statistics are included, or whether the call is safe and read-only.

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 never mentions model_id or work_class. The schema only provides types and defaults, leaving the agent without any explanation of how these optional parameters affect the returned statistics.

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 ('Return') and a precise resource ('empirical cost/verified-outcome statistics from MangoMe execution receipts'). This clearly distinguishes it from action-oriented siblings like record_execution_receipt or verify_slice.

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 model_stats instead of status, read_context, or other query-like tools. No alternatives, exclusions, or conditions are mentioned, so the agent must infer appropriateness from the name 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?

No annotations exist, so the description carries the full burden. It discloses the non-mutating read behavior and the permission model ('unrestricted for every agent'). It does not mention edge cases like missing family_id, or what exactly 'context includes, leaving some behavioral gaps.

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 exactly two sentences, with the core function front-loaded and the permission note in a second short sentence. Every word earns its place, and nothing is redundant.

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 the tool's low complexity, one parameter and existing output schema, the description is mostly adequate. The output schema covers return values, so those are not needed in the description. However, it leaves unclear what constitutes 'all current family context and how the agent should obtain the family_id, making the overall description thinner than ideal.

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 only parameter, family_id. The description says 'family context' implies family_id is relevant, but provides no additional meaning about what the parameter represents, its source, or expected format. The name alone carries nearly all interpretation, so the description does not compensate for the missing schema details.

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 uses the specific verb 'Read' with the resource 'all current family context,' clearly identifying the operation. It is not a tautology and is distinguishable from mutating siblings like create_family or start_slice. However, it does not explicitly differentiate from other read-like tools such as status or graph, so it misses full sibling differentiation.

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 statement that reading is unrestricted gives a clear condition for when the tool can be called by any agent, which is useful context. However, it does not name alternatives or provide exclusions, leaving when-to-use guidance mostly implied rather than explicit.

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. It discloses that the record is 'durable' and includes verification, repair, and human cost, which is useful, but it does not state whether this is an insert-only operation, whether it overwrites existing receipts, whether it requires prior slice state, or what the response contains. For a write operation with no annotation coverage, this is a significant gap.

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 sentence with no filler, and the core action is front-loaded. It is concise, though it could add a bit more guidance without becoming bloated.

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 16 parameters, 0% schema description coverage, no annotations, and a write operation, the description is not complete enough. It does not explain the required identifiers, the outcome/work_class vocabulary, the token fields, or the behavior of the durable cost aggregation. The output schema exists but the input semantics are largely unexplained.

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, but it only explains the cost-related fields at a high level ('verification, repair and human cost'). It does not explain the meaning of family_id, slice_id, actor_id, outcome, work_class, model_id, currency, token fields, or metadata. With 16 parameters and zero schema descriptions, this is a major 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 specific verb ('Record') and resource ('model/agent cost and outcome for a slice'), and clarifies that the durable cost includes verification, repair, and human cost. It is clear enough to distinguish it from siblings like model_stats or update_slice_progress, though it doesn't explicitly name a sibling alternative.

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 this tool is used after a slice execution to record costs and outcome, but it does not explicitly state when to use it versus alternatives like update_slice_progress or claim_done. There is no when-not-to-use guidance or mention of prerequisites.

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 burden of behavioral disclosure. It does communicate that the operation is deterministic and does not use an LLM, which are useful behavioral signals. However, it does not disclose side effects, idempotency, or what 'refresh all' 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 a single front-loaded sentence with no wasted words. Every phrase contributes either the operation, the scope, or the key exclusion of LLM usage.

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 an output schema, the description is reasonably complete for invocation. Still, it lacks usage context and side-effect disclosure, so an agent cannot fully judge when to run it or what consequences to expect.

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 has zero parameters, and the schema already shows this. Since there are no parameters to document, the baseline for no-parameter tools 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 names a specific operation ('refresh all family status projections') and adds a useful qualifier ('without LLM use'), so an agent can tell what the tool does. It does not explicitly distinguish it from sibling tools, 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?

There is no guidance on when to use this tool versus alternatives. The phrase 'Run deterministic maintenance' implies a use case, but the description gives no preconditions, no scheduling context, and no relationship to sibling operations.

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 of behavioral disclosure. It does disclose one important behavior: declared-id collisions are preserved and warned, never overwritten. However, it omits other potentially relevant behaviors such as whether this creates a new record or modifies existing state, error semantics, permission requirements, or side effects.

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-loaded: the core operation appears first, followed by the collision guarantee. Both sentences earn their place, though the extreme brevity leaves important gaps for a tool with eight parameters and no schema descriptions.

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 eight parameters, zero schema description coverage, and no annotations, the description is too sparse. It does not explain the required fields, the meaning of the contribution, how warnings are surfaced, or how this relates to sibling contract tools. It is minimally useful but clearly 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?

Schema description coverage is 0%, so the description needs to compensate, but it only references declared_id through collision behavior. The other seven parameters (kind, title, actor_id, checksum, family_id, storage_system, physical_location) receive no explanation of their meaning, constraints, or relationships.

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 uses a specific verb ('Append') and resource ('a contract contribution'), which moves beyond the tool name and indicates the core operation. It also adds collision-handling behavior that hints at append semantics, though it doesn't explicitly distinguish itself from siblings like import_contract_bundle or create_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?

There is no explicit guidance on when to use register_contract versus alternatives such as import_contract_bundle or resolve. The phrase 'Append a contract contribution' implies a use case, but no conditions, exclusions, or sibling comparisons are provided to help an agent choose correctly.

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 of behavioral disclosure. It only says 'register,' which implies a write operation, but it does not state side effects, idempotency, permissions, reversibility, or what output to expect. This is a serious gap for an action that likely creates a persistent record.

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, efficient sentence front-loaded with the verb and object. It wastes no words and is easy to parse. However, its brevity borders on under-specification, so it does not earn a 5 for 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?

For a tool with 4 parameters, no annotations, and an implied mutation, this description is far too thin. It lacks usage context, parameter explanations, behavioral details, and any sense of what the tool accomplishes beyond a vague registration. An agent cannot confidently call it correctly.

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 the 4 parameters (model_key, access_path, provider, metadata). The phrase 'model/access-path identity' only hints at two of them, and provider and metadata are left entirely unexplained. No parameter-level meaning 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 uses a specific verb ('register') and names its resource ('model/access-path identity') with a purpose clause ('for empirical execution comparisons'). This distinguishes it from sibling registration tools like register_contract, though it does not explicitly name alternatives. It is clear but could be more concrete about what 'register' entails.

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 is given on when to use this tool versus alternatives, no prerequisites, and no exclusions. The phrase 'for empirical execution comparisons' hints at a use case, but it does not tell the agent when to prefer this over register_contract or other siblings.

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 behavioral burden. 'Record' implies a write/mutation, but the description does not disclose whether the rejection finalizes the approval, whether it is reversible, whether it sends notifications, or what side effects occur in the surrounding process.

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 filler or repetition. It front-loads the core purpose, though the word 'explicit' adds only marginal value and could be dropped without losing meaning.

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 parameter documentation, and no usage context, the description is too thin for reliable invocation. An agent does not know the intended place in the approval lifecycle, what the output schema will return, or how rejection differs operationally from approval besides the obvious polarity.

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, but it adds no parameter-level meaning. 'approval_id' and 'decided_by' are loosely inferable from 'rejection decision', but 'decision_ref' remains unexplained, and no parameter formats, purposes, or relations to the workflow are given.

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 action ('Record') and object ('an explicit rejection decision'), so an agent understands the tool logs/commits a rejection. It distinguishes from siblings like approve_override and request_override by naming rejection explicitly, though it could be more precise by saying it rejects an override approval.

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 about when to use this tool versus approve_override, request_override, or list_approvals. The description does not state prerequisites, sequencing in the approval workflow, or situations where this tool should not be used.

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 must carry the burden of behavioral disclosure. It only says 'Create an explicit approval request' and gives two action names, without explaining side effects, whether the request is asynchronous, whether it requires further approval, or how it affects gate/slice state. Some intent is conveyed, but meaningful behavioral context is missing.

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 short and the actionable examples are placed in the second sentence, making it scannable. The word 'explicit' adds limited value, but overall every sentence contributes useful information.

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 four required parameters and zero schema descriptions, the description is too thin. It does not provide enough context about the parameters, the meaning of an override request, or how it relates to sibling approval tools, even though an output schema exists.

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 only hints at the action_type parameter by listing 'WAIVE_GATE' and 'ACCEPT_SLICE'. It does not clarify subject_id, requested_by, or reason beyond their bare schema titles, leaving the agent to infer their semantics.

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 uses a clear verb and resource: 'Create an explicit approval request.' The named common actions, 'WAIVE_GATE' and 'ACCEPT_SLICE', provide concrete examples that help identify the tool's purpose. However, it does not fully distinguish this request-creating tool from related siblings like approve_override or accept_slice.

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 alternatives such as approve_override, reject_override, or intake_request. The description offers common action examples but does not state prerequisites, sequencing, or when a request should be preferred over direct actions.

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 must carry the behavioral burden. It does not disclose whether resolution is read-only, what happens on missing or ambiguous IDs, or whether any side effects occur. 'Without semantic guessing' is a weak behavioral hint but does not convey operational semantics like error handling 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 filler words. It is concise and directly addresses the core operation, though it is so terse that it sacrifices explanatory power.

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?

Although the tool has only one parameter and an output schema, the description leaves critical gaps: no usage context, no behavior guarantees, and minimal parameter semantics. An agent cannot confidently decide when to call it or what to expect beyond a vague 'resolve' action.

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 describes 'query' only as a string with zero coverage. The description clarifies that the query can be a family, declared contract id, or slice id, but does not explain expected formats, examples, or how the tool distinguishes among the three. This partial compensation is insufficient for a 0%-coverage parameter.

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 ('resolve') and resource types ('family, declared contract id, or slice id'), which distinguishes it from sibling tools that create, register, or scan. The phrase 'without semantic guessing' adds a hint of exact matching, but does not name alternatives explicitly, so it stops short of full differentiation.

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 is given about when to use this tool versus siblings like read_context, status, or graph. It does not state prerequisites, exclusions, or scenarios where another tool would be more appropriate, leaving the agent to infer usage from the mnemonic verb 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 disclosure burden. It does add one meaningful constraint: updating a gate does not alone satisfy verification; all gates must be PASS/WAIVED. However, it does not disclose whether evidence_ids replaces or appends evidence, authorization requirements, or reversibility, leaving important behavioral gaps unaddressed.

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-loaded: two short sentences with no filler, and the second sentence earns its place by adding an important constraint. It could be slightly more informative, but structurally it is efficient.

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 4 parameters, 0% schema coverage, and no annotations, the description leaves too much implicit. Valid status values, evidence behavior, and identifier semantics are absent. An output schema exists, so return values are not needed, but the input context is 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?

Schema description coverage is 0%, so the description must compensate. 'Evidence references' hints at evidence_ids, but it does not explain the required status parameter, the roles of slice_id and gate_id, or how evidence_ids interacts with existing evidence. The required parameters remain underdocumented.

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 uses a specific verb and resource: 'Update an acceptance gate with evidence references.' It clearly identifies the action and object. However, it does not distinguish this tool from the sibling tool set_gate_controlled, so it stops short of full differentiation.

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 gives no explicit guidance on when to use set_gate versus alternatives such as set_gate_controlled or verify_slice. The note that verification still requires all gates PASS/WAIVED is a behavioral caveat, not a usage rule, and provides no help in selecting among siblings.

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 of explaining behavior. It clearly discloses the core integrity enforcement: PASS cannot be set without evidence and WAIVED cannot be set without an approved override. It does not describe failure modes on rule violations or actor permission requirements, but the most important behavioral rule is stated.

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 compact sentence with the key rule front-loaded: set a gate, then the integrity conditions. Every word contributes to the agent's decision-making, with no filler or repetition.

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 six-parameter tool with no annotations and a sibling raw setter set_gate, the description is too thin. It does not mention valid statuses beyond the two named ones, how to satisfy the evidence/override requirements through related tools, or what happens when the integrity rules are violated. The presence of an output schema helps but does not fill these gaps.

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 the six parameters. It adds meaning to status ('PASS', 'WAIVED') and indirectly to evidence_ids and approval_id, but it leaves slice_id, gate_id, and actor_id entirely unexplained. This is only partial compensation for the schema's lack of 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 uses a specific verb and resource ('Set a gate') and adds a clear differentiator: 'v0.1.1 integrity rules' distinguishes this controlled variant from the sibling set_gate. It also names the two key behaviors that define the tool's purpose.

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 gives implicit usage preconditions: PASS requires evidence and WAIVED requires an approved override. However, it does not explicitly say when to prefer this tool over set_gate or how the override/evidence workflow relates to siblings like approve_override or submit_evidence.

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 must disclose side effects and error handling. It mentions two behaviors (plan requirement, collision handling) but omits whether the operation is a mutation, what a successful start returns, or any permission needs. This is insufficient for a starting action.

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 brief and front-loaded with the primary action, but the brevity borders on under-specification. It could benefit from a structured breakdown of prerequisites or expected outcomes.

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 three required parameters, no annotations, and a rich sibling set, the description is severely incomplete. It does not cover return values, error conditions, or how it relates to accept_slice and other workflow tools, leaving agents without enough context to invoke correctly.

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 description provides no explanation of slice_id, actor_id, or plan_id beyond their obvious names. The description fails to compensate for the lack of schema documentation, leaving parameter meaning entirely to inference.

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 action ('Start a slice') and adds a specific precondition (mandatory recorded plan). It distinguishes from siblings like 'accept_slice' by implying this is the initiating step, though it does not explicitly name 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?

It gives a concrete prerequisite ('matching recorded plan is mandatory') and clarifies collision behavior ('collisions only warn'). However, it does not explain when to choose this over similar tools like accept_slice or submit_plan, leaving the routing partially implicit.

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 must disclose behavior on its own, and it does add the useful properties that the returned state is 'deterministic' and 'materialized,' but it does not mention whether the operation is read-only, whether permissions are needed, or any rate limits. This is moderately transparent for a simple status query but leaves room for more behavioral context.

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 focused sentence with no filler or repetition. The key facts—what it returns, the determinism/materialization behavior, and the family scope—are stated efficiently.

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 read-style tool with a provided output schema, the description covers the essential call semantics. The main gap is the lack of comparison to sibling state/query tools, but the simplicity of the interface and the schema coverage make the description largely 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?

The input schema describes family_id as a string with no additional description, so the phrase 'for one family' is the only semantic signal tying the parameter to the tool's scope. It compensates partially for 0% schema coverage, but does not explicitly say that family_id is the selector or explain its format/domain.

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 uses a clear verb ('Return') and identifies the resource as 'deterministic materialized project-management state' scoped to 'one family,' which is specific enough to understand what the tool does. It does not, however, distinguish status from siblings like read_context or graph, so the purpose is clear but not differentiated.

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 about when to use this tool versus the many sibling query tools (read_context, graph, refresh_views) or when not to use it. The description implies a read operation but provides no selection criteria or exclusions, leaving the agent to infer usage.

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 are not provided, so the description carries the full burden of disclosing behavioral traits. It does not state any side effects (e.g., whether evidence is immutable, requires special permissions, or affects downstream processes). For a tool that 'attaches' evidence, this lack of behavioral detail is a notable gap, especially without annotation support.

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 sentence with no unnecessary fluff. It is concise and front-loads the main action (attach) and the targets. However, it could be slightly more structured by separating the targets or adding a brief clause on usage, but as a one-liner it is acceptable.

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 the tool's complexity (7 parameters, 3 required) and the lack of schema descriptions and annotations, the description is incomplete. It does not explain what 'durable evidence' means, how the various targets relate (e.g., 'subject_id' vs. 'artifact_id'), or what the output schema contains. An agent would have to guess at parameter semantics and side effects, making this insufficient for reliable 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?

Schema description coverage is 0%, meaning the input schema provides no descriptions for any of the 7 parameters. The tool description spaces 'subject_id', 'evidence_type', 'source', and 'payload' but provides no meaning beyond their names. For example, it does not explain what format 'evidence_type' should take or how 'source' should be specified, leaving the agent to infer from parameter names alone.

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 verb ('attach') and a resource ('evidence'), and lists four possible targets (family, contract, slice, artifact). This distinguishes it from some siblings like 'attach_artifact' and 'link_entities', but it is vague about what 'durable evidence' means and does not specify the exact scope of what this tool handles compared to others that might also attach or link things.

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 provides no guidance on when to use this tool vs. alternatives. It does not mention when NOT to use it, nor does it reference any sibling tools (e.g., 'attach_artifact' or 'link_entities') that might be more appropriate in certain contexts. This is a significant gap for differentiation among many similar tools in the sibling 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 must disclose side effects. It notes that advisory collision warnings are returned, implying a non-blocking behavior, but it does not state that this is a mutating operation, whether authorization is needed, or what happens on validation failure. The word 'record' hints at persistence but is not explicit.

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, efficient sentence of 13 words that front-loads the action and return value. There is no redundant phrasing, and it is appropriately concise for the information it conveys.

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 11 parameters and no annotations, the description is severely under-specified. It does not explain parameter roles, preconditions, or the structure of a valid plan. The existence of an output schema does not compensate for the missing input semantics, making it hard for an agent to correctly construct a request.

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 provides no explanation of the 11 parameters, including required fields like family_id, request_id, spec_id, actor_id, intent, and proposed_slices. It fails to compensate for the schema's lack of semantic comments, leaving agents without guidance on how to fill in the fields.

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 states a specific action (record) on a specific resource (the mandatory pre-execution plan) and the return value (advisory collision warnings). It distinguishes from siblings like close_plan and start_slice by focusing on the initial recording phase, making purpose unambiguous.

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 'pre-execution plan' implies this tool is used before execution, giving conditional usage context. However, it does not explicitly mention when not to use it or provide alternatives (e.g., close_plan or start_slice), leaving the agent to infer the typical 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?

With no annotations provided, the description carries the behavioral burden. It clearly indicates this is a persistence/write operation and explicitly excludes verification/completion semantics. However, it does not disclose whether updates are partial or full overwrites, idempotency, or any side effects.

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 two short sentences, front-loaded with the core purpose and immediately followed by a clarifying boundary. Every phrase earns its place, with no redundant 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?

Given six parameters, zero schema descriptions, and no annotations, the description is too sparse for correct invocation. An agent would not know what execution_state values are expected, whether fields update incrementally, or what the output means, even though an output schema exists.

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%, yet the description adds almost no parameter-level guidance. 'Current slice state' vaguely maps to fields like execution_state and current_step, but it does not explain the roles of slice_id, actor_id, blocker, or valid values for execution_state or step values.

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: 'Persist current slice state.' It also explicitly differentiates itself from completion and verification workflows with 'Does not verify or complete work,' which clearly separates it from siblings like verify_slice, claim_done, and resolve.

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 gives a useful negative boundary by saying the tool does not verify or complete work, which implies it is for intermediate progress updates. However, it does not explicitly state when to use it versus a sibling tool, nor does it name an alternative tool for verification or completion.

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 burden. It reveals a precondition/enforcement behavior (gates must be PASS/WAIVED) but does not disclose what 'verify' does to the slice (status transition, side effects), whether verifier_actor_id has permission requirements, or how evidence_ids is used. For a workflow mutation tool this is a significant gap.

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 sentence, front-loaded with the verb and resource, with the condition stated compactly. There is no filler or repetition.

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?

An output schema exists and covers return values, but the tool has no annotations and 0% schema coverage for parameters. The description only supplies the precondition; an agent still cannot determine the effect of verifying, the meaning of evidence_ids, or who may verify. Important gaps remain.

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 provides no parameter information. Three parameters exist (slice_id, evidence_ids, verifier_actor_id) but only slice_id is inferable from the verb; evidence_ids and verifier_actor_id remain opaque. The description adds no meaning beyond the schema names.

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 action ('Verify') applied to a resource ('DONE_CLAIMED slice') and adds a precise precondition ('every acceptance gate is PASS or WAIVED'). The DONE_CLAIMED qualifier clearly distinguishes it from sibling tools like claim_done or accept_slice.

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 'only when...' explicitly constrains invocation: only if every acceptance gate is PASS or WAIVED. This is a clear usage condition, though it doesn't name alternative tools for different states (e.g., set_gate, claim_done).

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