Wever Labs Agentic Rails

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

Annotations provide readOnlyHint=false, and the description adds that the tool creates activation records, clarifying the write side effect. However, it doesn't disclose details like reversibility, credential mutation side effects, or operational requirements, leaving some transparency 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 a single concise sentence with no fluff, front-loading the action verbs 'check' and 'create.' It earns its place, though its brevity contributes to under-specification.

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

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

With two parameters, no required fields, no output schema, and sparse annotations, the description provides too little context. It doesn't cover parameter semantics, return behavior, or usage scenarios, leaving the agent with an incomplete picture.

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 is expected to compensate for parameter meaning. It implies 'targets' relates to the target credential environment, but 'submission_target' is completely unexplained, and no additional parameter details are 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 states the tool checks a target credential environment and creates credential activation records, which identifies the specific verb and resource. It doesn't explicitly distinguish it from sibling tools like validate_directory_submission_credentials or issue_agent_credential, but the 'activation records' wording is reasonably specific.

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, no prerequisites, exclusions, or workflow context. The description only says what it does, not when it should be invoked.

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 declare readOnlyHint=true, so safety is covered. The description adds minimal context by indicating the output is target-specific, but doesn't describe behavior beyond returning a payload. No contradiction.

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?

Single sentence, no unnecessary words, front-loaded with the main action. However, it could be clearer, but conciseness is good.

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 is simple (one param, no output schema) but the description leaves key questions unanswered: what is an 'adapter payload', what does 'target' mean, and how does this relate to the submission process. Given the low complexity, it's partially complete but not fully.

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 only parameter 'submission_target' has no description. The phrase 'target-specific' hints at its meaning but doesn't explain format, possible values, or how it affects the payload. Description fails to compensate for 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 'Return' and identifies the resource as 'directory adapter payload', but the concept is vague and does not distinguish from sibling tools like run_directory_submission_adapter or execute_directory_submission.

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 alternatives. There is no mention of prerequisites, exclusions, or alternative 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?

The description provides minimal behavioral context beyond the annotation readOnlyHint=false. It does not explain what side effects occur, whether the operation is destructive or idempotent, or what 'binding' actually does to the metadata or settlement state. This is insufficient for a mutation tool with only a readOnlyHint annotation.

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 concise sentence with no extraneous words. It is structured clearly as an action, but the brevity comes at the cost of specificity. It earns its place as a terse summary, though it could be improved with more detail.

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 has 4 optional parameters, no output schema, and only a readOnlyHint annotation, the description is inadequate. It does not explain return values, side effects, or valid use cases. The agent would likely be unable to invoke this tool correctly without external 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%, and the description does not mention any parameters. The property names (rail_key, challenge_id, movement_type, movement_amount_units) give some hints, but the description does not clarify how they relate to the binding operation. This leaves the agent without necessary parameter understanding.

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 verb ('Bind') and a resource ('x402 challenge metadata') but the operation is vague. 'Bind' is not a standard term, and the phrase 'facilitator readiness or sandbox settlement state' presents ambiguity about what is actually being set or changed. It does not clearly distinguish from sibling tools like 'create_x402_payment_challenge'.

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 description does not mention prerequisites, exclusions, or related tools. Given the long sibling list, this lack of direction leaves the agent without context for selection.

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 adds no behavioral context beyond what the annotations already convey. The readOnlyHint=false implies mutation, and 'Build' aligns with that, but there is no disclosure of side effects, permissions, return format, or any other behavioral traits. The description is essentially a restatement of the name.

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 ('Build callback packet.'), but this is under-specification rather than conciseness. It omits essential details, so it does not earn its place by providing useful information. A single vague sentence is not concise; it is incomplete.

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 minimal input schema (one optional string, no output schema) and no description of what a callback envelope is, the description is wholly inadequate. An agent cannot determine what the tool does, when to call it, how to populate parameters, or what to expect in return. The tool is essentially unusable from this definition alone.

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

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

The schema has one parameter (event_type) with zero description coverage (0%), and the description does not mention the parameter at all. This leaves the agent completely without guidance on what event_type should contain or how it affects the built envelope. With no compensation from the description, the parameter semantics are severely lacking.

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 'Build callback packet' uses a specific verb ('build') and a resource ('callback packet'), but the resource is vague and does not clearly distinguish this from many sibling 'build' tools like build_external_agent_client_package or build_mcp_package_metadata. The name and title add 'A2A callback envelope' specificity, but the description itself is generic.

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 versus alternatives. There are numerous sibling tools related to callbacks (e.g., complete_paid_rail_run_with_callback, store_callback_receipt_record), but no context is given about how this tool fits into those workflows. No exclusions or alternative recommendations are mentioned.

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 annotation readOnlyHint=true is consistent with the description's 'Return' verb, so no contradiction. However, the description adds no behavioral context beyond the annotation, such as what inputs it expects or whether any computation occurs. It only lists the output components.

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, front-loaded with the action verb 'Return' and lists the four key components. It contains no redundant words or filler, 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?

The description is too sparse to be contextually complete. It doesn't define 'target surfaces,' 'cadence,' or how the plan is structured, and it doesn't explain that the tool accepts arbitrary additional properties. The lack of an output schema and the minimal description leave the agent with insufficient information to invoke the tool 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?

There are zero parameters, so the baseline is 4 per the rubric. The schema is empty with additionalProperties allowed, and the description doesn't add parameter details, but no details are needed for zero defined parameters.

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 says 'Return target surfaces, required files, verification checks, and cadence,' which specifies the output components but does not explicitly state that it constructs a distribution plan. The verb 'Return' is generic, and the tool is not distinguished from sibling build tools like build_external_discovery_submission_pack. It is clear enough about 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?

The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, target scenarios, or excluded cases. Given the many sibling tools, this is a significant omission.

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 readOnlyHint=true annotation aligns with the 'Return' wording, so there is no contradiction. The description adds that it returns a manifest and smoke sequence, which is some behavioral context, but it does not disclose auth needs, rate limits, or other 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 a single sentence with no fluff, but it is so terse that it sacrifices clarity. It is concise in length but fails to convey enough information, making it less effective than a longer, more explicit description.

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 minimal schema and no output schema, and the description provides almost no context. It does not explain what a client manifest is, what a smoke sequence contains, or how package_target affects the result, making the tool underspecified for an agent.

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 only parameter, package_target, has no description in the schema and is not mentioned in the tool description. With 0% schema description coverage, the description fails to compensate, leaving the agent clueless about what value to pass.

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 says 'Return client manifest and smoke sequence,' which names a verb and objects, but the purpose is unclear because 'external agent client package' is never explained. The title says 'Build' while the description implies a read-only return, causing confusion. It also fails to distinguish itself from numerous sibling tools like build_external_agent_client_runner.

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 on when to use this tool versus alternatives. The description lacks any mention of scenarios, prerequisites, or exclusions, leaving the agent without direction.

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 declare readOnlyHint=true, and the description adds only that it returns files and pass markers. It doesn't explain what these markers are, how results are delivered, or any other behavioral details, so it contributes little beyond the annotations.

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 and front-loaded, but it is under-specified and the phrase 'pass markers' is cryptic. Conciseness is achieved at the expense of clarity.

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

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

With an empty input schema, no output schema, and a vague phrase like 'pass markers,' the tool's behavior and return values remain largely unexplained. More context about what external client files are and how markers are handled is necessary.

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 zero parameters and 100% coverage, so there are no parameter details to describe. The baseline of 4 is appropriate since no parameter information is needed.

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 vague verb 'Return' and unclear nouns 'external client files' and 'pass markers' without explaining what building a runner entails. It does not distinguish from siblings like build_external_agent_client_package or run_external_agent_client_runner.

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 on when to use this tool instead of similar build/run siblings. The description offers no context, prerequisites, or alternatives.

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 directly contradicts the annotation readOnlyHint=true by using 'Build' and implying creation of directory and registry objects. This is an annotation contradiction, and no further behavioral details are disclosed.

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 extremely short, but this is under-specification rather than conciseness. It omits essential context and provides no useful information beyond the title.

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

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

With only one parameter, no output schema, and conflicting annotations, the description should clarify scope, side effects, and expected behavior. It provides none, making the tool virtually unusable 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?

Schema description coverage is 0%, and the description provides no explanation of the sole parameter 'submission_target'. The description fails to compensate for the lack of schema-level 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 'Build directory and registry objects' is vague and does not mention the tool's actual purpose of building an external discovery submission pack. It fails to distinguish this from sibling build tools like build_external_agent_client_package or build_agent_discovery_distribution_plan.

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, contexts, or exclusions, leaving the agent without any basis for selection.

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

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

Annotations already declare readOnlyHint=true, and the description's 'Return' aligns with that. It adds some context by specifying the output contains metadata and public files, but it does not disclose response format, potential version-specific behavior, or any operational constraints beyond what the annotation already implies.

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, direct sentence with no filler or redundant phrasing. It communicates the core action efficiently, though it sacrifices detail for brevity.

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 simple one-parameter schema and read-only annotations, the description still misses essential contextual details: parameter semantics, output structure, and criteria for when to invoke this over siblings. The tool is simple, but the description is too sparse to fully support reliable autonomous use.

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

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

The only parameter, package_version, has zero schema description coverage and is not mentioned in the description at all. The agent receives no information about acceptable formats, default behavior when omitted, or how version affects the returned metadata, making correct invocation uncertain.

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 ('Return') and identifies the resource ('registry-grade MCP package metadata and public files'), making the tool's basic purpose clear. However, the phrase 'registry-grade' is vague and does not strongly differentiate it from sibling tools like 'build_public_agent_client_repo' or 'build_external_discovery_submission_pack'.

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, no exclusions, and no mention of prerequisites. The agent must rely on the name and title alone to infer appropriate usage, which is especially difficult given the large number of similar sibling 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?

The annotation readOnlyHint=true already signals a read-only operation, and the description's 'Return' is consistent with that. The description adds some context about the output being 'GitHub-ready' and including 'smoke tests', which is useful but does not disclose any other behavioral traits such as authentication needs, side effects, or limitations. No contradiction with annotations.

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 conveys the core purpose efficiently. However, it is arguably under-specified, but for conciseness it earns a solid score because every word contributes.

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

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

With no output schema and a single undocumented parameter, the description leaves the agent without critical details: what the 'package' includes, how 'smoke tests' are returned, and how 'release_version' is used. The presence of many sibling tools heightens the need for contextual guidance, which is absent.

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 one parameter ('release_version') with no description, and the schema description coverage is 0%. The description does not mention this parameter or its purpose, so the agent must guess how to supply the version. A self-explanatory parameter name is not enough to compensate for the total lack of semantic guidance.

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 resource ('GitHub-ready external client repo package and smoke tests'), making clear what the tool produces. However, it does not differentiate from closely named siblings such as 'build_external_agent_client_package' and 'build_external_agent_client_runner', so it lacks sibling distinction.

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 this tool versus alternatives. The description does not mention any prerequisites, exclusions, or when to prefer another tool. The overwhelming set of sibling tools makes this gap significant.

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 annotation readOnlyHint=false already indicates a write operation. The description adds that a payment reference or verified checkout reference must be present, which is useful behavioral context. However, it doesn't disclose side effects, validation steps, or what completing entails, offering only minimal additional transparency.

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

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

One sentence, 17 words, front-loaded with the action 'Complete a rail run'. Every word earns its place; no 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?

The tool has four parameters, no output schema, and minimal annotations, yet the description only covers the precondition. It doesn't explain the role of rail_key or movement_type, nor what a completed run looks like, leaving significant gaps for the agent.

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 payment_reference parameter by mentioning 'payment reference' (and introduces a 'verified checkout reference' not in the schema). It provides no semantics for rail_key, movement_type, or movement_amount_units, so it 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 uses a specific verb ('Complete') and resource ('rail run'), and adds a precondition ('when a payment reference or verified checkout reference is present'), clearly distinguishing it from sibling tools like start_rail_run or complete_paid_rail_run_with_callback. It states the action and scope unambiguously.

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 explicitly states the condition for use: when a payment reference or verified checkout reference is present. This gives clear context but does not mention alternatives or when-not to use it, such as the callback variant, so it lacks explicit 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 multiple mutative side effects: completing the run, building a callback envelope, optionally delivering to callback_url, and storing callback proof. This adds meaningful context beyond the readOnlyHint=false annotation, though it omits prerequisites and failure behavior.

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 concise sentence that front-loads the primary action and enumerates subsequent steps. There is no redundancy or filler, making it well-structured and 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?

Given the tool has four parameters, no output schema, and only a readOnlyHint annotation, the description omits critical context such as return values, prerequisites, and idempotency semantics. The action is described, but the overall contract is incomplete for an agent to invoke it confidently.

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 explicitly mentions 'callback_url' and alludes to payment via 'paid', but does not explain 'rail_key', 'idempotency_key', or 'payment_reference'. The schema provides names and an enum, but the description adds little additional meaning.

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 ('Complete') and resource ('paid run') and outlines sub-actions (build callback envelope, deliver, store proof), making the core purpose clear. However, it does not explicitly distinguish itself from sibling tools like 'complete_agent_self_serve_paid_rail_run' or 'build_a2a_callback_envelope', so it falls short of a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not state 'use when...' or contrast with sibling tools such as 'build_a2a_callback_envelope' or 'complete_agent_self_serve_paid_rail_run', leaving the agent without sufficient decision 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?

The readOnlyHint=false annotation already signals mutation, and the description adds detail by listing the specific operations (create, update, complete, read). However, it does not disclose side effects, idempotency, or how 'complete' behaves, so it only partially enriches beyond the annotation.

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 that front-loads the action verbs. It wastes no words, though it omits parameter details that could be structured separately. For what it contains, it is concise and well-ordered.

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

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

With 5 optional parameters, no output schema, and minimal annotations, the description is severely under-specified. It fails to explain parameter inputs, return values, usage context, or behavioral nuances, making it inadequate 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 schema has 5 parameters with 0% description coverage, and the tool description mentions none of them. There is no elaboration on what rail_key, receipt_id, a2a_task_id, lifecycle_mode, or production_run_id mean, leaving the agent to guess their roles.

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 tool's function with explicit verbs ('Create, update, complete, or read') targeting a specific resource ('A2A task lifecycle records'). It distinguishes itself from sibling tools by referencing a unique resource, though the title/name 'create' is narrower than the actual description.

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. No mention of prerequisites, scenarios, or exclusions. The description simply states what the tool does without contextualizing it among the many lifecycle-related sibling 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?

Annotations only indicate readOnlyHint=false, so the description carries the burden but adds little. It says 'return' an object, which implies a response, but gives no details on side effects, idempotency, error cases, authorization requirements, or the structure of the returned payment-required object. The lack of an output schema makes this gap more significant.

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

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

It is a single sentence with no redundancy, so it is concise. However, it's terse to the point of under-specification, missing critical details. It earns its place but fails to be informative enough.

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 2 parameters, no output schema, and no behavioral annotations beyond readOnlyHint=false, this description is much too sparse. It doesn't explain the return value shape, parameter meanings, or use context, leaving the agent to guess how the tool behaves and what inputs to provide.

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 needed to explain rail_key and movement_amount_units. It does not. No indication of what 'rail_key' enum values mean, how 'movement_amount_units' is denominated, or whether additional properties are permitted. The description is entirely unhelpful for constructing a correct call.

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 clear action and resource: 'Return payment-required object for rail movement.' This identifies what the tool does, though 'rail movement' is a bit cryptic. It doesn't explicitly differentiate from similar tools like create_stripe_movement_fee_checkout or create_x402_payment_challenge, but the 'rail movement' scope provides some distinction.

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. No mention of prerequisites, exclusions, or competing tools such as create_stripe_movement_fee_checkout, quote_movement_fee, or create_x402_payment_challenge. The agent is left to infer usage 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?

Annotations indicate readOnlyHint=false, so the description's 'Create' is consistent. The description adds the conditional behavior of returning env setup requirements, which provides some context beyond annotations. However, it does not disclose side effects (e.g., whether a charge is initiated, idempotency handling, or session expiration). The added value is modest but not minimal.

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, front-loaded with the core action, and includes the key conditional behavior. Every word contributes meaning; there is no filler or redundancy.

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 (4 undocumented parameters, no output schema) and the extensive sibling list, the description is too sparse. It does not mention return values, parameter relationships, or the conditions under which env setup requirements are returned. The overall context is insufficient for an agent to invoke this tool confidently without additional information.

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 explain any of the four parameters (rail_key, movement_type, idempotency_key, movement_amount_units). Even the enum for rail_key is not contextualized. The description fails entirely to compensate for the lack of schema documentation, leaving agents guessing about parameter meaning and usage.

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?

Description clearly states the primary action: 'Create Stripe Checkout Session for movement fee collection'. The verb 'Create' is specific and the resource 'Stripe Checkout Session for movement fee collection' is well-defined. The addition of 'or return env setup requirements' distinguishes this tool's conditional behavior from siblings like quote_movement_fee or verify_stripe_movement_fee_payment.

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 explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, scenarios, or exclusions. While the purpose implies usage, it does not differentiate from related tools such as quote_movement_fee, get_movement_fee_schedule, or verify_stripe_movement_fee_payment, which are present 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?

The description fails to disclose side effects (e.g., whether a challenge is persisted, sent, or merely returned), prerequisites, or error behavior. It mentions a 'payment_reference fallback' but does not explain what triggers it. With readOnlyHint=false indicating a write-capable action, the vague 'Return' wording is ambiguous and does not clarify the actual behavioral outcome.

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 that is front-loaded with the primary action and resource. It is concise and free of fluff, but the brevity comes at the cost of missing important details, so it earns an above-average but not excellent score.

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

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

With no output schema, sparse annotations, and three parameters lacking descriptions, the description should provide substantial context. It only mentions the envelope and a fallback, leaving the agent without enough information about parameters, alternatives, or expected results, making the tool hard 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%, so the description must carry the burden of explaining parameters. It offers no explanation for 'rail_key', 'movement_type', or 'movement_amount_units'. While the parameter names are somewhat self-explanatory, the description adds zero semantic context about how they affect the payment challenge.

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 resource ('HTTP 402/x402-compatible payment challenge envelope'), making the core purpose clear. However, it does not distinguish this from the similarly named sibling tool 'create_payment_challenge', which could lead to confusion about which to use.

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

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

The description offers no guidance on when to use this tool versus alternatives like 'create_payment_challenge' or 'get_movement_fee_schedule'. It neither states explicit usage context nor mentions exclusions, leaving the agent to infer when it 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?

The annotation readOnlyHint=false indicates a mutation operation, but the description adds little: it mentions validation and returning a write envelope but does not disclose side effects, whether the tool actually performs the write, what a write envelope contains, or any credential auth requirements. This ambiguity 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, compact sentence with no unnecessary words, making it concise. However, it is so brief that it sacrifices necessary detail, though that is a completeness rather than conciseness concern.

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

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

With no output schema and minimal annotations, the description should fully explain behavior, parameters, and return value. It fails to define 'write envelope', clarify parameter roles, or provide any context about the tool's place in the workflow, rendering it incomplete for safe 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% and the description does not explain any of the four parameters (rail_key, agent_key, write_tool, idempotency_key). The agent must infer their meanings from names alone, which is insufficient for a credential-aware write tool.

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 tool validates a credential and returns a write envelope, which is a specific process. However, the term 'write envelope' is undefined and the description does not differentiate this tool from sibling tools like enforce_agent_credential or validate_directory_submission_credentials, making its purpose somewhat ambiguous.

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 usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor any prerequisites or context, leaving the agent without direction for selecting it 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?

The readOnlyHint annotation already covers the non-mutating nature. The description adds that it validates a draft, implying no side effects, but does not disclose behavior like validation failure handling, return format, or specific criteria checked. Some value is added beyond annotations, but not rich 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 sentence with no filler, starting with the verb 'validate' and immediately specifying the resource and scope. It is efficient and well-structured for readability.

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 (12 optional params, no output schema, no parameter descriptions), the description is too thin. It lacks essential context about validation outcomes, required fields, how the listed dimensions map to schema properties, and what 'non-authoritative' means in practice.

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?

With 12 parameters and 0% schema description coverage, the description must compensate significantly. It only provides high-level categories (principal, agent, scope, budget) without mapping them to specific parameter names, and it omits several params like permission_mode, consent_reference, and identity_provider. The 'time window' mention has no corresponding parameter in 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 a specific verb 'validate' and identifies the resource as a 'non-authoritative mandate draft' with clear dimensions (principal, agent, scope, time window, budget). This distinguishes it from sibling tools like inspect_authority_mandate and execute_delegated_action.

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 usage for validating a non-authoritative mandate draft, but provides no explicit alternatives, exclusions, or when-not-to-use guidance. There is no mention of when to use this instead of inspecting an authoritative mandate or evaluating an authority action.

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 that the tool accepts or rejects a write, but says nothing about side effects, error behavior, or what rejection entails. The readOnlyHint=false annotation already indicates mutation, so the description adds minimal 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 extremely short, bordering on cryptic. While it avoids verbosity, it sacrifices necessary explanatory content, providing only a minimal phrase.

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

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

With no output schema, no parameter descriptions, and minimal behavioral information, the description is severely incomplete for a tool that likely has authorization implications. The agent has insufficient information to use it safely.

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 names no parameters. rail_key, agent_key, and idempotency_key are completely unexplained, leaving the agent unable to construct a valid call beyond guessing from the name.

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-object construction ('Accept or reject scoped write') indicating the tool makes an enforcement decision about a write operation. It is clear but does not differentiate from sibling tools like run_credential_enforcement_dry_run.

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 on when to use this tool versus alternatives. There is no mention of prerequisites, contexts, or exclusions, leaving the agent without direction.

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 set readOnlyHint=false, indicating a mutating operation. The description adds context about producing a signed passport and receipt verification, implying side effects like signing, but does not disclose whether it persists results, consumes the return package, or requires special permissions. It does not contradict annotations but leaves state-change implications vague.

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 lists all key outputs without fluff or repetition. Every word contributes to specifying the tool's purpose.

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

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

This is a complex tool with six parameters, nested objects, no output schema, and several overlapping siblings. The description does not explain what the five scores represent, the nature of the continuation decision, how receipt verification works, or the role of mission_type. It is too sparse to provide complete operational 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%, and the description does not compensate. It only mentions 'agent return package' (mapping to return_package) but fails to explain mandate, agent_id, asset_id, asset_ticker, mission_type, or how these interact. With six undocumented parameters, the description adds almost no semantic value beyond the schema's field 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 states the tool's function with a specific verb and resource: 'Evaluate an agent return package' and enumerates distinct outputs (five scores, continuation decision, signed Agent Commerce Passport, receipt verification). This differentiates it from siblings like fetch_return_package or publish_verified_commerce_proof.

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, prerequisites, or exclusions. It only states what the tool does, leaving the agent to infer appropriate usage from the name and sibling 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?

The readOnlyHint annotation already indicates a non-mutating operation, and the description reinforces this with 'without executing it'. It adds context about what is being checked (signed mandate, current lifecycle, single-use action grant) that goes beyond the annotation. It does not mention return formats or error behavior, but given the annotation coverage, the transparency is strong.

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, well-structured sentence that front-loads the verb and includes the critical qualifier 'without executing it'. Every word earns its place, with no redundant or extraneous 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?

The tool has high complexity (signed mandates, lifecycle, single-use grants) and sparse schema (3 object params, no descriptions, no output schema). The description gives a high-level overview but omits expected return values, failure modes, and what 'current lifecycle' refers to. Given the annotations only cover read-only safety, the description is minimally viable but not fully complete for complex 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?

With 0% schema description coverage, the description must compensate, and it does partially by naming the three inputs: 'an exact action' maps to the action parameter, 'signed mandate' to signed_mandate, and 'single-use action grant' to signed_action_grant. However, it does not explain the structure of these object parameters or the meaning of 'current lifecycle' (which is not a parameter), leaving significant ambiguity for an agent.

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 tool's function with a specific verb ('Check') and identifies the resources involved ('an exact action', 'signed mandate', 'current lifecycle', 'single-use action grant'). It also distinguishes itself from related tools like execute_delegated_action by explicitly noting it does not execute the action.

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 clearly implies the tool is for evaluating an action before execution, providing context for when to use it. It does not explicitly name alternative tools or exclusion criteria, but the phrase 'without executing it' effectively contrasts with execution tools in the sibling list, giving reasonable usage 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?

The annotation readOnlyHint=false already indicates a write, and the description adds that this is a credential-bound write requiring specific authorization artifacts. It does not explain failure behavior, whether the single-use grant is consumed, or any side effects, so the added transparency is moderate.

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 that front-loads the core action and preconditions. Every word contributes meaning, with no filler or redundancy.

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

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

For a tool with five object parameters, no output schema, and minimal annotations, the description leaves major gaps: it does not explain the purpose or structure of action, work_order, or commerce_proof, nor the response format or error cases. The security prerequisites are helpful but not enough 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?

Schema description coverage is 0%, so the description must compensate. It only hints at two parameters (signed_mandate and signed_action_grant) via 'signed mandate' and 'single-use action grant', but leaves action, work_order, and commerce_proof entirely unexplained. This is insufficient for five parameters.

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 tool as executing a credential-bound write operation that requires validation of a signed mandate and a single-use action grant. This distinguishes it from generic execute tools by specifying the security prerequisites, though the term 'delegated action' is only in the title, not the description.

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 after validating...' implies the tool must not be used until the signed mandate and action grant are validated, providing a usage condition. However, it does not mention alternative tools or explicitly state when not to use this tool, so guidance is 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?

Annotations only provide readOnlyHint=false, which is consistent with 'create record'. However, the description discloses no side effects, auth requirements, or creation behavior beyond what annotations already imply. It adds minimal 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 concise sentence with no filler. It is front-loaded and directly states the action and object, making efficient use of space.

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 (1 optional param, no output schema) and minimal annotations, the description leaves significant gaps: no usage context, no parameter explanation, and no hint of what a successful execution returns or how it integrates with sibling directory tools.

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

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

The schema has one parameter with 0% description coverage, and the description only says 'target-specific', which vaguely hints at submission_target but does not explain its format, allowed values, defaults, or required vs optional nature. The parameter semantics are largely unexplained.

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

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

The description states 'Create target-specific directory submission record' with a clear verb and resource. It distinguishes somewhat from siblings like 'adapt_directory_submission' by emphasizing record creation, but the tool name says 'execute' while description says 'create', introducing slight ambiguity.

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 alternatives such as adapt_directory_submission or run_directory_submission_adapter. The description provides no context, 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 adds the phrase 'target-specific' which hints at parameter scoping, but does not disclose whether this tool actually performs an external submission or merely creates record entries. It aligns with readOnlyHint=false but offers no additional behavioral details such as side effects, idempotency, or prerequisites.

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, which is concise, but it is under-specified rather than efficiently complete. It lacks the necessary detail to be useful, so the brevity does not contribute to clarity.

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 write tool with three undocumented parameters and no output schema, a one-sentence description is grossly inadequate. It omits key information about how the run executes, what the records contain, how 'live_submit' influences behavior, and how this relates to directory submission workflows.

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?

With 0% schema coverage, the description carries the full burden of explaining parameters, but it fails entirely to describe 'live_submit', 'target_endpoint', or 'submission_target'. The vague phrase 'target-specific' only indirectly references the endpoint-related parameters, providing no meaningful semantic value.

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

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

The description uses a specific verb 'Create' and names two resources: 'target-specific registry submission' and 'directory status records' which clarifies the tool's function. However, it does not distinguish this from closely named siblings like 'execute_directory_submission' or 'update_directory_status_record', leaving some ambiguity about its unique role.

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 versus alternatives. It does not mention any preconditions, intended scenarios, or exclusions, leaving the agent without context for selection among the many sibling 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?

readOnlyHint=false already signals a write operation, but the description does not disclose important behavioral traits such as financial impact (it is a 'paid' run), idempotency considerations (an idempotency_key parameter exists), or irreversible side effects. The phases listed add some context, but for a high-stakes financial mutation tool, much more transparency is expected.

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, front-loaded with the verb, and contains no filler words. It is concise, though arguably too terse to fully carry the meaning of a complex paid production run.

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 no output schema and no parameter descriptions, yet the description omits return values, error conditions, idempotency behavior, and financial implications. For a complex, paid, multi-phase operation, this is insufficient context for an agent to invoke it correctly and safely.

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 explain any of the four parameters. The rail_key enum values are self-explanatory, but idempotency_key, payment_reference, and movement_amount_units are undefined. The relationship to 'quote, package, receipt, verification' is only implicit, requiring the agent to guess.

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 ('Execute') and the object ('proof run' / paid production run) and outlines the process phases (quote, package, receipt, verification). However, it does not explicitly differentiate this from sibling run/payment tools, and the term 'proof run' is ambiguous compared to the title's 'paid production run'.

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 on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing rail_key or payment_reference) or exclusions, and no alternative tools are named. The user must infer usage from the phrase 'Execute proof run...'.

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 annotation readOnlyHint=true already indicates a safe read operation, but the description adds no behavioral details such as return format, error handling, or permissions. It merely restates the tool's action without additional 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 extremely short (5 words), which might seem concise, but it omits essential information about parameters and usage, making it under-specified rather than efficiently concise.

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 2 params, no output schema, and no param descriptions, this description is severely lacking. It provides no information about what the return package contract or hash represents, how to call it, or what to expect in response.

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 rail_key or return_package_id, leaving their purpose and required values unexplained. The enum for rail_key is present in the schema but not elaborated.

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 tool returns 'package contract and hash,' which clearly identifies the operation as fetching a return package's contract and hash. However, it does not differentiate from sibling fetch/read tools and uses the ambiguous term 'package contract.'

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

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

The description offers no guidance on when to use this tool, prerequisites, or alternatives. It is a single sentence with no contextual instructions.

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

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

Annotations declare readOnlyHint=true, and the description adds the further nuance that discovery does not authorize execution. This goes beyond the annotation by clarifying the tool's non-authoritative role, which is valuable behavioral context. No contradiction exists.

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 immediately states the action and scope, then adds a critical caveat. Every word earns its place, with no redundancy or filler.

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

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

Given the tool has 4 parameters (all optional) and no output schema, the description is too brief. It omits any mention of return behavior, result format, or parameter interactions (e.g., does include_registry default to true?). The minimal caveat is useful, but it leaves significant gaps for a discovery tool that is likely used in multi-step workflows.

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 'capability' as a search dimension. It does not explain the purpose or expected format of limit, query, include_registry, or capability, leaving the agent to infer their meanings from parameter names alone. This fails to compensate for the lack of schema 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 states the tool's function: searching Wever Labs first-party services and the official MCP Registry by capability. This distinguishes it from siblings like inspect_service (inspecting a specific service) and run_service (executing a service), making the 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 'Discovery does not authorize execution' provides implicit guidance that this is for discovery, not execution, implying users should use a separate tool to execute. However, it does not explicitly name alternatives or state when to prefer this over, e.g., inspect_service. The usage context is clear but not fully 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?

Annotations already declare readOnlyHint=true, and the description adds that it returns 'all' active rails with required fields, clarifying scope. However, it doesn't disclose potential overhead, ordering, or any limitations beyond the annotation, which is acceptable for a simple getter but not richly 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?

One short sentence, front-loaded with the verb and resource, with no filler. Perfectly sized for the tool's simplicity.

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 is simple with no params and a readOnly annotation, so the description is mostly adequate. However, since there is no output schema, the description could be more explicit about the structure of the returned catalog—e.g., what fields are considered 'required fields'—to fully guide the agent.

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?

Tool has zero parameters, and the schema covers 100% of parameter space (empty). The description's mention of 'all active rails' reinforces that no filtering exists, aligning with the baseline of 4 for parameterless tools.

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?

Description uses the specific verb 'Return' and identifies the resource 'all active rails' plus 'required fields', making its purpose clear. However, the sibling tool 'list_rails' suggests a potentially overlapping function, and the description doesn't explicitly differentiate the catalog from a simple listing.

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 alternatives like 'list_rails' or 'find_services'. The description simply states what it does without context 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 readOnlyHint annotation already signals that this is a read-only operation, so the description adds no additional behavioral context such as output format, pagination, or side effects. It neither contradicts the annotation nor provides meaningful behavioral detail beyond the stated return value.

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 concise sentence with no wasted words, and it is front-loaded with the action. However, the ambiguous 'movement fee trigger' phrase slightly detracts from the clarity that conciseness should provide.

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

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

With no output schema, the description must clarify the return value, but it only names two vague entities without explaining their structure or meaning. The tool has no parameters and is read-only, but the description still leaves substantial ambiguity about what the caller receives.

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, so the schema is fully complete and there is nothing for the description to clarify. The baseline of 4 applies because no parameter information is needed.

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 ('Return') and names resources ('zero-cost tools and movement fee trigger'), but the phrase 'movement fee trigger' is vague and unexplained. It does not distinguish this from sibling tools like get_movement_fee_schedule or get_tool_costs, and its purpose is only partially 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?

There is no explicit guidance on when to use this tool versus alternatives, and no mention of exclusions or preferred contexts. The description only implies a use case for retrieving zero-cost tools, leaving the agent to infer applicability.

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 readOnlyHint annotation already signals safe read-only behavior, and the description is consistent with that. It adds minimal context (transaction/escrow scope) but does not disclose optional parameters, return format, or other behavioral nuances.

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 or redundant content. Every word contributes to stating the tool's core purpose.

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

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

There is no output schema, so the description should offer some detail about return values or how the fee schedule is represented, but it does not. It also fails to explain optional parameters, hybrid movement type, or relationship to quote_movement_fee.

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 almost no parameter-level meaning. It clarifies that the schedule covers transaction and escrow movement types (partially addressing movement_type), but rail_key and movement_amount_units remain entirely unexplained.

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

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

The description uses a specific verb ('Return') and resource ('movement fee schedule') with a scope ('transaction and escrow'), clearly indicating what the tool does. It is distinguishable from most siblings, though it does not explicitly differentiate from quote_movement_fee.

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 on when to use this tool versus alternatives like quote_movement_fee or get_tool_costs. The description states only the tool's function, leaving the agent without context for selecting it.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds no extra behavioral context such as error handling, return format, or side effects, adding no value beyond the annotations.

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 that is front-loaded with the verb and resource. It is appropriately concise with no wasted words, though it may be too brief for full clarity.

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 lack of output schema, parameter descriptions, and usage guidance, the description is insufficient for an agent to fully understand the tool. It only states the basic action, omitting details about input and expected output.

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

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

The schema has one parameter (production_run_id) with no description, and schema coverage is 0%. The description does not mention the parameter at all, making it impossible for the agent to know how to use it beyond guessing from the name.

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 ('Return') and resource ('run state'), making the tool's purpose clear. However, it lacks differentiation from sibling tools like read_* functions, though the name itself is fairly distinctive.

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 versus alternatives. There is no mention of use cases, prerequisites, or exclusions, leaving the agent without any context for selection.

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

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

Annotations already declare readOnlyHint: true, so the read-only nature is covered. The description adds that the tool returns policy information, but does not disclose any additional behavioral traits (e.g., whether results vary by inputs, pagination, or default behavior). It is not contradictory to annotations, so a mid-range score is appropriate.

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 concise sentence that front-loads the verb 'Return'. It contains no fluff and earns its place, making it efficiently scannable for an AI agent.

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 3 parameters, no output schema, and zero parameter documentation. A one-sentence description that merely states what is returned is inadequate for the agent to invoke the tool correctly, especially given the existence of overlapping siblings. The description does not clarify how inputs affect results or what the response will contain.

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?

With schema description coverage at 0%, the description must compensate for undocumented parameters. It fails to explain rail_key, movement_type, or movement_amount_units, leaving their roles entirely ambiguous. The description's mention of 'zero tool access cost and movement fee policy' does not map to any of the three parameters.

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 'Return zero tool access cost and movement fee policy' clearly states the tool's action (return) and resource (zero tool access cost and movement fee policy). It is specific enough to suggest a read-only query about fee/cost policies, though the phrasing is slightly ambiguous and does not strongly differentiate from siblings like get_movement_fee_schedule.

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 on when to use this tool versus alternatives such as quote_movement_fee or get_movement_fee_schedule. There are no exclusions, prerequisites, or contextual hints, leaving the agent without direction on selecting this tool over its 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 annotations declaring readOnlyHint=true, the safety profile is already known. The description adds a bit of behavioral context by mentioning 'verified' and 'durable lifecycle state', implying validity checks and state retrieval. However, it does not disclose behavior when inputs are invalid or how the two parameters interact, leaving some ambiguity.

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, concise sentence that front-loads the primary purpose. Every word contributes meaning, and there is no filler or redundancy. It is appropriately sized for the tool's simplicity.

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 output schema, an unannotated nested object, and low schema coverage, the description needs to provide more context about expected inputs, outputs, and behavior. It does not explain what 'durable lifecycle state' entails, how to specify the mandate (by ID or signed object), or what a typical response looks like. This leaves significant gaps for an agent 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?

The schema has zero description coverage for both parameters (mandate_id and signed_mandate), and the tool description does not explain how these parameters are used or their relationship to the 'credential-bound agent or authorized operator'. The description fails to compensate for the lack of schema-level 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 ('Return') and names the resource ('verified mandate and durable lifecycle state'). It clearly indicates the tool's return value and references the credential-bound agent or authorized operator. However, it does not explicitly distinguish this from similar sibling tools like read_delegated_authority, so it misses the differentiation criterion.

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, no exclusions, and no mention of prerequisites. In the context of many sibling tools related to authority and delegation, the description provides no usage context or decision support.

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 readOnlyHint annotation already establishes safety; the description adds the specific boundary constraints, which is helpful context. However, it does not disclose return behavior, failure semantics, or whether both parameters are needed. No contradiction with annotations.

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

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

One clean sentence with no filler; it is front-loaded with the action and resource. Some jargon ('Resolver v1') is unexplained but not 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?

With no output schema and only readOnlyHint annotation, the description must carry more weight. It explains the evaluation criteria but not the returned result, prerequisites, or how candidate vs service_id relate, making it incomplete for a 2-param 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?

The schema has 0% description coverage and neither 'candidate' nor 'service_id' is explained in the description. The term 'service candidate' loosely hints at the first parameter but service_id is unaddressed, leaving the agent to guess inputs.

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 'Evaluate' and names the resource 'service candidate' plus the evaluation criteria (Resolver v1 HTTPS, free, public-data, read-only boundary). This clearly differentiates it from sibling tools like run_service or find_services.

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 instead of alternatives such as run_service, find_services, or request_service_use. The description only states what it does, not under what circumstances it should be chosen.

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 states the basic issuing action, consistent with the readOnlyHint=false annotation. However, it adds no details about side effects, persistence, permissions, or return values, providing no behavioral insight beyond the annotation's minimal signal.

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, concise sentence with no wasted words. However, it is under-specified; brevity comes at the expense of essential contextual structure, making it less useful than it could be.

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

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

With 3 parameters, no schema descriptions, no output schema, and a large set of sibling tools, this one-sentence description is severely inadequate. It provides no guidance on parameter semantics, return values, or use cases, leaving the agent to guess.

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 any parameters. The agent must rely on parameter names alone ('scopes', 'agent_id', 'allowed_rails'), which is insufficient for correct invocation.

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 ('issue') and object ('scoped credential envelope'), which goes beyond a mere tautology. However, it does not explain what a 'credential envelope' is or how it differs from related tools like 'register_issued_credential', leaving the purpose only partially 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?

No guidance is provided about when to use this tool, what prerequisites exist, or how it relates to alternatives such as 'enforce_agent_credential' or 'register_issued_credential'. The description offers no decision-making support.

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 include readOnlyHint: true, and the description's 'Return' is consistent with that. However, the description adds no additional behavioral context beyond the annotation, such as what constitutes 'active' or whether results are paginated. With the annotation covering the read-only nature, a neutral score is appropriate.

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, free of filler, and immediately states the action and resource. It is perfectly concise for a zero-parameter read-only tool.

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 tool with no parameters and no output schema, the description is adequate. It tells the agent what will be returned ('active rail contracts and movement fee schedule'), which is sufficient for basic invocation. Some ambiguity remains about the exact structure of the return, but given the low complexity, this is acceptable.

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, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema is trivially fully covered.

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 'Return' and identifies the resource as 'active rail contracts and movement fee schedule.' This clearly states what the tool does, though it does not explicitly differentiate from siblings like get_active_rail_catalog or get_movement_fee_schedule.

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 on when to use this tool versus alternatives. The description does not mention any conditions, exclusions, or alternative 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?

Annotations already declare readOnlyHint=false, and the description's 'Persist' is consistent, so no contradiction. The description adds the release-gate framing, but it does not disclose behavioral details such as idempotency, overwriting behavior, or side effects. With annotations present, the bar is lower, and the description provides marginal additional 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 fluff. It is appropriately concise and front-loaded with the main action and purpose.

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 three undocumented parameters, no output schema, and many related siblings, a one-line description is inadequate. It lacks information on return values, when to use it, prerequisites, and how it fits into the release-gate workflow.

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 mentions none of the three parameters (rail_count, passed_count, benchmark_hash). It provides no semantic meaning beyond the raw property names, which is insufficient for correct invocation, especially since no parameters are required but all are relevant.

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 ('Persist') on a specific resource ('multi-agent benchmark record') with a clear purpose ('as a release gate'). It distinguishes from siblings like run_multi_agent_rail_benchmark (which runs benchmarks) and store_regression_report (which stores reports), though not explicitly.

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

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

No guidance on when to use this tool versus alternatives. The phrase 'release gate' implies context, but it does not specify prerequisites, when to call it (e.g., after a benchmark run), or what distinguishes it from store_regression_report or run_release_gate_automation.

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 declare readOnlyHint=false, consistent with 'persist CI badge status' indicating a write operation. The description adds that the tool returns a smoke workflow, but does not disclose details about what persistence entails (e.g., target system, side effects, 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 sentence of nine words, front-loading the action. It is concise with no filler, though its brevity contributes to ambiguity in the parameter semantics.

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 no output schema, no parameter descriptions, and only one annotation (readOnlyHint=false). The description fails to specify what the returned workflow looks like, what data is persisted, or any prerequisites, making it 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?

Schema coverage is 0% with three parameters (repo_name, release_version, transcript_hash) lacking descriptions. The description does not explain how any of these parameters affect the tool's behavior, leaving the agent without necessary input 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 specifies a concrete action: return a GitHub Actions smoke workflow and persist CI badge status. This is distinct from sibling tools like run_release_gate_automation (which runs the workflow) and build_public_agent_client_repo (which builds the repository), making the purpose 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?

No usage guidance is provided. The description does not state when to use this tool over alternatives, nor any prerequisites or exclusion conditions.

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 readOnlyHint=false, the description adds value by revealing the multi-step process (evaluate, persist, publish), which goes beyond the simple annotation. However, it does not disclose potential side effects, authorization needs, failure behavior, or idempotency, so the transparency is only partial.

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 efficiently communicates the tool's core action without unnecessary words. It is highly concise while still conveying the sequence of operations.

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, nested objects, no output schema), the description is too sparse. It does not explain return values, error conditions, or the effect of publish_to_feed, and it lacks context about how this tool fits into the broader workflow with siblings.

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

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

Schema coverage is 0%, yet the description does not compensate for the lack of parameter explanations. It only vaguely references the return package and verification requirements, without describing the meaning or expected format of mandate, agent_id, asset_id, asset_ticker, mission_type, or publish_to_feed.

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 tool evaluates, persists, and publishes a proof record, with a specific resource (credential-bound agent return package). However, it doesn't explicitly distinguish itself from the sibling tool evaluate_agent_commerce_proof, which likely performs the evaluation step alone.

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 on when to use this tool versus alternatives. The condition 'when all verification requirements pass' implies a prerequisite, but there is no mention of preferred usage context or exclusions, especially given many related sibling tools like evaluate_agent_commerce_proof and fetch_return_package.

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 readOnlyHint annotation already covers the safety profile, and the description is consistent with it. However, the description adds no additional behavioral context such as whether the fee is computed dynamically, requires authentication, or how invalid inputs are handled.

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 a front-loaded verb and no unnecessary words. It is appropriately sized 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?

With no output schema, the description should explain what the returned fee looks like, but it only says 'Return fee.' It omits return format, currency, precision, and how rail_key affects the quote. This leaves a significant gap for an agent invoking 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%, and the description only mentions 'movement amount and type,' leaving the rail_key parameter unexplained. The schema provides enums for rail_key and movement_type, but movement_amount_units lacks units or context. The description does not sufficiently compensate for the low schema 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 uses a specific verb 'Return' + resource 'fee' and identifies the key inputs (movement amount and type). It is clear and concise, but it doesn't explicitly differentiate this from sibling get_movement_fee_schedule, which might also return fee-related data.

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 usage when a fee for a movement is needed, but provides no explicit guidance on when to use this tool versus alternatives like get_movement_fee_schedule or quote_run. No exclusions or when-not scenarios are mentioned.

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 readOnlyHint annotation already indicates this is a safe read operation. The description adds the specific return fields but does not explain what these fields mean, whether a calculation is performed, or any other behavioral traits. It adds minimal context beyond the annotation.

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 concise sentence that is front-loaded with the action 'Return' and the list of fields. It is efficient and to the point, though it could be more informative while remaining concise.

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 three optional parameters, no output schema, and only a readOnlyHint. The description provides none of the missing context: it does not explain what a rail run is, what the units represent, how the parameters influence the result, or the meaning of the return fields. It is not complete enough for an agent to use confidently.

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 zero description coverage and none of the three parameters (rail_key, movement_type, movement_amount_units) are mentioned in the description. The description does not compensate for the missing schema information; it only lists output fields, not input parameters or how they affect the quote.

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 'Return tool_access_units, movement_fee_units, total_units, currency, and return fields,' which names specific output fields but does not clearly explain that this tool quotes a rail run or computes pricing. It is more a list of return values than a statement of purpose, and it does not distinguish itself from sibling tools like quote_movement_fee or get_tool_costs.

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 description does not mention when a quote is needed, what scenarios it suits, or any exclusions. Sibling tools exist for similar purposes but the description provides no orientation.

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 readOnlyHint annotation is consistent with the description's 'Return' action, and the description adds useful context about the contents of the returned contract. However, it does not disclose additional behavioral traits such as response format, size, or any required prerequisites. With annotations covering the read-only safety aspect, this is adequate but not exceptional.

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, well-structured sentence that front-loads the action ('Return the machine contract') and efficiently lists the components covered. No words are wasted, and the length is appropriate for the tool's simplicity.

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

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

For a zero-parameter read tool with no output schema, the description states what is returned but leaves the term 'machine contract' undefined. The enumeration of phases provides some context, but an agent may not know the structure, format, or purpose of the contract without more detail. The description is minimally sufficient but lacks depth.

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, so the description does not need to explain parameter semantics. According to the rubric, a baseline of 4 applies when there are no parameters, and the description does not conflict with this. No additional parameter information is needed.

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 'Return' with a clear resource ('the machine contract') and enumerates the process phases it covers (discovery, quote, payment, run, return package, receipt proof). This distinguishes it from sibling tools that start or complete runs. However, the term 'machine contract' is somewhat ambiguous, preventing a perfect score.

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 this tool versus alternatives such as start_agent_self_serve_paid_rail_loop or complete_agent_self_serve_paid_rail_run. It does not mention any exclusions, prerequisites, or preferred contexts, leaving the agent to infer usage 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?

The annotation readOnlyHint=true already signals safety, and the description adds the 'recent' scoping, which hints at a time-based filter. However, it does not disclose pagination, limit behavior, ordering, or what specific records are returned. Since annotations cover the read-only aspect, the bar is lower, but the description adds minimal extra value.

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 six words, front-loaded and with no filler. Every word contributes to the meaning, making it appropriately concise and 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 no output schema, so the description should provide at least some context about the returned records. 'Recent' is ambiguous regarding time window or count, and there is no mention of how records are ordered or what fields are included. However, given the simplicity of a zero-parameter read tool and the existing annotation, completeness is borderline adequate. A brief clarification of 'recent' or a link to related storage tools would improve it.

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?

There are zero parameters, so the baseline is 4 per the rubric. The schema coverage is 100% (vacuously) and the description adds no parameter information, which is acceptable since no parameters exist. The additionalProperties=true in the schema is not addressed, but that is not the description's responsibility.

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 verb 'Return' with the resource 'recent callback and receipt records,' which clearly states the tool's function. However, it does not differentiate from sibling tools like read_receipt_ledger or read_payment_settlement_records, so it lacks sibling distinction.

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 versus alternatives. It does not mention exclusions, prerequisites, or context such as 'use this for callback-specific receipts' vs. other receipt-reading tools. There is no indication of when not to use it.

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

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

Annotations already declare readOnlyHint true, so the agent knows it's a safe read. The description adds value by specifying exactly what the tool returns (supported tools, identity providers, rails, enforcement boundary), going beyond a bare 'read delegated authority'. No contradicting behavior is described.

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 is front-loaded with the verb and resource, and enumerates the return contents without any waste. Every word contributes 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?

For a zero-parameter read-only tool with no output schema, the description fully states what the tool does and what it returns. The list of included items gives complete context for an agent to select and 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 zero parameters, so the baseline is 4. The description adds no parameter details since there are none, but it doesn't need to; the absence of parameters is already clear from 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 'Return' and clearly identifies the resource: the Wever Labs Delegated Authority contract, plus the key components (supported tools, identity providers, rails, enforcement boundary). This distinguishes it from sibling read tools like read_callback_receipt_records or read_directory_status_console.

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 usage: use this when you need the delegated authority contract details. However, it does not explicitly state when to use it over alternatives like inspect_authority_mandate or execute_delegated_action, nor does it mention any exclusions or 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?

Annotations already mark readOnlyHint=true, so the safety profile is known. The description adds only the qualifier 'recent' without detailing ordering, limits, or return structure, providing minimal extra 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?

A single sentence with no wasted words, front-loading the core purpose. It is appropriately sized for the tool's simplicity.

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

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

The description is minimal but adequate for a read-only tool with no parameters and no output schema, given the readOnlyHint annotation. However, 'recent' and 'directory status records' lack definition, leaving some ambiguity about the return content and scope.

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?

With zero parameters defined and schema coverage trivially 100%, the description need not explain parameters. additionalProperties=true is not mentioned, but the absence of parameters makes this acceptable.

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 'Return' and a clear resource 'directory status records', which distinguishes it from sibling write tools like update_directory_status_record. It effectively states what the tool does.

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 versus other sibling read tools (e.g., read_recent_regressions, read_live_supabase_verification). It lacks context for selecting among similar read_* 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?

Annotations already declare readOnlyHint=true, which is consistent with the description's 'Return' wording. The description adds minimal context by specifying 'recent' and 'live', but it does not disclose details such as pagination, record limits, or whether results are ephemeral. It does not contradict the annotations.

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 redundant words. Every word contributes to conveying the tool's purpose 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 tool's simplicity (no parameters, no output schema, readOnly annotation), the description is minimally adequate. However, it lacks information about what constitutes a 'verification record' or whether 'recent' implies a limit. The description does not mention return format or any limitations, leaving room for ambiguity about the exact data returned.

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, so the baseline for parameter semantics is 4. The description does not need to explain parameters since none exist; the schema's empty properties and additionalProperties:true leave no ambiguity. The description's mention of 'recent' and 'live' gives some context but doesn't introduce parameter-like behavior.

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 ('Return') and the resource ('recent live Supabase verification records'), making the tool's purpose immediately understandable. While it doesn't explicitly contrast with sibling tools like 'run_live_supabase_verification', the 'read' prefix and readOnlyHint help differentiate it from mutation/execution variants.

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 versus alternatives (e.g., 'run_live_supabase_verification' or 'verify_live_registry_listing'). There is no mention of prerequisites, intended context, or scenarios where this tool is preferred over others.

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 readOnlyHint annotation already declares this is a read operation, and the description is consistent. However, it adds minimal behavioral context beyond the resource scope, such as what 'recent' means or any filtering/sorting behavior. It doesn't contradict the annotation.

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, concise sentence that is front-loaded with the action and resource. Every word provides value; no waste.

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 read tool with no parameters and no output schema, the description is adequate but not complete. It states what is returned (recent Stripe movement fee payment event records) but does not clarify the meaning of 'recent' or describe the record fields, which could be ambiguous for an agent. Given the lack of output schema, more detail would be helpful.

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, so the description correctly avoids parameter details. The schema has no properties, and with 0 params, the baseline of 4 applies. There is nothing more to add.

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 ('Return') and a specific resource ('recent Stripe movement fee payment event records'). It clearly identifies this tool as reading Stripe movement fee payment events, distinguishing it from sibling tools like read_receipt_ledger or read_callback_receipt_records.

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 on when to use this tool versus alternatives, nor any exclusions. The description only states what it does, leaving the agent to infer usage context from the tool name and 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?

Annotations declare readOnlyHint=true, and the description 'Return recent receipt ledger entries' is consistent with a read operation. The description adds the 'recent' scope but does not define what 'recent' means or describe pagination or return structure. With annotations covering the safety profile, this is adequate but not rich.

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 with no wasted words. It is front-loaded with the action and resource, achieving maximum conciseness.

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

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

With no output schema, the description should explain return values but does not, leaving the structure of 'receipt ledger entries' undefined. 'Recent' is also vague. However, the tool has no parameters and the readOnlyHint annotation reduces complexity, so it is minimally adequate but with clear 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?

The input schema has zero parameters, so schema coverage is trivially 100%. The description does not need to explain parameters, and the baseline for zero parameters is 4. The description adds the 'recent' behavioral scope, but no parameter semantics are required.

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

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

The description 'Return recent receipt ledger entries' has a specific verb ('return') and resource ('receipt ledger entries'), with a scope ('recent'). It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools like read_callback_receipt_records or read_payment_settlement_records, so it misses the top score for 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?

There is no guidance on when to use this tool versus alternatives. The description does not mention any exclusions or refer to sibling tools, leaving the context implied at best. Given the large sibling set, explicit usage guidance would be valuable, but it is absent.

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

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

Annotations already declare readOnlyHint=true, and the description adds the source context ('stored or sandbox'), which clarifies that this reads existing history rather than generating it. It does not explain what 'sandbox' means or describe the return format, but the annotation covers the safety profile.

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 conveys the action and object efficiently, every word earning its place.

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

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

For a simple read-only tool with no parameters, the description is mostly adequate, but 'stored or sandbox' is under-specified and there is no output schema to clarify what the returned history contains. It is minimally viable but leaves ambiguity about the data source and shape.

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 is empty with 100% coverage, so no parameter-level semantics are needed. The baseline score of 4 applies because there is nothing for the description to add.

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 ('Return') and names the resource ('stored or sandbox regression history'), making the core purpose clear. It distinguishes from write/run siblings like store_regression_report and run_synthetic_agent_regression, though 'stored or sandbox' is slightly ambiguous.

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, no exclusions, and no mention of how it relates to run_synthetic_agent_regression or store_regression_report. The context implies a retrieval use case but does not explicitly state it.

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

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

Annotations already provide readOnlyHint=true, and the description adds meaningful selection behavior: credential-bound, receipt-verified, and opted-in to public publication. It does not contradict the read-only annotation, though it omits return format or pagination details.

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

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

A single, front-loaded sentence precisely states the tool's function and scope with no filler or redundant text.

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, zero-parameter, read-only tool without an output schema, the description sufficiently identifies what is returned and the governing constraints. It does not describe output shape or pagination, but this is a minor gap given the tool's simplicity.

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 an empty schema, so the description carries the semantic burden. It effectively defines the implicit filter that would otherwise be parameters, adding value by specifying the exact criteria for returned items.

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 tool returns a specific resource: 'credential-bound, receipt-verified Commerce Proof missions' with a clear scope filter ('explicitly opted into public publication'). This distinguishes it from siblings like publish_verified_commerce_proof and read_receipt_ledger.

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 the tool (when needing public, verified commerce activity) but does not explicitly name alternatives or state when not to use it. The word 'only' clarifies the result set, not tool selection relative to sibling read 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?

Annotations declare readOnlyHint:false, and the description implies a mutation ('bind'), so there is no contradiction. However, the description adds no behavioral details beyond annotations—no mention of side effects, idempotency, required prior state, or what happens on failure. With minimal annotations, the description carries the burden and fails to disclose meaningful behavior.

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, concise sentence with no filler words. It is front-loaded with the verb and resource, making it easy to parse quickly. However, the extreme brevity sacrifices necessary context.

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 3 undocumented parameters, no output schema, and no usage guidance, the one-sentence description is insufficient. It does not explain what constitutes a receipt, how the 'binding' works, or what the return value is, leaving the agent with significant ambiguity.

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 'run' and 'package' parameters (production_run_id, return_package_id) but does not explicitly explain them or the total_units parameter. With no parameter descriptions in the schema, the description should compensate, but it falls short.

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 "Bind receipt to run and package" uses a specific verb (bind) and names the resource (receipt) and targets (run, package). This is clearer than a tautology and distinguishes from siblings like sign_receipt or verify_receipt, though the concept of 'receipt' remains underspecified.

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 on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or when not to use it, leaving the agent to infer usage from the name and 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?

Annotations already indicate readOnlyHint=false, and the description aligns with a write operation. The description adds some context about what is persisted (fingerprint, scopes, rails, expiration) but does not disclose important behaviors such as idempotency, overwrite semantics, or prerequisites beyond what annotations 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 one concise sentence that front-loads the action and key attributes. It is free of fluff and clearly communicates the core purpose, earning a top score.

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 sparse annotations, no output schema, and 0% parameter coverage, the description is insufficiently complete. It does not mention return values, error conditions, meaning of additional properties, or relationship to sibling tools, leaving a substantial gap for a write operation.

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

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

Schema coverage is 0%, so the description must compensate. It mentions 'fingerprint' which maps to key_fingerprint, and lists additional fields (scopes, allowed rails, expiration) that likely correspond to additionalProperties. However, it does not clarify the role of agent_id or the structure/format of the additional fields, leaving significant ambiguity.

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 'Persist' and identifies the resource as 'issued credential' with the specific fields (fingerprint, scopes, allowed rails, expiration). This clearly distinguishes it from siblings like 'issue_agent_credential' or 'enforce_agent_credential'.

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 the tool (when you have an issued credential to persist), but it does not explicitly state when to use it vs alternatives or provide exclusions. No mention of issue_agent_credential or other related tools, so usage guidance is only implied.

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 annotation readOnlyHint=true already establishes the read-only nature, so the description only needs to add context. It adds the specific return values and the policy reference ('Resolver v1 standing rules'), which gives useful behavioral context. However, it doesn't disclose any side effects, auth requirements, or external dependencies, leaving some 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 a single sentence, front-loaded with the core behavior and return values. It is highly concise and structured effectively. The brevity comes at the cost of important semantic detail, but for what it contains, every word earns its place.

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

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

Given the tool's complexity (nested candidate object, unclear task semantics, no output schema, no sibling differentiation), this description is incomplete. It doesn't explain what 'candidate' should include, what 'task' means, or how the output should be interpreted beyond the enum values. The reference to 'Resolver v1 standing rules' is 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?

The schema has 0% description coverage for its three parameters, so the description must compensate. It only implicitly references 'service' (likely service_id) but leaves 'task' and 'candidate' completely undefined. The properties are vague, and the description doesn't clarify their structure, purpose, or relationship to the standing rules.

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 'Return' and clearly identifies the resource ('a service under Resolver v1 standing rules') and the output domain (ALLOW/REQUIRE_HUMAN/DENY). This conveys the tool's core decision-making function. It doesn't explicitly contrast with sibling tools like run_service or evaluate_authority_action, but the unique return value set helps differentiate it.

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 versus alternatives, no prerequisites, exclusions, or contextual triggers. It simply states what it returns without explaining the decision-making context (e.g., when a service use request is being evaluated). No alternatives or exclusions are mentioned.

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 provides no behavioral details beyond the readOnlyHint annotation. It doesn't state that rotation invalidates the old version, requires any permissions, or has side effects. The annotation flags it as a write operation, but the description adds no additional transparency.

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, making it concise but under-specified. It could be more informative without losing conciseness, so it earns a 4 for brevity but not for 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?

The tool lacks an output schema and the description doesn't explain the return value's structure or behavior. Together with no parameter details and no usage context, the description is insufficient for an agent to invoke the tool 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 input schema has a single optional parameter, new_signing_version, but the description provides no explanation of its meaning, format, or what happens if omitted. With 0% schema coverage, the agent receives no guidance on parameter usage.

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 tool returns a new active signing version, which together with the name and title makes it clear that it rotates the signing secret and returns the newly activated version. However, it doesn't explicitly mention the rotation action in the description itself, making it slightly ambiguous whether it performs the rotation or merely retrieves the version.

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 on when to use this tool, prerequisites, or how it differs from sibling tools like sign_receipt or verify_signature_by_version. The description offers no context for selecting this 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?

The annotations provide readOnlyHint=false, indicating this may mutate state, but the description adds no further behavioral context. It does not explain side effects, required permissions, or what 'running through MCP proof path' implies. No explicit contradiction, but minimal value added.

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 structurally concise. However, it is under-specified to the point of being cryptic, sacrificing clarity for brevity.

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

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

There is no output schema, no parameter descriptions, and no explanation of terms like 'rail' or 'proof path'. Given the complexity implied by sibling tools and the lack of any supporting context, this description is grossly inadequate for selecting and invoking the tool 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% and the description does not mention rail_key or idempotency_key at all. The enum for rail_key and the meaning of idempotency_key remain completely unexplained, so the agent cannot correctly map inputs to their purpose.

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 'Run one rail through MCP proof path' provides a verb and resource, but 'rail' and 'proof path' are unexplained jargon. It does not distinguish this tool from sibling run tools like run_multi_agent_rail_benchmark or run_external_agent_invocation_test.

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, nor any prerequisites or context. The description stops at stating the action, leaving the agent without decision criteria.

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 annotation only provides readOnlyHint=false, which signals a write operation. The description adds meaningful behavioral context by stating it persists a signed result and routes material changes for review, which clarifies side effects and the review workflow. It does not contradict annotations.

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, dense sentence that places the primary verb first and lists all key actions without redundancy. Each phrase ('read', 'compare', 'persist', 'route') earns its place, making it highly concise and scannable.

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 is complex (autonomous research cycle, 2 params, additionalProperties, no output schema), yet the description provides only a high-level process summary. It omits input semantics, expected outputs or return values, idempotency behavior, and failure or exception handling, making it insufficient for reliable selection and 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 two parameters (asset_scope, idempotency_key) with 0% schema description coverage, and the description does not mention either parameter. It fails to explain what asset_scope should contain or how idempotency_key should be used, leaving the agent without guidance for correct invocation.

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 multi-step purpose: read the approved external market source, compare prior Atlas snapshot, persist a signed result, and route material changes for review. It specifies the resource ('Atlas research cycle') and the actions, distinguishing it from generic sibling tools like run_multi_agent_rail_benchmark or run_claude_evidence_analysis.

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 explicit when-to-use or when-not-to-use guidance is provided. The description implies it is the autonomous Atlas research cycle but does not state what conditions trigger it, what alternatives exist, or what prerequisites are required (e.g., an approved market source).

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 only says 'analyze' and 'return proof,' providing no information about side effects, external calls, or data modifications. The annotation readOnlyHint=false suggests potential writes, which conflicts with the read-only connotation of 'analyze,' though not explicitly contradicting.

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 with no filler. It is front-loaded with the action ('Use Claude...') and gets to the point quickly, though its brevity comes at the cost of essential 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?

With no output schema, minimal annotations, and zero parameter descriptions, the description is far too sparse. It does not explain the return value, side effects, parameter semantics, or even the concept of 'evidence packet context,' leaving the tool functionally opaque.

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 descriptions cover 0% of the 4 parameters, and the description does not mention any of them (packet_type, requested_outcome, required_evidence, available_evidence). The agent receives no hints on what these inputs mean or how to fill them, making correct invocation nearly impossible.

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 tool's purpose: using Claude inside Compliance EvidenceOps to analyze structured evidence packet context and return Wever Labs proof. This distinguishes it from siblings like run_claude_proof_relay by its focus on evidence analysis, though the meaning of 'Wever Labs proof' remains vague.

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 on when to use this tool versus the many sibling tools. It does not mention alternatives, prerequisites, or any conditions for use, leaving the agent to guess how it fits into a 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?

Annotations only include readOnlyHint: false, so the description must disclose behavioral traits. 'Bind' implies a write operation, but the description does not explain side effects on the various state stores (overwrite vs append), idempotency, failure modes, or required permissions. It adds minimal behavioral context beyond the annotation.

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 one concise sentence with no wasted words; it is front-loaded with the action verb. However, its brevity sacrifices essential detail, making it under-specified rather than effectively concise. Still, structurally it is tight and well-formed, earning a 4.

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—5 parameters including nested objects, no output schema, and sparse annotations—the description is extremely incomplete. It does not explain how parameters map to the target stores, what the expected outcome is, or any preconditions. It is far less complete than other tools like 'update_drive' that at least list fields.

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 5 parameters, and the description does not mention any parameter names or their meanings. It vaguely references 'Evidence Analysis output' which could relate to 'analysis_result', but no explicit mapping is given. The description adds virtually no value to the raw schema for parameter understanding.

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 tool's action ('Bind') and its resource ('Evidence Analysis output') with specific target stores (Receipt Passport, Agent Run Ledger, Proof Relay, Retry Manager). This is more specific than a tautology, but it does not differentiate itself from sibling tools like 'run_claude_evidence_analysis' or 'record_receipt', which also deal with evidence and receipts. Hence a 4.

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 versus alternatives such as 'run_claude_evidence_analysis' or 'store_receipt_ledger_entry'. There is no mention of prerequisites (e.g., run evidence analysis first), ordering, or exclusions. The single sentence merely states what it does, not when to use it.

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 only indicate readOnlyHint false; the description adds no clarification that this is a dry run (simulated vs actual execution), what side effects occur, or what output to expect. It does not disclose whether actions are actually executed or only validated, which is a key behavioral trait.

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 one short sentence that immediately states the purpose. It is front-loaded and contains no fluff, though it is terse to the point of under-specification.

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

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

For a tool with two untyped object parameters, no output schema, and only a boolean readOnlyHint, this description is too sparse. It fails to explain what the payloads contain, what the dry run does, how success is determined, or what the output looks like. The complexity demands more detail.

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?

There is 0% schema description coverage and no field descriptions. The description maps deny_payload and allow_payload to 'denied action' and 'allowed action', but gives no structure, required keys, or formats. It only minimally compensates 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 states a specific action ('run') and describes the payload (one allowed and one denied action) with a clear goal (prove scoped boundaries). However, it does not explicitly distinguish this dry run from related tools like enforce_agent_credential or credential_aware_mcp_write, so it is clear but not fully 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?

No guidance on when to use this tool versus alternatives is provided. It does not mention prerequisites, situations where it should be preferred, or exclusions. The implied use is to test credential scoping, but no explicit when/when-not context exists.

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 readOnlyHint annotation already discloses the read-only nature, and the description's 'Return' is consistent. The phrase 'target-specific' adds a small behavioral detail that the output varies based on the target, but it does not explain error behaviors, return format, or dependency on other state. No contradiction with annotations.

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, tightly worded sentence with no redundant information. It is appropriately front-loaded with the verb and directly communicates the core function, consisting of just five words with zero waste.

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?

Despite being a simple tool with one parameter and a read-only annotation, the description leaves significant gaps: it does not explain what a 'discovery payload' contains, what the 'submission_target' parameter represents, or when this tool is applicable. With no output schema, the agent cannot anticipate the return structure, and the absence of usage context makes it hard 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?

The schema has one parameter 'submission_target' with no description (0% coverage). The description uses 'target-specific' to indicate the parameter influences the payload, but this is minimal and largely restates the parameter name. It does not clarify what constitutes a valid target (e.g., URL, ID, name) or provide any format constraints, so the description fails to compensate for the missing schema 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 'Return target-specific discovery payload' clearly states the action (returning) and the resource (a discovery payload) with a scoping qualifier (target-specific). It distinguishes itself from siblings like 'execute_directory_submission' and 'adapt_directory_submission' by indicating a read-only payload retrieval rather than execution or adaptation.

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 versus alternatives like 'adapt_directory_submission' or 'build_external_discovery_submission_pack'. There are no explicit exclusions or contexts mentioned, leaving the agent to infer usage solely from the tool name.

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 annotation readOnlyHint=false already indicates a write operation, and the description's 'Record' agrees, so no contradiction. However, the description does not disclose side effects such as whether the event is durable, idempotent, auditable, or whether it updates existing ledger entries. 'Durable' appears in the tool name but is not explained in the description.

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 or repetition. It front-loads the core action, but conciseness here comes at the expense of necessary detail; still, as a standalone text 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?

The tool has 9 undocumented optional parameters, no output schema, and only a read-only flag to characterize behavior. The description does not explain return values, required parameter combinations, event types, or error conditions, making it insufficient for an agent to invoke correctly in most real scenarios.

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?

With schema description coverage at 0%, the description needed to meaningfully explain the 9 parameters. It does not: no parameter names or values are mentioned, and the partial list of activity types is insufficient to map to rail_key, event_type, proof_hash, receipt_id, etc. The schema itself also lacks descriptions, so the agent has no way to interpret the parameters.

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