reviewpaper.ai

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real context beyond them: the mapping preserves distance from each venue's acceptance bar and is explicitly a heuristic, which is meaningful behavioral disclosure.

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 core action and closed with the caveat. Every clause earns its place with no repetition of structured fields.

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 hint at the return shape; it implies per-venue mapped scores but doesn't state the format explicitly. Everything else an agent needs to call it correctly is present.

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 documents venue, score, and the default-all to list. The description adds no parameter-specific syntax or format detail, making the baseline 3 correct.

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 ('Map an overall review score at one venue to the same position on other venues' scales') and even explains the mapping philosophy, so the agent knows exactly what it does. It stops short of naming a sibling like iclr_acceptance_odds to distinguish itself, keeping it at 4 rather than 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?

'A heuristic for intuition, not an official equivalence' tells the agent the trust level and appropriate context of use. It gives clear usage context but names no explicit alternative tool or when-not condition, so it falls short of a 5.

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/idempotent/non-destructive, so the safety profile is covered; the description adds real behavioral context on top: the 'CVPR' shorthand resolves to the next upcoming edition, dates are reported AoE and in ISO format, and the payload includes links to a review form. It omits what happens when a conference matches nothing, but this is a strong contribution 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?

Two dense, front-loaded sentences: return content first, input behavior second. Every clause carries information and nothing is padded.

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 describe returns, and it does so field-by-field with timezone/format conventions plus the review-form links. It stops short of covering the not-found/ambiguous-name case, which is the only gap for a single-parameter lookup 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% and the schema already gives example values, so the baseline is 3. The description goes further by defining a resolution rule absent from the schema — a bare venue name like 'CVPR' selects the next upcoming edition, and both 'cvpr-2027' and 'CVPR 2027' are valid forms.

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 ('Full timeline for one conference edition') and enumerates the returned date fields (abstract/registration, paper, author response, decision) plus review-form links. The scope word 'one' implicitly distinguishes it from the list_deadlines sibling, though the sibling is never named.

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 explains accepted input formats and the bare-name fallback, which hints at when it is usable, but it never states when to prefer this tool over list_deadlines or get_review_form, and gives no exclusions or error conditions. Usage is implied rather than guided.

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 the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the payoff of the response: the policy content plus an 'official policy link'. That return-content hint is useful given there is no output schema, though it stops short of noting behavior when a venue has no published policy.

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 waste: what it returns first, when to use it second. Front-loaded and appropriately sized for a one-parameter read tool.

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, fully-annotated read tool, the description covers purpose, trigger, and response shape. The one unaddressed case is what happens when a venue has no LLM policy on record, which an agent might want to know before relying on 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 100% and the single 'venue' parameter is documented in the schema as accepting a slug, name or alias. The description adds no formatting or lookup guidance beyond that, so the 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?

States a specific resource and scope: a venue's LLM/AI-use policy, covering both authors and reviewers, plus the official policy link. No sibling in the list overlaps with this domain, so differentiation isn't needed. The only minor shortfall is that the verb ('get') is implicit rather than stated.

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 triggering condition: 'Use before advising someone on AI use for a submission or a review.' There are no exclusions or named alternatives, but none of the siblings compete for this task, so the guidance is sufficient context without being explicit about when not to use 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 readOnly, idempotent, non-destructive, closed-world behavior, so the bar is low. The description earns credit by detailing exactly what is returned (ordering of fields, official score labels, checklist, acceptance bar), which is valuable given there is no output schema.

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, no filler: one enumerating return contents, one covering accepted input forms. The content list is dense but every item is informative, and parameter guidance is appropriately deferred to the second sentence.

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 return-value burden and does so thoroughly. The single required parameter is fully covered. Only the missing sibling-disambiguation (e.g. reviewers form vs LLM policy) keeps it from being 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 coverage is 100% for the single venue parameter and already lists examples ('iclr', 'CVPR'). The description echoes the slug/name/alias flexibility with matching examples ('iclr', 'NeurIPS', 'ACL Rolling Review', 'cvpr'), adding marginal value 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 specific resource (the venue's reviewer form) and enumerates its contents precisely (fields, score scales, author checklist, meta-review, acceptance bar, LLM policy). It's clear what the tool returns, though it leads with a noun phrase rather than a verb and doesn't explicitly distinguish itself from the overlapping get_llm_policy 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?

There is no statement of when to use this tool versus get_llm_policy, get_deadline, or the other siblings, despite the LLM-policy overlap being an obvious source of confusion. Usage must be inferred from the content list 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add what they can't: the data source (public OpenReview decisions), the estimation method (kernel estimate over past score profiles), and the important caveat that the result is historical, not predictive. This is meaningful context beyond the structured fields, though it doesn't address output granularity (e.g., whether a confidence measure or sample size accompanies the rate).

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 what is computed, then the input rule, then the scope disclaimer. No filler and nothing buried; every sentence carries a distinct piece of 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?

With no output schema, the description carries the burden of explaining the return value; it identifies the output as an acceptance rate derived from a kernel estimate, which is enough to know what comes back conceptually. It stops short of saying whether the response includes a sample size or uncertainty range, a modest gap for a statistical estimate 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 3 is the baseline; the description earns above that by clarifying that ratings must be given 'as the reviewers gave them' — i.e., raw reviewer scores, not converted/normalized values — which matters directly given the sibling convert_score. The 3–6 count repeats the schema's minItems/maxItems rather than adding new information.

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 computation (historical acceptance rate for papers with similar reviewer ratings) over a specific resource (OpenReview decisions), which is clearly distinct from every sibling tool (convert_score, get_review_form, list_venues, etc.). An agent can tell immediately this is an odds/lookup tool, not a score converter or form fetcher.

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 gives a clear input condition ('Give 3–6 ratings as the reviewers gave them') and an explicit boundary ('Not a prediction of any decision'), which tells the agent when the output is and isn't appropriate to lean on. It does not name an alternative tool, but no sibling competes for this use case, so the omission is minor.

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, idempotent, non-destructive, closed-world), and the description usefully adds sort order ('soonest first'), dual time representation (AoE and ISO-8601 UTC), and the default exclusion of projected dates. Missing details like result caps/pagination behavior or data refresh cadence keep it from a 5.

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 dense sentence that front-loads the resource and scope, then qualifies formatting and filtering. No filler, though the final clause about projected dates is somewhat heavy for one sentence.

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 disclosing coverage (~64 conferences), ordering, timestamp formats, and default filtering behavior, while all four parameters are bounded or described in the schema. An agent has enough 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 75% and the area enum, within_days and include_estimated are all documented in the schema. The description only restates the include_estimated filter ('projected (not yet announced) dates are excluded unless include_estimated is true') and says nothing about limit, so it adds little beyond the schema — baseline 3.

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 ('Upcoming paper and abstract deadlines for ~64 ML, CV, NLP... conferences'), plus scope, coverage count and sort order. The plural/list framing cleanly distinguishes it from the singular sibling get_deadline and from list_venues.

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?

Clear context for when this is the right call: upcoming deadlines only, soonest first, projected dates withheld unless include_estimated is true. It does not name an alternative sibling (e.g. get_deadline) or state exclusions in terms of those tools, so it falls short of a 5.

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, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description adds real behavioral value by disclosing what is returned: score scale, official-vs-modeled provenance flag, and links.

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 tightly written sentences, front-loaded with the scope (29 venues) and ending with the sibling routing rule. No filler or repetition of the title.

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 usefully previews the returned fields (score scale, provenance, links), which is what an agent needs before calling. It is complete for a simple read-only listing, though it omits things like ordering or pagination behavior.

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 'area' parameter's enum is fully documented in the schema. The description's mention of ML/NLP/CV/data-mining hints at the area filter but adds no syntax or format detail beyond the structured field, 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?

States a specific verb ('List') and resource ('venues') with concrete scope (29 ML / NLP / CV / data-mining venues whose forms are modeled). It explicitly distinguishes itself from the sibling get_review_form, which returns the full form rather than the directory.

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 sentence 'Use get_review_form for the full form' gives an explicit alternative for the detail case, so the agent knows this is the browsing/selection step. It does not spell out when-not-to-use conditions beyond that, keeping it at a strong 4 rather than 5.

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