agent-health

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

Annotations already declare readOnly=false and destructive=false; the description adds useful non-annotation context: challenges expire in 24 hours, owner key is required, and the returned value must be published in DNS before verification. This enriches agent understanding without contradicting 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?

Three short sentences each carry distinct information: purpose, required workflow, and expiration behavior. The most important action is front-loaded and there is 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 an output schema and only two parameters, so the description covers the high-level flow and expiry constraint. It is incomplete only in parameter semantics, and it does not explain what 'exact endpoint hostname' or the owner-key check entails, so a capable agent still needs to infer some details.

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

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

Schema description coverage is 0%, so the description must explain what agent_id and api_key mean. It only mentions 'Owner key required' and gives no guidance on where these values come from or how they relate to the challenge endpoint, leaving the agent to guess from parameter 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 opens with a specific action ('Issue/retrieve') and a clear resource ('DNS TXT challenge for your agent's exact endpoint hostname'), which distinguishes it from siblings like verify_agent_domain and agent_webhook_secret. It clearly communicates the tool's role in the domain-verification 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?

It states the required prerequisite ('Owner key required') and the follow-up step ('call verify_agent_domain'), giving concrete context for when to use this tool. It does not explicitly enumerate exclusions or alternative tools, but the workflow instruction is specific enough for most agents.

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 read/write openness, and the description adds concrete behavioral context: it performs two bounded HEAD/GET checks, operates on a DNS-verified endpoint, enforces a per-hour rate limit, and reports no score effect. The main unstated aspect is what happens if no previous assessment exists when consent=false, but this is minor given the output schema 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 brief, front-loaded, and every sentence carries meaningful information. It covers both consent modes, the rate limit, the operational scope, and explicitly disclaims audit/LLM-test functionality in two compact sentences.

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 essential behavioral modes, constraints, and exclusions, and an output schema exists to describe return values. However, it does not explain how agent_id and api_key are used or direct the agent to any alternative sibling tools when this tool is inappropriate. These gaps are moderate but not disabling.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It explains the consent parameter's true/false behavior, but agent_id and api_key are left completely unexplained. Their purpose may be inferable from names, but the description does not connect them to the DNS-verified endpoint or authentication context.

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

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

The description clearly identifies a specific verb and resource: "run two bounded HEAD/GET checks on your DNS-verified endpoint" or "read your last private result." It also distinguishes itself from audit/LLM tests by stating "Not an audit or LLM test; no score effect," which prevents confusion with similar assessment 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 gives explicit conditional usage based on consent: consent=true triggers checks, consent=false reads the last result. It also provides a rate limit ("max once/hour") and clarifies that this tool has no scoring effect. It doesn't name alternative sibling tools, but the mode-based guidance is clear enough for an agent to decide when to invoke 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 and destructiveHint=false, so the description is not required to restate safety. It adds context by specifying that results are recent, HTTP/TLS-oriented, and limited to 1–500, which is useful. However, it does not disclose what 'recent' means, how results are ordered, or any pagination behavior beyond the limit.

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 only two short sentences. The action and purpose come first, and the limit detail is front-loaded efficiently. There is no filler, redundancy, or unnecessary elaboration.

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 presence of an output schema and safety annotations reduces the burden on the description. Still, the description omits guidance for choosing this tool among several health-related siblings and fails to document the required agent_id. It is adequate for a straightforward read operation but not fully 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 0%, so the description must compensate. It only adds meaning to the limit parameter ('Limit 1–500') and leaves the required agent_id parameter completely unaddressed. This is insufficient for a 2-parameter tool with zero 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 states a clear action ('Read'), a specific resource ('recent HTTP/TLS results'), and a purpose ('to diagnose failures'). This is more specific than a tautology and gives the agent a concrete idea of what the tool does, though it does not explicitly distinguish it from siblings like agent_health_status or agent_health_heartbeat.

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 'to diagnose failures' implies a use case, but the description does not explicitly say when to use this tool versus alternatives, nor does it mention any exclusions. With multiple health-related sibling tools, an agent could still be unsure whether to pick this over agent_health_status or agent_health_heartbeat.

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 already cover read-only and non-destructive behavior, so the description goes beyond them by disclosing 'unsigned' evidence, recent incidents, and the trust-relevant flags. The caveat 'This does not certify agent safety' adds meaningful behavioral context about the limits of the data. 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 front-loaded with the core purpose, followed by field guidance, a caveat, and api_key semantics. It is not padded, though the final sentence about 'owner activation' is dense and somewhat opaque, making it slightly harder to parse than it needs to 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 an output schema available and readOnly/openWorld annotations present, the description covers the essential trust-relevant details: unsigned data, recent incidents, caveats, and the optional api_key effect. It does not fully explain the relationship to sibling health tools or clarify the 'owner activation' attribution, but an agent can still 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 description coverage is 0%, so the description must compensate. It does explain the optional 'owner api_key' behavior, but it never clarifies the meaning of the required 'agent_id' beyond the schema title 'Agent Id.' The agent_id is inferable from the tool name and context, but the description does not explicitly define it.

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

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

The description uses a specific verb and resource: 'Read unsigned, timestamped operational evidence and recent incidents.' It clearly distinguishes this from sibling health tools by framing it as pre-trust-decision evidence and explicitly stating 'This does not certify agent safety.' This gives an agent enough to separate it from status/checks/heartbeat 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 tells the agent when to use it ('before a trust decision') and what to inspect ('stale, provisional, open_incident and incidents_truncated'). It also provides a key exclusion by noting the tool does not certify agent safety, though it does not name specific alternative tools or enumerate 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 establish readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context beyond that: the auth requirement ('owner-authenticated', 'Use the agent-specific key, not X-Autonet-Token') and a misuse boundary. It stops short of describing what server-side state the heartbeat updates, but the added context is genuinely useful.

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, each earning its place: primary action and scope, auth key selection, and a misuse warning. The core purpose is front-loaded, with no filler or repetition of schema/annotation content.

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 2-parameter tool with an output schema present, the description covers purpose, usage context, auth specifics, and exclusions. The only gap is the unspecified server-side effect of a heartbeat on agent health state, which is minor given the output schema and annotations already carry the remaining burden.

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 does so for api_key with the critical clarification 'Use the agent-specific key, not X-Autonet-Token', which prevents a common auth mistake. The agent_id parameter, however, is left only to the schema title 'Agent Id' with no additional guidance on format or source.

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+resource: 'Send an owner-authenticated heartbeat from the actual worker loop'. The explicit exclusion 'does not replace endpoint checks' differentiates it from sibling tools like agent_health_checks and agent_endpoint_assessment. An agent can tell what this tool is for without opening the schema.

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 an explicit when ('from the actual worker loop') and explicit when-nots ('does not replace endpoint checks', 'Never send a heartbeat to pretend a failed worker is alive'). It also provides a routing hint by distinguishing heartbeat signaling from endpoint checks, which are presumably handled by 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 already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is well established. The description adds useful context about the contents and scope of the instructions, giving the agent expectation about what information will be provided without contradicting 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 that begins with the critical directive 'Read FIRST' and then lists the covered topics in a compact, scannable format. Every phrase earns its place and there is 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?

For a parameterless instructions tool with output schema available and annotations covering safety, the description is complete. It tells the agent exactly what content to expect (purpose, endpoint ownership, heartbeat setup, scoring limits, API usage) and signals where this fits in the overall 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?

The tool has zero parameters, so the input schema carries no burden and the description needs to explain nothing extra. The baseline for a parameterless tool is 4, and the description appropriately focuses on the tool's content rather than 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 this as a 'read first' instructions tool, listing the specific topics it covers: purpose, endpoint ownership, heartbeat setup, scoring limits, and API/free service usage. This distinguishes it from the sibling tools that perform actual health operations, though it stops short of explicitly stating 'returns onboarding instructions'.

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?

'Read FIRST' is an explicit temporal cue that this tool should be used before the other agent health tools. It conveys the intended ordering and scope of use, though it does not directly name sibling alternatives or explicitly say 'use this before agent_health_checks'.

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 convey readOnly/openWorld/non-destructive. The description adds context by noting the status is public, the trust score is nested, may be null ('Provisional score is null'), and the result is not a certification. This exceeds the annotation baseline without contradicting it.

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

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

Two compact sentences, with the primary operation front-loaded and the caveat packaged efficiently. There is no filler or repetition.

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

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

For a simple single-parameter read tool with an output schema and safety annotations, the description covers the essential behavior: public status, trust score, nullability, and what it is not. It could add one sentence on typical use, but nothing critical is missing.

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

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

Schema description coverage is 0% and the description does not explain agent_id or how to obtain/use it. The parameter name and schema title make it obvious, but the description itself adds no semantic value for the only required parameter.

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

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

Description specifies a clear verb and resource: 'Read public operational status and nested trust score.' It also adds a distinguishing negative ('not identity/safety certification'), though it does not explicitly differentiate from sibling health/check 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 phrase 'read public operational status' implies a lightweight read-only status lookup, and 'not identity/safety certification' offers an exclusion. However, it gives no explicit guidance on when to prefer this over agent_health_checks or agent_health_heartbeat.

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 the operation is non-read-only and non-destructive, but the description adds the authorization boundary ('Owner-only'), the rotation policy ('when explicitly requested'), and a security handling rule ('Keep the secret private'). This is meaningful behavioral context beyond the annotation flags, though rotation side effects are not detailed.

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 only two short sentences with no filler. It front-loads the primary action and each clause adds necessary context about scope, behavior, or confidentiality.

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 output schema present and only three scalar parameters, the description covers owner-only access, the retrieve/rotate operations, and secret sensitivity. However, it does not clarify the required parameters or the effects of rotation, leaving a moderate completeness gap.

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 explicitly explain agent_id, api_key, or rotate. The phrase 'when explicitly requested' only loosely hints at the rotate parameter, leaving the meaning of the other parameters to be inferred from their 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 uses specific verbs, 'retrieve' and 'rotate', with a clear resource, 'webhook signing secret', and an explicit owner-only scope. It is easy to distinguish from sibling health/domain tools because the resource and operation are different.

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 states the two relevant use cases: retrieving the secret or rotating it only when explicitly requested. It also provides the owner-only restriction and a privacy directive, though it does not explicitly name alternatives or when not to use 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuine context by stating id and history are preserved, i.e. this is a non-destructive state transition. It does not mention that an api_key credential is required or what happens to the prior heartbeat configuration.

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 dense sentence that front-loads the action and states the key preservation guarantee. No filler, though the term 'graduate' costs a little clarity for the brevity it buys.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Still, for a four-parameter mutating tool with zero schema descriptions, the omission of api_key's role and the polling interval semantics leaves the agent under-informed.

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% across four parameters, so the description carries the full burden. It only obliquely gestures at agent_id ('preserving id') and endpoint_url ('endpoint probing'); api_key and check_interval_sec are entirely unexplained, including the 60s default's 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 a clear transition: an existing owned heartbeat registration is converted into public endpoint probing, with id and history preserved. It distinguishes itself from siblings like register_agent_health and send_heartbeat by implying it upgrades an existing registration rather than creating one or sending a ping. The jargon 'graduate' is slightly opaque but the resource and effect are recoverable.

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?

Usage is implied by the precondition 'owned heartbeat registration' — the agent must already have one, so register_agent_health is the prerequisite path. However, there is no explicit when-to-use versus alternatives such as agent_endpoint_assessment or probe_me_now, and no when-not-to-use 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?

Beyond the annotations, the description discloses cost ('up to max_coins'), temporary limits ('1 hour, 20 events'), retry/idempotency behavior, and read/write key separation. There is no contradiction with readOnlyHint=false or destructiveHint=false.

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

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

Three dense sentences front-load the core action and limits, then add the most important operational caveats. 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?

The description covers cost, duration, event quota, retry behavior, and access modes. Since an output schema exists, return-value details are not the description's responsibility, and no needed calling context is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies max_coins and request_key semantics, but api_key is left to its title alone, leaving one required parameter under-explained.

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

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

The description identifies a concrete resource ('temporary callback inbox') and a clear action: spend coins to obtain it. It is readily distinguished from sibling tools like delete_callback_inbox and read_callback_events.

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 provides actionable usage guidance: reuse request_key on retries and note that the receive URL is write-only while reads need the utility key. It does not explicitly route to sibling alternatives, but the intended usage context is 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?

Annotations already mark this as a non-read-only, non-destructive, open-world operation; the description adds genuinely useful context: the one-time nature, the private API key returned, the welcome coins, and the absence of billing/health registration. It does not fully explain consequences of a repeated call, but 'once' provides a strong 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?

Two short sentences with the core imperative and key outcome first, followed by caveats/incentives. Every clause earns its place: create once, save key, coins, no billing/health.

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 creation tool with an output schema, the description tells an agent everything it needs to invoke it correctly: create it, save the key, and expect no billing or health steps. It doesn't explain what the utility account is used for, but that is not required 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?

There are no parameters and schema coverage is 100%, so the baseline is 4. The description contributes no parameter-specific meanings but reinforces that no billing or health registration details 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 opens with a specific verb and resource: 'Create a free utility account'. It then adds concrete details (returned private API key, 100 welcome coins) and a clear scope delimiter ('No billing or health registration') that distinguishes it from health-related siblings.

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

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

It gives actionable usage guidance: create once and immediately save the returned private API key. 'No billing or health registration' clarifies prerequisites and helps an agent avoid expecting setup steps. It stops short of explicitly naming alternatives such as utility_account or the health registration tools, so it is not a 5.

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 the tool as destructive, and the description adds valuable specifics: it permanently removes both the registration and probe history, and admin request logs are retained for up to 30 days. This goes beyond the annotations by clarifying the exact scope and retention 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?

Two sentences with no unnecessary filler. The most important information—permanent deletion and retention of admin logs—is front-loaded and clearly stated.

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 destructive tool with an output schema, the description covers the essential details: what is deleted, permanence, and log retention. It does not mention error cases or idempotency, but the presence of an output schema and the clarity of the operation make this a reasonably complete description.

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 bears the burden of explaining parameters. It refers to 'owned registration' and 'operator', which hints at authorization, but it never explicitly defines what agent_id or api_key mean or how they are used. The parameter names are somewhat self-explanatory, but the description does not compensate for the missing schema descriptions.

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

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

The description clearly states the action: 'Permanently remove an owned registration and probe history' with a specific verb and resource. It is easily distinguished from sibling tools like register_agent_health, update_agent_health, and agent_health_status.

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 'when the operator requests it' gives clear context for when deletion is appropriate. It does not explicitly contrast with sibling tools, but the delete-vs-register/update/status distinction is clear from the description and 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds valuable context beyond annotations: immediate deletion of all events, receive URL stops working, no coin refund, and usage ledger remains. This is strong behavioral disclosure for a destructive 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?

Three short sentences, each carrying distinct information: the action, the consequence, and the financial/ledger impact. No fluff, front-loaded with the core action.

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

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

For a destructive tool with two simple parameters and an output schema, the description covers the key consequences an agent needs to know before invoking. It doesn't mention how to get inbox_id or what the output contains, but the output schema exists and the sibling list_callback_inboxes implies the discovery path. Minor gap: no explicit warning about irreversibility beyond 'immediately'.

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 mentions 'owned inbox' and 'receive URL' but doesn't explain what api_key and inbox_id mean or how to obtain them. The description adds some context (ownership requirement) but leaves parameter semantics mostly to the schema, which only provides names and types.

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 (delete), the resource (owned inbox), and the immediate effect (all its events deleted, receive URL stops working). It distinguishes itself from siblings like list_callback_inboxes and read_callback_events by focusing on deletion.

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

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

The description implies when to use it: when you want to permanently remove an inbox and its events. It doesn't explicitly name alternatives or exclusions, but the destructive semantics and immediate effects are clear enough for an agent to decide. It could be improved by stating 'use list_callback_inboxes to find inbox_id first'.

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, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds the useful detail that the read concerns 'public registry' data and heartbeat regularity, but says nothing about rate limits, freshness, or behavior when the agent is unknown.

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 tight sentence with no filler, and the verb plus resource list is front-loaded. It is arguably too terse for the ambiguity it leaves, but there is no wasted wording.

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

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

An output schema exists, so return-value explanation is not required, and annotations cover the safety profile. However, the meaning and provenance of the sole required identifier are left entirely unexplained, which is the main gap an agent would hit when 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?

The single required parameter agent_id has 0% schema description coverage, and the description never explains what an agent_id is, how it is obtained, or what format it takes. The description does not compensate for the schema gap.

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

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

States a specific verb ('Read') and names three concrete pieces of information returned: public registry status, evidence mode, and heartbeat receipt regularity. It is distinguishable from most siblings, though it overlaps conceptually with agent_health_status and agent_health_heartbeat without clarifying the boundary.

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 versus the many adjacent health/status siblings (agent_health_status, agent_health_feed, agent_health_heartbeat). The agent must guess the selection criteria 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only behavior is covered. The description adds context beyond annotations by disclosing that paid usage and invoices are disabled in the beta, which is a meaningful behavioral restriction an agent must know.

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, front-loaded with the core action, and no filler or repetition. Every clause earns its place.

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

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

With zero parameters and an output schema present, the description covers what is needed: the primary purpose and the beta-specific limitation. The output schema handles return-value details, so no key guidance 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?

The input schema has zero parameters, so the description is not expected to explain parameters. The schema is fully covered (100%), and with no params, the baseline is 4.

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 ('Get') and resource ('current coin costs and resource limits'), making the tool's purpose immediately clear. It is distinguishable from siblings like internet_utils_instructions and create_utility_account, which are about instructions and account creation, respectively.

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 'before spending' gives a clear usage context, telling the agent when to call this tool. However, it does not explicitly name alternatives or state when not to use it, 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 annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds what content is read but reveals no additional behavioral traits such as rate limits, external calls, or response handling. It does not contradict the annotations, but it also does not go beyond them.

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 the relevant topics and adds one clarifying caution about health endpoints. There is no redundant wording, and every phrase earns its place.

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

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

For a zero-parameter, read-only instruction tool with an output schema and safety annotations, the description is largely complete: an agent knows what information it will get and that no health endpoint is involved. The only minor gap is not clarifying the relationship to the sibling internet_utils_catalog, which could cause selection ambiguity at a glance.

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 schema description coverage is 100%, so the schema carries no parameter burden. The description correctly focuses on what the instructions contain rather than attempting to explain nonexistent parameters, which fits the baseline 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?

The description uses the specific verb 'Read' and names the concrete resources: free coin allowance, callback workflow, privacy limits, and API usage. It also distinguishes itself from health-related siblings with 'No health endpoint required,' though it does not explicitly distinguish itself from the similarly named internet_utils_catalog.

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 'No health endpoint required' gives some context that this is not a health-check tool and does not need endpoint validation. However, it does not explicitly state when to use this tool over alternatives like internet_utils_catalog, nor does it give conditions or exclusions beyond the health note.

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 destructiveHint=false, so the description does not need to re-establish safety. It adds useful context by noting the 'unexpired' filter, receive URLs, and a privacy caution, but does not mention pagination, rate limits, or auth behavior 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?

Two short, purposeful sentences. The core action and scope are front-loaded, and the privacy note earns its place; there is 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 simple one-parameter read-only tool with an output schema, the description is mostly adequate. However, the missing parameter guidance for api_key and the lack of sibling differentiation leave some gaps an agent must infer.

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, api_key, has no schema description (0% coverage), and the tool description never mentions it. The description does nothing to explain where the key comes from, its format, or how it should be supplied.

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 ('list'), a resource ('callback inboxes'), and scope ('your unexpired'), and clarifies the output includes receive URLs. This clearly differentiates it from create/delete callback inbox siblings.

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

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

There is no explicit guidance on when to use this tool versus alternatives like read_callback_events or create_callback_inbox. The description implies a listing use case but offers no exclusions, prerequisites, or 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?

With annotations only marking this as non-read-only, open-world and non-destructive, the description adds substantial context: an auth requirement (owner key), a 60s rate limit, a suspended-agent precondition, the side effect of incident transitions, and an explicit negative scope statement about heartbeats.

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 short sentences, action front-loaded, no filler. The final two sentences are terse fragments, but each still carries a distinct fact (mechanism and negative scope) so little is wasted.

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

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

An output schema exists, so return values need not be described. The description covers preconditions, limits, auth, and non-goals; the only real gap is that it never clarifies what the two required inputs should 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?

Schema coverage is 0% for both required parameters, so the description carries the full burden, and it does not. "owner key" loosely hints that api_key is a credential, but neither agent_id nor api_key is explained in a way an agent could act on beyond what the bare titles say.

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

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

The description gives a specific verb+resource ("Probe your registered endpoint now") and clarifies the mechanism as scheduled HTTP/TLS checks with incident transitions. It is distinguishable from siblings like agent_health_heartbeat, but it never names or contrasts with the adjacent agent_health_checks / agent_health_status 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 states a hard rate limit ("One per 60s"), a precondition ("paused agents must resume first"), and an explicit exclusion ("Does not send a worker heartbeat"), which routes the agent away from the heartbeat sibling. It stops short of naming a preferred alternative tool for any situation.

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?

Beyond the readOnlyHint annotations, the description discloses that events are not consumed, no coins are spent, payloads are untrusted, and sender signatures are not verified. This is valuable behavioral context that structured annotations alone do not provide, and it does not contradict any 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 short, front-loaded with the core action, and every sentence adds meaningful information. There is no filler or repetition of schema data.

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

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

The output schema covers return-value structure, and the description adds pagination, security, and consumption behavior. Given the tool moderate complexity, this is nearly complete; the only small gap is the lack of any note about the exact structure or error conditions for the cursor, but the presence of an output schema reduces that burden.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meanings. It adds semantics for the cursor behavior via 'after' and 'next_cursor', but it does not explain api_key or inbox_id, leaving two of three parameters dependent on agent inference.

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

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

The description clearly states the specific operation: reading up to 20 callback events after a cursor. It also distinguishes the tool from siblings like create_callback_inbox and list_callback_inboxes by focusing on event consumption and pagination.

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 usage context: use it to read a bounded window of events after a cursor without consuming them, and persist next_cursor to continue. It does not explicitly name alternatives or exclusions, but the pagination and non-consuming behavior effectively disambiguate when this tool is appropriate.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the agent knows this is a non-destructive write to an open system. The description adds useful context: owner key shown once, fields public, endpoint requirement per mode, and a warning against faking activity. It does not cover rate limits, idempotency, or what happens on re-registration.

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 four short sentences, front-loaded with the main action and mode distinction, and includes a security warning. It is efficient, though it omits some key parameters.

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 output schema present, return values need not be explained. However, for a 10-parameter mutation tool with no schema descriptions, the description covers only a fraction of the parameters and omits other important behavioral details like re-registration behavior or error handling. It is adequate but incomplete.

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

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

Schema coverage is 0%, so the description must compensate. It names and explains only a few parameters (name, contact, note, version) and the mode distinction, leaving most of the 10 parameters (endpoint_url, webhook_url, checks_config, intervals, etc.) undocumented in both schema and description. Baseline 3 because the description adds some meaning but does not fully cover the parameter set.

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 'Register a real worker once' and distinguishes heartbeat vs probe modes, which clarifies what mode does. However, it doesn't clearly explain what an 'agent health' registration is or differentiate from siblings like update_agent_health or agent_health_heartbeat. The purpose is implied but not crisply stated.

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 mode differences (heartbeat needs no endpoint, probe requires a URL), offering some implicit guidance. But there is no explicit when-to-use-this-vs-alternatives guidance, no mention of prerequisites, and no routing to sibling tools like update_agent_health or send_heartbeat.

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?

Annotation Contradiction: annotations set openWorldHint=true, implying possible real-world side effects beyond the MCP server, while the description explicitly states 'No network requests, production registration, coin spend or external delivery' and 'Discards state.' Although the description itself discloses useful behavior (signed webhook fixture, discarded state), the direct contradiction with openWorldHint forces a score of 1 per rubric.

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 short sentences deliver purpose, scenario list, output, and behavioral constraints with zero filler. The core purpose is front-loaded, and every sentence earns its place.

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

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

With one optional parameter, an output schema, and this description, an agent has enough to invoke the tool correctly. The only completeness gap is the openWorldHint contradiction, which could confuse an agent that weighs annotations more heavily than the description.

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 carries the burden. It lists the three scenario values (healthy, incident, stale_payload) inline, which is exactly what an agent needs to populate the 'scenario' parameter even though the schema only provides a default. It does not detail each scenario's behavior, but output schema and the dry-run nature reduce the need.

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 ('run_autonet_sandbox') with a precise purpose: a lifecycle dry run covering healthy, incident, or stale_payload scenarios. It explicitly contrasts itself with production effects, distinguishing it from siblings like register_agent_health and test_agent_webhook that involve real registration or delivery.

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 signals when to use the tool: for an isolated local verification, as it explicitly rules out network requests, production registration, coin spend, and external delivery. It does not name specific alternatives, but the negative constraints make the safe-context usage 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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, but the description adds real context beyond them: an owner key/API-key auth requirement, that note/version become public, a rate-limit instruction (Retry-After), the side effect that dormant workers revive on receipt, and the caveat that this does not prove uptime. It stops short of describing failure behavior or idempotency.

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?

Four terse, front-loaded clauses with zero filler; the core action comes first and each remaining sentence carries a distinct piece of operational 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?

An output schema exists, so return values need not be explained, and the description covers auth, side effects, rate limiting and a meaningful caveat. The remaining gap is the absence of any differentiation from the closely related heartbeat sibling 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% across five parameters, so the description must carry the load. It partially does, mapping api_key to an owner key and flagging note/version as public, but agent_id and status are left entirely undocumented in both schema and description.

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

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

States a specific verb and resource ("Send a self-reported heartbeat from the actual worker") and clarifies the origin is the worker itself. However, it does not distinguish this tool from the near-identical sibling agent_health_heartbeat, leaving the agent to guess which one applies.

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?

Usage is implied rather than stated: "from the actual worker" and "Honor Retry-After" hint at who calls it and how to retry, but there is no explicit when-to-use, when-not-to-use, or pointer to agent_health_heartbeat as the alternative.

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?

Discloses that it sends a webhook (side effect), explicitly states 'No incident or score change,' and adds rate limit and permission requirements. This goes beyond the annotations (readOnlyHint=false, destructiveHint=false) by clarifying the exact nature of the side effect and constraints.

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

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

Three concise sentences, front-loaded with purpose, then constraints, then post-action guidance. No wasted words; every sentence earns its place.

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

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

Complete for a simple test tool: purpose, constraints, and clear post-action guidance. Since an output schema exists, return values are covered by that. Nothing an agent needs to call 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 has no descriptions for agent_id and api_key, and the description doesn't explain them. It implies agent_id identifies the webhook and api_key is for authentication, but this is not explicit. With 0% schema coverage, the description should compensate, but it doesn't.

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 exactly what it does: 'Send one signed incident.test to your configured webhook.' This is a specific verb and resource, and the additional constraints (owner-only, once/minute) help distinguish it from other agent tools like health checks or endpoint assessments.

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 clear usage constraints: 'Owner-only, once/minute' and instructs to 'Inspect delivered and receiver_status; do not automatically replay.' While it doesn't explicitly name alternatives, the context is clear enough for an agent to know when to call it and what to do afterward.

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 destructiveHint=true, readOnlyHint=false and openWorldHint=true. The description adds genuinely useful context beyond that: an ownership requirement ('Owner-only update') and a URL constraint ('public URLs you control'). It still never explains what the destructive behavior actually is (does pausing stop monitoring? lose state?), which is the main thing the destructiveHint raises.

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 short, front-loaded sentences with no filler; the ownership constraint leads and the parameter guidance follows. Slightly clipped to the point of under-specification, but structurally 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?

An output schema exists so return values need not be described, but for an 8-parameter destructive mutation with zero schema coverage the description is too thin: most configuration parameters and the nature of the destructive change are unaddressed.

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% across 8 parameters, so the description carries the full burden. It clarifies the semantics of 'paused' (false resumes) and constrains endpoint_url/webhook_url, but leaves checks_config, heartbeat_enabled, check_interval_sec, agent_id and api_key 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 verb 'update' and the resource implied by the name (agent health) are present, but the description never says what an agent-health update actually configures or changes. Siblings like agent_health_status, agent_health_heartbeat, and delete_agent_health are not differentiated, so the scope must be inferred from the schema.

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?

'Pause when retiring/testing; resume with paused=false' gives real conditional guidance for the paused parameter. However, there is no guidance on when to use this tool versus siblings such as delete_agent_health or register_agent_health, so usage 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read'. It adds useful context beyond annotations: the data is private, and the required key type is a utility key rather than a health owner key. This is meaningful auth/scope information not captured by 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?

Two short sentences, both essential, with the primary purpose front-loaded. There is no filler or redundant restating of the tool name.

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

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

Given the simple single-parameter schema, the output schema, and annotations covering safety, this description is complete. An agent knows the operation, the auth requirement, and the data scope. Nothing critical is missing for selecting and calling 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 documentation coverage is 0%, so the description must compensate for the api_key parameter. It partially does by explaining that the tool requires a 'utility key', which tells the agent what kind of value api_key expects. It could be more explicit about how to obtain or format the key, but the key type is meaningful.

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 ('Read') with a clear resource ('private coin balance and usage ledger'), and the sibling create_utility_account makes the read-vs-create distinction obvious. An agent can tell exactly what this tool does and what it does not do.

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

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

The description gives a clear usage context: reading account data, and it states a prerequisite/auth requirement ('Requires a utility key, not a health owner key'). It does not explicitly name alternative tools or when to prefer them, but the context is strong enough that an agent would not reach for create_utility_account or the health-related 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 only declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds valuable behavioral details beyond annotations: the once-per-minute check limit, hourly renewal on success, and 24-hour expiry. This gives the agent a realistic model of side effects and limitations without contradicting 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?

Three short sentences carry essential information: the action, the limitation, and the lifecycle behavior. There is no filler or repetition, and the most important scoping statement is front-loaded.

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 verification lifecycle well and an output schema exists, so return-value documentation is not needed. However, it omits the prerequisite relationship with agent_domain_challenge, and it never explains which domain the TXT record should be on or how agent_id and api_key map to that domain. This leaves gaps for an agent deciding whether it has everything needed.

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 two required parameters, agent_id and api_key, with 0% schema description coverage. The description says nothing about what either parameter means, which domain is verified, or how the API key is used. The schema only provides titles, so the agent must guess crucial invocation 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 a specific verb and resource ('Check your published DNS TXT record') and immediately clarifies the scope ('Proves domain control only, not agent identity or safety'), distinguishing it from identity or safety verification tools. The purpose is unmistakable.

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

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

The description implies usage: check a DNS TXT record after publishing it, and use it when domain control proof is sufficient. It does not explicitly state when to prefer this tool over siblings like agent_domain_challenge, nor does it give an explicit when-not-to-use condition, though the 'not agent identity or safety' caveat provides useful context.

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