Voidly Hosted MCP

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe-read profile is covered. The description usefully adds what the statistics comprise, but says nothing about auth requirements, rate limits, or freshness of the metrics. 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?

A single front-loaded sentence with the verb and resource first followed by the returned metrics. Every clause earns its place with no 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?

With no output schema, the description compensates by enumerating the returned fields, and with zero parameters and readOnly annotations there is little else an agent needs. It could still note metric freshness or auth, but it is largely complete for a simple stats endpoint.

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 no parameter semantics to document; the schema is trivially complete at 100% coverage. Baseline of 4 applies for a parameterless tool.

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

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

States a specific verb ('Get') and resource ('Voidly Agent Relay network statistics') and enumerates the concrete metrics returned (registered agents, 24h active agents, channel count, message volume, capability registry). It does not explicitly differentiate itself from siblings like get_incident_stats or get_probe_stats, so it falls short of a 5.

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

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

There is no guidance on when to call this versus alternatives such as voidly_capabilities, voidly_home, or get_probe_stats. Usage is only implied by the tool name and description; no exclusions or conditions are 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 non-readonly, open-world, non-idempotent, non-destructive. The description adds real behavioral context beyond them: the body bytes must be forwarded unmodified, the caller must supply an Ed25519 signature over the exact board path, no key is stored server-side, and no payment occurs. It omits nonce-replay and timestamp-window behavior, but the signing contract is well 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?

Four short sentences, front-loaded with the core contract (unmodified byte forwarding) before the signing requirement and the two exclusions. No filler; every sentence carries 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/mutation profile. The description supplies the unusual signing workflow and the no-key/no-payment guarantees. Gaps remain around replay protection and timestamp validity, but the essential operational contract is 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% with six parameters, so the description must carry the load and only partly does: it explains replyTo as the public thread selector and implies signature/did semantics via the Ed25519 signing statement. did, nonce, timestamp, and bodyJson constraints (formats, size limits, freshness) go unexplained in prose.

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 title and first sentence establish a specific operation: forwarding a caller-signed raw JSON body to a public board. It distinguishes the mechanism (signed post) from siblings and notes no payment is involved, implicitly separating it from the voidpay_* tools. It does not explicitly name a sibling it should be preferred over.

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 prerequisite ('a local client must sign the exact board path with its Ed25519 key') and rules out payment, giving useful context. However, it never says when to choose board_post versus board_reply_private or board_reply variants, leaving the private-vs-public reply distinction to inference from 'replyTo selects a public thread reply.'

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/idempotent/non-destructive, so the bar is lower, and the description still adds real value: a hard reply cap of 20, the guarantee that private replies are excluded, and a prompt-injection warning that board text and links are untrusted public content.

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, zero filler, with the core read scope front-loaded and the security caveat last.

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 low-complexity read tool with an output schema (so return values need no explanation), the description covers scope, privacy filtering, and the untrusted-content caveat; only cursor-based pagination is left unexplained.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning; it explains the reply cap ('up to 20') which matches the limit maximum, but says nothing about cursor pagination, which is the non-obvious parameter for retrieving results beyond the first page.

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 scope: 'Read one post and up to 20 public replies.' The clause 'Private replies are never included' implicitly distinguishes it from the sibling board_reply_private, though it never names alternatives like board_post or board_search.

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 'Read one post' and the private-reply exclusion, but there is no explicit statement of when to prefer this over board_search or board_post, and no prerequisites or exclusions beyond the privacy rule.

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 (readOnly/idempotent/openWorld/non-destructive), the description discloses substantive constraints: no message text, ciphertext or keys accepted, no reply sent, and that sender/recipient DIDs are retained in the DM rail. These privacy and scope facts are exactly what an agent needs and are not in the structured fields.

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, purpose front-loaded, followed by scope exclusions. No filler, though the retention note ('The current DM rail retains...') is slightly abrupt and could tie back to privacy more explicitly.

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. The description usefully clarifies that no reply is actually sent despite the 'reply' name, though it leaves the postId parameter entirely unexplained.

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

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

Schema description coverage is 0% and the description never mentions the single parameter or its required UUID postId format. With the schema carrying no prose, the description fails to compensate; only the indirect mention of 'post author' hints at the input'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 specific verb and resource: 'Resolve the post author,' distinguishing this private DM-prep operation from the public board_post/board_read/board_search siblings. The framing is slightly at odds with the 'reply' name and title, which could confuse an agent about whether a reply is sent, but the first sentence is concrete.

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: the description rules out sending and content handling, signaling the caller must compose the DM locally, but it never states when to pick this over alternatives or what workflow it belongs to. No sibling is named as an alternative.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new context: the result is a single 'bounded' page, and the returned content is untrusted, with listing links explicitly not payment proof. That trust/warning detail goes beyond anything structured fields provide.

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

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

Three short sentences with no filler, and the core scope statement is front-loaded. The trust warning is compact and earns its place, though the three ideas are slightly disjointed.

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 untrusted-content warning covers a real risk. Still, for a five-parameter tool with 0% schema coverage, the description omits too much (query syntax, tag meaning, limit default, cursor pagination) to be fully actionable.

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

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

Schema description coverage is 0% across five parameters, so the description must carry the burden, yet it only clarifies 'board' (omit for all). The query (q), tag, limit, and cursor parameters are entirely undocumented, leaving pagination and filtering semantics unexplained.

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

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

The description gives a concrete verb and resource: 'Read one bounded public board page', with 'public board' establishing scope. It is clear it is a bounded read, but it never mentions that this tool accepts a query string or tag to filter, which is the defining behavior of a 'search' tool.

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?

'Omit board for All posts' gives an explicit conditional on one parameter, which is useful usage guidance. However, it never states when to use this tool versus siblings like board_read or board_post, so routing between board tools is left to inference.

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=true, openWorldHint=false), and the description adds genuinely useful behavioral context by naming the return fields (blocking status, evidence sources, confidence, blocking method) and the detection techniques (DNS, TCP, TLS, HTTP). It omits caveats like snapshot vs. real-time detection or latency, which keeps it short of 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?

Two tightly written sentences with no filler; the purpose is front-loaded and the return-value detail follows compactly.

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

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

There is no output schema, so the description carries the burden of describing return values, which it does by enumerating status, evidence, confidence, and method. For a simple two-parameter read operation with annotations covering safety, nothing critical is missing, though detection limitations are 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 coverage is 100%, so the schema already documents both parameters with examples. The description adds no syntax or format detail beyond what the schema provides, so the baseline 3 is appropriate.

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

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

The description states a specific verb ('Check') and resource ('a specific domain is blocked in a country'), and the blocking-method detail distinguishes it from siblings like check_service_accessibility or get_domain_timeline. An agent can identify the tool's function 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?

Usage is implied by the name and description (check a domain's blocking status in a given country), but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as get_national_blocklist or check_service_accessibility. This is minimum-viable context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine context by flagging real-time freshness and enumerating return fields (blocking status, block rate across ISPs, evidence), but it discloses no rate limits, latency, or coverage caveats.

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

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

Two tight sentences, front-loaded with the core question and followed by the return summary. Nothing is wasted, though the second sentence is a lightweight list rather than substantive detail.

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

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

With no output schema, the description correctly summarizes what is returned, and both required params are documented in the schema. However, for a tool sitting among many overlapping censorship/accessibility siblings, the description lacks the routing context an agent needs to pick it confidently.

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

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

Schema description coverage is 100%, with both domain and country fully documented including examples and the ISO 3166-1 alpha-2 format. The description adds no additional parameter meaning, so the baseline 3 applies.

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

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

The description states a specific verb (check) and resource (domain/service accessibility in a specific country), and adds real-time scope plus the shape of the result (blocking status, block rate across ISPs, evidence). It is clear what the tool does, but it never differentiates itself from similarly named siblings such as check_domain_blocked, get_ai_service_availability, or get_national_blocklist.

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 when-to-use guidance or named alternative. The phrase 'right now' implies a temporal scope (current status vs. historical tools like get_domain_timeline), but the agent must infer that itself, 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 cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds meaningful behavior beyond them: large outputs are truncated, the status column distinguishes corroborated vs suspected rows, and the REST URL is the escape hatch for full files. Missing only specifics like the truncation threshold or auth requirements.

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

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

Three tight sentences with the core purpose front-loaded and no filler. Each sentence carries distinct information (formats, output semantics, truncation guidance), though the format list partially duplicates the schema.

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

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

With no output schema, the description bears the burden of explaining returns; it does cover the status column and truncation, which is useful. However it never says where the 'REST URL' comes from or what the export actually returns, leaving a gap an agent would hit in practice.

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

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

Schema description coverage is 100%, so format enum and country ISO filter are already documented. The description restates the format options and adds only a weak contextual hint that country filtering reduces truncation. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Bulk export of the incident corpus') and enumerates the output formats, which cleanly separates it from single-record siblings like get_incident_detail and incremental ones like get_incidents_since. It does not explicitly name those siblings, so differentiation is implied 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?

Provides some operational routing — 'filter by country or fetch the REST URL for the full file' — but this addresses truncation, not tool selection. There is no explicit when-to-use versus the many get_incident_* siblings; the bulk-vs-incremental distinction is left to inference from the word 'bulk'.

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 openWorldHint=false, so the safety profile is covered; the description usefully adds behavior beyond that — a best-first ranking that surfaces real events over single-source outage signals, and the default citable=true filtering behavior. It stops short of describing return shape or volume/pagination behavior.

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

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

Three compact sentences with the core purpose and ranking behavior front-loaded. The sentence about the human-readable ID format earns its place by flagging citability, though it is slightly tangential to invoking the 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?

With no output schema, the description still notes the citable ID format and the ranking/ordering behavior, and the readOnly annotation covers the safety profile. An agent has everything needed to call this correctly for a simple filtered list 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 100%, so all four parameters (limit, citable, country, min_sources) are already fully documented in the schema. The description only re-explains citable (its false branch) and adds no syntax or semantics for limit/country/min_sources, matching the baseline for schema-dominated definitions.

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+resource ('Get citable censorship incidents') and adds scope/ordering ('multi-source, evidence-backed, ranked best-first'), distinguishing citable incidents from raw single-source IODA outage signals. It does not name any of its close siblings (e.g., get_incidents_since, get_incident_detail), so it falls just short of full sibling differentiation.

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

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

Provides one explicit conditional ('Set citable=false to include raw outage signals'), which hints at when to loosen filtering, but offers no when-to-use guidance relative to the many incident-related siblings or any exclusions. Usage is largely 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful semantics by stating that state blocking and vendor geo-restriction are labeled separately in the results, but it says nothing about freshness, coverage scope, or how the labels appear.

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 (per country), the resource (AI services), and the distinguishing output semantics are all packed into one clause with zero waste.

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

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

With no parameters and no output schema, the description carries the burden and mostly meets it by stating what is returned conceptually (per-country reachability with separately labeled blocking types). A brief note on data source or freshness would close the remaining gap, but nothing essential is missing.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there are no parameter semantics for the description to clarify or omit.

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 one-liner names a concrete resource (AI services such as ChatGPT, Claude, Gemini, HuggingFace) and the scope (per country), and adds the key distinction between state blocking and vendor geo-restriction. It does not explicitly name the closest siblings (check_service_accessibility, check_domain_blocked), so an agent must infer the routing.

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, when-not-to-use, or alternative naming, despite heavy overlap with check_service_accessibility and check_domain_blocked in the sibling list. Usage is only implied by the topic itself, which is insufficient for choosing among several similar availability 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 and openWorldHint=false, covering the safety profile. The description adds real context beyond that: the method (unsupervised DBSCAN, CenDTect-style), an accuracy figure (AUC 0.65), and the fact that it surfaces 'shape-anomalous days labels never saw' — useful behavioral framing about output character and reliability.

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 core purpose and packs methodology, accuracy, and output character into a parenthetical. Every clause carries information, though the parenthetical is somewhat heavy for the tool's simplicity.

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

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

For a one-parameter read-only tool with no output schema, the description covers purpose, method, accuracy, and output character adequately. It lacks any note on return shape or usage conditions, but those are minor for a tool this simple.

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

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

The single country_code parameter is fully documented in the schema (100% coverage, with ISO 3166-1 alpha-2 format examples), so the description adds nothing about parameter semantics. Baseline 3 is correct when the schema does all the work.

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 (produces a DBSCAN anomaly score), scopes it explicitly to a country, and names its relative role as a 'second-opinion' that is 'weaker than the supervised classifier,' which corresponds to sibling tools like get_classifier_score. An agent can distinguish this from the supervised classifier tools 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?

The phrase 'second-opinion' implies when this tool is useful (as a complement to the supervised classifier), but the description never explicitly names an alternative or states a when/when-not condition. Usage is inferable but not spelled out.

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 openWorldHint=false, so the safety profile is covered. The description adds that the output consists of A–F censorship grades and that omitting country_code returns all graded countries, but it does not describe return structure or other behavioral details beyond that.

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

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

The description is two efficient sentences with no wasted words. It front-loads the resource and output type before giving the optional parameter guidance.

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

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

For a simple one-parameter read tool with annotations and no output schema, the description covers what the tool returns and how to scope it. It could be slightly more complete by clarifying the return shape of the grade table, but overall it is adequate.

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

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

Schema description coverage is 100%, and the schema already documents country_code as an optional ISO alpha-2 code. The description reinforces the omit-for-all behavior but adds no syntax, format, or validation detail beyond what the schema provides, so the baseline 3 applies.

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

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

The description states a specific verb-resource pair: retrieving 'Atlas Score v2 A–F censorship grade(s).' It clearly defines the returned data type and the optional scope, but it does not explicitly distinguish this tool from related siblings such as get_censorship_index or get_country_profile.

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 clear parameter-driven usage guidance: 'Pass country_code for one country; omit for all graded countries.' However, it offers no guidance on when to use this tool versus the many sibling censorship-grade/report tools, so the usage context is only implied.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine behavior beyond that: the returned counts are a floor ('over the >=3-network confirmed layer') and China is under-counted due to the GFW anomaly — meaningful data caveats an agent should know before trusting the numbers.

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 opening clause and the caveat is clearly flagged with 'HONEST'. However the middle sentence is a dense three-clause run-on about domain/block/country counts that could be tightened; it is information-rich but bordering on verbose.

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

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

With no parameters, no output schema, and structured fields covering the safety profile, the description fully describes what the tool returns (human names, domain counts, confirmed-blocked counts, country counts) and the constraints on those numbers. 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate on the input side.

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 ('maps every category code ... to its human name') and enumerates example codes (NEWS, POLR, HUMR...). The scope (a legend/reference table) is unmistakably distinct from siblings like get_category_coverage or get_category_leaders, 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?

Explicitly names when to reach for it: 'The reference for interpreting any category code returned by get_category_leaders, get_censorship_intent, or the national blocklist.' This routes the agent from three sibling tools to this one with a clear condition.

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=true, openWorldHint=false), so the description's burden is lower. It still adds real behavioral context: the quantified blind spot (~69% coverage via the 14k-domain Citizen Lab list), the framing that the tool exposes its own limitation, and the exact return contents.

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 question, then the return shape, then the use case — every clause carries information. The em-dash aside about disclosing a blind spot is editorial but still informative; a slightly tighter phrasing would reach 5.

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

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

With no input parameters and no output schema, the description carries the full burden and discharges it by naming the aggregate and per-category return values plus the coverage figure. Nothing an agent needs to call this correctly or interpret the result is missing.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies no input configuration is needed and focuses entirely on what the call produces.

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 measure (what fraction of the measured-domain corpus carries a Citizen Lab category) plus the concrete output shape (tagged/untagged counts and per-category domain counts). This is clearly distinct from siblings like get_categories or get_censorship_by_category, which return category data rather than coverage-of-categorization meta-data.

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

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

"Use to gauge how complete any 'by category' analysis is" gives a clear triggering condition and implicitly routes the agent here before trusting category breakdowns. It stops short of naming the specific sibling tools whose results it qualifies, so it is not a full when/when-not/alternatives statement.

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 openWorldHint=false, so safety is covered. The description then adds substantive behavioral context beyond the annotations: the ranking methodology (confirmed across >=3 networks) and a candid caveat that anomaly-based censors like China's GFW are under-counted, so counts are a floor. That data-limitation disclosure is genuinely useful, though return format details are not given.

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?

Delivered in two dense, front-loaded sentences with the key question answered first and the methodology and caveat following. The mid-sentence list of category codes (NEWS, HUMR, ANON, ...) partially duplicates the schema, which is minor redundancy but otherwise the text 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?

There is no output schema, so the description carries the burden of explaining returns, and it does: countries ranked by distinct blocked domains with example domains given. Combined with annotations covering the safety profile and the stated counting caveat, an agent has everything needed to call and interpret 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 coverage is 100% and the single parameter is documented in the schema, but the description adds value by giving a concrete usage example (category=LGBT) and reinforcing the set of valid category codes. It clarifies the semantics of what the parameter drives (the ranking) rather than merely repeating the schema.

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

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

The description states a specific verb+resource: it ranks countries by how much they censor a given Citizen Lab content category, measured by distinct domains nationally blocked. This is a clear, distinctive purpose that separates it from generic siblings like get_censorship_by_category or get_most_blocked_domains, though it does not name any 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 implied through the worked example (category=LGBT -> Russia/Iran/Indonesia) and the valid code list, so an agent can infer when it applies. However, there is no explicit when-to-use vs. when-not, and no routing to alternatives like get_censorship_by_region or get_most_censored.

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 openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that - what the data actually reveals (content-targeted blocking, e.g. TCP-reset for messaging vs DNS-poisoning for news) - without covering pagination or output format.

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 front-loaded clauses with the core purpose first, then a concrete illustration, then parameter guidance. The 'e.g.' example is somewhat long but earns its place by clarifying the emission insight; no redundant 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?

With no output schema, the description carries the burden of describing returns and does so conceptually (per-category technique composition). A single optional parameter tool with readOnly annotation is well covered, though return shape (list/aggregate format) is 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 100%, so the ISO 3166-1 alpha-2 semantics are already documented. The description still adds meaning beyond the schema by specifying the default behavior when the parameter is omitted (global view), which the schema alone does not state.

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: it returns the blocking-technique composition per content category, with concrete examples (news, communication tools, anonymity/VPN, search, adult). The 'by category' axis implicitly distinguishes it from sibling get_censorship_by_region, letting an agent pick the right one 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?

Explicitly tells the agent how to vary scope: 'Omit country_code for a global view; add it to see one country.' That is clear when-to-use guidance conditioned on the parameter, though it names no alternative sibling tool or exclusion.

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 and openWorldHint=false, so the description carries the real behavioral load: it discloses the >=3-network confirmation gate, explains why Africa shows 0 confirmed blocks despite high block fraction, and explicitly labels the confirmed-block counts as a measurement-density map rather than a ranking. That is exactly the kind of non-obvious caveat an agent needs to avoid misreporting the data.

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-loaded with what is returned, then the caveat, then the recommended fields to use. No filler; the honesty caveat is the highest-value content and is given prominent placement.

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

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

With no output schema, the description still names the returned fields (countries measured, block fraction, confirmed national blocks per region) and explains how to interpret them. For a read-only, single-parameter aggregation tool, nothing an agent needs to call or report on it correctly is missing.

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

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

Schema coverage is 100% and the single parameter is already described, but the description adds specificity beyond the schema by tying level=subregion to 'UN sub-region' and restating the continent default in operational terms. This is modest added value on top of an already-documented 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?

States a specific verb+resource ('Censorship aggregated by world region') and immediately scopes it with the level parameter (continent by default, UN sub-region otherwise), which cleanly separates it from siblings like get_censorship_by_category or get_global_heatmap. An agent can identify the tool 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?

It gives interpretation guidance ('Use block_fraction + countries_measured for context') and warns about the measurement-density trap, which is useful for reading results, but it never states when to choose this tool over the many sibling censorship aggregations (by_category, index, summary). Usage 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 cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower, yet the description still adds real context: the aggregation sources (OONI, IODA, CensoredPlanet), the recent measurement window, and the fact that country coverage varies and must be read from the response. That variability caveat is exactly the kind of operational detail an agent needs.

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, front-loaded with the core action, then return shape, then the coverage caveat. Nothing is redundant or padded, though the final sentence is slightly clipped in phrasing.

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

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

With no output schema, the description carries the burden of describing return values and does so: country scores, risk tiers, and measurement counts. Combined with the coverage caveat, an agent has enough to call and interpret it, though it omits any hint about freshness or update cadence.

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 no parameters, so there is nothing for the description to disambiguate; the 0-parameter baseline is 4. The schema is empty and fully covered, and the description correctly focuses on output semantics instead.

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 resource (the global censorship index) and its scope (rankings for monitored countries), so an agent can tell it apart from narrower siblings like get_most_censored or get_censorship_by_region. It stops short of explicitly contrasting with the nearest siblings, so a 4 rather than a 5.

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

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

There is no statement of when to prefer this tool over the many sibling index/summary tools (get_censorship_summary, get_global_heatmap, get_atlas_score). The only soft guidance is the instruction to read coverage from the response, which is a hint about interpretation, not tool selection.

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

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

Annotations already indicate this is a read-only, non-open-world operation. The description adds valuable behavioral context: results are confirmed across >=3 networks, China is under-counted because GFW is treated as an anomaly rather than confirmed, and shares are computed only over tagged domains. These caveats substantially improve interpretation.

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

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

The description is dense but front-loaded, leading with the core purpose and then supplying category definitions and caveats. Most parenthetical details earn their place, though the single long paragraph mixes several concepts and abbreviations without much visual structure.

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

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

For a read-only analytics tool with no output schema, the description covers the key output concepts (focus shares, full category breakdown, primary_focus), the optional country filter, and important data limitations. It could better explain the abbreviated category codes, but overall it is sufficient for correct invocation and interpretation.

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

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

Schema description coverage is 100%, and the single optional country parameter is already documented in the schema with an ISO example. The description adds only that passing country gives one country, which is a minor clarification beyond the schema baseline.

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 analytical purpose: what each censor targets per country, including category mix, three focus shares, and primary focus. It clearly distinguishes this intent-oriented tool from related sibling tools like get_censorship_by_category by explaining that it reveals WHY a country censors.

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 parameter-level guidance ('Pass country=XX for one country') but does not explicitly say when to use this tool versus alternatives such as get_country_profile or get_censorship_by_category. Usage is implied by the purpose rather than stated with comparisons or exclusions.

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

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

Annotations already cover safety (readOnlyHint, openWorld=false), so the description's real value is the data-quality disclosure: most_blocked_category is legal gambling-blocking not political, and China is under-counted (GFW=anomaly). These honest caveats materially change how an agent should interpret results and are not recoverable from annotations. It lacks detail on output shape, but no parameters and a snapshot scope limit that concern.

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 core purpose is front-loaded in the first clause, followed by a tight enumeration and then the honesty caveats. It is dense and runs long across two sentences, but nearly every clause carries information an agent needs; minimal 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?

With no parameters and no output schema, the description carries the full burden and delivers by listing the return contents and qualifying their reliability. An agent has everything required to decide to call it, call it with no args, and interpret the response.

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

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

The schema has zero parameters and 100% coverage, so there is nothing to document and the baseline for 0 params is 4. The description correctly adds no parameter noise.

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 ("One-call snapshot of the state of global censorship Voidly measures") and then enumerates exactly what the snapshot contains: countries measured, confirmed national blocks, deepest censor, broadest-blocked category, depth, coverage, freshness. This makes it immediately distinguishable from the many sibling per-metric endpoints (e.g. get_most_censored, get_national_blocklist).

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 ideal first call" plus the example query routes the agent to this as the entry point, and naming "links to the per-metric endpoints" signals the alternatives for drill-down. However, it never states an explicit when-not condition, so the selection guidance is strong but not complete.

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 openWorldHint=false, so the safety profile is covered. The description adds useful content context by naming the technique taxonomy the response is broken down by, plus an illustrative China/TCP-reset example. It stays silent on return format, data freshness, and whether values are per-country aggregates or raw counts, which is the remaining gap for a read-only analytic 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?

Front-loaded with the core value proposition, then the technique list, then the usage rule. It is a single flowing sentence plus a short clause, with the China example earning its place as a concrete illustration. Slightly heavy on enumeration but 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?

For a single-optional-param, read-only tool with 100% schema coverage and no output schema, the description is nearly complete: it explains purpose, scope, technique categories, and the country-vs-global switch. It could note data time range or aggregation level, but nothing essential to 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?

Schema coverage is 100% — the schema already documents country_code as an optional ISO 3166-1 alpha-2 code with an 'Omit for all countries' note. The description's 'omit for a global all-country view' largely restates that, adding only a format example (CN). Baseline 3 is appropriate when the schema does the work.

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+resource ('breakdown of blocking techniques') and enumerates the technique dimensions (DNS manipulation, TCP-reset injection, Tor blocking, DPI/middlebox, etc.), so an agent knows exactly what this returns. The 'how a country censors, not just what' framing distinguishes it from the summary/index/'what is blocked' siblings, though it never names the closely related get_censorship_technique_trend.

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 one concrete usage rule ('Omit country_code for a global all-country view'), which is genuinely helpful. However it never states when to use this over alternatives like get_censorship_technique_trend, get_censorship_intent, or get_censorship_summary, leaving the agent to infer the distinction from the description's framing alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuinely valuable behavioral detail beyond annotations: shares are coverage-robust percentages rather than raw counts and are therefore not skewed by growing measurement volume. It stops short of return shape/pagination specifics, keeping it at a strong 4.

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 purpose, then the sibling disambiguation, then a data-semantics caveat and the scoping defaults. Every sentence 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?

With no output schema, the description must imply the return shape, and 'monthly percentage composition' does so adequately, while annotations cover safety. A minor gap remains around exact output fields and pagination, but nothing essential to 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?

Schema description coverage is 100%, and the description's parameter guidance ('Omit country_code for global; months defaults to 12') largely restates the schema's own descriptions ('Omit for all countries', 'default 12, max 60'). Baseline 3 is appropriate since the schema carries the semantics.

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

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

States a specific resource (censorship method mix) and verb/scope (shifts over time, monthly percentage composition) and enumerates the techniques measured. It explicitly distinguishes itself from the sibling get_censorship_techniques by labeling that one a snapshot and this the trend, so an agent can route without opening either 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?

Names the alternative (get_censorship_techniques) and the exact condition that selects between them (snapshot vs trend). Also gives the operator lever: 'Omit country_code for global; months defaults to 12', leaving no inference needed for scoping.

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 openWorldHint=false, so the safety profile is covered. The description adds a substantive behavioral claim beyond that: the response includes evaluation methodology and caveats, suggesting an honest, self-critical disclosure rather than a raw number. However, it does not describe the shape or volume of that 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?

A single front-loaded sentence with a colon list of contents. It is efficient and waste-free, though the fragment style is terse rather than fully structured prose.

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-arg, read-only tool the description is close to sufficient, but with no output schema and no explanation of return format, an agent does not know how version, training data, methodology, and caveats are presented. It is adequate but leaves the response shape unspecified.

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, which sets the baseline at 4 per the rubric. With no inputs to misdocument, the description is not required to carry parameter burden 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 resource (classifier transparency) and enumerates what it returns: version, training data, evaluation methodology, caveats. It is clear what the tool delivers. It is not fully differentiated from siblings like get_classifier_scope or get_classifier_score, which the description does not name or contrast against, so it falls short of a 5.

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

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

There is no when-to-use guidance, no condition that selects this tool over get_classifier_scope or get_classifier_score, and no exclusions. An agent sees an alphabetically adjacent trio of classifier tools and gets no routing signal from this description.

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 openWorldHint=false, so the safety profile is covered. The description adds real value beyond them by disclosing data provenance ('reads the live training sidecars') and a vintage caveat (the retired v2 '0.998 F1' figure had country-tier leakage). Liquidity of results is hinted at but return format, caching, and cost are not discussed.

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 content is dense and almost every clause earns its place — the regime names, the AUC/F1 pairs, the delta AUC, and the v2 caveat are all decision-relevant. It opens with a rhetorical question rather than the operation, and the closing 'HONEST:' restates the earlier 'The honest answer', a minor duplication.

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

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

With no output schema, the description carries the full burden of describing returns and does so thoroughly: which regimes, which metrics, the sample basis (127 countries), the generalization gap, and guidance on which metric to cite. An agent can answer the accuracy question correctly without any further source.

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 and the schema is fully closed (additionalProperties: false), so there is nothing for the description to disambiguate. Baseline 4 applies and no parameter discussion is needed.

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

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

The description states precisely what the tool returns: accuracy under three named evaluation regimes (stratified-random, leave-country-out, forward-temporal) with concrete metrics and the generalization gap. That is a specific verb+resource. It does not, however, name the sibling it supersedes — get_classifier_score or get_classifier_info — leaving the 'never quote one number alone' contrast implicit 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 gives an explicit triggering condition ('Use when asked how accurate is the model?') and a directive against the common misuse ('never quote one number alone'). That is clear context, but no named alternative is offered for callers who want a single headline number, and no exclusions are 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 establish read-only and closed-world behavior. The description adds useful context about model version and validation metrics, including a caveat about median F1 inflation, but it does not explain the returned score's scale, meaning, or interpretation.

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, beginning with the resource and then placing model details in a parenthetical. The model-performance statistics are dense but relevant to interpreting the score.

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

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

For a simple read-only score tool, the schema and annotations cover invocation and safety, and model provenance adds some context. However, with no output schema, the description should explain what the score represents or its scale, and it does not.

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

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

Schema description coverage is 100%, so the single country_code parameter is fully documented in the schema. The description adds no parameter-specific details beyond the schema, so the baseline 3 is appropriate.

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

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

The description identifies the resource as a 'country-day censorship classifier score' and adds model provenance, but it uses a noun phrase rather than stating an action and does not distinguish this from sibling tools like get_classifier_info or get_classifier_scope.

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

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

There is no guidance on when to use this tool versus alternatives, nor any prerequisite or context for selecting it. The description provides only model metadata, not usage conditions.

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

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

Annotations already declare it a safe read (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description still adds real value beyond that: it warns that overlap is correlation and NOT proof of coordination, and discloses a data limitation ('China under-counted'). Those caveats meaningfully shape how an agent should interpret results.

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 core definition is front-loaded before the illustrative example and the honesty caveat. It is dense and parenthetical-heavy, but nearly every clause carries signal; only the specific Iran-Russia numbers verge on more detail than an agent needs to select the tool.

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

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

For a zero-parameter, no-output-schema tool, the description covers what is returned (the signals and their acronym expansions), the interpretive caveat, and a known data gap. Ordering or result limits are unstated, but nothing essential to calling 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?

There are zero input parameters, so the baseline is 4. The description also explains the output concepts it returns (shared blocklist size, Jaccard, shared_political covering NEWS/HUMR/POLR, shared_tooling covering ANON/VPN), which compensates for the absence of an output schema.

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

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

The description states a specific resource with unusual precision: country PAIRS that nationally block the same domains, plus the exact metrics computed (shared blocklist size, Jaccard, shared_political, shared_tooling). The pair-oriented framing distinguishes it conceptually from the per-country sibling tools like get_country_profile or get_country_compare, but no sibling is 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?

There is no explicit when-to-use statement and no named alternative. The Iran-Russia example and the mention that shared_tooling 'strips coincidental gambling/adult overlap' imply the analytical use case, but an agent is left to infer when this tool beats get_country_compare or get_most_blocked_domains on its own.

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=true and openWorldHint=false. The description adds substantial behavioral context: built on confirmed-national layer (>=3 independent networks), counts are a floor not a census, no uniquely-blocked lists because absence is unconfirmed, and China is under-counted due to GFW anomaly. This goes well beyond the annotations.

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

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

The description is dense but front-loads the core purpose, then layers in examples, honesty caveats, and limitations. Every sentence adds value, though its length is near the upper bound for a two-parameter tool; it remains well-structured and readable.

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

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

For a complex comparison tool with no output schema, the description fully explains the return contents (blocked counts, shared blocklist, per-category breakdown) and important limitations. An agent has everything needed to understand the output and call the tool correctly.

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

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

Schema description coverage is 100%, and the description adds no parameter-specific syntax, format, or constraint details beyond what the schema already provides. Baseline 3 is appropriate when the schema fully documents both ISO country code 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 action (head-to-head comparison) and resource (country censorship) with explicit outputs: blocked domain counts, shared blocklist, per-category side-by-side. It distinguishes itself from siblings by naming get_national_blocklist and get_co_blocking as related tools and providing an example (IR vs RU).

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 says 'Use for how does country X's censorship differ from Y's?' and clarifies the confirmed-national layer basis. It also notes what the tool deliberately does not provide ('uniquely blocked' lists) and that counts agree with get_national_blocklist + get_co_blocking, giving clear routing context.

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

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

Annotations already declare the safety profile (readOnlyHint=true, openWorldHint=false). The description adds useful behavioral context about the data itself: it returns data freshness, a 30-day measurement window, a technique mix, and domains confirmed across at least three networks. This goes beyond annotations to disclose scope and a reliability threshold, though it does not cover output structure or potential limitations.

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

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

The description is two sentences, front-loaded with the tool's scope and contents, and closes with a clear selection recommendation. Every phrase earns its place with no filler or redundancy.

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

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

With no output schema, the description must convey the return shape, and it does so by listing the four main profile components. It is nearly complete for an agent to decide and call correctly, but it could be more explicit about the exact response fields or any pagination limits.

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

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

Schema description coverage is 100%, and the single country_code parameter is fully documented in the schema with its ISO 3166-1 alpha-2 format. The description adds no parameter-level detail beyond what the schema already provides, so a baseline 3 is appropriate.

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

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

The description names a specific resource (measured-censorship profile for a country) and enumerates the exact components returned: data freshness, 30-day volume, technique mix, and nationally blocked domains. It explicitly positions itself as the 'Best single call for a country overview,' which distinguishes it from narrower siblings such as get_censorship_techniques or get_national_blocklist.

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 'Best single call for a country overview' gives a clear context for when to use this tool over granular alternatives. It does not explicitly name those alternatives or state when not to use it, but the recommendation is unambiguous enough for selection.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by listing the returned content (blocked domains, anomaly rates, risk tier, incidents), but says nothing about freshness, caching, or error behavior for unknown codes — relevant given a get_data_freshness sibling 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?

A single front-loaded sentence that names the verb, the scoping parameter, and the returned fields with zero filler. Nothing is redundant with the title or schema.

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 read-only, single-parameter lookup with no output schema, the description usefully enumerates what is returned, compensating for the absent return spec. Only minor gaps remain, such as behavior for invalid or unsupported country codes.

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

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

Schema coverage is 100% and the single country_code parameter is fully documented with format and examples (IR, CN, RU). The description adds no syntax or validation meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get detailed censorship status for a specific country') and enumerates the payload (blocked domains, anomaly rates, risk tier, recent incidents). It does not differentiate from near-siblings such as get_country_profile or get_censorship_summary, which an agent would need to disambiguate.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives despite many overlapping country-scoped siblings (get_country_profile, get_country_compare, get_censorship_by_region). The agent must infer the appropriate context from the name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the 0-100 scoring range, the high/medium/low band, the four derivation inputs, and the fact that it is the observatory auditing its own data — useful for interpreting the output. It does not describe return shape/pagination, but no output schema exists to constrain expectations further.

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 tight sentences: the metric and its meaning are front-loaded, with the derivation and usage tucked in after. Zero filler, and the scope ('per-country') plus scale arrive before any elaboration.

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

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

With no parameters and no output schema, the description carries the full burden, and it does explain the return value well (0-100 range, three-band label, four input dimensions) plus the intended interpretation, which is what an agent needs. Minor gaps remain — no mention of geographic coverage or staleness of the score itself — but nothing essential to invoking 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?

The tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to clarify. The baseline for a no-parameter tool is 4, and nothing here requires a lower score.

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 resource (per-country data-trustworthiness scores) with scale and band, and explains what it measures (trust in Voidly's censorship measurements) and how it is derived (freshness, volume, stability, source diversity). It reads as a distinct meta-quality metric versus sibling tools like get_data_freshness or get_measurement_freshness, though it never names an alternative, so full sibling differentiation is only implied.

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 says when to use it: 'use it to weight conclusions about sparsely-measured countries,' which is a concrete usage condition. It does not name a specific alternative tool or state exclusions, so it stops short of the when/when-not/alternatives bar required for a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavioral context by naming which pipelines' delivery times are reported, but says nothing about recency thresholds, staleness semantics, or return shape.

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 with the subject front-loaded, zero filler, and the key enumeration placed after the core noun phrase. Every clause earns its place.

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

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

For a no-arg, read-only tool with no output schema, the description is nearly sufficient: it says what is measured and by which sources. It could add how freshness is expressed (timestamps vs. lag) but the omission is minor.

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 the schema carries no parameter meaning for the description to augment. Baseline 4 applies; the description's list of sources is the only parameter-like dimension and it is handled.

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 resource (per-source data freshness receipts) and enumerates the exact pipelines covered (OONI, IODA, CensoredPlanet, probes), plus the semantic payload ('when each pipeline last delivered'). It is clear what the tool returns, though it does not explicitly distinguish itself from the closely named sibling get_measurement_freshness.

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 statement of when to call this versus alternatives, nor any prerequisites or exclusions. Given the near-identical sibling get_measurement_freshness, the absence of routing guidance is a real gap.

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 openWorldHint=false, but the description adds crucial behavioral context beyond them: corpus start date, clustering artifact, and how to interpret absent countries. This is honest limitation disclosure that materially affects how an agent should present results.

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 purpose, then alternatives, use cases, invocation, and caveat. Efficient overall, though the example invocation repeats what the schema already shows, slightly reducing density.

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?

No output schema exists, so the description carries the burden and does so: it explains the timeline content (first observed per country, method evolution, sorted earliest-first) and the key interpretation caveat. An agent has enough to call it and frame results correctly.

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

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

Schema description coverage is 100%, so both parameters are already well-documented with examples. The description's 'Pass domain=twitter.com (optional country=IR to focus one country)' largely repeats schema content without adding syntax, format, or edge-case semantics.

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

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

States a specific verb (get), resource (domain timeline), and scope (full-corpus, first observed per country, method evolution). Explicitly distinguishes itself from check_domain_blocked and get_domain_history as the long-horizon companion, 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?

Names alternatives and their contrasting scope ('current/recent status'), provides explicit use-case examples ('when did country X start blocking Y?', 'how did they block it?'), and gives a concrete invocation pattern. The when-to-use guidance is clear and actionable.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context by disclosing that the result is synthesized from multiple sources (elections + forecast + historical correlation), but says nothing about freshness, coverage limits, or what the briefing contains.

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, front-loaded with the resource and scope, with no filler or redundancy. It is slightly jargon-heavy ("election-aware", "joined with") but still compact and information-dense.

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

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

For a one-parameter read-only tool with no output schema, the description conveys the core scope and composite nature of the returned briefing adequately. What remains thin is the exact contents/format of the briefing, but the annotations cover safety and the schema covers the input.

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

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

Schema description coverage is 100% and the single country_code parameter is documented in the schema with an ISO 3166-1 alpha-2 format and examples. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

Names a specific output (a censorship risk briefing for a given country) and specifies its distinguishing composition: upcoming elections joined with forecast and historical election-censorship correlation. This differentiates it from siblings like get_upcoming_elections and get_risk_forecast by signaling it is a composite briefing rather than a single-signal lookup.

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 never states when to use this tool instead of the many adjacent siblings (get_upcoming_elections, get_risk_forecast, get_shutdown_risk, get_country_profile). Scope implies usage but no condition or alternative is named, leaving the agent to infer 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful scope context (every watched country, sorted by risk) but says nothing about return shape, result size, or whether filters affect ordering.

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

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

One tight sentence with the resource and scope front-loaded and no filler. Every clause (single-call, scope, sort order) carries information the agent can act on.

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

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

For a one-parameter, read-only tool with full schema coverage and no output schema, the description covers what it returns (risk across all watched countries, risk-ordered) adequately. It could note the min_risk effect on the heatmap, but 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?

Schema description coverage is 100% and the single min_risk parameter is fully documented with type, range, and default, so the schema carries the burden. The description does not mention min_risk at all, adding no semantics beyond the schema, which is the expected baseline.

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 resource (shutdown-risk heatmap) and scope (every watched country) with a clear verb phrase, and adds the output ordering (sorted by risk). It is distinguishable from per-country siblings like get_shutdown_risk, though it does not explicitly name a sibling it replaces.

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 'Single-call ... across every watched country' implies the use case: prefer this over repeated per-country lookups when you want a global view. However, no alternative tool is named and no exclusions or prerequisites are stated, so usage is only implied rather than spelled out.

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 openWorldHint=false, so the safety profile is covered. The description adds the 7-day forecast window and the default threshold value, which is useful scoping context, but says nothing about return shape or ordering (and no output schema exists to compensate).

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 tight sentence that front-loads the resource and the filtering condition with zero wasted words. It is efficient, though its brevity is part of why routing and behavioral detail are missing.

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

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

For a simple read-only filter tool with full schema coverage and annotations, the essentials are present. Still, with no output schema and many sibling risk tools, the definition leaves the agent guessing about return format and how this differs from adjacent forecasting endpoints.

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

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

Schema coverage is 100% and the single parameter's description already states range 0-1 and default 0.5, so the description's restatement adds little. Baseline 3 is appropriate when the schema does the heavy lifting.

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 resource (countries) and the exact filtering predicate (7-day forecast exceeding a risk threshold), so an agent understands the output set without opening the schema. It does not, however, differentiate itself from sibling risk tools like get_risk_forecast or get_shutdown_risk_leaderboard.

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 or when-not-to-use guidance, and no alternative is named despite a crowded sibling set containing several risk/forecast tools. The agent is left to infer selection from the name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by enumerating the kind of content returned (evidence links, domains, blocking methods, timeline), which stands in for the missing output schema. It says nothing about behavior for an unknown/expired incident ID, which would be the natural next 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?

One front-loaded sentence that opens with the verb and resource and then lists the payload contents. No filler, no redundancy, nothing to trim.

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 single-parameter lookup with no output schema, the description adequately sketches what the caller receives. It is close to complete; the only thing missing is a note on failure behavior or whether all listed sections are always populated.

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

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

Schema description coverage is 100% and the single parameter is fully documented in the schema, including both the human-readable (IR-2026-0142) and hash ID forms. The description only refers to 'a specific incident' and adds no syntax or format detail beyond the schema, so a baseline 3 is appropriate.

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

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

The description gives a specific verb ('Get') and resource ('detailed information about a specific censorship incident') and enumerates the content returned (evidence links, affected domains, blocking methods, timeline). It does not, however, differentiate this tool from close siblings like get_incident_evidence, get_incident_report, or get_incidents_since, leaving the agent to infer the distinction from names alone.

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

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

There is no explicit when-to-use statement, no prerequisites, and no mention of alternative tools for related data. The sibling set contains at least four other incident-oriented tools, so failing to route between them is a real gap rather than a minor omission.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe read-only profile is covered. The description usefully adds that the output is permalinks/raw measurements, but says nothing about pagination, count limits, or behavior when no evidence exists for an incident.

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 tight sentence that front-loads the resource and its scope, with zero filler. Size is well matched to a one-parameter 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?

For a simple read-only tool with one required param and no output schema, the description adequately conveys what is returned (evidence permalinks). It could be more complete by indicating the return shape or empty-result behavior, but the essentials 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 100% — the single incident_id parameter is fully documented ('Readable or hash incident ID'). The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific resource (evidence permalinks) scoped to one incident, and clarifies the content is 'raw measurements' — more informative than a generic 'get incident' verb. It hints at differentiation from detail/report siblings but never names them, so the agent must infer the boundary.

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

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

The phrase 'a journalist can verify' implies a verification use case, giving implied usage. However, there is no explicit when-to-use, when-not-to-use, or routing to alternatives like get_incident_detail or get_incident_report, which is a notable gap given the many incident-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 already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the report is citation-formatted output, but says nothing about what the report contains, its length, or how it differs from the detail/evidence endpoints.

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, front-loaded sentences with zero filler. The core purpose leads and the format options follow, which is the right ordering for an agent.

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

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

With no output schema and no annotations about content, the description should say more about what the report actually includes beyond the citation format. It is adequate for invocation but leaves the return content opaque.

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

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

Schema coverage is 100%, so both parameters are already documented, including the enum values and the ID format example. The description merely repeats the format options already present in the schema enum, adding no new semantics.

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

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

States a specific verb (retrieve) and resource (citable incident report) scoped to one incident. The 'citable' framing distinguishes it from get_incident_detail and get_incident_evidence, though it never names those siblings, so the differentiation must be inferred.

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 'ready to paste into an article or reference manager' implies the citation use case, which is useful context. However, it offers no explicit when-to-use vs. when-not guidance and does not name the closest alternatives like get_incident_detail.

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/openWorldHint, so the description carries the operational burden and delivers: at-least-once paging semantics with a de-duplication requirement on hashId, cursor continuation protocol, and the upstream corpus_truncated cap that makes has_more:false non-authoritative. This is exactly the behavioral context an agent cannot infer from structured fields.

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 semantics (what, ordering, delta), then the pagination contract, then the truncation caveat. Every sentence changes agent behavior — none is restating the name or schema.

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

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

With no output schema, the description must name the response fields that drive logic, and it does: has_more, next_cursor, corpus_truncated, plus the hashId dedup key. An agent has everything needed to sync correctly and to report partial syncs honestly.

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

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

Schema coverage is 100%, so baseline is 3. The description still adds meaning by explaining cursor's lifecycle ('call again with cursor=<next_cursor>', from the previous response) and the role of the since boundary in delta semantics; limit's cap is left to the schema.

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

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

States a specific verb+resource+scope: incidents created OR updated after an ISO timestamp, returned oldest first as a delta sync. That framing ('delta sync', 'created or updated') distinguishes it from pure-state siblings like get_active_incidents or aggregate siblings like get_incident_stats. An agent knows exactly what this returns 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 clear conditions for continued use ('if has_more is true... call again with cursor=<next_cursor> until it is false') and a caveat about when the result is not trustworthy (corpus_truncated). It does not explicitly compare itself to alternatives like export_incidents or get_incident_detail, 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 already cover read-only and closed-world safety. The description adds real semantic context beyond them: citable_censorship excludes suspected/draft data while by_status is the complete breakdown, which tells the agent how to interpret and trust each aggregate.

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, front-loaded with the tool's function and followed immediately by the field interpretation guidance. Nothing is wasted and the ordering is sensible.

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

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

With no output schema, the description carries the burden of explaining return values, yet it only names two fields of what is presumably a larger aggregate payload and says nothing about scope, time window, or other breakdowns. It is helpful but not complete for a zero-parameter data tool.

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

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

The tool takes zero parameters, so the baseline is 4. The description instead characterizes the returned metrics, which is a reasonable substitute for parameter discussion.

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 ("Aggregate incident statistics") and names two of the fields it returns, which distinguishes it from incident detail/listing siblings. However, it never explicitly contrasts itself with closely related tools like get_censorship_summary or get_incident_detail, so the differentiation is implicit.

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

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

There is no guidance on when to call this tool versus its many siblings. It does give field-level selection guidance by recommending citable_censorship as the "honest citable headline" over the full by_status breakdown, which is useful implied usage direction, but tool-selection context is absent.

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

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

Goes well beyond the readOnlyHint=true/openWorldHint=false annotations with substantive honesty caveats: block_rate is over MEASURED domains, an absent category is UNMEASURED rather than allowed, and ASN coverage is sparse and dominated by CensoredPlanet DNS so most networks read 'blanket'. This is exactly the kind of context that prevents an agent from misinterpreting results.

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 purpose, then parameter modes, then caveats – a sensible order. The two inline examples (KZ AS207446, RU AS47541) are illustrative but make the description dense; slightly more than strictly needed, though each sentence earns most of 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 no output schema, the description carries the return-value burden and does so: it names the outputs (per-category block rates plus a blanket/selective/permissive/mixed label, or ranked networks) and flags measurement limitations. An agent has everything needed to call and interpret it correctly.

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

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

Schema coverage is already 100% (both params documented), so baseline is 3. The description adds real semantic value by defining what each parameter combination yields (single-network profile vs ranked country list) and clarifying asn accepts '207446' or 'AS207446'. Lacks enum or syntax detail beyond that.

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: which content categories an ASN blocks vs leaves alone, and frames the analytical goal (separating targeted political censorship from blanket filtering). This clearly distinguishes it from siblings like get_isp_risk_index, get_category_leaders, and get_censorship_by_category.

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 explicit usage modes: 'Pass country=XX&asn=NNNN for one network's per-category block rates... pass country=XX for the country's networks ranked.' This tells the agent exactly how to invoke it for each intent. It does not name a sibling alternative to use instead, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the composite score's constituent factors, which is meaningful context, but says nothing about ranking direction (higher = worse?), result ordering, or coverage limits of the data.

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 subject (ISPs ranked by score) leads and the supporting detail follows compactly.

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 single-parameter, no-output-schema query tool, the description conveys what is produced and how it is ordered. Minor gaps remain around ranking direction and the per-ISP fields returned, but the conceptual picture is sufficient to invoke 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?

Only one parameter with 100% schema coverage; the schema already documents country_code with its ISO format and examples. The description adds no syntax, scoping, or edge-case detail beyond the schema, so baseline 3 applies.

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

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

States a specific resource (ISPs in a country) and the returned artifact (a risk index ranked by a composite censorship score), and decomposes the composite into aggressiveness, category breadth, and blocking methods. It does not distinguish itself from nearby siblings like get_isp_categories or get_censorship_index, so it falls short of a 5.

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

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

There is no when-to-use guidance, no mention of when to prefer get_isp_categories or get_country_profile, and no prerequisites. The agent must infer the use case from the name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety profile is covered. Description adds the four-band taxonomy (live/recent/aging/stale) and the map/list shape, which is useful context beyond annotations. Does not enumerate what other stale-related tools return or rate limits, but the band semantics are the key behavioral 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?

Two compact sentences, front-loaded with the core output spec ('last-measurement timestamp + band') then the use-case. Every clause earns its place; no repetition of the title.

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

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

Zero-param, read-only, no-output-schema tool; description covers output content and purpose adequately. Slightly incomplete on the exact map key/value format and band thresholds, but the agent has enough to call and interpret it correctly.

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

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

Zero parameters, so baseline is 4. No parameter semantics to document, and the description correctly confines itself to describing output rather than fabricating inputs.

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

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

States a specific verb+resource ('get_measurement_freshness') and crisply defines the output: last-measurement timestamp plus a four-band freshness label across all monitored countries. Distinguishes itself from siblings like get_data_freshness and get_data_confidence by scoping to per-country measurement recency.

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?

Explicit when-to-use: 'to check whether a country's censorship data is current before relying on it.' Tells the agent how to act on the result (find the country in the returned map). No explicit exclusions or named alternatives, but the context is clear.

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

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

Annotations (readOnlyHint=true, openWorldHint=false) already establish a safe read over a finite dataset, so the bar is lower. The description still adds real value by disclosing the ranking methodology and the honest composition caveat (gambling/piracy/adult dominating over political censorship), which 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?

Two sentences, front-loaded with purpose then the caveat, with zero filler. The 'HONEST:' framing is informal but functions as an effective signal to the agent; the description is neither bloated nor truncated.

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

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

With no output schema, the description carries return-value burden and does so adequately by describing the shape (a ranked leaderboard) and its typical contents. Pagination/limit behavior is left entirely to the schema, and the exact returned fields are unspecified, keeping it just short of 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 coverage is 100%, so baseline is 3. The description goes beyond the schema by explaining the semantic effect of specific category values (ANON isolates circumvention tools; NEWS targets news sites) and naming example domains, which the terse schema enum examples do not.

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 resource ('global leaderboard of the most-blocked domains') plus the exact ranking metric ('ranked by how many countries nationally block them'). An agent immediately knows this is a domain-level leaderboard distinct from country-level or category-level 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 strong interpretive guidance on what the default result contains and how to steer it ('use category=ANON ... or category=NEWS'). It does not, however, name the sibling tools (e.g. get_most_censored, get_category_leaders) that an agent might otherwise pick, so the routing guidance is contextual rather than comparative.

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 openWorldHint=false, so the safety and scope profile is covered. The description adds the return shape (country, score, risk tier, blocked categories), which is useful, but says nothing about ordering direction, ties, or how much data is available beyond the limit. Adequate but thin for the annotation-lowered bar.

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

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

Two sentences, zero waste, front-loaded with the purpose before the return fields. Nothing is padded or redundant.

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

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

There is no output schema, and the description compensates by naming the returned fields, which is the key missing piece. For a simple read-only leaderboard with one documented parameter, this is nearly complete; only the sibling disambiguation is absent.

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

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

The single 'limit' parameter has 100% schema description coverage including default and max, so the schema carries the semantics. The description adds nothing about the parameter (no mention of the cap, defaults, or effect of limit on ranking), so the baseline 3 applies.

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

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

States a specific verb ('Get') and resource ('most censored countries') with the ranking criterion ('censorship severity score') and enumerates the returned fields. It is clear on its own, but it does not differentiate itself from close siblings such as get_high_risk_countries or get_censorship_index, which an agent could easily confuse it with.

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 statement of when-not-to-use it, and no pointer to an alternative among the many sibling ranking/risk tools. The agent is left to infer that this is a global leaderboard view rather than a per-country lookup.

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

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

readOnlyHint=true already establishes this as a safe read with no side effects, so the description only needs to add context. It usefully discloses the output composition (SHAP features, conformal intervals), but says nothing about model assumptions, latency, or data freshness, which matter for a forecast.

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 resource and horizons before the output detail. Every clause carries information, though the jargon (SHAP, conformal intervals) is left unexplained.

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

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

With no output schema, the description does step in to describe return contents, and the sole required parameter is covered. However it omits usage guidance, forecast reliability caveats, and freshness, leaving gaps for a forecasting tool with many sibling overlaps.

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

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

Schema coverage is 100% and the single parameter country_code is fully documented in the schema with examples. The description's 'for a country' merely restates that mapping without adding format or constraint detail, so baseline 3 is appropriate.

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

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

The description states a specific resource (censorship forecasts for a country) and scopes it precisely with the 1/7/30-day horizons plus output content (per-horizon SHAP features, 90% conformal intervals). It distinguishes itself from generic siblings like get_risk_forecast and get_prediction_track_record by the multi-horizon framing, though it never names those alternatives.

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

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

There is no guidance on when to pick this over the many other forecasting/risk siblings (get_risk_forecast, get_shutdown_risk, get_prediction_track_record). The agent must infer the use case from the output description alone.

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

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

Annotations only cover the safe-read profile (readOnlyHint, openWorldHint=false). The description goes well beyond that: it names the return fields, discloses the confirmation methodology, and adds honest caveats—includes legal gambling/piracy blocks, absence is not 'accessible', and China is under-counted. This is unusually rich behavioral context for a read 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?

Front-loaded with purpose and routing, then return fields, then caveats—each clause earns its place. It is dense and long-ish, but the length is justified by the genuine caveats rather than 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?

With no output schema, the description compensates by describing the returned structures (restriction_map, partial_map, confirmed_block_layer). Combined with routing and caveats, an agent has everything needed to call and interpret the tool correctly.

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

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

Single parameter with 100% schema coverage, and the schema fully documents the ISO 3166-1 alpha-2 format. The description adds no per-parameter meaning beyond the schema, so the baseline of 4 for a well-covered one-param tool is appropriate.

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

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

States a specific verb and resource ('COMPLETE list of domains a country blocks nationally') plus the scope ('confirmed across >=3 independent networks') and the sub-national distinction. It explicitly differentiates from siblings by naming check_domain_blocked and get_country_profile, so an agent can select it 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?

It gives explicit when-to-use guidance ('Use this for a full report') and names the two alternatives with the selecting condition ('for a single domain use check_domain_blocked, for a summary use get_country_profile'). Nothing is left to inference.

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 read-only, closed-world profile, but the description adds real behavioral context: concrete magnitude examples (RU 510 / IN 80 / IR 50), the ~42-country tag coverage, and the interpretive caveat that low depth means under-measurement rather than safety. It does not discuss caching, freshness, or response shape beyond the sample values.

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 definition before the caveats, and every clause carries information. It is dense and dash-slash heavy in a single run-on paragraph, which costs some readability.

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

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

With no output schema, one optional parameter, and a read-only annotation set, the description supplies what an agent needs: what the number means, what it does not mean, sample values, and single-country vs full-set behavior. Nothing material is left unclear.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning the schema omits: passing country=XX scopes to one country, implying omitted means the full tagged set, and it clarifies the code semantics with ISO examples.

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 precise verb and resource: per-country count of distinct ISP networks (ASNs) Voidly has evidence from. The framing ('proxy for independent vantage points', 'bounds what the >=3-network confirmed-block gate can confirm') makes it clearly distinguishable from siblings like get_data_confidence or get_probe_stats.

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

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

Gives clear context for when the number matters (gauging how well-backed a country's confirmed-block data is) and an explicit caution against misuse ('NOT a censorship score; absent/shallow is under-measured, not free'). However, it never names an alternative tool or states an explicit when-not-to-use condition.

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 openWorldHint=false, so the safety profile is covered. The description adds value by previewing the response shape ('which countries block it and the overall global risk level'), but says nothing about scoring methodology, freshness, or platform-name validation against the enum-less string parameter.

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 tight sentences with no filler, and the scope constraint is front-loaded before the return-value summary. It is efficient, though the second sentence is essentially a terse result preview rather than essential call guidance.

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

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

For a simple read-only, single-parameter lookup with no output schema, the description tells the agent what to pass and what comes back (blocking countries plus a global risk level). Only minor gaps remain, such as whether unknown platforms error or return an empty result.

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

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

Schema description coverage is 100% and the single 'platform' parameter is fully documented with eight concrete example values, so the schema carries the semantic load. The description adds no format, casing, or normalization guidance beyond what the schema provides, matching the baseline 3 for high-coverage single-parameter 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?

States a specific verb and resource ('Get censorship risk score for a specific platform') plus the scope ('across all monitored countries'), which distinguishes it from country-centric siblings like get_country_profile. It does not explicitly differentiate itself from the closely named get_platform_scores, so it falls short of a 5.

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

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

Usage is only implied by the scope phrase 'across all monitored countries'. There is no explicit statement of when to pick this over the very similar sibling get_platform_scores, nor any exclusions or prerequisites, leaving the agent to infer 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the ranking basis (global censorship risk) and the universe of entries (all monitored platforms), but says nothing about ordering direction, score scale, or whether results are paginated or cached.

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 that identifies the resource, examples, and the ranking criterion with zero filler. Nothing is wasted and the key noun is first.

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

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

With no output schema, zero parameters, and read-only annotations, most of the burden is already met. What is missing is differentiation from get_platform_risk and any hint about the shape or scale of the ranking.

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 the schema has nothing to document and there is no parameter semantics to add. Baseline 4 applies for a no-argument tool.

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

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

The description states a specific resource (all monitored platforms) and the ordering criterion (global censorship risk), with example platforms that make the scope concrete. However, it does not distinguish itself from the sibling get_platform_risk, which an agent could easily confuse with this tool.

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 alternatives. With a similarly named sibling (get_platform_risk) present, the absence of any routing hint is a real gap.

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 openWorldHint=false, so the safety profile is covered. The description adds that results are public and that baselines are included ('honest baselines'), which is useful framing, but it says nothing about freshness, coverage window, or how misses are defined.

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 compact sentence with no waste, front-loading the subject (track record) before the scope detail. It is a noun phrase rather than a full statement of action, which slightly weakens the lead.

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

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

For a zero-parameter read-only tool with annotations covering the safety profile and no output schema, the definition is minimally sufficient. It never indicates what a record entry contains or over what period, so an agent cannot preview the shape of the answer.

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 no parameter semantics to explain; baseline 4 applies. The description correctly signals that the result is unfiltered across all forecast products.

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 resource and scope: a public prediction track record spanning Voidly forecast products, explicitly covering hits, misses, and baselines. An agent can tell it apart from the many forecast tools (get_risk_forecast, get_multi_horizon_forecast) because it is retrospective scoring rather than a forward-looking forecast, though no sibling is 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?

No when-to-use guidance, no exclusions, and no named alternative. The word 'public' hints that no authentication is required, but nothing tells the agent when to reach for this versus the forecast tools it complements.

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 and openWorldHint, so the description carries the interpretive burden and does so well: it warns that last-probe time differs from fetch time and that community-path rows can be Voidly-operated and do not prove independent operators or accepted measurements. These are non-obvious semantic caveats an agent could not derive from the schema or 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 dense sentences, front-loaded with purpose, then pagination, then interpretation caveats. Every clause carries information, though the phrase 'as bounded JSON pages' is slightly jargon-heavy and the by_domain reference assumes structure not documented elsewhere.

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

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

There is no output schema, and the description does supply the key caveats needed to interpret results correctly (probe time vs fetch time, community-path provenance). It references by_domain rows and next_cursor without describing the returned shape, which is the remaining gap for a no-output-schema 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?

With one parameter at 100% schema coverage, the baseline is 3, but the description adds traversal semantics the schema does not: start with no cursor, then follow next_cursor for each by_domain row. That is meaningful usage context beyond the schema's 'opaque next_cursor' note.

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 scope: 'Read rolling 24-hour raw probe metrics and lifetime Voidly evidence counters as bounded JSON pages.' An agent knows exactly what data class this returns. It does not explicitly differentiate itself from near-neighbors such as agent_relay_stats or get_measurement_freshness, so it falls short of a 5.

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

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

Gives operational traversal guidance ('Start without a cursor; follow next_cursor for every by_domain row'), which is real usage instruction. However, it never says when to prefer this tool over the freshness/stats siblings, nor when not to call it. Usage is implied rather than contrasted against alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful context about the model family (XGBoost) and training data (historical OONI + political events), improving trustworthiness understanding, but omits forecast output shape, confidence, and horizon semantics.

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

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

Single efficient sentence that front-loads verb, resource, and horizon, then the methodology. No wasted words, though slightly dense.

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 read-only prediction tool with one well-documented parameter and no output schema, the description is adequate but lacks return-value context (prediction, confidence, factors) that would help interpret results, especially against many sibling forecast 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 100% and country_code is fully documented with format and examples in the schema. The description adds no parameter meaning beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource (get 7-day shutdown/censorship risk forecast), plus the model and data sources. However, it does not differentiate from closely related siblings such as get_multi_horizon_forecast or get_shutdown_risk, leaving the agent to infer the difference.

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

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

No explicit when-to-use guidance or exclusion criteria. Siblings like get_shutdown_risk, get_multi_horizon_forecast, and get_election_risk occupy overlapping territory, and the description gives no routing logic 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context that the model is gate-promoted, the live version accompanies the response, and validation caveats are included inline, but it stays vague about what those caveats or confidence signals actually look like.

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 redundant filler. The parenthetical jargon ('gate-promoted model') is dense but earns its place by flagging model versioning.

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

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

For a one-parameter tool with annotations covering safety and no output schema, the description is adequate but leaves gaps: it does not explain the probability's scale, how the 'caveats inline' manifest, or how results differ from the accountability/leaderboard siblings.

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

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

Schema coverage is 100% with a single well-documented country_code parameter, so the schema does the heavy lifting. The description adds no format or interpretation detail beyond what the schema already provides, which is the expected baseline.

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 a clear horizon: '7-day shutdown probability for a country'. The 'KeepItOn-validated' and 'gate-promoted model' qualifiers add specificity about methodology, but it never distinguishes itself from close siblings like get_shutdown_risk_accountability, get_shutdown_risk_leaderboard, or get_risk_forecast.

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 when-to-use guidance and no mention of alternatives, despite several sibling tools covering shutdown and risk forecasting. The agent is left to infer that this is the per-country 7-day variant from the name alone.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context that the data is a 'running public record' of archived predictions joined to outcomes, but says nothing about freshness, scope, or update cadence.

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

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

A single sentence is appropriately sized, but the trailing 'the model proves itself in the open' is promotional filler that consumes space without adding selection signal. Structure is front-loaded on the data content, which is fine.

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

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

For a zero-parameter read tool with no output schema, the description gives a rough sense of what comes back (predictions joined to outcomes) but omits any indication of ordering, scope, or whether 'KeepItOn' is the only outcome source. Adequate but with clear gaps.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate beyond confirming it is a parameterless retrieval.

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 noun phrase 'archived shutdown-risk predictions joined to actual KeepItOn outcomes' does identify the resource, but there is no verb ('returns', 'lists') and no differentiation from near-name siblings like get_prediction_track_record, get_shutdown_risk, or get_shutdown_risk_leaderboard. An agent can guess at the topic but must infer the operation type.

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

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

There is no when-to-use guidance, no exclusion criteria, and no mention of the sibling tools that overlap (get_prediction_track_record, get_shutdown_risk_leaderboard). The 'proves itself in the open' clause conveys tone, not invocation context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new information about the payload — it returns everything ranked by 7-day probability and includes risk bands and as-of dates — which matters because no 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?

A single front-loaded sentence that names the ranking metric first and then the accompanying fields. Zero filler and nothing to trim.

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, zero-output-schema read tool, the description supplies the scope (all scored countries), the sort key, and the return fields, which is most of what an agent needs. It could say more about scale or whether the list is exhaustive/capped, but nothing essential is missing.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter syntax the description needs to compensate for. Schema coverage is 100% and additionalProperties is false, leaving nothing ambiguous.

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 resource (all scored countries) and the ranking criterion (current 7-day shutdown probability), which is a real verb+resource statement. It does not explicitly differentiate itself from overlapping siblings like get_shutdown_risk or get_high_risk_countries, so it falls short of a 5.

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

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

The description implies a leaderboard/ranking use case through 'sorted by current 7-day shutdown probability', but never states when to pick this over get_shutdown_risk (single-country detail) or get_high_risk_countries. Usage is inferable but not 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 openWorldHint=false, so safety is covered. The description adds that results carry a censorship-risk overlay, which is real context beyond the annotations, but says nothing about pagination, coverage, or data freshness.

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 tight sentence, front-loaded with the resource and scoping. 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 read-only one-parameter tool with annotations covering safety, the description is nearly sufficient, but it leaves 'censorship-risk overlay' undefined and does not clarify the boundary with the sibling get_election_risk.

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

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

Schema coverage is 100% and the single 'days' parameter is fully documented in the schema with its default. The description adds nothing about the lookahead window, so baseline 3 applies.

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

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

States a concrete verb+resource ('upcoming elections') with worldwide scope and names the value-add ('censorship-risk overlay'). It is discernible from most siblings, though the closely related get_election_risk is not distinguished.

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

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

No indication of when to use this versus alternatives such as get_election_risk or get_risk_forecast, and no prerequisites or exclusions. The agent must infer usage entirely.

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=true and openWorldHint=false, so the safety profile is covered. The description still adds value by disclosing the data sources consulted and that the output is a verdict with supporting evidence, which goes beyond the structured fields.

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 tight sentences that front-load the action and data sources before the return behavior. Every clause 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?

For a single-parameter verification tool with no output schema, the description adequately covers input intent and the shape of the result (verdict plus evidence). It is nearly complete, missing only a note on how verdict evidence is structured or how it differs from adjacent check 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 100%, and the schema itself supplies natural-language examples of claims. The description adds nothing to the single parameter, so the baseline 3 for full coverage applies.

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

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

The description states a specific verb (Verify) and resource (a censorship claim) and names the underlying data sources (OONI, CensoredPlanet, IODA). It does not distinguish itself from siblings like check_domain_blocked or check_service_accessibility, so an agent must infer the distinction from scope alone.

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

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

There is no explicit when-to-use guidance and no mention of alternatives such as check_service_accessibility or check_domain_blocked, which target narrower inputs. The trigger (a natural-language claim) is only implied by the parameter example, leaving routing decisions to inference.

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=true, destructiveHint=false, openWorldHint=false), but the description adds real context beyond them: that a listed or owner-accepted bounty is still unpaid and that payout happens owner-side, outside this system. That is exactly the kind of economically important caveat an agent cannot derive from structured fields.

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, purpose front-loaded, no filler or restated name/title. The closing phrase 'payout is owner-run and off' is clipped to the point of being slightly awkward, which costs a point but the density is otherwise excellent.

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 list tool with no output schema, the description covers purpose and payment semantics but says nothing about what a listing actually contains (fields, count, filtering/ordering, pagination). Adequate, but an agent does not know what it will receive back.

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 the baseline is 4. The description correctly implies a single unfiltered listing call and does not promise filtering semantics that do not exist, though it also adds no parameter guidance (none is needed).

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

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

States a specific verb and resource ('List public owner-posted work bounties') with an explicit scope qualifier (public, owner-posted). It implicitly separates itself from voidly_bounty_status/claim/submit, which operate on a single bounty, though it never names those siblings directly.

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 routing to the obvious alternatives (voidly_bounty_status for a specific bounty, voidly_bounty_claim/submit for acting on one). The use case is only inferable from the verb '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 declare destructiveHint=true and readOnlyHint=false, but the description adds real context beyond them: signing must happen locally, the exact signed JSON must be forwarded, the idempotency key must be included, and critically that 'claiming does not make it payable or paid.' That last point clarifies the side effect so the agent does not expect payment, which is valuable given the destructiveHint.

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 with no filler, front-loading the core action before the signing mechanics and the side-effect caveat. Efficient, though the flow could be marginally clearer about which fields the agent supplies versus signs.

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 cryptographic, 6-parameter mutation tool with no output schema and 0% schema coverage, the description gives the high-level signing flow but omits parameter-level detail and any notion of the response. Adequately describes the mechanics but not complete enough to call the tool correctly without external knowledge.

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

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

Schema description coverage is 0% with 6 required parameters, so the description bears full burden. It hints at the idempotency key (likely mapping to the undocumented nonce) and the notion of a signed body, but nothing explains did, timestamp, signature, or bounty_id beyond what their names imply. Most parameter meaning is left unexplained.

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

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

The description states a specific verb and resource: 'Forward exact caller-signed JSON to claim one bounty.' An agent can distinguish claiming from reading (voidly_bounty_status) or submitting. However, it does not explicitly differentiate from the closely named voidly_bounty_submit sibling, leaving that boundary 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 explicit when-to-use guidance. The description never routes the agent to voidly_bounty_status (to check claimability) or distinguishes claiming from voidly_bounty_submit. It implies a claim action but gives no conditions or prerequisites for selecting this tool over its siblings.

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

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

Annotations already establish readOnly/destructive=false/openWorld=false, and the description adds real value beyond them: it discloses that the call requires a locally signed proof (auth requirement) and clarifies lifecycle semantics ('Owner acceptance remains unpaid; payout is owner-run and off'). That off-platform payout note is non-obvious and prevents wrong assumptions.

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, front-loaded with the core action and auth mode. The payout sentence is tangential to invocation but short and informative, 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?

For a read-only, auth-gated tool with no output schema, the description covers the auth mode and payout semantics but omits what the status response contains and how the five signing parameters relate. Adequate but leaves real gaps an agent would face at call time.

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 5 required params, so the description carries the full burden, and it largely does not meet it. The phrase 'locally signed GET ... proof' hints that did/nonce/timestamp/signature form a signed auth envelope, but it never explains how to construct or order those values, and says nothing about bounty_id usage.

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

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

States a specific verb+resource: reading bounty status, and distinguishes two audience views (claimant vs posting operator). It is separable from siblings like voidly_bounties and voidly_bounty_claim, though the phrase 'claimant or posting operator view' could be sharper about which status fields are returned.

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

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

No explicit when-to-use or when-not guidance relative to siblings such as voidly_bounties, voidly_bounty_claim, or voidly_bounty_submit. The claimant/operator framing implies an audience but does not tell an agent which tool to pick in a given 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 declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the write-oriented safety profile is covered. The description adds real value beyond that: it notes the caller must supply signed JSON (the tool does not sign), that an idempotency key is involved, and that payment/acceptance happens elsewhere – none of which the annotations 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?

Two sentences, front-loaded with the core action and endpoint, with the exclusion about acceptance/payment following. Dense and largely waste-free, though the second sentence packs several distinct constraints into one clause.

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

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

For a six-param tool with 0% schema description coverage and no output schema, the description covers the write semantics and non-goals well but leaves parameter-level meaning incomplete (notably the signing fields and bounty_id). It is adequate at the operation level but thin 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 six required params. It hints at caller-signing (implying did/nonce/signature/timestamp) and mentions an idempotency key and result text buried inside raw_body, but never explains the meaning or format of did, nonce, signature, timestamp, or bounty_id. Most parameters remain semantically undocumented.

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

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

The description states a specific verb and resource ('Forward ... to POST /v1/bounties/{id}/submit') and scopes it as submitting bounty work, which distinguishes it from sibling tools like voidly_bounty_claim and voidly_bounty_status. It does not explicitly name those siblings, but the action is concrete enough to identify the tool.

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 clarifies scope boundaries ('Owner acceptance is separate and unpaid; this tool does not sign or pay'), which implies when this tool applies versus downstream steps. However, it never states when to use this versus voidly_bounty_claim or voidly_bounty_status, so routing relies on inference.

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 safety is covered. The description adds useful context beyond that: it is public, has no payment/action side effects, and is 'versioned' (implying content may change over time). Missing only return-shape or frequency details.

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

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

Two tight sentences with zero waste; the core purpose and the 'no action/payment' caveat are both front-loaded and easy to scan.

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

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

For a no-parameter read tool with no output schema, the description pre-summarizes the manifest's sections and disclaims side effects, giving an agent everything needed to decide whether to call 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?

Zero parameters with 100% schema coverage, so the baseline is 4. There is nothing for the description to clarify on the parameter front, and it correctly doesn't invent any.

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 ('versioned Voidly agent capability manifest'), then enumerates exactly what the manifest contains (endpoints, auth, price basis, examples, availability). This is clearly distinguishable from siblings like voidly_home, voidly_join, or voidly_bounties.

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 clause 'performs no action or payment' implies this is a discovery/introspection step, so usage is implied. However, it never explicitly says when to call this versus alternatives, nor that it should be consulted before invoking action endpoints.

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 safe read-only profile, and the description adds material context beyond them: a per-call fresh four-header proof requirement (auth), the explicit trust boundary that board/job/listing text is untrusted, and the guarantee that no action or payment is performed. This is exactly the extra disclosure the 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.