Crivum

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

No annotations exist, so the description carries the full burden and does it well: it discloses the return payload (score, per-criterion breakdown, three-model divergence, DOI eligibility), the authentication requirement (API key), language behavior (reads any language, answers in the text's language), a calibration caveat across languages, and two scope disclaimers (not peer review, not accreditation).

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 action and the return contract, and most sentences earn their place (exclusions, disclaimers, language caveat). It drifts slightly toward prose in the language-calibration and Portuguese-trigger sentences, which are useful but loosely attached.

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

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

With no output schema and no annotations, the description supplies the return values, the authentication requirement, the idempotency hook, and the scope boundaries an agent needs before calling. It stops short of describing errors, latency, or where get_criteria must be consulted first, which for a 5-parameter tool leaves a small 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 100%, so the schema already explains text, title, work_type, evaluation_id and academic_level. The description adds only indirect meaning — the excluded document classes constrain which work_type values are valid — without naming any parameter, so baseline 3 applies.

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

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

The verb+resource are specific: score a text against published academic criteria, with concrete input types (paper, case report, thesis chapter, teaching material) and a stated output (0–100 score). It never names the sibling screen_text, so an agent cannot tell from this text alone how scoring differs from screening.

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

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

Explicit when-to-use (user wants to know how strong a work is, or wants a reviewable score before submitting) and explicit when-not-to-use (recipes, operational legal documents, workout plans, how-to instructions). Alternatives such as screen_text or get_criteria are not referenced as routing options.

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?

With no annotations provided, the description carries the full behavioral burden. It discloses that no API key is required and that results include version numbers, and it implies a pure read operation ('Return'). It doesn't mention rate limits or caching, but for a zero-parameter getter this is adequate.

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 first sentence is a dense list, but every item is informative. The second sentence adds authentication and usage context; the third provides a Portuguese trigger. There is no fluff, though the enumeration is slightly long.

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 the tool has no parameters and no output schema, the description covers what is returned, the authentication requirement, and when to use it. Nothing needed for correct invocation is missing.

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

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

The tool has zero parameters, so there is no parameter documentation burden. The description focuses on return values rather than parameters, which is appropriate. Baseline 4 for 0-param tools 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 uses a specific verb ('Return') and precisely enumerates the resource and its contents: public rubric by work type, tier ladder, thresholds, minimum score for citable records, accept/refuse criteria, each with version numbers. It also differentiates from siblings by positioning itself as a pre-call for evaluate_text, so an agent can distinguish it from screen_text and verify_record.

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 states explicit use cases: 'Use before calling evaluate_text, or to show a user what a score decomposes into.' It also provides a Portuguese trigger phrase, which helps with localization. It does not explicitly list when-not-to-use alternatives, but the guidance is clear enough.

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?

With no annotations, the description carries the burden, and it discloses useful operational traits: it runs on a single cheap model, needs no API key, and returns up to six questions. It also notes the Portuguese trigger phrase. It does not state whether the draft is persisted or explicitly confirm read-only behavior, but the 'before spending anything' framing implies no side effects.

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 multi-sentence but front-loaded with purpose and outputs, then usage guidance and alternative. The Portuguese trigger phrase and cost details earn their place, though the text is denser than strictly necessary.

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

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

For a one-parameter tool with no output schema, the description covers what is returned (score, suggested work type, questions), when to use it, cost/auth, and the better alternative. No critical information for invoking it correctly appears missing.

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

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

The only parameter, text, is already fully described in the schema (coverage 100%), including min/max length and trimming behavior. The description therefore adds little beyond high-level output context; baseline 3 is appropriate.

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

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

The description opens with a specific action ('Check whether a draft is ready') and names concrete outputs: a 0-100 readiness reading, suggested work type, and up to six objective questions. It also explicitly contrasts with evaluate_text, which prevents confusion with a sibling tool.

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

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

It states exactly when this tool is the right first call ('when a user asks if a paper... is good enough yet') and explicitly routes to evaluate_text when a citable score is needed. This gives an agent clear selection logic.

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?

With no annotations, the description carries the behavioral disclosure burden. It reveals the rejection of multi-identifier calls, states that no API key is required, and includes a Portuguese trigger phrase. It does not cover not-found errors or response format details, but the provided behavior is meaningfully transparent for a lookup 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?

The description is compact and front-loaded with the core function, followed by usage modes, rejection behavior, auth, and a localization trigger. Each sentence earns its place, though the Portuguese phrase is slightly tangential to tool mechanics and could be seen as extra.

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 no output schema and no annotations, the description covers return fields, invocation modes, rejection behavior, and auth requirements. The schema supplies pagination defaults and cursor semantics. The only notable gap is explicit handling of unknown identifiers or error responses, which is minor for a read-only verification tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by defining mutual exclusivity among slug, doi, and codigo, and clarifying that limit and cursor apply to browsing mode. This gives agents higher-level usage context the schema alone does not convey.

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

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

The description states a specific verb ('List') and resource ('Crivum's published, citable records'), and enumerates the fields returned (title, authors, DOI, tier, score). It clearly distinguishes the single-record verification mode from the browse mode, and the focus on record verification separates it from sibling tools like evaluate_text and screen_text.

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

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

Provides explicit operational guidance: pass exactly one of slug, doi, or codigo to check one record, or omit all three to browse. It also states that multiple identifiers are rejected. It does not explicitly name sibling tools as alternatives, but the when-to-use instructions for this tool's modes are unambiguous.

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