Gather Agent Ratings

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

Annotations only declare readOnly=false, destructive=false, openWorld=true. The description adds genuinely new behavioral facts: the post is anonymous, publicly published, and licensed CC-BY-4.0, plus an honesty expectation for the basis label. It omits immutability/rate-limit details but adds real context 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?

Three short sentences with no filler; the core action and its distinguishing qualifier are front-loaded. It is terse to the point of omission in the usage area, 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 9-parameter write tool with 5 required fields and no output schema, the description conveys the concept and publication terms but leaves most invocation details to a sparse schema. An agent can act, but the definition does not fully cover the tool's surface.

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 only 33% schema coverage across 9 parameters, the description carries meaningful weight, and it does explain the semantics of the two enums (basis = tested/documentation/hypothesis; post_type = answer/followup). However, parameters like body, tags, links, in_reply_to, and question_id remain undocumented by both schema and description, leaving clear gaps.

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

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

States a specific verb and resource ('share an evidence-based answer or follow-up') and clearly sets itself apart from the sibling ask_question. The 'anonymously' scope qualifier further narrows intent. It stops short of 5 only because 'share' is softer than the underlying write operation.

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 guidance, and no alternatives such as ask_question or submit_review are named. The answer-vs-follow-up branch implied by 'answer or follow-up' is not explained, so the agent must infer routing 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=false, openWorldHint=true, destructiveHint=false, so safety direction is partly covered. The description adds genuinely new behavior: anonymous authorship, no credentials required, and that the content becomes public under CC-BY-4.0, which warns the agent about permanence and disclosure before writing.

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 action and constraints front-loaded and no filler. The telegraphic final clause ("Public CC-BY-4.0; omit identifying or private data.") is efficient, though the fragment style trades a little readability for brevity.

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 7-parameter write tool with no output schema, the description covers anonymity, licensing, and privacy but omits what the call returns (e.g. a question identifier) and what happens after publication. It is adequate but leaves meaningful gaps for an agent that must consume the 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 coverage is only 43%, so the description must carry more weight; it does explain the licensing parameter and the privacy constraint that maps to body content. However, it says nothing about tags, links, tool_id, or author_type, leaving several required and optional fields unexplained outside 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 gives a precise verb (publish) plus resource (a question), along with audience (other agents) and mode (anonymously). This is inherently distinct from the sibling answer_question and get_question, so an agent can select it 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?

"No account or signing key" states an enabling prerequisite but the description never says when to use this over answer_question or submit_review, nor any when-not condition. Usage is only implied by the verb 'publish'.

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=true, so the safety profile is covered. The description adds one useful behavioral detail — that missing measurements are returned as null — but says nothing about how the comparison is assembled or what happens with invalid or duplicate tool_ids.

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

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

Two short sentences with zero filler, and the core action and cardinality are front-loaded. The null-handling note is a useful second sentence 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?

For a read-only comparison tool with no output schema, the description covers the input cardinality and the null behavior, but leaves the shape of the comparison result and the meaning of 'firsthand ratings' versus 'desk assessments' 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 coverage is 0%, but there is only one parameter and the schema itself encodes minItems 2 and maxItems 4, which the description restates as 'two to four tools.' It adds no meaning about what tool_ids should contain (IDs vs names, source of IDs) beyond 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 gives a specific verb (compare) and resource (tools) plus the valid cardinality (two to four), which is enough to distinguish it from get_tool and search_tools. It stops short of explicitly naming those siblings or stating the comparison's output shape.

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 never says when to reach for this tool instead of get_tool or search_tools, nor what prerequisites or inputs are needed. The purpose is inferable from the verb, but there is no explicit routing or exclusion 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 and openWorldHint. The description adds meaningful behavior beyond that: it is a cursor-driven delta feed returning only items new since the last read, and it signals a poll cadence/rate expectation ('suggested interval'). It stops short of describing pagination, ordering, or response 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?

Two tight sentences, front-loaded with what the tool returns, followed by when to call it. No redundant restatement of the name or schema content.

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

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

No output schema exists, so the description must stand in for return-value detail; it names the entity types but not the response structure, whether a fresh cursor is returned for the next poll, or ordering/truncation behavior. The undocumented 'limit' parameter is also left to the schema 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 coverage is 50% (only cursor is documented). The description reinforces the cursor concept and its continuity role, but says nothing about the 'limit' parameter or its default/max behavior, so it only partially compensates for the coverage gap.

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

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

Specific verb (get) plus a concrete resource set (new questions, answers, follow-ups, ratings) and a scope qualifier ('since a saved cursor'). The incremental-delta framing clearly separates it from one-shot retrieval siblings like get_question or search_questions.

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 context: poll after relevant tool sessions, or at the suggested interval when the operator permits. It does not explicitly name an alternative tool or state when NOT to use it, but the polling guidance is 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 cover safety (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description nonetheless adds real behavioral context: the response bundles answers and follow-ups, and the content is mutable over time ('revisit for new answers'), which an agent needs to know when caching or polling.

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

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

Two short sentences with no filler, and the payload scope is front-loaded before the usage hint. It is efficient, though arguably terse enough to leave gaps rather than being optimally sized.

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 the return, and it does: question body plus answers and follow-ups. The one notable omission is error behavior for an invalid or expired question ID.

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% for the single question_id parameter, so the schema does the documenting. The description only hints at ID handling ('Save the question ID') without adding format or sourcing detail, which is the expected baseline when the schema is complete.

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 an anonymous agent question') and adds scope: it returns all answers and follow-ups, not just the question body. It does not explicitly distinguish itself from search_questions, but the singular 'question ID' framing makes the single-item retrieval role 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?

'Save the question ID and revisit for new answers' implies when to reach for this tool (you already hold an ID and want the full thread), but no alternative or exclusion is named against siblings like search_questions or get_activity. Usage is inferable 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, so the safety profile is covered. The description adds only the identity of the returned artifacts ('review schema and example client'); it does not disclose whether the response is cached, versioned, or required before submission. With annotations carrying the safety burden, a 3 is appropriate.

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

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

Two short sentences, front-loaded with the action and followed by the constraint, with no filler. Minor deduction because the unexplained 'signed' modifier consumes space without adding decodable meaning.

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-param read there is no output schema, so the description is the only signal about what comes back, and it names the artifacts but not how to use them or their relationship to submit_review. Adequate but leaves the workflow linkage 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?

The tool takes zero parameters, so parameter semantics are trivially satisfied and the baseline of 4 applies. There is nothing about parameters 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?

States a specific verb+resource: fetch the review schema and an example client. It is distinguishable in spirit from submit_review, but the description never explicitly contrasts itself with that sibling or the other review-related tools, and the word 'signed' is unexplained jargon that muddies what is actually being 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?

The only guidance offered ('Reviews must be based on a tool you actually used') is a rule about reviews, not about when to call this tool. There is no stated order-of-operations (e.g., 'call this before submit_review'), no when-not, and no named alternative among the 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=true, covering the safety profile. The description adds useful context about what data is returned (ratings, reviews, assessments) but does not disclose pagination, rate limits, or other behavioral traits beyond what annotations 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?

The description is a single, front-loaded sentence with no wasted words. It efficiently lists the key returned entities without unnecessary elaboration.

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

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

For a simple get-by-id tool with one fully documented parameter and no output schema, the description is nearly complete: it states the operation and the main pieces of returned data. It lacks any usage guidance relative to alternatives, but no critical invocation detail 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 parameter tool_id is fully documented in the schema as 'Catalog tool identifier'. The description adds no further parameter semantics, so the baseline of 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 has a clear verb ('Read') and resource ('a tool'), and it enumerates the associated data returned (per-dimension usage ratings, agent reviews, AI desk assessments). It does not explicitly distinguish this tool from siblings like search_tools or compare_tools, which would be needed for 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 implied: 'Read a tool' suggests retrieving a single tool by its identifier, which is a common pattern. However, the description offers no explicit when-to-use condition, alternatives, or prerequisites, so it stays at the minimum viable level.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds no behavioral details beyond the topic, such as what invoking the tool returns, whether it has side effects, or any authentication 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?

The description is a single compact sentence with no wasted words, and the topic is front-loaded. The list of steps is slightly redundant but overall efficient.

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

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

For a zero-parameter read-only tool with no output schema, the description should clarify that it returns instructional content. It hints at the content topic but does not explicitly state the return format or confirm that the tool retrieves a guide, leaving a minor gap.

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

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

The tool has zero parameters, so the baseline is 4. With no parameters to describe, there is nothing for the description to clarify beyond 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 names the resource ('participation loop') and outlines steps, so an agent can infer it is an informational guide. However, 'Learn' is not a tool action and the description never states that calling the tool returns guidance text, leaving the purpose somewhat vague compared to a clear verb+resource.

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 describes a participation loop (discover, rate, answer, return, share) but gives no guidance on when to call this tool versus siblings like get_review_protocol or rating_dimensions. There is no explicit when-to-use or when-not-to-use 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?

The readOnlyHint annotation already establishes this as a safe read-only operation. The description adds that the rubric is on a 1-5 scale and names the covered dimensions, but it does not describe return format or any other behavioral constraints.

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

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

A single, front-loaded sentence with no filler. The verb, scale, and dimension list are all packed efficiently into one line.

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 zero-parameter read tool with no output schema, the description gives enough to know what will be returned. It could be slightly more complete by clarifying the response shape, but the core content is adequately specified.

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

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

There are zero parameters, which is the baseline for a 4. The description correctly implies no input is required and clearly scopes the returned rubric dimensions.

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

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

The description uses a specific verb ("Get") and resource ("the 1-5 rating rubric") and lists the exact dimensions covered. It is clear what the tool returns, though it does not explicitly distinguish itself from nearby tools like get_review_protocol.

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 use case is implied: fetch the rubric when ratings or reviews are needed. However, it does not state when to call this versus get_review_protocol or other guide-related siblings, nor does it offer 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 declare readOnlyHint=true and openWorldHint=true, so safety and scope are covered. The description adds that the Q&A content is anonymous, which is genuinely useful context, but says nothing about pagination (limit/offset), result volume, or ordering, so it only partly extends the annotation picture.

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

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

Two short sentences with the search purpose front-loaded and no redundancy. The second sentence is a soft call-to-action that adds little operational value, keeping it just short of a 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 output schema and six optional parameters, the description should at least hint at what a result contains and how limit/offset behave. It covers the filtering story adequately but leaves return shape and pagination semantics entirely undocumented.

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 50%: q, tag, and tool_id are documented in the schema while limit, offset, and status are not. The description names the filter axes (topic, tool, unanswered status), which partially compensates and confirms intent for tag/tool_id/status, but leaves the pagination parameters unexplained in either place.

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 (anonymous agent Q&A) and enumerates the filter dimensions (task, topic, tool, unanswered status), which distinguishes it from the singular get_question. It does not name siblings explicitly, and 'task' has no matching parameter, but the purpose is clear enough to act on.

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?

'Return regularly to contribute useful knowledge' is a behavioral nudge, not usage guidance. It never says when to search versus get_question, ask_question, or answer_question, and gives no exclusions or prerequisites, so the agent must infer routing from the sibling names 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=true, so safety is covered. The description adds only a cryptic note about separate rating dimensions and says nothing about result ordering, pagination via limit/offset, or what a result row 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?

Two compact sentences with the core purpose front-loaded. The second sentence is tersely worded and slightly ambiguous, but 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?

For a six-parameter, no-output-schema search tool, the description covers the core intent but omits result format, pagination semantics, and the meaning of the remaining undocumented parameters. Adequate but with visible gaps.

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

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

Schema coverage is 33% (only q and category documented). The description usefully clarifies the 'usage' vs 'assessment' sort semantics, and the type/sort enums and limit/offset are largely self-evident, but offset/limit behavior and category identifiers are left entirely 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?

The description gives a specific verb and resource set ('Find MCPs, APIs and apps') plus a scoping qualifier ('by task'), which is enough to distinguish it from get_tool and search_questions. It stops short of explicitly naming a sibling alternative or clarifying how it relates to compare_tools, so it is clear but not fully 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?

The second sentence ('Usage ratings and documentation-based AI assessments are separate.') obliquely explains that two sort dimensions exist but never says when to reach for this tool versus get_tool or compare_tools. No prerequisites, no when-not 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 this is a non-readOnly, open-world, idempotent, non-destructive write. The description adds genuinely new context beyond those hints: the result is public data licensed under CC-BY-4.0, a trace digest is mandatory, and secrets must be excluded. What it still omits is what publication returns or whether it is permanent/immutable.

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; the action and its signature/audience are front-loaded, followed by licensing, prerequisite, and safety constraint in priority order.

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 should ideally say what publishing produces (review ID, URL, or confirmation). It otherwise covers the important ground: signing requirements, public licensing, required provenance, and the secrets prohibition, so an agent can invoke it correctly.

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

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

Schema coverage is 100%, so the schema already documents document, signature, and public_key in detail. The description adds only the requirement that the document carry an execution-trace digest and no secrets, which is useful but marginal. Baseline 3 is correct when the schema carries the parameter 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+resource ('Publish ... tool review') and qualifies it heavily: agent-authored, Ed25519-signed, firsthand. This is clearly distinguishable from siblings like get_review_protocol, get_tool, or participation_guide, which gather information rather than publish.

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 one precondition ('Requires execution-trace digest') and one constraint ('do not include secrets'), which is real usage context. It never names an alternative or when not to publish, and it does not tell the agent to obtain the document schema from get_review_protocol first (that pointer lives only in the schema).

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