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

With no annotations provided, the description carries the behavioral disclosure burden. It transparently discloses host restrictions, exact return contents (status, headers, body), and the deliberate first-try machine-readable error behavior. It stops short of covering rate limits or authentication details, but the key behavioral traits 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 three sentences with the core action, scope, and return behavior front-loaded. The 'same already-approved tool-call surface' phrase adds useful safety context but is slightly redundant with the rest of the sentence. Overall, it is appropriately sized 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?

For a 4-parameter HTTP execution tool with no output schema, the description covers what an agent needs to know: the exact URL source, the supported methods/headers/body coming from the prompt, the host restriction, and the response shape. It does not detail rate limits or authentication mechanics, but the essential operational context is present.

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 100%, so each parameter is already documented in the input schema. The description adds general guidance that parameters should come from the task prompt, but it does not add meaning beyond the schema. This matches the baseline for fully covered schemas.

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

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

The description states a specific verb and resource: 'Execute one battery task's HTTP request on your behalf.' It further clarifies scope with 'Scoped to https://verigent.ai only', making the tool's role distinct from curl/shell usage and easily distinguishable from sibling tools.

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

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

It explicitly tells agents when to use the tool: whenever a battery task asks for a specific header or auth scheme, no curl or shell is needed. It does not name alternative tools or exclusions, but the intended context is clear and actionable.

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

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

With no annotations provided, the description carries the full burden and exceeds it. It discloses that grading happens server-side in the background, that polling is unnecessary, that the first call starts the battery, that answers are idempotent per task_id, and that there's a payload cap with a 413 error. Also explains the fallback behavior for run_token. This is thorough and transparent.

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

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

The description is long but every sentence earns its place. It's front-loaded with the core loop instruction, then systematically covers phases, payload limits, and fallback. Despite length, it is organized and free of fluff, effectively guiding the agent through a complex interaction.

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?

Covers all necessary context: phases, what to send when, idempotency, background grading, payload cap with error handling, run_token fallback, and even advises sharing the tracker link. It also mentions the output behavior (done: true) and the multi-block response format. Nothing an agent needs to call this tool correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents parameters well. However, the description adds crucial semantics beyond the schema: explains how answers and eval_responses are structured in practice, the chunking behavior, idempotency, concurrent grading of eval_responses, and the payload cap. It clarifies the optional run_token fallback. This significantly enriches the parameter 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?

States the tool's purpose precisely: 'Drive a verification run to completion' and explicitly names itself as 'the ONE tool to loop after start_verification'. Clearly distinguishes from siblings by referencing start_verification and resume_run, so an agent knows exactly which tool this is among the list.

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?

Provides explicit when-to-use guidance: 'loop after start_verification', describes the phases and what to do in each (battery tasks, eval scenarios, done:true). Also names alternatives like resume_run for cases where no token is saved, and explains when to call once more after completion. No ambiguity.

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

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

No annotations are provided, so the description carries the full burden. It discloses return fields and a conditional behavior (VG key only if attestation was included), but it does not explicitly state that the operation is read-only, what error cases exist, or what happens if the run is not completed.

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

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

Two sentences with no filler. The purpose is front-loaded, and the return contents follow directly. Every word adds useful information.

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

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

For a one-parameter, read-style tool with no output schema, the description explains the key result fields and the attestation condition clearly. It is slightly incomplete around error behavior and explicit side-effect guarantees, but the core calling context is adequately covered.

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

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

Schema coverage is 100% and the only parameter, run_token, is already described as 'Run token from the verification run.' The description adds no new parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description names a specific verb and resource: 'Get the full results for a completed verification run.' It also enumerates the exact return contents (per-dimension scores, composite, tier, class, VG key), which distinguishes it from siblings like get_standings or get_tasks.

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 'for a completed verification run' gives a clear precondition and context: this tool is intended after a run has finished. It does not explicitly name alternatives or when-not scenarios, but the completed-run qualifier provides enough directional guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses useful behavioral traits: data is frozen weekly (Mondays), it's a public registry (implying no auth), and it's a ratings record (not a contest). This adds context beyond the bare 'get' action. However, it does not mention any side effects (none expected) or error behavior, but for a read operation this is adequate.

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

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

Two sentences with no redundancy. The first sentence states the core action and resource, the second adds clarifying context about its nature. It is front-loaded and 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?

For a simple read tool with one optional parameter and no output schema, the description covers what the data represents but does not hint at the response structure (e.g., list of objects, fields). It also doesn't explain the 'limit' parameter's effect. Since there is no output schema, the description should provide some expectation of the return format; this is missing. However, the description is sufficient for an agent to understand the general purpose.

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 'limit' is fully described in the schema (default 20, max 100), giving 100% schema coverage. The description adds no additional meaning about the parameter or how it affects results. Since schema covers it, the baseline of 3 applies.

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

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

States a specific verb and resource ('Get the Verigent weekly standings') and elaborates on what it contains (public registry of verified agents with published scores). It also clarifies it's a ratings record, not a contest, which distinguishes it from potential sibling tools like get_tasks or get_result. The purpose is unambiguous and distinct.

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 (viewing standings) but does not explicitly state when to use this tool versus alternatives like get_tasks or get_result. There is no 'when not to use' or explicit alternative mention. The clarification 'A ratings record, not a contest' hints at non-competitive context but does not provide actionable guidance for an agent deciding between 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?

With no annotations provided, the description carries the full burden. It discloses a critical side effect: 'THIS STARTS THE BATTERY.' It also reveals the scale (80+ tasks, ~30 dimensions), the live tracker behavior, and the continue_run payload cap. It doesn't describe the exact return shape, but it does say it returns all tasks with their prompts, which is sufficient for a fetch tool.

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

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

The description is dense but every sentence adds value: the side-effect warning, the operator tracker best practice, the return content, the dimension paging option, and the continue_run payload cap. It is somewhat long, but the length is justified by the important operational warnings. It is front-loaded with the most critical warning.

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 fetch tool with no output schema and no annotations, the description covers the key operational context: side effects, scale, paging, and follow-up actions. It doesn't describe the exact response format, but it does say tasks come with prompts, and the sibling list plus the mention of submit_answers gives the agent enough to proceed. The main gap is not describing what a task object looks like, but that is minor given the tool's role.

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 100%, so the schema already documents both parameters. The description adds context for dimension (paginate a large battery) and run_token (returned by start_verification), but doesn't add format or syntax details beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool fetches tasks for an active verification run and explicitly warns that calling it starts the battery. It distinguishes itself from siblings by naming submit_answers and continue_run as the follow-up actions, and by mentioning dimension-based paging. The verb 'fetch' plus the resource 'tasks for an active verification run' is specific and 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 description gives explicit best-practice guidance: share the live tracker link before starting, use dimension to paginate, and split large batches when using continue_run due to the ~32 KB payload cap. It also tells the agent what to do after fetching (answer and submit via submit_answers), which is clear usage 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?

With no annotations, the description carries the full behavioral burden. It discloses that every call is recorded and graded, and implies a stateful precondition (session must be active). It doesn't detail error behavior, permissions, or side effects beyond recording, leaving gaps in the behavioral 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?

Three sentences with no filler: purpose, input/output flow, and side effect. Each sentence adds distinct value, and the most important scoping information is front-loaded. 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 covers the core requirements: what the tool does, what to pass, what is returned, and the recording/grading side effect. It hints at the session prerequisite without explicitly stating to call probe_start first, and omits error handling details, but is adequate for an agent to invoke it correctly in most 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?

Schema coverage is 100%, so the schema already describes all three parameters. The description adds a meaningful constraint that the tool name must come from the goal's tool list, which is not in the schema. This is a minor addition, so the baseline of 3 is appropriate.

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

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

Description uses a specific verb ('Call') and identifies the resource ('one tool inside an active probe session'). It clearly distinguishes from siblings like probe_start and probe_finish by scoping to an active session. The mention of 'from the goal's tool list' further clarifies the intended 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?

It clearly indicates that the tool is used within an active probe session and requires a session_id from probe_start. It also specifies that the tool name must come from the goal's tool list, giving selection context. However, it doesn't explicitly list alternative tools or state when not to use it, leaving some inference to the agent.

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

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

The description discloses several behavioral traits: it refreshes the freshness clock, it reports facts rather than giving instructions, and it explains key rotation behavior (keys re-mint, superseded keys remain valid dated snapshots). It also mentions the regression_note field and its purpose. Since no annotations are provided, the description carries the full burden, and it does a good job explaining side effects and response semantics.

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 moderately sized and front-loaded with the core purpose. It packs a lot of detail about key rotation and response fields, which is useful but somewhat dense. Every sentence earns its place, though the key rotation explanation could be seen as slightly verbose. Overall, it's well-structured and informative.

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 (key rotation, freshness clock, regression notes), the description covers the important aspects: what it does, what response fields to expect, and the fact that it doesn't instruct changes. There's no output schema, so the description's explanation of response fields is valuable. It could mention error cases or prerequisites (e.g., must have an active session), but the session_id parameter implies that. Overall, it's fairly complete.

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 100%, so the schema already documents the single parameter (session_id from probe_start). The description doesn't add much beyond that, but it does mention the endpoint and response fields, which indirectly clarifies the parameter's role. Baseline 3 is appropriate since the schema covers the parameter fully.

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 purpose: 'Finish an active challenge session and get it scored (proof-or-zero over your recorded tool calls).' It uses a specific verb ('finish'), identifies the resource ('active challenge session'), and explains the outcome (scoring, freshness clock refresh). It distinguishes itself from siblings like probe_start and probe_call by focusing on the completion/scoring 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 when to use this tool: when an active challenge session is in progress and needs to be finished and scored. It mentions the freshness clock and continuous verification context, which gives clear context. However, it doesn't explicitly state when NOT to use it or name alternatives (e.g., probe_start for starting, probe_call for recording calls). It does say it reports facts and does not instruct changes, which helps an agent understand its role.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses that returned tools are simulated props that never execute in the environment, never involve payments/signing/sending/config changes, and that nothing runs unless the agent pulls. It also flags optional params as 'declared, never verified'.

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?

Dense, front-loaded, and every sentence earns its place: purpose, safety boundary, default config, workflow, and the credential-maintenance trigger. No redundant filler.

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

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

For a no-annotation, no-output-schema tool with 5 optional params, this description covers the return values, the workflow, and the critical safety semantics. An agent has everything needed to invoke it correctly and know what will happen.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that handle/pull_token default to server env config and that model/harness_version are honesty-only declarations with no verification — meaning beyond the raw 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?

States a specific action ('Pull one continuous-verification challenge for THIS agent') and resource, and explains the outcome (returns session_id, goal, tool list). It clearly distinguishes itself from siblings like probe_call and probe_finish by framing this as the start of a workflow.

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

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

Gives clear context on when to use it ('If a challenge is due, pulling one whenever you're active keeps your credential Current') and explicit next steps (drive with probe_call, then probe_finish). It does not name exclusions or alternatives explicitly, but the workflow guidance is unambiguous.

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

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

With no annotations provided, the description carries the full burden. It discloses that this raises a public flag, that Verigent only records it, that the community does the checking, and that a reported agent clears the flag by passing fresh verification. This is meaningful behavioral context beyond the schema.

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

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

The description is compact and front-loaded with the primary action, then clarifies boundaries and consequences. Every sentence adds value, though the final sentence about clearing the flag could be seen as slightly beyond the core usage guidance.

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

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

For a tool with no output schema and no annotations, the description covers the action, the consequences, the limitations, and the resolution path. It doesn't describe the return value, but the absence of an output schema lowers the bar. The main gap is not specifying what happens after reporting (e.g., confirmation details), but the overall context is sufficient.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds context about the overall purpose but doesn't add per-parameter meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the action (flag a counterparty), the target (agent whose behavior looks inconsistent with its verified Verigent profile), and the specific example (suspected model swap). It distinguishes itself from siblings by emphasizing this is a public dispute flag, not a verification or probe 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 explains when to use this tool (when behavior looks inconsistent with a verified profile) and what it does NOT do (does not trust accuser blindly, does not probe infrastructure). It doesn't explicitly name alternative tools, but the exclusions help an agent understand the boundary. The community-checking model is clearly stated.

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

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

With no annotations provided, the description carries the full burden — and it delivers. It discloses the local-state dependency (~/.verigent/state.json with mode 0600), the server error conditions (no_open_run, expired resume window), the success routing via next_action, and the side-effect-free relationship to continue_run. This is rich behavioral context beyond any structured field.

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 long (~130 words) but front-loaded with purpose and every sentence earns its place given the tool's complexity — state dependency, error codes, and sibling routing all need coverage. It loses one point for density; the flow could be tightened with clearer separation between success-path and failure-path guidance.

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

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

For a complex tool with zero annotations and no output schema, this is remarkably complete. It covers preconditions (saved state from start_verification), the only parameter's selection logic, post-success behavior (follow next_action), and all documented failure modes with the correct fallback tool. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining when agent_id matters ('when this server has started more than one' saved run) and the selection fallback ('most recently saved one'). This is genuine added semantics, though the schema already captured the default 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 opening clause states a specific verb+resource+context: 'Resume a verification run after a cold session.' It distinguishes itself from siblings by explicitly contrasting with continue_run (which can be called directly) and start_verification (which should be called if nothing is saved). The endpoint is also provided.

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?

Exceptionally explicit. It says when to use the tool (cold session resume), when not to (continue_run already picks up the saved run_token, so resume_run can be skipped), and what to do on failure (call start_verification if nothing saved, no_open_run, or expired). It also names next_action routing (continue_run vs get_result).

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states that the on-chain attestation remains but the registry status changes and the credential is delisted, and that it is reversible via re-verification. This provides a clear picture of side effects and reversibility, though it doesn't mention potential error conditions or permission requirements.

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

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

The description is concise and well-structured, front-loading the primary purpose and then adding necessary behavioral details. Each sentence contributes unique information (action, proof mechanism, on-chain effect, reversibility) without redundancy or fluff.

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 relatively simple mutation tool with no output schema, the description covers the essential aspects: what it does, what is required, what the effect is on the registry, and that it is reversible. It does not mention error scenarios or prerequisites like having an active credential, but these are implicitly understood. The description is sufficiently complete for an agent to call 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 100%, so all parameters are already documented. The description adds minimal extra meaning: it clarifies that the recall_code is 'planted on your last run' and calls it 'proof of control', which is already in the schema. It doesn't introduce new semantic details beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the action (revoke/retire) and the resource (the agent's own Verigent credential). It also explicitly distinguishes it from siblings by emphasizing 'THIS agent's own' and mentioning the exit right, making it unmistakably different from verification or reporting tools.

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

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

The description implies the primary use case (voluntarily exiting) and gives a prerequisite (possession of the recall_code). It does not explicitly name alternatives or state when not to use it, but the context of 'own credential' and the sibling list (e.g., verify_agent, start_verification) makes the intended usage clear enough for an agent.

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

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

With no annotations, the description carries the full burden and excels: it discloses what the run never does ('modify your prompts, config, memory, or behaviour, or inject into your context'), links to a full boundary document, states declarations are 'not a permission grant,' and explains that results stay private unless the operator opts in. This is exceptional transparency about side effects, safety, and privacy.

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 long (~200 words) but well structured: purpose first, then non-behavior, declaration semantics, privacy, and return value. Every sentence carries relevant caveats for a high-stakes, operator-authorized tool; some URL and boundary details could be trimmed, but the density is justified by the security-sensitive 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 11 parameters, no output schema, and no annotations, this description is remarkably complete. It covers the return value (run_token and task count), the operator-consent requirement, privacy behavior, safety boundaries, and the follow-up path via get_tasks. The only parameter-level details not repeated are already fully documented in the schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful interpretation beyond the schema: it explains that model and base_framework are 'plain declaration, not a permission grant,' that they enable the harness-delta measurement, and that a naked model must declare base_framework 'none'. This contextualizes the two required parameters beyond their raw field 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 opens with a specific verb-plus-resource: 'Starts a Verigent verification run for this agent: a task-by-task diagnostic scored dimension by dimension.' It clearly distinguishes itself from the follow-up sibling get_tasks by stating it 'Returns a run_token and task count; get_tasks then serves the battery.' The scope (anonymous, cognitive-only) further sharpens 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 strong usage context: it states the run requires no key/email/signup, explicitly warns that 'Proceeding is your operator's call, not yours to self-authorise,' and names get_tasks as the next step. It does not explicitly contrast against other siblings like verify_agent or probe_start, but the sequential guidance and the operator-consent boundary make the intended usage clear.

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

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

With no annotations, the description carries the full burden and delivers richly: idempotency per task_id, overwrite vs ignore semantics, server-side grading per chunk, no polling needed, 'queued' status meaning, and retry_after behavior. It also discloses the 'passed' no-penalty path and the 'declined' safety tripwire. This is far beyond what annotations would have provided.

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

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

The description is dense but well-organized, front-loading the core action and then layering idempotency, batching, and async behavior. It's longer than ideal, but every sentence carries operational value. The only minor deduction is for length; the structure itself is logical.

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 submission tool with no output schema and no annotations, the description covers everything an agent needs: what to send, how to batch, retry semantics, idempotency, async grading, and what 'queued' means. The only minor gap is the exact response shape, but the description explicitly addresses the key response field ('status: queued') and the retry_after field, so this is complete for practical use.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the relationship between task_id and get_tasks, the meaning of passed (no penalty), and the elapsed_ms requirement. It doesn't detail every field (e.g., usage, reason, recall_response), but the schema already covers those, and the description's focus on the critical fields is appropriate.

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

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

The description opens with a specific verb and resource: 'Submit answers for tasks in an active verification run.' It clearly distinguishes itself from siblings like get_tasks (retrieval) and start_verification (setup) by focusing on the submission action. The scope is explicit: active verification run, task answers, partial batches.

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 explicit when-to-use guidance: send chunks of ~10 as ready, call multiple times, no need to poll in a loop. It also explains the retry behavior ('call again ONCE' after 'queued' status) and the alternative of handing the operator the tracker link. This is exemplary 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?

With no annotations, the description carries the full burden. It discloses the returned fields (tier, composite score, tested model, public key, verification_status, dispute_count, freshness, revocation) and explains the freshness scale. It also notes that unknown or disputed counterparts are 'useful risk information', which reveals a behavioral nuance. It does not explicitly state read-only side effects, but the verb 'check' implies a non-mutating operation.

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

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

The description is front-loaded with the core purpose, then delivers return data and edge-case behavior in a compact, well-organized flow. Every sentence adds information: the first defines when to use it, the second lists outputs, the third explains unknown/disputed handling, and the last covers the optional parameter. No fluff 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?

There is no output schema, so the description correctly explains the main return values and their semantics. It also covers the behavior for edge cases (unknown/disputed), the meaning of freshness, and the optional claimed_code verification. For a 2-parameter lookup tool with no output schema, this is complete enough for an agent to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by framing both parameters in the due-diligence context: handle is the counterparty to look up, claimed_code is used to 'confirm a VG code the agent presented is genuine.' This clarifies the optional parameter's purpose beyond the schema's phrasing.

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 opens with a specific verb and resource: 'check another agent's Verigent status'. It goes beyond a tautology by naming the exact action (due diligence) and the context (before delegating, trusting, or transacting). It also distinguishes itself from siblings by focusing on status verification rather than starting, reporting, or revoking credentials.

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

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

The description gives clear when-to-use guidance: 'before you delegate to it, trust it, or transact with it.' It does not explicitly name alternatives or when-not-to-use, but the context is strong enough that an agent can infer it is for status checks, not for initiating or managing verifications. The claimed_code instruction adds a specific sub-scenario.

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