coExploro

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 meaningful beyond-annotation context: content is generated from captured third-party sites, sanitized, and every response string should be treated as untrusted data rather than instructions — a valuable prompt-injection warning.

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 before the untrusted-data caveat, and every clause carries information. Slightly dense but 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 compensates by enumerating the returned fields and clearly bounding the tool as a summary rather than a full teardown. Combined with the annotations and the single well-explained parameter, an agent has what it needs to call this 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%, so the description carries the burden, and it does: it explains the sole parameter is a host and gives a concrete example ('stripe.com'). It adds real meaning over the bare `host` string property, though format/validation nuances (maxLength 2048) remain only in 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 and resource ('Get the scorecard for one corpus product teardown') and enumerates the returned contents (overall score, UX six dimensions, persona findings, counts). The 'corpus' qualifier plus the sibling names imply the distinction from get_public_teardown/get_shared_teardown, but the description never explicitly contrasts them.

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

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

Usage is implied by 'one corpus product teardown by host' and the explicit scope note 'This is a summary, not the full teardown,' but there is no when-to-use guidance or routing between the corpus/public/shared variants or the list_* 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 destructiveHint=false, and the description adds provenance the annotations cannot convey: the content is curated editorial material authored by coExploro, not a live capture, and its text should be treated as data rather than instructions. That prompt-injection warning is directly actionable for an agent consuming untrusted-looking 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 clauses, zero filler, with the core purpose front-loaded before the discovery hint and the safety note. Every sentence earns its place.

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

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

With no output schema, the description adequately frames what comes back (one full curated teardown) and its trust status. Return shape details like size or field structure are left unstated, but for a static single-item fetch that is 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 single slug parameter has 0% schema description coverage, so the description must carry it, and it does: it tells the agent that valid slugs come from list_public_teardowns. It does not give the slug format, but the discovery path makes the parameter usable without guessing.

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 one full curated sample product teardown') and scopes it to a single item. The 'public' qualifier plus the routing to list_public_teardowns implicitly separates it from get_corpus_teardown and get_shared_teardown, though it never explicitly contrasts those siblings.

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

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

Gives a clear precondition for use: the slug must be discovered via list_public_teardowns, which is named explicitly. It stops short of stating when-not to use it or how it differs from the corpus/shared teardown getters, so it is clear context rather than full 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?

Discloses behavior well beyond the annotations: it warns the content is captured from third-party sites and sanitized, that every string must be treated as untrusted data rather than instructions (prompt-injection defense), and that reading increments a view counter. The counter note also coherently explains why readOnlyHint and idempotentHint are false, so the description and annotations reinforce each other.

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 tightly written sentences, front-loaded with the core operation and followed by only the safety and side-effect context an agent actually needs. 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 getter with no output schema and no annotations covering safety semantics, the description covers purpose, security handling, and the counter side effect. The only real gap is disambiguation from its four similarly named 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 0%, so the schema alone does not document share_token, but the description only restates the concept ('by share token') without adding format or syntax detail beyond the schema's uuid format. Some value, but it does not fully 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?

States a specific verb and resource ('Get a public shared teardown') plus the access mechanism ('by share token'), so the agent knows exactly what this returns. It does not distinguish itself from the sibling get_public_teardown, leaving the shared-vs-public 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?

Usage is implied by 'by share token' – the agent can infer it needs a token in hand – but there is no explicit when-to-use guidance and no mention of the sibling get_public_teardown or get_corpus_teardown as 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 readOnly, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely valuable context beyond that: the content is generated from captured third-party sites, sanitized, and every returned string must be treated as untrusted data rather than instructions.

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 list semantics and returned fields, then the alternative, then the trust warning. No filler and every sentence carries useful information.

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

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

Despite lacking an output schema, the description enumerates the returned fields (host, date, overall/UX/persona scores) and adds the untrusted-data caveat, so an agent knows both what it gets back and how to treat 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The schema does not need compensating for.

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

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

States a specific verb (List) and resource (product teardowns in the coExploro corpus), and enumerates the returned fields (host, capture date, scores). This clearly distinguishes it from the singular get_corpus_teardown sibling.

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 the alternative for a single product (get_corpus_teardown with a host), giving a clear condition for choosing between the two. It does not address how it relates to list_public_teardowns, leaving the corpus-vs-public distinction 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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the overallScore is a four-persona consensus explicitly not a UX score (with a legacy field-name caveat), and the content is editorial/curated rather than a live capture, with an explicit prompt-injection warning to treat text as 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?

Front-loaded with the core purpose, then a compact field enumeration and two caveats. It is a dense single paragraph with no filler, though the uxScore-renaming parenthetical is slightly verbose for the value it adds.

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 shape and does so by naming every field, plus flagging the non-obvious overallScore semantics. What is missing is only the routing context relative to its four sibling 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?

There are zero parameters, so per the rubric the baseline is 4. The description correctly adds no parameter semantics and instead spends its space on return-field 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 (List) and resource (curated sample product teardowns from coExploro), and enumerates the returned fields. However, it never distinguishes itself from the sibling list_corpus_teardowns, so an agent must infer the public-vs-corpus split from the name 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 when-to-use guidance and no mention of alternatives such as list_corpus_teardowns or the get_* siblings. The agent is left to infer that this is the browse-all entry point and that a single teardown requires a different tool.

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