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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), and the description adds the non-obvious adaptive fallback mechanism plus the fact that the response reports which search mode was used. It does not mention rate limiting, scraping fragility, or how the fallback broadens the query, but the core behavior is disclosed.

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 purpose sentence is front-loaded and the args list follows logically. Given zero schema descriptions, enumerating each parameter earns its place, though the Args/Returns formatting is slightly verbose for a six-parameter 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?

With an output schema present, the brief Returns note suffices, and all six input parameters are documented. For a read-only search tool, an agent has everything needed to invoke it and interpret the search-mode field.

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 full burden and does: it explains every parameter, including the operational meaning of min_results, defaults for count and min_results, and all four sort_by values with their semantics. This is meaningfully more than the schema's bare titles and defaults.

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: an adaptive Google Scholar search that tries precise matching first and falls back to fuzzy matching when results are sparse. The two-stage behavior is clear, but it never names the siblings it competes with (scholar_search, search_papers), so differentiation is left 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?

The description explains the internal trigger condition (results below min_results switch to fuzzy), which is real usage guidance for tuning behavior. However, it gives no guidance on when to pick this over the many sibling search tools, nor any 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, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond them and is actually ambiguous: 'enrich metadata' implies mutation of stored metadata, which sits in tension with readOnlyHint — the description should clarify that enrichment is returned, not persisted. No mention of what alignment entails (matching, merging fields, conflict handling) or cost/latency of an open-world operation.

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?

One short, front-loaded sentence with zero waste, but the brevity is under-specification rather than economy — there is no second sentence earning its place by resolving the ambiguity the first creates.

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?

An output schema exists, so return-value explanation is not required. However, for a single-parameter open-world tool with no schema coverage and an ambiguity between read-only annotation and 'enrich' wording, the definition leaves too much unanswered.

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 parameter paper_id has 0% schema description coverage, so the description must compensate — and it does not. It never says what form of identifier is expected (internal ID, DOI, arXiv ID, Zotero key), which is the main way a caller could get this wrong.

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?

Two verbs (align, enrich) are named, but the resource is left implicit — it is unclear whether the target is a stored paper record, a Zotero entry, or a transient result object. Nothing distinguishes it from siblings such as paper_detail, verify_bibtex, or zotero_save, which plausibly overlap with 'align/enrich 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?

No statement of when to call this versus the many sibling lookup/enrichment tools, and no preconditions (e.g., the paper must first be identified via search_papers or have both preprint and published versions). The agent is left to infer usage entirely.

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, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds only the return type ('str: service status information'), and since an output schema exists, that detail is largely redundant. It adds little context beyond structured fields.

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 lines with no filler, and the core purpose is stated first. The trailing Returns block is slightly redundant given an output schema but is not verbose.

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 health check with rich annotations and an output schema, the description covers what an agent needs to call it correctly. Missing only explicit usage framing, which is minor here.

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 the baseline is 4; there is nothing for the description to disambiguate and the empty schema matches the description's framing.

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 clear verb+resource ('health check endpoint') and states its function ('verify whether the service is running normally'). It is easily distinguished from the search/paper-oriented siblings, though the opening phrase largely restates the tool name.

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 implies the use case (checking service health) and why one would call it, but never states when to use it versus alternatives or any exclusions/prerequisites. Adequate but with clear gaps.

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, idempotentHint and openWorldHint, so the safety profile is covered. The description adds nothing beyond that: it does not say what happens with an invalid or unknown paper_id, what fields the detail contains, or that results come from an external source (openWorld). For a lookup tool it is minimally adequate but contributes no behavioral context of its own.

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 text is short and front-loaded with the purpose, which is good, but the Args/Returns blocks are boilerplate that restate structured fields, and the overall brevity reflects under-specification rather than efficiency.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Still missing are how to source the paper_id and what failure looks like, which matter for an openWorld lookup.

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 must carry parameter meaning. Instead it simply restates the schema field (paper_id: 论文ID) without stating the expected format, whether it is a DOI/arXiv/Corpus ID, or that it should be obtained from a prior search call.

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 and resource: retrieve detailed information for a paper. An agent can tell this is a detail-fetch-by-ID rather than a search, but the description never names or contrasts with siblings such as search_papers or read_paper_sections, so differentiation is left implicit.

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 tool versus alternatives, nor any precondition such as where a valid paper_id comes from. The agent must infer that the ID originates from a search tool.

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, idempotentHint and openWorldHint, so the safety profile is covered. The description adds that the result is a Dict of citing papers, but says nothing about pagination limits on count, rate limits, or whether the call fails for unknown IDs — with annotations carrying most of the load, 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?

Front-loaded with the one-line purpose, then structured Args/Returns sections. The sort_by enumeration is verbose but each entry earns its place by defining a value the schema leaves unspecified.

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 three-parameter read-only query with an output schema already present, the description supplies the purpose, defaults, and full sort semantics. Only the identifier format is underspecified, which is a minor gap given the output schema covers return values.

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 must compensate, and it largely does: it documents count's meaning and default, and enumerates all four sort_by values with their semantics and default, none of which appear as an enum in the schema. The remaining gap is paper_id, described only tautologically as '论文ID' with no format (DOI, arXiv ID, corpus ID).

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: retrieve the list of papers that cite the given paper (获取引用指定论文的文献列表). It is clearly distinct from siblings like paper_detail or search_papers. One caveat: 'references' conventionally means the works a paper cites, while the Chinese phrasing points to citing works — the ambiguity is worth flagging, though the description itself is readable.

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 the purpose statement; there is no explicit 'use this when…' guidance, no mention of when to prefer paper_detail or search_papers instead, and no prerequisites such as whether paper_id must come from a prior search.

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, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds nothing behavioral beyond that — it doesn't note that this performs a network fetch against Google Scholar, whether results are paginated, or how missing/private profiles behave.

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 single imperative purpose line is front-loaded, and the Args block is tight and scannable. The Returns stanza ('Dict: 论文列表') is dead weight since a full output schema exists, but otherwise there is no 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?

With zero schema descriptions across five parameters and no annotation gaps filled in the prose, the description leaves the date-range filters entirely invisible to an agent. For a tool in a namespace full of paper-search siblings, it also gives no routing signal, so it is not complete enough to drive correct selection on its own.

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%, and the description compensates well for three of five parameters, most importantly by enumerating the accepted sort_by values (relevance/citations/date/title) that the schema leaves as an unconstrained string. But year_start and year_end are never mentioned, so two filtering parameters remain completely undocumented anywhere.

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 opening line states a specific verb and resource (retrieve a scholar's papers), so the agent knows exactly what operation is performed. However, it does nothing to distinguish it from crowded siblings such as scholar_search, search_papers, or paper_detail — the profile_url argument is the only implicit signal that this operates on one author's page.

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, no prerequisites, and no mention of any sibling tool. The agent must infer from the profile_url parameter alone that this is the right call for listing an author's publication list versus searching across papers.

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 annotations already declare read-only, idempotent, and open-world behavior. The description adds useful context that the PDF is open-access and that pymupdf4llm must be installed, but it does not describe failure behavior or how section selection behaves.

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 filler. Every clause contributes either the core action or a prerequisite.

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?

An output schema exists and the annotations cover safety, which reduces the description's burden. However, with 0% schema description coverage and no explanation of paper_id or sections, the definition is incomplete for reliable invocation.

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 must explain paper_id and sections. It does neither beyond the generic word 'sections,' leaving the meaning and accepted values of both parameters undefined.

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: 'Extract sections from an open-access PDF.' It is clear what the tool does, but it does not differentiate itself from siblings such as paper_detail or summarize_papers.

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 conditional guidance is the environment prerequisite 'when pymupdf4llm is installed.' It does not say when to use this tool instead of alternatives, nor 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 readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral detail through sort semantics (relevance/citations/date/title) and the year-range scoping behavior. It is slightly inconsistent about output, saying it returns paper abstracts in the headline but a dict of papers in the Returns block, which leaves the result shape a bit ambiguous despite the 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?

The purpose is front-loaded in a single sentence, followed by a structured Args/Returns block that is easy to scan. The parameter enumeration is somewhat redundant in places (restating defaults already in the schema), but nothing is bloated or off-topic.

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 an output schema present, return values need not be fully explained, and the parameter coverage is thorough. What is missing for a search tool in a crowded sibling set is any routing context explaining when this tool is the right choice over the other search and enrichment 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 description coverage is 0%, so the description carries the full burden and largely succeeds: it documents all six parameters, supplies defaults (count=5, fuzzy_search=False, relevance), and enumerates the four sort_by values with their meanings. The only gaps are that fuzzy_search behavior is not explained and year_start/year_end merely say 'optional'.

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 lead sentence names a specific verb and resource (search Google Scholar, return paper abstracts) and maps directly to the tool name. It does not, however, distinguish the tool from close siblings like search_papers, adaptive_search, or paper_references, so an agent cannot tell from the description alone which search entry point to pick.

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 search_papers, adaptive_search, or verify_bibtex. The parameter list is documented, but no use-case conditions, exclusions, or prerequisites are stated anywhere in the description.

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, idempotentHint, and openWorldHint, so safety and side-effect behavior are covered structurally. The description adds only that results come back as a papers list plus metadata, and leaves the cost/latency/scope differences between 'exact', 'adaptive', and 'hybrid' unexplained — the one behavioral distinction that actually matters here.

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?

Well-structured Args/Returns layout that is easy to scan and front-loads the key differentiation. Mild waste in repeating defaults already present in the schema, but overall tight.

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?

The output schema exists, so the terse 'Returns' note is acceptable, and all parameters are at least named. The gap is the undefined strategy modes — for a six-parameter search tool with three distinct search strategies, an agent cannot predict which mode to pick or how they differ.

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 list all six parameters. But several entries merely restate the schema (count default 5, year_start/end 'optional') while the genuinely useful additions are the enumerated values for strategy and sort_by, which the schema does not declare as enums. Strategy semantics remain undefined, so it does not fully compensate.

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 ('Unified academic paper search') and explicitly names the two siblings it supersedes (scholar_search, adaptive_search). An agent can distinguish it from those tools without opening a 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?

The 'replaces scholar_search + adaptive_search' clause is an effective routing hint telling the agent to prefer this tool over those siblings. However, it gives no when-not conditions, no mention of paper_detail or profile_papers as follow-ups, and does not explain when to choose each strategy value.

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, openWorldHint, and idempotentHint, so the safety profile is largely covered. The description adds the return format (Markdown summary) and sorting/date-filter behavior, but does not disclose data source, freshness, summary generation method, or rate limits. With annotations covering the basics, 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?

The description is front-loaded with a clear one-sentence purpose, then structured Args and Returns. The sort_by list is verbose but earns its place because the schema lacks descriptions; overall it is 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?

An output schema exists, and the description also states the return is Markdown summary text. All 5 parameters are documented, including defaults and enum values. The main missing context is sibling differentiation, which is a usage-guideline issue rather than incomplete calling information.

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 must carry parameter meaning, and it does: it explains topic, count with default 5, sort_by with all four enum meanings and default, and optional year_start/year_end. Minor gaps like topic format (keywords vs phrase) remain, but the compensation is strong.

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 pair ('搜索并总结') and resource ('论文') scoped to a topic, so the agent knows it searches and summarizes papers rather than merely listing them. It does not differentiate itself from siblings like search_papers or scholar_search, which keeps it short of 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?

There is no explicit guidance on when to use this tool instead of search_papers, scholar_search, adaptive_search, or paper_detail. The purpose implies a use case, but alternatives and exclusions are absent.

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, openWorld). The description adds genuinely useful behavior — the two-stage matching order — but says nothing about what happens when verification fails, what 'strict title match' tolerates, or external API dependence, which matters for an openWorld 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?

One short sentence, front-loaded with the action and strategy. There is no filler, though it is arguably too terse for the 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?

An output schema exists, so return values need not be explained, and a single read-only parameter keeps the tool simple. Still missing is any detail on failure semantics and input format, which an agent needs to 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 description coverage is 0%, so the description must compensate. It never clarifies that the single 'bibtex' parameter is a full BibTeX record/string rather than a key or DOI, leaving the only input ambiguous.

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 (verify) and resource (BibTeX), plus the verification strategy (DOI first, then strict title match). It does not explicitly distinguish itself from siblings such as align_and_enrich or paper_detail, but the function is unambiguous on its own.

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 ordering hint ('by DOI first, then by a strict title match') implies how verification proceeds, but there is no explicit statement of when to use this instead of align_and_enrich or paper_detail, and 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=false and openWorldHint=true, so the agent knows this mutates state and touches an external service. The description adds a genuine prerequisite (configured API credentials) that the annotations do not convey, which is useful. However, it does not say whether it creates a new item vs updates an existing one, what happens on auth failure, or whether saves are idempotent.

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 key action and prerequisite come first. It is efficient, though its brevity borders on under-specification rather than waste.

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?

An output schema exists so return values need not be explained, but for a mutating external-integration tool with two undocumented parameters the description is too thin. Missing are the meaning of paper_id, the collection semantics, and failure behavior when credentials are missing or the target collection is invalid.

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 must carry the burden, and it does not. It never explains what 'paper_id' refers to (an ID from search results? a DOI?) nor what 'collection' does beyond the schema's bare default of 'Inbox', leaving both parameters semantically opaque.

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 ('Save') and resource ('paper metadata to Zotero'), so the agent knows this is a write-to-Zotero operation rather than a search or read. It is not explicitly differentiated from siblings, but none of the siblings reference Zotero, so confusion is unlikely.

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?

'when API credentials are configured' states a precondition, which implies usage context, but there is no guidance on when to prefer this over other enrichment tools (e.g., align_and_enrich) or what to do when credentials are absent. Usage is implied rather than stated.

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