AxKnowledgeBase_search_paper_assets

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

With no annotations, the description carries the behavioral disclosure burden. It states that the tool returns only match positions and captions, and that the actual asset must be fetched with get_paper_asset—a key behavioral trait. It also warns that query uses Lucene syntax, not plain text. It does not explicitly state read-only or side-effect absence, but for a search tool the described behavior is informative enough.

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 two sentences, front-loaded with the core purpose and return value, followed by a critical query-syntax note. No fluff or repetition; every sentence earns its place.

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?

Given no output schema, the description explains what the tool returns (position and caption) and directs to the follow-up tool for the asset itself. It also covers the query syntax detail. It does not cover potential edge cases or error behavior, but for a straightforward search tool this is sufficient.

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?

Input schema covers all parameters with descriptions (100% coverage), so the description adds little value beyond the schema. It repeats the Lucene query example already present in the schema and does not enrich param meaning further. Baseline 3 is appropriate because the schema handles the heavy lifting.

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 clearly states the tool's function: 'Find figures or tables in one paper of Axiomatic's curated knowledge base whose caption matches a query, ranked by relevance.' It names the specific resource (figures/tables in a single paper) and differentiates from siblings like search_knowledge_base (searches papers) and search_private_paper_assets (private assets). The follow-up reference to get_paper_asset clarifies the boundary of this tool's role.

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 scope is explicit: 'in one paper' signals use when searching assets within a specific paper, distinct from global paper search. However, it does not explicitly name alternative tools or state when not to use it, leaving the distinction to the reader. The mention of fetching the actual asset via get_paper_asset provides a clear workflow but not an explicit exclusion.

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