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

Annotations already cover the safety profile (readOnlyHint, openWorldHint=false), and the description adds real value beyond them: it discloses the return shape (matches with page links) and an important caveat that work under review surfaces only as a one-line summary. No auth, paging, or match-count limits are mentioned, keeping it short of 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?

Two tight sentences, front-loaded with the action and resource, then the return shape and the one caveat. Every clause carries information and nothing is repeated from the schema.

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 one 100%-documented parameter, annotations, and no output schema, the description supplies what is needed: what it searches, what it returns, and the under-review limitation. The only gap is not distinguishing itself from the closely named 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?

Schema coverage is 100%, so the baseline is 3, but the description meaningfully broadens the query semantics: the schema example is 'topic keywords' only, whereas the description states the query can span topic, system, or venue. That is genuine added meaning over 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 (search) and resource (Izzet's publications) plus the dimensions searched (topic, system, venue), which distinguishes it from get_publication and search_papers. However it never names those siblings, so the agent must infer the boundary from the names 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?

Usage is implied by 'search ... by topic, system, or venue', but there is no explicit when-to-use vs when-not, and no pointer to get_publication for a known single item or to search_papers for paper full text. The agent must reason about the routing itself.

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=false, so the safety profile is covered. The description's only extra detail is that a call returns a single section rather than the whole CV, which is already enforced by the required section schema field, leaving no added behavioral context such as error handling 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?

A single front-loaded sentence with no filler. It is appropriately sized, though its brevity borders on under-specification for the ambiguity it leaves unaddressed.

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 tool with sibling overlap and no output schema, the description should clarify the CV/profile distinction and what a section read returns. It does neither, leaving an agent to infer scope from the enum 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 description coverage is 0%, so the description should compensate by explaining the section parameter. Instead it merely says 'one section' and never names the parameter or acknowledges the experience/education/service/certifications/skills enumeration defined 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: read one section of Izzet's CV. It is clear what the tool returns, but it does not distinguish itself from the sibling get_profile, which an agent could reasonably confuse with a CV 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?

There is no guidance on when to use this versus get_profile or the publication tools. The only implied usage is 'read a CV section,' with no exclusions or alternatives named.

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=false, so safety and locality are covered structurally. The description's added value is disclosing the content categories the response contains (contact details, public profiles), which meaningfully helps an agent judge relevance. It says nothing about response format, length, or whether the content is static, but with annotations carrying the behavioral burden that is a minor gap.

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 that lists the payload contents in descending order of importance, with no filler. Every clause maps to something the agent would actually get back.

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 parameters, the description carries the burden of conveying return content, and it does so via the content enumeration. The only thing an agent might still want is a hint about size/format or how this differs from get_cv, which is not covered.

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 for parameter-free tools applies. No misleading parameter hints are present.

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 a specific resource (Izzet's profile) and enumerates the contents: identity, work, goals, contact info, and public profiles. That gives an agent a concrete picture of what it returns. It does not, however, distinguish this from the close sibling get_cv, which plausibly overlaps heavily with 'who he is / what he works 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?

Usage is only implied: calling it an 'Overview' suggests it is the general-summary tool and get_cv/get_publication are the detailed ones, but the description never states when to prefer it or when to use a sibling instead. There are no exclusions or prerequisites.

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=false, so the safety profile is covered. The description adds real context by scoping the read to public data only and enumerating the returned fields, which is valuable given there is no output schema; only error/not-found behavior is left unstated.

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 resource and the returned payload are stated immediately and 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 one-parameter read tool with annotations covering safety and no output schema, listing the returned fields in the description is enough to call it correctly. Only guidance on obtaining a valid id (via find_publications) 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 coverage is 100% and the single id parameter is documented in the schema with an example ('agentstage'). The description's 'by its id' restates what the schema already provides, so the 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 ('Read') plus the resource ('one publication') and enumerates the data returned (authors, venue, summary, results, abstract, links). The phrase 'by its id' implicitly separates it from find_publications/search_papers, but no sibling is named explicitly.

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 only implied: 'by its id' signals that a known publication id is required, so an agent would need find_publications first, but that routing is never stated. There are no explicit when-to-use or when-not-to-use conditions.

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=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the no-section call yields a section listing, and long sections are chunked into parts — critical for an agent to know before calling.

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 section/no-section behavior is front-loaded. Every clause carries information an agent needs.

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 does so at a high level: a section list versus section text split into parts. It stops short of saying what the section list contains (ids vs titles) or how chunking terminates, which is the main remaining gap for a three-parameter read 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 67%; id and section are documented in the schema, but part has no schema description. The description alludes to paging ('in parts when it is long') yet never states that part selects a chunk, its 1-20 range, or how to detect the final part, so it only partially compensates.

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 a public paper's full text') and the scope of what is returned. It implicitly distinguishes from search_papers/find_publications by returning full text rather than matches, but it never names a sibling, so an agent must infer the difference from get_publication (likely metadata).

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 implies usage through its branch logic: omit section to enumerate sections, supply one to fetch body text. That is useful, but there is no explicit when-to-use vs get_publication/get_cv guidance and no stated prerequisites or 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 and openWorldHint=false, lowering the burden, but the description still adds real value by disclosing the return shape (best passages plus paper id and section) despite no output schema. It doesn't mention result limits or ranking behavior, which would be the final piece.

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 and immediately followed by the return behavior and hand-off. No filler or redundancy.

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 read-only search with no output schema, the description covers what it searches, what it returns, and what to do next. Only ranking/limit behavior is absent, which 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?

Schema coverage is 100% and the single query parameter is well documented with an example, so baseline is 3. The description's phrasing about methods, results, datasets, and terms loosely characterizes good query content, but adds no syntax or formatting detail 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?

States a specific verb (search), a precise resource scope (full text of Izzet's public papers and posters), and the target unit (passages about a method, result, dataset, or term). An agent can immediately distinguish it from read_paper or find_publications.

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 routes follow-up behavior: 'follow up with read_paper for more,' giving a clear next step when passage-level results are insufficient. It lacks an explicit 'use X instead when...' exclusion against find_publications, so it stops just short of full when/when-not guidance.

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