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, destructiveHint=false and openWorldHint=true. The description adds the owner-only access constraint, which is useful, but says nothing about retention window, pagination beyond the limit, or what the output schema contains. With annotations carrying the safety profile, a 3 is appropriate.

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

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

Two short sentences with zero waste, front-loading the read scope and then the limit constraint. Efficient and appropriately sized for a simple read tool.

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

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

An output schema exists, so return values need not be explained. But with 0% schema coverage and an undocumented required agent_id, plus no guidance on how this differs from adjacent diagnostic tools, the description is only minimally complete for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for all three parameters. It gives a range for limit (1–500) but leaves agent_id and api_key completely undocumented in both schema and description, which is inadequate for a required agent_id.

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

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

States a specific verb (read) and resource (recent HTTP/TLS results), plus the purpose (diagnose failures). It distinguishes itself from sibling readers like agent_health_feed or agent_health_status by naming the exact result type, though it doesn't explicitly contrast with them.

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 'to diagnose failures', but there is no explicit when-to-use/when-not-to-use guidance or naming of alternatives such as diagnose_http or diagnose_mcp, which the agent must infer from the sibling list.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the floor is low, yet the description adds genuine behavior: the evidence is unsigned and timestamped, it explicitly does not certify safety, and api_key is required for owner attribution. The only real omission is any note on pagination or rate limits for what is clearly a feed.

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 the core purpose front-loaded, and the caveat and auth requirement are appropriately placed. The second sentence ('Check stale, provisional, open_incident and incidents_truncated') lists output field names without context, and the final clause about owner activation is grammatically convoluted.

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 detail is unnecessary, and the description covers purpose, an explicit non-guarantee, and auth requirements. It is close to complete for a read feed, with only the relationship to closely-named siblings left implicit.

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

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

Schema coverage is 0%, so the description must carry the parameter burden. It does explain the non-obvious api_key semantics (owner-scoped, required unless publicly shared, used for attribution on scheduled-check retrieval), but says nothing about agent_id beyond what the schema name implies.

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 resource (unsigned, timestamped operational evidence and recent incidents), and the word 'unsigned' implicitly distinguishes it from the sibling agent_signed_evidence. It doesn't name any sibling explicitly, so the differentiation is only inferable rather than 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?

'before a trust decision' gives real situational context for when to call it, and the 'does not certify agent safety' caveat signals a boundary. However, it never says when to prefer this over the very similar siblings (agent_health_status, agent_health_checks, agent_signed_evidence), so an agent must guess between them.

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

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

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 declare readOnly, openWorld, and non-destructive behavior. The description adds meaningful context beyond that: the access constraint of owned/shared agents, the presence of a nested trust score, the fact that a provisional score is null, and the limitation that it is not a safety certification.

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

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

Two short sentences, front-loaded with the tool's action and scope. The second sentence adds useful limitations without repeating the schema or annotations. It is appropriately sized, though 'nested trust score' could be slightly clearer.

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, with many sibling tools and zero schema parameter documentation, the description leaves gaps about when to use this versus get_agent_status and how agent_id/api_key affect access.

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 would need to explain agent_id and api_key. It does not describe either parameter's meaning, format, or whether api_key is required for access. It only implies an ownership/sharing condition indirectly.

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: reading operational status and a nested trust score. It also clarifies that it is not an identity/safety certification, which sharpens scope. However, it does not distinguish itself from close siblings such as get_agent_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?

It gives an access condition ('owned or explicitly shared') and a negative scope ('not identity/safety certification'), which implies some when-not-to-use guidance. But it does not name alternatives or explain when to choose this tool over get_agent_status or 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?

Beyond the read-only annotations, it discloses a shared rate limit (60 reads/IP/minute with presence badges and signed evidence), the credential requirement, the trust caveat ('self-reported receipt evidence, not uptime'), and record-exclusion semantics. That is exactly the kind of context annotations cannot carry.

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 and front-loaded: the primary function comes first, then caveats, auth, exclusions, and rate limits. A stray mid-sentence line break and telegraphic phrasing slightly hurt readability but no sentence is 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?

An output schema exists so return shape need not be explained, and the description covers data meaning, trust caveats, auth, exclusions, and rate limits. The only real gap is not directing the agent to a sibling when the requested mode or evidence type does not match this 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% for 2 parameters. The description explains the owner-key condition, which covers api_key semantics, but adds nothing about agent_id beyond what its name implies. Baseline 3 is right since one parameter is effectively undocumented.

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

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

The description names a specific verb (Read) and a tightly bounded resource: 30-day completed heartbeat windows, daily counts, gaps and streaks. The qualifiers 'Heartbeat mode only' and 'self-reported receipt evidence, not uptime' separate it from status/assessment siblings like agent_health_status or agent_endpoint_assessment.

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 an auth condition ('Owner key required unless publicly shared') and a mode exclusion ('Heartbeat mode only'), plus which records are excluded (incomplete windows, no grace for registration-anchored windows). It stops short of naming which sibling to use instead for other presence or evidence needs, so it is clear context without explicit alternative routing.

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 cover the safety profile (readOnly, openWorld, non-destructive), and the description adds real substance on top: a five-minute TTL, the signing algorithm, the exact claims to validate, and the caveat that the signature proves origin/integrity only. It doesn't mention failure modes or what happens when the evidence has expired or the key endpoint is unreachable, which keeps it below a 5.

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

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

Three tight sentences, front-loaded with what the tool returns before the verification recipe and the scope caveats. Dense but every sentence carries information; slightly jargon-heavy phrasing is the only cost.

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 no further explanation, and the annotations handle the safety profile. The behavioral picture (TTL, verification steps, limits of the signature) is well covered; the only material hole is input-parameter meaning, which is scored separately.

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

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

Schema description coverage is 0% and the description never mentions agent_id or api_key. The claim list ("issuer, audience, subject and expiry") refers to JWS fields, not input parameters, so it does not compensate for the gap. With neither schema nor description explaining what agent_id selects or when api_key is needed, the parameter layer is effectively undocumented.

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

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

States a specific verb plus resource ("Get a five-minute Ed25519 signed presence observation") and names the cryptographic primitive, which clearly sets it apart from siblings like evidence_signing_keys or run_signed_diagnostic. It stops short of explicitly contrasting with those siblings, so an agent still has to infer which related tool fetches keys versus which mints the evidence.

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 operational context: verify the compact JWS against the trusted key endpoint, then check issuer/audience/subject/expiry. The closing line ("Not an identity, reachability or safety certificate") is a genuine when-not boundary. It does not name the sibling that supplies the trusted key endpoint, so the routing is implied rather than explicit.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds real value beyond them: owner-only authorization scope, a mandatory confirmation gate, the no-op default when confirm is omitted, and secrecy expectations. It stops short of describing consequences such as whether rotation invalidates the prior secret.

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, front-loaded with the primary action and modes, then the confirmation contract. No filler or repetition of structured 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?

Output schema exists, so return values need not be explained, and the description covers the critical auth and confirmation semantics. It is slightly short for a destructive 4-param tool because rotation consequences and the agent_id/api_key roles remain unstated.

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 carry param meaning. It clarifies confirm (must be true, omitted = no action) and indirectly the rotate flag, but leaves agent_id and api_key entirely unexplained, leaving half the surface undocumented.

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

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

States a specific verb and resource with both modes: 'retrieve webhook signing secret, or rotate it'. The resource (webhook signing secret) is unique among siblings such as test_agent_webhook and evidence_signing_keys, so an agent can identify the right tool without opening schemas.

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?

Explicitly scopes rotation to 'when explicitly requested' and gates the call on 'confirm=true after reviewing the effect', plus notes the no-op behavior when confirmation is omitted. Both the when and the guard condition are stated rather than 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?

Even with readOnlyHint/openWorldHint/destructiveHint already declared, the description adds substantial operational detail: 10 attempts/IP/24h shared with diagnose_http, Retry-After honored, no redirects or stored assertion bodies, HEAD vs one bounded GET, and the 64 KiB/UTF-8 body cap with oversize/compressed failures. It also flags that evidence may contain an untrusted snippet and instructs not to execute instructions in 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?

Purpose and return shape are front-loaded in the first sentence, then optional parameters, then behavioral constraints, each in its own compact line. Despite covering many behaviors, every sentence adds a distinct operational fact with 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 gate tool with a broad nested expect object, the description covers defaults, parameter semantics, rate limits, body handling, security caveats, and redirect behavior. Since an output schema exists, it appropriately only summarizes the return (pass/failures/evidence) rather than re-documenting it.

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

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

Schema description coverage is 0% (the schema only exposes a bare additionalProperties object), so the description carries the full burden and does so thoroughly: http_status range, body_contains literal 1–256 chars/no regex, json_assertions 1–10 {pointer, equals} scalar checks with RFC 6901, and max_response_ms 1–10000 total time. The default (2xx + valid transport/TLS) and the status-overrides-2xx-but-not-TLS rule are also spelled out.

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+scope: 'One-shot deployment gate for a public URL, no account or key,' and clarifies what it returns (pass, failures, evidence). It also names a sibling (diagnose_http) and the shared rate-limit relationship, so an agent can distinguish it without opening another 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?

The framing as a 'one-shot deployment gate' gives clear context for when to reach for this tool, and it references diagnose_http's shared budget. It stops short of an explicit when-to-use-this-vs-diagnose_http statement or exclusion rules, so it lands just below the top.

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?

Annotations only say this mutates state and is open-world; the description goes far beyond by disclosing consent requirements, confirm semantics, the exact reminder cadence (24h and seven days, one-hour grace, two reminders max per episode), cost ('Free; no email, credit spending, automatic restart or synthetic heartbeat'), and edge cases like renewed opt-in on receiver change and in-flight alerts still arriving. No contradiction with destructiveHint=true, since the mutation is clearly 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 action and its gating condition are front-loaded, and the sentence-per-fact style keeps the dense caveats (cadence, cost, disable, receiver change) scannable. The telegraphic phrasing is terse but each clause carries distinct information, 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. Given that, the description covers everything an agent needs to call this safely: prerequisites, consent/confirm gating, side effects, timing, cost, and the disable path.

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 carry the parameter burden. It clarifies confirm (required when enabling, not needed when disabling) and enabled (opt-in/opt-out), but says nothing about agent_id or api_key, and never explains that the webhook receiver is implicit rather than a parameter.

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

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

The description gives a specific verb and resource: opting into quiet-agent recovery reminders over the agent's existing HTTPS webhook, and it scopes the feature with 'Heartbeat mode only.' It is distinguishable from most siblings, though it never names the obvious read counterpart (read_agent_reengagement), leaving the read/write split to be inferred from the tool name.

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

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

It states the conditions that gate use (heartbeat mode only, explicit owner consent, confirm=true) and the disable path ('Disable without confirm'). It also advises using a durable supervisor/owner receiver independent of the worker. It stops short of naming alternatives such as read_agent_reengagement or the liveness subscription 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?

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?

Goes well beyond the annotations (destructive/openWorld/not-readOnly) by disclosing the cost model (completed checks cost 1 credit even when the target is broken, worker failures cost zero), budget-stop behavior, minimum interval, confirm gating, signed webhook transitions, MCP baseline/schema-drift semantics, and best-effort scheduling. This is exactly the operational context annotations can't carry.

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?

Front-loads the core definition, then packs differentiated facts into short, declarative sentences with no filler. Every line adds a distinct operational fact (cost, gating, idempotency, webhook, MCP drift, scheduling caveat).

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

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

For a 9-param, mutation-style scheduling tool with an output schema available, the description covers prerequisites, cost, safety semantics, idempotency, and scheduling caveats. Return format is correctly omitted since an output schema exists, and nothing needed 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?

With 0% schema description coverage across 9 params, the description carries the burden and does so for nearly every meaningful field: api_key (utility account key), max_coins (spending cap), request_key (idempotent retries), confirm (must be true to start), interval_sec (min 300s, default hourly), webhook_url (public HTTPS, signed, save secret), and kind (HTTP vs MCP). Only name and url are left to inference, which is trivial here.

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 ('Watch a public HTTP endpoint or MCP server on a recurring schedule') and scopes it as recurring and private. This clearly separates it from the one-shot diagnose_http / diagnose_mcp siblings without naming them, so an agent can route correctly.

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 concrete prerequisites and usage rules: requires a utility account key, an explicit max_coins cap, owner consent, 'nothing starts unless confirm=true', and 'save/reuse request_key on uncertain retries'. It never explicitly frames when to choose this over the one-off diagnostic tools, but the recurring-watch framing makes the context 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description discloses the crucial behaviors: it never charges a saved card, the owner must complete the returned provider checkout, and there is no automatic top-up or invoice. These are exactly the facts an agent needs before invoking a payment-adjacent 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?

Purpose is front-loaded in the first sentence, and each subsequent sentence adds one distinct fact (no card charge, owner completion, retry key, budget, no auto top-up). 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?

With an output schema present, return values need not be described, and the description covers preconditions, mutation semantics, retry behavior, and budget intent for all three parameters. A brief note on failure/expiry of an incomplete checkout would make it 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 carry parameter meaning, and it explains request_key (reuse for retries/idempotency) and max_usd_cents (explicit owner-approved purchase budget). Only api_key is left to inference, which is self-evident.

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 (prepare a checkout) plus the exact resource and scope ($5/500-credit, owner-completed, funding-enabled). It is clearly distinguishable from siblings like request_monthly_credits or create_utility_account without opening any 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?

"Only when funding is enabled" gives an explicit precondition, and "Reuse request_key for retries" tells the agent how to handle repeated invocation. It does not name an alternative tool for the funding-disabled case, so it stops short of full when/when-not routing.

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 a non-read, open-world, non-destructive write, and the description adds substantive context beyond that: it is free, the returned private API key must be saved immediately, there is a 500-credit monthly top-up through December 2026, and there is no automatic billing or health registration. These are exactly the operational facts an agent needs before invoking a create 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?

Three short sentences, front-loaded with the action and the critical follow-up ('immediately save the returned private API key'). Every clause carries information; 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?

An output schema exists, so return-value details need not be described, and the description still flags the important output artifact (the API key). Combined with the credit policy and the explicit scope exclusions, the definition is complete enough for a zero-parameter create call.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The schema is empty and the description correctly adds no parameter claims, so there is no gap to compensate for.

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: 'Create a free utility account'. The scope ('once') and the credit model are clear. It does not, however, name the sibling 'utility_account' or otherwise distinguish itself from the read counterpart, leaving that inference to the agent.

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?

'Create ... once' implies this is a one-time onboarding call and 'No automatic billing or health registration' rules out two misreadings, which is useful. But there is no explicit when-to-use statement and no named alternative (e.g. utility_account for reading an existing account), 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 flag destructiveHint=true, yet the description adds genuinely new context: the deletion is permanent, probe history is destroyed alongside the registration, admin request logs are retained for up to 30 days, and an omitted confirm performs no action. That is exactly the destructive/irreversibility detail the annotations cannot convey.

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

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

Three tight sentences: the destructive scope leads, the retention caveat follows, and the confirmation requirement closes. No filler and every sentence adds a distinct fact.

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 no explanation, and the description covers destruction scope, retention, and the confirm gate. It is only slightly short on auth/permission expectations for api_key, which is a required parameter.

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 full burden. It does explain the confirm parameter's semantics (must be true; omission = no action), but api_key and agent_id are never described, leaving two of three parameters with no meaning beyond 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?

States a specific verb (permanently remove) plus the exact resources destroyed: the owned registration and its probe history. This distinguishes it cleanly from register_agent_health, update_agent_health, and agent_health_status among its 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?

Gives a usage condition ('when the operator requests it') and a hard prerequisite ('Requires confirm=true after reviewing the effect'), and clarifies that omitting confirmation is a no-op. It stops short of naming any alternative tool or when-not-to-use case, but the gating condition 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 flag destructiveHint=true, but the description goes well beyond them: it discloses immediate (non-deferred) deletion, cascading removal of all events, that the receive URL stops working, that there is no coin refund, and that the usage ledger persists. These are exactly the consequences an agent needs before calling a destructive 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?

Four short sentences, front-loaded with the destructive action and cascade effect, then consequences, then the confirmation contract. 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 destructive, output-schema-backed tool, the description covers the effect, side effects, irreversible cost implications, and the confirmation gate. Return values need not be explained since an output schema exists.

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

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

Schema description coverage is 0%, so the description carries the burden for all three parameters. It explains the non-obvious 'confirm' flag fully (must be true, omitted means no action), but says nothing about api_key or inbox_id, which are only inferable 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?

States a specific verb and resource ('Delete an owned inbox') and scopes the blast radius ('and all its events immediately'). It is easily told apart from create_callback_inbox, list_callback_inboxes and read_callback_events by the destructive verb, though it never names a sibling explicitly.

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

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

The confirmation requirement ('Requires confirm=true after reviewing the effect; omitted confirmation performs no action') is clear invocation guidance. However, it offers no when-to-use vs when-not guidance and no routing toward alternatives such as listing or reading the inbox before deleting 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 flag destructiveHint=true and openWorldHint=true, yet the description goes well beyond them: an in-flight check may still complete and burn a credit, pending alerts are cancelled, and accounting records persist. That is exactly the 'what gets destroyed / what survives' context an agent needs before calling a destructive 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?

Three tight sentences, front-loaded with the action and followed by the consequences. No filler, no restatement of the tool name, and each sentence adds a distinct fact.

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 no explanation, and annotations cover the safety profile. The side-effect disclosure is thorough; the only real gap is the confirm parameter's default/semantics, which matters for a deletion gate.

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 three parameters, so the description carries the full burden. It hints at the confirm gate ('after confirmation') but never explains that confirm defaults to false and must be set true, nor what api_key or watch_id require — the two undocumented parameters are left entirely to the agent.

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

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

States a specific verb+resource pair ('Stop and delete your watch'), which cleanly separates it from create_diagnostic_watch, update_diagnostic_watch, and read_diagnostic_watches. It does not name those siblings explicitly, but the verb alone makes the routing 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?

'After confirmation' implies the confirm gate and the surrounding sentences describe what happens on invocation, but there is no explicit when-to-use vs. when-not guidance and no mention of alternatives such as update_diagnostic_watch for pausing without deleting. Usage is implied rather than 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?

Annotations already declare destructiveHint=true and openWorldHint=true, so safety is partly covered. The description adds real value on top: immediate revocation behavior, explicit non-destruction of monitored agents, and the confirm guardrail defaulting to a no-op.

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

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

Three tight sentences: action first, scope boundary second, guardrail third. Each sentence carries distinct information and is front-loaded, with no waste.

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

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

For a destructive tool with annotations covering the safety profile and an output schema already defined, the description supplies the remaining essentials: what is revoked, what is not affected, and the confirmation requirement.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It explains confirm thoroughly (required true, omitted performs no action) but leaves subscription_id and subscription_key undecorated beyond their self-evident names, so it only partially compensates for the coverage gap.

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

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

States a specific verb ('Revoke') and resource ('pull subscription and its key') and clarifies the scope boundary ('Does not delete monitored agents'), which helps separate it from delete_agent_health. It doesn't name an alternative sibling explicitly, so it falls just short of top marks.

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 invocation guidance via the confirm=true requirement and notes that omission is a no-op, which is genuinely useful. However, it never states when to prefer this tool over alternatives, and usage of the subscription flow 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 only cover the safety profile (readOnly, openWorld, non-destructive). The description adds substantial behavior beyond them: no redirect following, no body fetch, one server vantage, and a concrete rate limit (10 attempts per IP per 24h, honor Retry-After).

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?

Front-loaded with the core action and densely packed with constraints in a few lines, with no filler. The telegraphic phrasing ('one server vantage and one selected address') is slightly terse but not wasteful.

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

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

An output schema exists, and the description still signals the return shape (cause, evidence, suggested_action) while covering scope limits, rate limits, and vantage caveats. Nothing essential for correct invocation 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?

With one param and 0% schema description coverage, the description carries the burden and does add meaning: the URL must be public, ports restricted to 80/443, no credentials/query strings/fragments. It explains valid input shape even though the schema itself is bare.

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 (diagnose) and resource (one public HTTP(S) URL) with the exact probe steps (DNS, TCP, verified TLS, HTTP HEAD). This distinguishes it from siblings like probe_me_now and agent_endpoint_assessment without opening their schemas.

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 preconditions (public URL, no registration, only ports 80/443) and explicit when-not scope ('not browser compatibility or application health proof'). It stops short of naming which sibling to use instead for related checks, so it is clear context but lacks explicit routing.

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 read-only and non-destructive, and the description adds substantial context beyond them: shared rate limit (10 attempts/IP/24h with diagnose_http and assert_healthy), 10-second deadline, 256 KiB cap, max 3 pages, port 80/443 only, no credentials/query strings/fragments/redirects, and JSON/SSE support. It also warns that incomplete catalogs never prove a match and that instruction/description content is not returned.

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

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

Dense but front-loaded, leading with what is checked before constraints. It is longer than typical, but nearly every sentence carries an operational constraint or caveat, 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?

With an output schema present, the description still covers the interpretive layer by explaining what connection_assessment conveys (readiness, authentication, incomplete catalogs, schema changes). All binding constraints an agent needs before calling are 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 coverage is 0%, so the description must compensate. It explains the drift-detection workflow for expected_schema_fingerprint and flags that incomplete catalogs can never confirm a match, plus it constrains url (ports 80/443, no credentials, query strings, fragments or redirects). The url format is not spelled out, but the semantics added are 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?

States a specific verb ('Check') and resource ('public anonymous Streamable HTTP MCP endpoint') and enumerates the exact handshake steps (initialize, initialized, tools/list). It is clearly distinguished from sibling diagnose_http and assert_healthy, which are named.

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 a clear workflow: capture schema_fingerprint from a complete baseline and pass expected_schema_fingerprint on later calls to detect contract drift. It also frames scope with 'Point-in-time checks, not scheduled monitoring,' implicitly steering to diagnostic watches, but it does not explicitly name a replacement sibling for monitoring.

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 readOnly/destructiveHint=false/openWorld, so the safety bar is low. The description adds genuinely useful context beyond that: keys are public, signing secrets are never returned, and retired keys are included — the last point materially affects how a caller should handle rotation.

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, front-loaded with what is returned, then a safety note, then the pinning hint. No filler; 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 an output schema present, the description need not explain return values, and annotations carry the safety profile. It covers the public/secret distinction and retired keys, though it says nothing about key rotation cadence or caching behavior, which would help a caller relying on pinning.

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

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

There are zero parameters, so per the rubric the baseline is 4. Schema coverage is 100% and there is nothing for the description to compensate for.

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 resource (Autonet's public Ed25519 verification keys / JWKS), and adds scope (including retired verification keys). This clearly distinguishes it from siblings like agent_signed_evidence or verify_agent_domain, which consume or validate rather than expose keys.

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 'Pin issuer https://autonet.work' line hints at the verification use case, but the description never states explicitly when to call this versus alternatives such as agent_signed_evidence. Usage is implied rather than stated, and no exclusions or prerequisites are given.

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 the read-only/non-destructive profile, and the description adds substantial context beyond them: the export is unsigned, it does not renew tokens or certify reliability, the JSON must be saved privately, and no credit is spent. These are the security, trust and cost facts an agent needs to reason about the result.

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?

Front-loaded with the core action and window, then auth/ownership scope, then return payload, then side-effect limits. Every sentence carries content, though the middle section is dense and list-like rather than cleanly segmented.

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, yet the description still usefully names the return shape (versioned JSON timeline, coverage/truncation notes, checksum, retained signed tokens). Combined with auth requirements, the 30-day window limit and the no-credit/no-sharing constraints, it is nearly complete for a 6-parameter tool; explicit start/end format for callers who miss the 'Unix-second' phrase is the main omission.

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 carries the burden and does so reasonably: the Unix-second window maps to start/end, 'up to five owned watches' maps to watch_ids, and the 'agent's separate owner key even for public agents' maps to agent_api_key/agent_id. The distinction between api_key and agent_api_key is implied rather than spelled out, leaving a small 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 (export) and resource (private retained incident evidence) plus scope (UTC Unix-second window within 30 days). It also distinguishes itself from signed-evidence siblings by noting the export is unsigned, so an agent can separate it from agent_signed_evidence without opening a 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 clear boundaries: free read of own diagnostics, up to five owned watches, optional agent history requiring the agent's separate owner key, and explicit non-actions (no public sharing, new checks, registration or credit spend). It does not name the alternative tool an agent should call when it needs signed or certified evidence, so routing guidance is present but not fully explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful access-control context ('owned or explicitly shared'), which tells the agent results are permission-scoped, but it omits return format, pagination, and any rate/refresh notes.

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

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

A single front-loaded sentence with no filler; the scope constraint appears before the list of returned data. It is efficient, though 'evidence mode' and 'heartbeat receipt regularity' are jargon that could be clearer.

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 spelled out, and annotations cover the safety profile. However, for a read tool surrounded by many near-synonym siblings, the absence of any disambiguation or usage context leaves the definition only minimally 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% and there are two parameters, yet the description explains neither agent_id nor api_key semantics. With no schema documentation and no description-level compensation, the agent gets no guidance on what identifiers are valid or how api_key affects access.

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 specific resources (registry status, evidence mode, heartbeat receipt regularity) with a scope qualifier ('owned or explicitly shared'). It is clear what the tool returns, but it never names or contrasts with the many similar siblings (agent_health_status, agent_presence_history), leaving differentiation to inference.

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 when-to-use guidance, no exclusions, and no mention of prerequisites or alternatives. The agent must infer from the name alone when this is preferable to siblings like agent_health_status. The access-scope phrase hints at authorization but not at selection 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?

Annotations already establish this is a safe read (readOnlyHint=true, destructiveHint=false), and the description adds a real policy fact beyond them: invoices and automatic overage are disabled, so the agent knows spending will not silently continue. It does not, however, say anything about rate limits or the cost unit behind "coin."

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 action front-loaded and the policy caveat second. Slightly marred by the loose terminology "coin costs" / "funding availability," which are used interchangeably without definition.

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, and this is a zero-parameter read against a simple resource. The description covers purpose plus the overage policy, which is adequate; only the unspecified meaning of the returned 'costs/limits' units keeps it from being 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?

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. The schema coverage is 100% and the description introduces no parameter claims that could mislead.

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 does state a verb and resources — retrieving current coin costs and resource limits — but never reconciles with the tool's name (a 'catalog' of internet utilities) or enumerates what limits are returned. It is understandable in isolation but weakly differentiated from siblings like request_monthly_credits, utility_account, and create_funding_checkout.

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?

"Before spending" implies a preflight/pre-check context, which is useful timing guidance. However, no alternative tool is named and there is no explicit when-not-to-use guidance (e.g., versus fetch credits via request_monthly_credits or check funding via create_funding_checkout).

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?

Goes well beyond the annotations by disclosing a rate limit (60 reads/IP/minute plus hosted MCP quota), that no auth is required, that attribution may reflect a NAT/VPN/proxy/hosted runner rather than the device, and that missing or stale attribution is surfaced explicitly. These are the exact operational caveats an agent needs before relying on the output.

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 purpose is front-loaded in the first clause and each subsequent sentence contributes distinct information (auth, rate limits, identification caveats, boundaries, data-quality note). It is slightly dense, but there is essentially no filler to cut.

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-argument, read-only tool with an output schema already covering return values, the description supplies everything else: rate limits, auth posture, interpretation caveats, and explicit boundaries. Nothing an agent needs in order to call and correctly interpret it 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?

With zero parameters the baseline is 4, and the description reinforces this by stating 'No signup, key or target argument,' removing any ambiguity about whether arguments are expected. Nothing further is needed given there are no parameters to document.

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: report the source IP as Autonet sees it, plus cached ASN/geo. It even carves out a boundary ('Does not probe inbound reachability'), which implicitly separates it from probe-style siblings. It stops short of naming a specific alternative tool, so sibling differentiation is inferential rather than explicit.

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 signals the call needs no signup, key, or target, and clarifies what it does not do (no probing, no egress disclosure), which implies when it is appropriate. However, it never states when to choose this tool over neighbors like probe_me_now or diagnose_http, so usage is implied rather than directed.

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?

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), and the description adds real value beyond them: an auth requirement that applies even to public agents, a zero-cost statement, and an interpretive caveat that returned-after-delivery is observed sequence rather than causal evidence. It stops short of rate limits or response-shape detail.

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 dense sentences, front-loaded with what is read, then auth, then the interpretation caveat. Slightly clipped phrasing but no sentence is 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?

An output schema exists, so return values need not be spelled out, and the description covers the non-obvious parts: auth precondition, cost, and the causality caveat. Only pagination/volume behavior and explicit alternative-routing are 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 0% with two required parameters, so the description carries the burden. It clarifies that an owner key is required even for public agents, which loosely maps to api_key, but it never names either parameter or explains agent_id, leaving the semantics largely undocumented.

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

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

States a specific verb (read) and resource (agent reengagement), and enumerates what is returned: reminder settings, next eligibility, deliveries, observed returns. It clearly contrasts with the configure_agent_reengagement sibling by being the read counterpart, though it never names that sibling explicitly.

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

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

Usage is only implied — an agent can infer this is the read-side of reengagement, and the description adds a precondition (owner key required even for public agents) plus a cost note ('read costs zero'). But there is no explicit when-to-use vs alternatives guidance and no named sibling to route against.

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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: zero cost, a 30-second polling floor, and an auth constraint that only the utility account key can read the records with no public sharing. Error behavior and what an invalid/expired key returns are left unstated.

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 tight sentences with the two usage modes front-loaded, followed by cost, pagination, rate-limit, and auth notes. Every sentence adds a distinct operational fact and none is 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?

With an output schema present, return values need not be described, and the description covers purpose, modes, cost, pagination, polling cadence, and auth scope. The only gap is the meaning of watch_id=null versus a populated value and how this read tool relates to the sibling watch-management tools.

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

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

Schema description coverage is 0% (only bare titles), so the description carries the burden and largely does: it ties the after parameter to next_cursor for pagination and frames the watch_id read path and the api_key as the utility account credential. It never names watch_id explicitly nor explains that its null default selects the list mode, so some syntax remains implicit.

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 concrete verb and resource ('List your private watches, or read one watch's recent results and transition events') and captures both operating modes (list-all vs single-watch read) in one sentence. The resource 'diagnostic watch' cleanly separates it from sibling tools like read_callback_events and read_liveness_events, so an agent can select it without opening a 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 clear operative context: reads are free, use the cursor by persisting next_cursor as after, and poll no faster than every 30 seconds. It does not explicitly say when to prefer this over related read tools (read_callback_events, read_liveness_events) or when not to call it, so it stops short of full routing 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 readOnly/openWorld/destructive annotations, it discloses a wealth of behavior: a 30 reads/subscription/minute rate limit, seven-day expiry requiring a fresh subscription/snapshot, that deleted and monitoring_changed are terminal events, that retries can replay, and that evidence is self-reported. This is exactly the value-add a description should provide on top of structured 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?

Front-loads the core action and then packs rate limits, expiry, terminal-event semantics, and a caveat into tight sentences with no filler. Dense but every sentence earns its place, so nothing 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?

With an output schema present, the description needn't explain return values, and it still references next_cursor and has_more to support correct draining. Operational and behavioral guidance is thorough; only the ambiguity between the two subscription parameters leaves a minor 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% across three required params, so the description must compensate. It only partially does: 'after the saved cursor' clarifies the integer cursor param and 'Key is subscription-specific' hints at subscription_key, but the roles of subscription_id versus subscription_key are never distinguished.

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 ('Read heartbeat transitions') scoped to 'after the saved cursor', which clearly separates it from siblings like read_callback_events and subscribe_liveness. It does not, however, explicitly name a sibling alternative, so it stops short of the top band.

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 concrete operating context: poll every 30 seconds, drain pages when has_more, deduplicate event IDs, and persist next_cursor. This tells the agent how to drive the tool, though it never states when to prefer it over siblings or when not to call 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?

With readOnlyHint=false and destructiveHint=false already structured, the description adds real value: atomic registration+first receipt, owner key shown once and needing secure storage, default private with explicit public sharing, and a warning not to fabricate monitoring activity. It doesn't describe rate limits or what happens on duplicate registration, but the mutation/auth-sensitive traits are surfaced.

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?

Front-loaded with the core action, then packages mode behavior, the one-time owner key, and privacy defaults into a few tight sentences. A stray line break splits a sentence but the content is dense with little waste.

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

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

The description is adequate for a 12-param registration tool with annotations and an output schema: it covers safety, the one-time secret, and mode toggles. But with 0% schema coverage it leaves nine parameters unexplained and doesn't say what to do with the returned owner key beyond 'store securely,' which an agent needs in order to configure follow-up heartbeat calls.

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 param burden but only explains three of twelve parameters (mode, start_heartbeat, visibility, plus endpoint_url implicitly for probe mode). It says nothing about contact, agent_type, webhook_url, checks_config, heartbeat_enabled, check_interval_sec, or heartbeat_interval_sec, which is a significant gap at 12 params.

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 opens with a clear verb+resource: "Register a real worker once," and distinguishes two operating modes (heartbeat vs. probe) that no sibling name conveys. It's specific about the resource being a monitoring registration, though the existence of sibling tools like update_agent_health and agent_health_heartbeat means an agent must infer 'register' means the initial creation step rather than an update.

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 a conditional for start_heartbeat=true and says probe mode requires a deployed readiness URL, plus a visibility default. But it never states when to choose this tool over siblings like update_agent_health, attach_agent_endpoint, or subscribe_liveness, so the agent gets mode guidance without routing 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?

Annotations only cover the safety profile (readOnlyHint=false, openWorld=true, destructive=false). The description adds substantial non-derivable behavior: it sends a fixed-recipient email, grants no automatic payment/invoice/credit, splits responsibility (sales agrees terms, admin approves), and requires confirm=true or performs no action.

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

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

Front-loaded with the action and destination, and every sentence adds a distinct constraint (email behavior, contact rules, no-payment scope, confirm gate, approval split). The telegraphic, fragment-heavy style is slightly harder to parse than flowing prose but wastes little.

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 process, confirmation gating, and the human approval flow. It is essentially complete for calling the tool correctly; only the api_key parameter and any rate-limit expectations 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%, so the description must carry the burden. It defines the meaning of confirm (must be true, else no action), monthly_credits (normally 1000), request_key (reuse it), contact_email (real owner contact with permission, no secrets), and use_case (short). Only api_key is left undescribed, a minor gap against a fully undocumented 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 (request a monthly credit allowance) addressed to a specific recipient (sales@autonet.work) and names the default amount. It also routes the agent away from itself by pointing to read utility_account for status checks, so it is distinguishable from siblings without opening schemas.

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 operational context: reuse request_key, supply a real owner contact with permission, never include secrets, and read utility_account for status. Lacks an explicit 'do not use this when...' exclusion, but the workflow and alternative are both indicated.

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?

The description richly discloses behavioral details beyond the annotations: a cost model (1 credit per completed http/mcp/assert check), an idempotency rule (save one request_key per operation and reuse on retry), a spending safeguard (max_coins is your explicit spending cap), charging logic (broken targets and failed assertions still charge; invalid requests and worker failures cost zero), and replay semantics (replays return a privacy-safe receipt without rechecking or recharging). This is exceptional behavioral disclosure for a paid 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 text is dense but every clause delivers actionable information: pricing, idempotency, spending cap, charging rules, and replay behavior. It is front-loaded with the core cost model, though the multi-idea packing makes it slightly heavy.

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 paid, open-world diagnostic, the description covers cost model, idempotency, spending controls, failure-charge rules, and replay semantics, and an output schema exists to explain returns. The main missing piece is parameter-level detail for url, kind, and expect, given the 0% schema coverage.

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 carry the parameter burden. It meaningfully explains request_key (save one per operation, reuse on retry), max_coins (spending cap), and api_key context, and implies the assert check relates to 'expect'. However, the url and kind parameters and the expect object structure are never explained, leaving gaps.

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 it is an opt-in diagnostic using utility credits that performs http/mcp/assert checks. This is a specific verb+resource, and the credit/billing angle distinguishes it from the free diagnose_http or diagnose_mcp siblings. Without naming those alternatives directly, sibling differentiation remains implicit, keeping this a 4.

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

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

Usage is implied by 'Opt-in diagnostic' and 'Read pricing first', but there are no explicit when-to-use or when-not-to-use instructions versus the many diagnostic siblings (diagnose_http, diagnose_mcp, assert_healthy, run_autonet_sandbox). The agent gets context but must infer which diagnostic tool fits which 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?

Despite having annotations, the description adds substantial behavioral context annotations cannot convey: 1-credit pricing with no signing surcharge, zero cost on worker/signing failure, a five-minute expiry that retries never renew, and idempotent request_key behavior returning the SAME bundle. It also inverts the naive assumption that a valid signature means success, and describes what the signature binds (URL, assertions, result, observation time, nonce).

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?

Purpose is front-loaded and every sentence carries real information about cost, signature semantics, failure behavior, or retry rules. It is dense to the point of near-overload and the pricing sentence restates one idea twice ('same 1-credit price, no signing surcharge'), but nothing is 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 6-required-parameter, open-world, credit-consuming tool with an output schema, the description covers the hard parts an agent needs: prerequisites, cost, failure semantics, expiry, and retry idempotency. Remaining gaps are the allowed values/formats for kind, url, and expect, which neither the description nor the schema supplies.

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 7 parameters, so the description carries the full parameter burden. It meaningfully explains api_key (utility key), max_coins (must be explicit), evidence_nonce (random 16-128-char URL-safe value from the receiving principal) and request_key retry semantics, but leaves url, kind, and expect 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?

States a specific verb (run) plus the resource (HTTP/MCP/assert diagnostic) and the distinctive artifact it produces (signed evidence for delegation), which naturally separates it from run_credit_diagnostic and diagnose_http. It never names a sibling explicitly, so an agent must infer the boundary from the 'signed'/'delegation' qualifier rather than being told.

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 operating rules: when retries are uncertain reuse request_key, when signing is inappropriate ('No generic signing of caller-provided claims'), and where to get verifier guidance (internet_utils_instructions). It stops short of an explicit 'use this instead of X when Y' comparison against the many sibling diagnostic and evidence 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?

Adds substantial context beyond the annotations: auth requirement (owner key), privacy behavior (note/version stay private), throttling behavior (honor Retry-After), a real side effect (dormant workers revive on receipt), and an explicit limitation (does not prove service uptime). With annotations only covering readOnly/openWorld/destructive, this is rich disclosure.

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

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

Four short sentences, front-loaded with the core action, and each sentence adds a distinct operational fact. No padding.

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, and the description covers auth, side effects, privacy, and throttling. It stops short of explaining the status parameter or failure semantics, but is otherwise complete for a heartbeat call.

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 carries the full burden, and it only explains the privacy of two parameters (note, version) plus implicitly the owner key/API key. status and agent_id are left without meaning, leaving meaningful gaps against 5 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?

States a specific verb and resource ('send a self-reported heartbeat') and clarifies the scope ('from the actual worker'). It doesn't differentiate itself from the close sibling agent_health_heartbeat, which an agent would need to disambiguate, so it stops short of a 5.

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

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

Provides a prerequisite ('Owner key required') and a rate-limit instruction ('Honor Retry-After'), plus a caveat that it doesn't prove uptime. However, it never says when to choose this over agent_health_heartbeat or agent_health_heartbeat-adjacent siblings, 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 only flag it as a non-destructive write with open-world effects; the description adds a lot beyond that: the key is returned only once, the cursor/key must be saved, the initial snapshot is self-reported and not verified reachability, 10 creation attempts/IP/day, and no push delivery. These are non-obvious traits an agent must know before calling.

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 but every clause carries load-bearing information: key rules, return-value persistence, snapshot caveat, rate limit, delivery mode. Front-loaded with the action and target constraints, 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?

Despite an output schema, it usefully warns that subscription_key and cursor are returned only once and must be saved, plus rate limits and the self-reported nature of the snapshot. Nothing an agent needs to invoke or correctly consume the subscription 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 0%, so the description must carry both parameters. It explains api_key semantics (omit for public targets, owner key for private) and constrains agent_ids to 1–20 existing heartbeat agents, which is meaningful beyond the bare schema 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?

States a specific verb+resource+scope: 'Opt in to a seven-day pull feed for 1–20 existing heartbeat agents.' It is clearly differentiated from siblings like delete_liveness_subscription and read_liveness_events, which handle removal and consumption of the same feed.

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?

Explains the key requirement: public targets need no key, private targets require the owner's api_key, which tells the agent when and how to invoke it. It does not explicitly name read_liveness_events/delete_liveness_subscription as the downstream alternatives, so routing guidance is implicit via 'pull feed' and 'No push delivery'.

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 a non-read-only, non-destructive, open-world call, and the description adds substantive context beyond them: no incident or score change, a once-per-minute rate limit, owner-only authorization, and the confirm=true gate that makes an omitted confirmation a no-op. These are exactly the behavioral facts an agent cannot infer from 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 purpose is front-loaded in the first sentence, followed by constraints and the confirmation requirement in four tight sentences. Every clause carries actionable information with 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 state-adjacent, confirm-gated action with an output schema, the description covers side effects, rate limits, auth, the confirmation flow, and even points at output fields ('delivered and receiver_status'). Nothing needed 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 coverage is 0%, so the description must carry parameter meaning. It explains confirm thoroughly ('omitted confirmation performs no action'), but agent_id and api_key are left entirely to their schema titles, which is a real gap at 0% coverage.

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

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

The description states a specific verb and resource: 'Send one signed incident.test to your configured webhook.' It is clearly distinct from siblings like agent_webhook_secret (which manages credentials) and the inbox tools, but it never names an alternative to differentiate itself explicitly.

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

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

It gives concrete operating conditions: 'Owner-only, once/minute', 'Inspect delivered and receiver_status; do not automatically replay', and 'Requires confirm=true after reviewing the effect'. The do-not-replay and confirmation guidance is strong, though it stops short of naming sibling alternatives an agent might confuse it with.

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 destructive=true and openWorld=true, but the description adds real value beyond them: owner-only auth requirement, that agent_id and owner key persist across renames, that names are self-declared and unverified, that setting visibility=private revokes subscriptions, and that endpoint/webhook must be public URLs the caller controls.

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?

Front-loads the critical constraint ('Owner-only update') and then packs dense, non-redundant guidance into short clauses. Every sentence earns its place with 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a 10-parameter tool with zero schema description coverage, several parameters (checks_config, heartbeat_enabled, check_interval_sec) are never addressed, leaving meaningful gaps.

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

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

Schema coverage is 0% across 10 parameters, so the description must carry the load. It explains name, visibility, paused, endpoint_url, and webhook_url, but leaves checks_config, heartbeat_enabled, check_interval_sec, api_key, and agent_id completely undocumented, so it only partially compensates.

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 verb and target ('Owner-only update') and enumerates the updatable fields (name, visibility, paused, endpoint, webhook), so an agent understands the operation. It does not explicitly distinguish itself from siblings like register_agent_health or delete_agent_health, keeping it short of a 5.

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

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

Gives concrete when-to-use context for parameters: 'Pause when retiring/testing; resume with paused=false' and 'Set visibility=public to share... or private to revoke sharing and subscriptions.' There is clear contextual guidance but no explicit exclusions or routing to alternative tools.

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

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

Annotations already flag destructive=true and openWorld=true, and the description goes well beyond them: budget is a lifetime cap rather than an added grant, there are no automatic increases, pause is immediate but an in-flight check may still finish and charge, and accepting a baseline authorizes future credit use but never a cash payment. These are exactly the side-effect and irreversibility details an agent needs before mutating a watch.

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 action list is front-loaded in the first sentence and each subsequent sentence carries a distinct constraint. Several sentences are dense fragments ('No automatic budget increases.'), which is efficient but slightly telegraphic rather than fully 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 destructive mutation tool with an output schema present (so return values need no explanation), the description covers confirmations, side effects and the meaning of a baseline acceptance. It falls short only on the undocumented required-parameter semantics and the possible values of state.

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 carries the burden. It usefully explains confirm, max_coins (the budget cap semantics) and accept_baseline, but leaves the accepted values of state implicit, and says nothing about the two required parameters watch_id and api_key. Roughly half the parameters are given meaning, so a middling score is warranted.

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 precise enumeration of the four operations the tool performs (pause, resume, increase lifetime budget, accept baseline) on a diagnostic watch, which maps cleanly onto update_diagnostic_watch. It is easy to separate from create_diagnostic_watch, delete_diagnostic_watch and read_diagnostic_watches even though those siblings are never named explicitly.

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

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

It gives concrete usage conditions: resume/budget/baseline require confirm=true, pause is immediate, and a baseline should only be accepted from a reviewed fingerprint of the latest complete observation. What's missing is explicit routing to siblings (e.g. create/delete/read watches) or guidance on when no update is warranted.

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.