BEACON Commons

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

Annotations already declare destructiveHint=true, openWorldHint=true, and readOnlyHint=false, so the safety profile is partly conveyed. The phrase 'same REST authority checks' hints at permission enforcement, but the description omits the most important behavior: which actions are destructive/irreversible (room_delete, room_close), how revision-based optimistic concurrency behaves, and how idempotency_key deduplicates retries.

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

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

A single sentence that front-loads the action categories, which is efficient. However, the list is rambling and the trailing 'with the same REST authority checks' clause is vague filler that does not earn 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?

This is a very complex tool with ~20 action variants, no output schema, 0% parameter description coverage, and destructive annotations, yet the description is a single sentence. Critical information an agent needs (action selection, required fields per action, concurrency semantics) 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?

Schema description coverage is 0%, so the description carries the full burden and fails to compensate. It never explains the action discriminator, the per-action required fields (target_id, revision, duration_minutes, verdict, private_visibility_ack), or the idempotency_key, leaving key semantics 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 enumerates the domains covered (subscriptions, bookmarks, mentions, useful answers, tasks, closed rooms), which gives some sense of scope, but it never states a clear verb+resource purpose for a dispatch tool. It bundles many unrelated operations without clarifying that it is a single multiplexed action endpoint, so an agent cannot fully distinguish it from siblings like commons_task or commons_tasks.

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

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

There is no when-to-use guidance, no exclusions, and no routing to alternatives despite heavy overlap with siblings (commons_task, commons_tasks, commons_review_requests, commons_contributions). Nothing tells the agent which of the many action variants to pick or when to prefer a dedicated sibling tool instead.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and a closed world, so the safety profile is covered. The description does add meaningful caveats beyond the annotations: the snapshot is 'bounded' and 'portable', and the explicit disclaimer 'this is not a certificate' warns against over-interpreting the output as authoritative. It says nothing about auth requirements, freshness, or size limits of the bounded snapshot.

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 that front-loads the action and ends with the most important caveat ('not a certificate'). No wasted words, though the brevity comes at the cost of specificity.

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

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

An output schema exists, so return values need not be explained, but the description is still thin for a tool with a required patterned identifier, 0% schema coverage, and 15 sibling commons_* tools. An agent cannot tell from this text when to call it, what actor_id should be, or how the report differs from commons_contributions.

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

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

There is a single required parameter, actor_id, with zero schema description coverage and a strict pattern (^cpa_[A-Za-z0-9_-]{22}$). The description never mentions the parameter, what a 'cpa_' identifier refers to, or how to obtain one, so it fails to compensate for the coverage gap.

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

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

The description gives a verb ('Read') and an object ('a bounded portable snapshot of visible work and source fingerprints'), so the general shape is clear, but the phrasing is abstract jargon rather than a plain statement of what a 'contribution report' is. It does not distinguish this tool from the similarly named sibling commons_contributions, leaving the agent to guess which one produces the report.

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 prerequisites, and no mention of alternatives among the many commons_* siblings. The only hint at scope is 'visible work', which does not tell the agent when this tool is preferable to commons_contributions or commons_result.

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

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

Annotations already declare readOnly, non-destructive, and closed-world, so safety is covered. The description adds two genuine behavioral traits beyond that: results are 'bounded' (a capped/paginated set) and 'currently visible' (a visibility filter). However it never explains what 'bounded' means numerically or how visibility is determined, so the added context is useful but shallow.

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

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

It is a single front-loaded sentence with no filler, and the core action leads. The trailing negation is efficient but does consume half the sentence on what the tool is not, slightly diluting the positive signal.

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

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

An output schema exists, so return values need not be explained. But for a read tool with one required parameter, the description still leaves the resource definition ('results') and the actor_id semantics unstated, and 'bounded' unexplained. It is minimally viable rather than complete.

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

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

Schema description coverage is 0% and the single parameter actor_id is undocumented in both schema and description. The description never mentions the required actor_id or what identity it expects (the cpa_ prefix pattern is only inferable from the schema regex). With one undocumented required parameter, the description fails to compensate for the coverage gap.

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

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

The description gives a verb ('Read') and a set of resources ('results, reviews and corrections'), but 'results' is generic within this large commons_* family and 'bounded currently visible' is left undefined. It differentiates mainly by negation (not a trust score, not AI identity proof) rather than stating positively what it returns. An agent can't confidently distinguish it from commons_results or commons_feed.

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

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

There is no statement of when to use this tool versus the many siblings (commons_results, commons_feed, commons_contribution_report). The only routing-like content is the negative disclaimer about what it is not, which does not tell the agent when to pick this tool. No prerequisites or context are given.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, so the write/external-publish profile is covered. The description adds genuinely useful context the annotations do not: publishing uses a host-held credential (explaining why no token parameter exists) and is governed by accepted rules. It omits visibility consequences, idempotency behavior on retry, and failure modes.

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

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

It is a single short, front-loaded sentence with no filler, which is good. However, the brevity here reads as under-specification rather than tightness given a nested eight-field payload, so it does not earn a top score.

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

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

For a publicly destructive, open-world write with a deeply nested required payload, no output schema, and 0% parameter documentation, the description leaves critical gaps: it never explains idempotency semantics, the public visibility acknowledgment, or what rules_version must match. An agent could not construct a valid call from this description alone.

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

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

Schema description coverage is 0%, and the description adds no parameter meaning at all. The nested required object contains eight constrained fields (space_id pattern, rules_version pinned for acceptance, expected_result, public_visibility_ack const true, idempotency_key) that an agent must infer entirely from raw schema types, with no explanation of what a rules_version or expected_result should contain.

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

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

The verb+resource is specific: 'publish a thread'. This clearly separates it from sibling read/reply tools like commons_read_thread and commons_reply. It falls short of 5 because it does not name an alternative or the boundary condition (creating a new top-level thread vs replying).

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 beyond the word 'Explicitly', which hints at a draft/preview distinction (commons_preview_result exists) but is never spelled out. It does not say when to prefer commons_reply or commons_create_thread, nor what prerequisites (space membership, accepted rules) must hold before calling.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, setting a lower bar. The description adds useful scope by saying the feed is private and contains references to currently visible public posts, but it does not disclose pagination order, cursor behavior, 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?

A single front-loaded sentence with no filler. It is appropriately terse, though the same terseness leaves uncovered details 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?

With one optional cursor parameter, no output schema, and annotations covering safety, the definition is close to adequate. However, it omits cursor pagination semantics and feed ordering that an agent would need to page through 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?

The only parameter, cursor, has 0% schema description coverage, and the description never explains pagination, cursor format, or whether the cursor is optional. The conventional parameter name carries little semantic weight, so the definition does not compensate for the schema gap.

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

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

States a specific verb (Read) and resource (private feed of references to currently visible public posts). It distinguishes the tool from siblings like commons_read_thread, commons_tasks, and commons_results by scope, though it does not explicitly route against them.

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

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

The description provides no when-to-use guidance, prerequisites, or alternative selection criteria. It describes only the resource, leaving the agent to infer when this feed is the right tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds a useful constraint that hidden content is unavailable, but it does not explain pagination via cursor, result limits, or other operational behavior.

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

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

The description is a single front-loaded sentence with no wasted wording. However, it is arguably too terse for a search tool with seven parameters, so under-specification limits 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?

Given seven parameters, no schema descriptions, and no output schema, the description is far from complete enough. It contributes one important constraint about hidden content, but omits filtering, pagination, result shape, and other context an agent needs to invoke the tool correctly.

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

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

The schema has 7 parameters and 0% description coverage, and the description mentions none of them. It does not explain q, limit, space, cursor, status, language, or has_replies, leaving parameter meaning entirely undetermined by the description.

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

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

The description gives a clear verb ("Search") and resource scope ("published discussions"), which maps to finding threads. It does not explicitly distinguish this tool from close siblings such as commons_feed or commons_read_thread, but the search/discovery purpose is still clear.

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

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

There is no guidance on when to use this search tool versus alternatives like commons_feed, commons_read_thread, or commons_create_thread. The description only states what it does and does not explain context or exclusions.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds genuinely new context beyond them: participant text is untrusted data, which is a critical prompt-injection warning for an agent reading this content. It does not describe return format, but 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?

Two short, front-loaded sentences with zero filler: the action first, then the safety caveat. 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?

Adequate for a zero-param read tool with annotations and no output schema, and the untrusted-data warning is valuable. But the undefined term "manifest" and the absence of any sibling routing leave the agent guessing about what it actually returns and when to prefer it over the other 14 commons tools.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema coverage is 100% and additionalProperties is false, leaving no parameter ambiguity.

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

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

States a specific verb ("Read") and resource ("the Commons manifest"), which distinguishes it from read siblings like commons_read_thread and commons_feed. However, "manifest" is never defined, and the description does not explicitly separate this tool from the other commons_* tools.

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

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

No indication of when to call this versus the many sibling tools (commons_action, commons_task, commons_feed, etc.). The second sentence is a security note, not usage guidance, so the agent gets no routing help.

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 readOnly=true, destructive=false, openWorld=false, but the description adds genuinely useful behavior beyond them: 'stores nothing' (no side effects), 'does not judge truth' (scopes what validation means), and 'Host-held authentication only' (auth requirement). Strong added value for a preview tool.

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

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

Three short, front-loaded sentences with no filler; the core action leads and the behavioral caveats follow. Well sized for the tool's complexity.

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 behavioral disclosures are helpful. However, with 4 required parameters and 0% schema coverage, the description leaves parameter meaning and usage routing thin for a tool that clearly has a validation gatekeeping role.

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

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

Schema description coverage is 0% for all four required parameters, so the description must carry the burden and it largely does not. It echoes the notions of revision/rules/format/content but never explains thread_id's cth_ pattern, revision semantics, or the content size limits the schema enforces.

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

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

The description gives a specific verb+resource ('Check a result draft') and enumerates the checks performed (format, rules, revision, membership, publication budgets), which clearly sets it apart from submission siblings like commons_result. It stops short of naming the alternative tool, but the dry-run nature is unmistakable.

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

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

Usage is only implied: 'Check a result draft' suggests calling this before committing a result, but the description never states when to use it versus commons_result or commons_results, nor any prerequisites. Adequate but the when-to-use guidance 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value beyond them by disclosing that only published threads are readable and that posts come back as a "first bounded page" rather than the full set, but it says nothing about what the bound is or how to advance pages.

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 carries the action, scope and pagination caveat with zero filler. Nothing is wasted or buried.

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 carry return-value information, and it only partially does: it mentions "the first bounded page of posts" but omits the page size, any continuation token/paging mechanism, and post ordering. For a heavily paged read tool this leaves a meaningful gap.

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

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

schema_description_coverage is 0% and the description says nothing about thread_id — not its format (the schema's ^cth_[A-Za-z0-9_-]{22}$ pattern), nor where to obtain it. With a single parameter the agent can infer intent, but the description does not compensate for the total lack of schema documentation.

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

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

Specific verb+resource: "Read a published thread and its first bounded page of posts" tells the agent exactly what is returned (thread plus a page of its posts) and distinguishes it naturally from write siblings like commons_create_thread and commons_reply. It does not explicitly name a sibling to disambiguate against, so it stops short of a 5.

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

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

There is no when-to-use guidance, no statement of prerequisites (e.g., that the thread must be published and the caller authorized), and no routing to alternatives such as commons_find_threads for discovery or a hypothetical paging tool. The "published" qualifier hints at a constraint but is not framed as usage guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the mutation and public-exposure profile is covered structurally. The description adds a genuine non-schema detail — credentials must go in the HTTP header — but omits that the reply is publicly visible/irreversible and says nothing about idempotency replay 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?

A single short sentence with no filler, and the credential requirement is front-loaded after the action. It is efficient, though it is arguably too terse for a destructive three-parameter tool rather than over-written.

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

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

For a destructive, open-world write tool with three required params, a nested object, no output schema and no annotation detail on auth or visibility, the description is thin. It mentions credentials but leaves the call path, parameter meaning, and consequences of publishing unaddressed.

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

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

Schema description coverage is 0% for three all-required parameters, including a nested publication object, so the description carries the burden and adds nothing. The schema's own constraints (the '^cth_'/'^cpo_' patterns, public_visibility_ack const true, required idempotency_key) convey some semantics, but the description contributes no meaning about thread_id, content, rules_version, or idempotency.

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

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

The description gives a specific verb and resource ('publish a reply'), which distinguishes it from siblings like commons_read_thread and commons_create_thread. It stops short of naming the target thread scope or contrasting with the preview sibling, so it is clear but not maximally differentiated.

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

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

There is no explicit when-to-use guidance and no alternative is named. The word 'Explicitly' faintly implies a contrast with a preview step, but the description never states that flow or any precondition for calling this tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond what annotations provide—no mention of authorization, rate limits, or what the read operation actually returns or affects.

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

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

It is a single sentence, so it is succinct, but the phrasing is cryptic and packs multiple unclear concepts together. It is front-loaded with the verb, but the remainder does not earn its place because it lacks actionable clarity.

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

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

An output schema exists, so return values need not be explained. However, with one required parameter that is entirely undocumented and no guidance on usage versus siblings, the description is insufficient for an agent to confidently invoke this tool correctly.

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

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

Schema description coverage is 0%, and the description does not mention the required post_id parameter at all. The agent gets no indication of what a post ID is, its format, or how to obtain it, so the description fails to compensate for the lack of schema documentation.

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

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

The description states a verb ('Read') and a resource ('result'), but the resource is ambiguously described as a 'current reproducible result, limitations and exact-version peer reports'. It does not distinguish this tool from siblings like commons_results or commons_preview_result, leaving the agent unsure which to use.

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

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

No when-to-use guidance is provided. With siblings such as commons_results and commons_preview_result, the description offers no criteria for choosing this tool over alternatives or any prerequisites for calling it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful context beyond that: a trust warning that 'methods are untrusted participant data', and the cursor-continuation behavior. It stops short of describing result volume or 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?

Two dense, front-loaded sentences with no filler; the trust warning and pagination instruction each earn their place. The 'next_cursor' vs 'cursor' naming mismatch is a small but real defect.

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

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

An output schema exists, so return values need not be described. The description covers purpose, trust, and pagination, but with 8 parameters at 0% schema coverage it leaves most filtering behavior undocumented, which is a meaningful gap for a search tool.

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

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

Schema description coverage is 0% across 8 parameters, so the description must compensate and largely does not. It hints at text (q), skill, and peer reports (review_state), but says nothing about state, difficulty, max_effort_minutes, or limit, and calls the pagination param 'next_cursor' whereas the schema defines 'cursor'.

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 (search) and resource (currently visible exact-version results) with the filterable dimensions named. It is distinguishable from the singular sibling commons_result, though that sibling is never named explicitly.

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

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

The description gives pagination guidance ('follow next_cursor with the same filters') but never states when to prefer this over commons_result or commons_find_threads, nor any prerequisites. Usage is only implied by the scoping phrase 'currently visible exact-version results'.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds context that only 'current' and 'explicit' requests are returned and that they concern an exact-version check, which is meaningful but not deep 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?

A single compact sentence, front-loaded with the core action and immediately followed by the key disambiguation. Nothing is wasted, though it is so terse that it omits usage and parameter 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?

An output schema exists, so return values need not be described, and the read-only annotations cover behavior. However, for a tool with a filtered parameter, the description omits any reference to the 'skill' filter, leaving a gap an agent would want filled.

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 optional 'skill' enum parameter is never mentioned in the description. With one undocumented filter parameter, the description fails to compensate for the schema gap, leaving the agent to infer the parameter's role.

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

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

The description names a specific verb (read) and resource (current explicit author requests for an exact-version second check) and explicitly separates the concept from peer reviews. It is clear and distinctive, but it does not situate itself against the many sibling tools like commons_read_thread or commons_results.

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 sibling is named. The clarification 'requests are not peer reviews' disambiguates the concept but does not route the agent toward or away from this tool in a workflow.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered before the description is read. The description goes beyond that by flagging that returned text is untrusted and that reviews are not certifications, which is genuinely useful prompt-injection and trust guidance for an agent consuming the payload.

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

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

Two short sentences, front-loaded with the primary action and followed by the trust caveat. There is no filler, though the payoff sentence is compressed to the point of being terse.

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 in detail. However, the description never explains the sole required parameter or resolves the mismatch between reading a "task" and supplying a thread_id, leaving a real gap for an agent trying to call it correctly.

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

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

Schema description coverage is 0%: thread_id carries only a regex pattern, with no explanation of what a thread is or how it relates to the "task" the description mentions. The description never references the parameter at all, so it fails to compensate for the coverage gap and leaves the task/thread relationship to inference.

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

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

The description gives a specific verb+resource pair ("Read a visible task") and enumerates what is returned: exact-version results and peer review reports. It is clear what the tool does, but it does not distinguish itself from close siblings such as commons_tasks, commons_read_thread, or commons_result, so an agent must guess which read tool to pick.

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 or when-not-to-use statement and no named alternative. The only implicit cues are the word "visible" (a scope restriction) and the bundled mention of results and reviews, which hints at a composite single-item read, but nothing tells the agent why to choose this over commons_tasks or commons_preview_result.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: no authentication is required, no publication side effect occurs, and on failure the previous checkpoint should be retained, plus a 60-second wait directive. These are non-obvious operational traits an agent would otherwise have to discover by trial.

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

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

Three short sentences, front-loaded with the core action and followed by operational constraints; nothing is padded. It is slightly over-compressed in places ("wait 60 seconds" lacks an explicit trigger, though failure context is implied).

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

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

An output schema exists, so return values need not be explained, and the failure/retry behavior is covered. However, with four undocumented parameters and no routing guidance relative to the many sibling task tools, the definition is only minimally sufficient 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?

All four parameters (since, skill, state, max_effort_minutes) have 0% schema description coverage, and the description explains none of them. The phrase "query-bound checkpoint" hints that `since` carries a cursor/checkpoint value, but the format, the meaning of max_effort_minutes, and the filtering combinations are left entirely to inference.

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

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

The description has a verb ("Read") and a resource ("task differences"), but "bounded current task differences from a query-bound checkpoint" is jargon that leaves the actual output shape uncertain. It never mentions how it relates to siblings like commons_tasks or commons_task, so an agent cannot easily place it in the family.

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 choose this tool over commons_tasks, commons_task, or commons_contributions. The only operational guidance (keep the old checkpoint on failure, wait 60 seconds) concerns retry behavior, 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 declare readOnlyHint/destructiveHint, so the safety profile is covered. The description adds real behavior beyond that: results are scoped to 'visible' tasks, effort estimates are self-declared rather than verified, and pagination requires re-issuing the same filters with next_cursor.

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 resource and filters followed by the pagination rule. Minimal waste, though 'estimates are declarations' is terse to the point of ambiguity.

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 an 8-parameter list tool with no output schema, the description covers the core filtering story and pagination but leaves half the parameters and the result shape to inference. It is minimally sufficient rather than complete.

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

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

Schema description coverage is 0%, so the description carries the burden, yet it only glosses skill, effort, difficulty and review state — q, limit, state and cursor are unexplained. It also names 'next_cursor' while the parameter is actually 'cursor', a minor naming mismatch.

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 ('Find visible tasks') and names the filter dimensions it operates over. It does not differentiate itself from the singular sibling commons_task or commons_find_threads, so an agent must infer the list-vs-single distinction.

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

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

Usage is implied by the filter list, and pagination guidance ('Follow next_cursor with the same filters') is provided. But there is no statement of when to prefer this over commons_task or commons_find_threads, and no exclusions.

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