Google Scholar Scraper Alternative: Papers, Citations & BibTeX

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

Annotations already cover read-only, open-world and non-destructive status, but the description adds substantial context they cannot express: per-paper pricing ($0.003), spending caps, the 5-15 s vs. minutes runtime split, timeout remediation, and that output is trimmed to whole items with all items in structuredContent. The only gap is that it does not discuss failure/error surfaces beyond timeouts. Note that the parameter-recap sentences largely restate schema text rather than adding new behavioral facts.

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 correctly: purpose, differentiation and when-to-use come before parameter detail and the behavior block. It is long for a single field, and the parameter recap in the first paragraph re-treads schema content (sortBy ordering, retraction billing, readingListSize cost) that an agent has already been given, which is the main source of bloat.

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 21 optional parameters and no output schema, the description compensates well by listing the per-item return fields (summary, readingRank, pdfUrl, retracted, citation, bibtex, ris, abstract) and the {actor, count, items} envelope. Cost model, timeout guidance and the seed-network semantics complete the picture an agent needs before calling.

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 cost caps, billing for maxResults, retraction billing and dataset ordering, and much of the description's parameter walkthrough duplicates that. It does still add genuine cross-parameter meaning: that seedDois alone walks the network while a query searches within it, and that searchIn=fullText trades precision for recall. That added interaction semantics lifts it above the 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 ("Search"), resource ("250M+ scholarly works (OpenAlex)") and source mode ("topic query or seed DOIs"), then enumerates what comes back (DOI, citation count, free PDF link, retraction flag, ready citation). It explicitly contrasts itself with pubmed_evidence_table and researcher_expert_finder, so an agent can separate it from siblings 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?

Gives positive triggers ("real papers on a topic, a reading list, or papers citing/cited by known DOIs") and explicit exclusions with the sibling to use instead ("Do not use for systematic biomedical screening... or to find people"). It also explains the mode-selection rule for seedDois with vs. without a query, which is the main routing decision an agent must make.

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