Disambiguate a human author name into ranked identity candidates. Use this before scholarfetch_author_papers when the name is ambiguous and you need a stable candidate_index. If you pass engines, it must include openalex.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| limit | No | ||
| engines | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose a constraint on the engines parameter and indicates the output includes a stable candidate_index. However, it does not describe ranking behavior, error handling, or any side effects. With no annotations, this is acceptable but not comprehensive.
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 the primary purpose, and every clause earns its place. No filler or redundancy. The key usage guidance and a critical constraint are included without extra verbosity.
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 tools' purpose and usage are well covered, and the output schema exists so return values are not the description's burden. However, with no annotations and no parameter descriptions for limit, the description is slightly incomplete for a tool of moderate complexity. Still, the guidance is enough for an agent to select and call the tool 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 add meaning. It gives context for `name` (human author name) and `engines` (must include openalex), but `limit` is not explained beyond its schema default. The description adds some value but does not fully compensate for the lack of parameter descriptions.
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, actionable verb phrase: "Disambiguate a human author name into ranked identity candidates." This clearly distinguishes the tool from siblings like scholarfetch_search (which searches literature) and scholarfetch_author_papers (which fetches papers for an existing author identity).
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 usage guidance is provided: "Use this before scholarfetch_author_papers when the name is ambiguous and you need a stable candidate_index." This names the sibling tool and states the precise scenario where the tool is needed. It also adds a critical constraint: if engines is passed, it must include openalex, guiding parameter choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct operation: searching, DOI lookup, author disambiguation, paper listing, abstract/full-text retrieval, reference expansion, and saved-list management. No two tools overlap in purpose, and the descriptions clearly differentiate entry points (DOI vs. author vs. keyword) and output types.
All tools share the 'scholarfetch_' prefix and use lowercase snake_case, but the second part mixes nouns (abstract, article_text, references) with verb phrases (saved_add, doi_lookup, search). This is a minor deviation from a strict verb_noun pattern, but the overall pattern remains predictable and readable.
With 12 tools, the server is well-scoped for academic literature retrieval and management. Each tool has a clear role, and the count is within the ideal range, providing a complete workflow without unnecessary bloat.
The tool surface covers the full research process: discovery (search, DOI lookup), author exploration (candidates, papers), reading (abstract, full text), citation traversal (references), and library management (saved add/list/remove/export). No obvious gaps exist for the stated purpose.