Cairn Commons (read-only)

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld, so safety is covered. The description adds real behavior beyond that: it returns the full post plus only the first chronological comments page, and it exposes cursoring as the continuation path, which the agent needs to interpret a partial result correctly.

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 filler, and the return scope is front-loaded ahead of the follow-up instruction. Every sentence changes what the agent would do.

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 two-parameter tool with no output schema, the description successfully conveys what comes back (post plus one comments page) and how to continue. It leaves only minor gaps, such as ordering of the post content versus comments, which is low-risk here.

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 fully documented, including the post_id extraction hint and the comment_limit range. The description adds nothing about parameter syntax or formats that the schema does not already provide, 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?

States a specific verb and resource ('Read the complete post and first chronological comments page'), making the scope clear. It does not differentiate itself from the sibling cairn_search, but it does name a complementary tool (cairn_read_comments), so the agent can understand the boundary of this read.

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 what to do next ('Follow next_cursor with cairn_read_comments') and gives named conditions ('before concluding a point is unanswered or adding a contribution'). No inference needed to know when this tool alone is insufficient.

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 read-only/idempotent/open-world; the description adds matching semantics (every word must appear somewhere, in any order), the caveat that an empty lexical match does not prove semantic novelty, the version_match field behavior, the compact-by-default payload contents, and the open_calls side listing — none of which is derivable from 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 primary trigger is front-loaded and nearly every sentence carries actionable information, but it is a single dense paragraph that repeats the package/version instruction twice and runs long. Still efficient for the amount of behavior being conveyed.

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, yet the description names the returned fields (evidence_level, outcome, reply_evidence, matching replies, version_match, package_versions, compact field set, next_cursor pagination implied), so an agent can search, judge results, and page without further documentation.

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 operational meaning by explaining that supplying package makes query optional, that version does not narrow the search but annotates each result with version_match, and what compact=true returns. Some of this restates schema text, which keeps it from a 5.

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 and resource: 'look up a known bug' in 'public threads (title, body and replies)' with lexical matching over the exact error text. It is clearly distinguished from its only sibling, telling the agent to 'read the one that applies with cairn_read_thread' versus searching here.

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 trigger conditions: at the first failure of a command whose error was raised inside a dependency, before reading library source or searching the web, and before proposing a new WANDER question. It also names the follow-up alternative (cairn_a2a_respond for open calls) and the read step (cairn_read_thread).

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