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

With no annotations, the description carries the full burden. It does disclose two real behavioral traits: it never returns key values (a privacy/exposure guarantee) and it does not validate entitlements (an explicit scope limit). It is silent on auth requirements, side effects, and what the report actually looks like.

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 short sentences, zero filler, with the scope limitation front-loaded right after the core action. Nothing could be removed without losing meaning.

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, no-output-schema check, the description conveys the essential contract: a boolean-style report on key presence with no value leakage and no entitlement validation. It would be stronger if it sketched the return shape, but nothing critical 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. The empty schema at 100% coverage confirms the baseline of 4 applies here.

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+resource ('Report whether keys are set') and immediately scopes it ('never their values'). It is unambiguously distinct from the paper-oriented siblings (search_papers, read_passage, etc.), though it doesn't name a sibling it could be confused with.

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?

'Does not validate entitlements' is a useful when-not boundary, steering an agent away from using it as an entitlement/authorization check. However, there is no positive guidance about when an agent should reach for this tool versus other diagnostic steps.

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?

With no annotations, the description carries the full burden, and it discloses the auth/entitlement requirement plus an important behavioral constraint (metadata-only responses are rejected as full text) and the returned identifier. It omits failure modes, error behavior, and where the downloaded XML is stored, keeping it below the top band.

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?

Three short sentences, front-loaded with purpose, then prerequisites, then output linkage and constraint. Every sentence carries distinct information with no filler.

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 downloader with no output schema and no annotations, the description covers prerequisites, the return value, and the key acceptance constraint. Missing details (destination/format of the downloaded XML, error cases) are minor but non-zero gaps.

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% for the single doi parameter, but the description indicates the DOI is the lookup key and the target is Elsevier full-text XML. The parameter name is self-explanatory, so the added meaning is marginal rather than compensatory.

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 (Download), resource (Elsevier full-text XML), and retrieval key (DOI), which lets an agent distinguish it from the sibling download_springer_nature_paper by publisher. It stops short of explicitly naming that sibling or stating it should not be used for non-Elsevier DOIs, so it is clear but not fully differentiated.

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 concrete preconditions (ELSEVIER_API_KEY and access entitlement) and a downstream workflow hint (returns paper_id for index_papers), which is more than implied usage. It does not, however, tell the agent when to prefer this over alternatives such as download_springer_nature_paper or extract_paper.

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?

With no annotations, the description carries the full burden and does disclose key behaviors: auth requirement, coverage limitation, and an explicit failure contract ('unavailable full text is reported, never fabricated'). It omits rate limits, permission scope details, and what the returned JATS payload looks like.

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?

Three short sentences, front-loaded with the action and source, followed by prerequisite and limitation. Every sentence carries distinct information with no 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 download tool with no output schema and no annotations, the description covers auth, coverage limits, and error behavior adequately. It could add return-format expectations, but the essential call-time information is present.

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 'doi' has 0% schema description coverage, so the description should compensate, but it only implies matching via 'matching full-text' and never explains the doi argument itself. The parameter name is largely self-evident in this context, so this is a minor rather than severe gap.

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 (Download) and a precisely scoped resource (full-text JATS from Springer Nature's OPEN ACCESS API). This clearly distinguishes it from the sibling download_elsevier_paper and from search/index tools.

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 a clear prerequisite (SPRINGER_NATURE_API_KEY with Open Access API enabled) and an explicit scope limit (subscription articles are not provided), which tells the agent when this tool will not work. It does not explicitly route to an alternative tool for subscription content, so it falls short of a 5.

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?

With no annotations, the description carries the full burden and does so: it warns summaries may be incomplete or inaccurate, notes the first call downloads model weights if uncached, that calls are serialized due to memory limits, that cached chunks resume after interruption, and that partial extraction is labeled. This is unusually rich operational context.

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 most decision-relevant fact (LEGACY/SLOW/OPTIONAL) and every subsequent sentence carries distinct information: cost, preference, resumption, and return value. No filler.

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?

No output schema exists, and the description covers the return value (summary_id for read_summary) as well as runtime cost and failure modes. An agent has everything needed to decide whether and how to call it.

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 0% for two parameters. The description clarifies the question parameter ('Use the original research question') but says nothing about paper_id semantics or format. It compensates for one of two parameters, so it lands at a minimum-viable 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+resource (read every body chunk, save a summary) and immediately distinguishes itself from siblings by naming the preferred alternative (index_papers + retrieve_evidence). The 'LEGACY, SLOW, OPTIONAL' prefix makes its role unambiguous without opening any 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?

Explicitly says to prefer index_papers + retrieve_evidence and that this tool is not part of the default RAG workflow, plus the concrete condition 'Use the original research question'. Both when-to-use and when-not-to-use are spelled out.

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?

With no annotations, the description carries the full burden and does well: it discloses that no Qwen/cloud LLM call occurs, that unchanged papers reuse their existing index (idempotent behavior), that the first run downloads an embedding model, and what is returned (chunk counts and timing). Missing only auth/permission or failure-mode details.

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?

Four short sentences, front-loaded with the action and scope, then the key behavioral facts. Every sentence adds distinct information with 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?

No output schema exists, but the description tells the agent what comes back (chunk counts and timing) and what preconditions apply (papers must be downloaded, first run downloads a model). Complete enough for a one-param indexing tool, though permission/error behavior is unstated.

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 0% for the single param, but the description compensates by stating the IDs must be for already-downloaded papers and that the batch size is bounded to 1–100. That is meaningful semantics the bare `paper_ids: array[string]` schema does not convey.

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 verb and resource (index paper IDs into local Qdrant) and pins the underlying stack (LlamaIndex + BGE embeddings), which is far more than a restatement of the name. It doesn't explicitly name a sibling to contrast with, so it stops 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?

"Preferred fast path" signals this is the default indexing route and implicitly contrasts with a slower alternative, but no alternative tool is named and no when-not condition is given. Usage is implied rather than spelled out.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It lists returned fields but omits whether the operation is read-only, whether it requires authentication, whether it paginates or orders results, and whether it has side effects.

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 exact fields returned. No wasted words, and the verb and resource come first.

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 listing tool with no output schema, the description does name the returned fields, which is useful. However, it remains vague on important terms like 'index readiness' and 'retrieval settings,' and offers no usage or behavioral context to compensate for the absence of annotations.

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 (100% schema coverage for an empty schema), so the baseline of 4 applies. The description does not need to add parameter semantics.

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 ('List') and a clear resource ('paper IDs, titles, DOI, index readiness, chunk counts, and retrieval settings'). It does not differentiate this tool from siblings like index_papers or search_papers, which limits it from 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?

The description only states what is returned. It gives no guidance on when to use this tool, no prerequisites, and no alternatives such as index_papers or search_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?

With no annotations, the description must carry the behavioral burden. It implies a read-only operation and discloses that neighboring chunks are returned and original wording is preserved. However, it omits indexing requirements, neighbor semantics, return format, and any permissions or rate limits.

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 wasted words. It is appropriately sized for a simple read tool and places the core action first.

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 three parameters, 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It lacks parameter definitions, usage routing, and behavioral details that an agent would need to call 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 schema provides only parameter names. The description loosely connects to the domain ('indexed source passage', 'neighboring chunks') but never defines paper_id, chunk_index, or what the neighbors parameter controls.

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 ('Read') and resource ('indexed source passage plus its neighboring chunks'), and adds a key property ('preserves original wording'). It does not explicitly differentiate itself from siblings like retrieve_evidence, but the core action is clear.

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 when-to-use guidance, no alternatives, and no conditions for selecting this tool over retrieve_evidence, search_papers, or read_summary are provided. Usage is only implied by the word 'indexed'.

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?

With no annotations, the description carries the full burden and does add real behavioral context: the content is untrusted paper-derived evidence, quotes are text-validated, and the main LLM must judge whether quotes support claims. This is meaningful trust/verification context beyond any structured field. It stops short of describing what the summary contains or how truncation interacts with max_chars.

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 core action, then pagination rule, then the trust warning. Every sentence earns its place; the only blemish is the 'next_offset' naming mismatch against the 'offset' parameter.

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 3-parameter tool with no annotations and no output schema, the description covers pagination termination and content trust but leaves max_chars undefined and does not say what a summary record contains or how partial reads behave. Adequate but with clear gaps.

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. It gives partial semantics for the pagination cursor ('next_offset until null', albeit named 'next_offset' while the parameter is 'offset') but says nothing about 'max_chars' or what 'summary_id' expects. Roughly one of three undocumented parameters is clarified.

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 saved per-paper summary.' That is clearly distinct from read_passage or retrieve_evidence, though the description never explicitly names those siblings to sharpen the boundary. An agent can identify the resource without opening the 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 operational guidance for sequential reading ('Continue at next_offset until null; do not skip pages'), which tells the agent how to iterate but not when to choose this tool over read_passage or retrieve_evidence. Usage is implied rather than contrasted with alternatives.

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?

With no annotations, the description carries the full behavioral burden. It discloses one important limitation ('Results are not complete paper summaries') and the odd framing that 'The main LLM writes the answer,' but says nothing about permissions, rate limits, result ordering, or what the citations look like in the response. Partial disclosure only.

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?

Four short lines, front-loaded with purpose then scoping then a usage hint then a limitation. No filler, though the 'The main LLM writes the answer' line is a slightly awkward aside that doesn't directly help invocation.

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?

No output schema, no annotations, and 3 parameters at 0% description coverage mean the description must do more. It covers purpose, scoping, and one limitation, but omits top_k behavior, result count expectations, and any failure modes, leaving real gaps for an agent invoking it blind.

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 does explain paper_ids semantics (scoping to chosen papers vs. current local index) and implies question is the search query and that multiple focused subqueries are expected, but top_k is left entirely unexplained with no default rationale. Partial compensation for a 0% coverage 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?

The opening sentence names a specific verb (retrieve), resource (original scientific passages), the retrieval mechanism (semantic + keyword search), and the return enrichment (DOI citations). This clearly distinguishes it from read_summary or read_passage, though it does not explicitly name the sibling it replaces the way a 5 would.

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 states scoping behavior for paper_ids ('omitted IDs search the current local index'), advises focused subqueries for multi-aspect questions, and routes the agent to read_passage for context. This is clear context-setting, but no explicit when-not-to-use conditions (e.g., vs search_papers) beyond that single routing hint.

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?

With no annotations, the description carries the full burden and does disclose real behavior: it does not invoke an LLM, it rejects unknown and duplicate DOIs, and a subset is acceptable. It omits persistence semantics (does a new ranking replace or append to prior rankings?) and any permission/auth requirements, leaving a gap for a mutation 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?

Short and front-loaded: the core action and its key constraint come first, with caveats following. Four compact sentences, though the trailing 'Unknown and duplicate DOIs are rejected' is somewhat bolted on rather than integrated.

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 2-parameter write tool with no output schema and no annotations, the description covers the essential call-time concerns: what to rank, what inputs are valid, and that it does not run an LLM. The main missing piece is run_id semantics and overwrite/append behavior.

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 adds ordering semantics for ranked_papers ('descending relevance order') and subset allowance, but run_id is never explained and the rejection rule for bad DOIs is the only validation detail given.

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 precise verb+resource ('Record the main LLM's chosen DOIs in descending relevance order') and immediately clarifies the boundary 'Does not run an LLM,' which separates it from the search/read siblings. An agent can identify exactly what artifact this tool persists without inspecting the 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?

It states the input basis ('Rank using titles and abstracts from search_papers') and the constraint 'do not imply you read full texts yet,' plus permission to select a subset. It never names an explicit alternative tool or a when-not-to-use case, but the procedural context is clear.

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?

With no annotations, the description carries the full burden and does well: it discloses the return shape (titles/abstracts), the post-processing contract (instructs the MAIN LLM to rerank), null-abstract handling, explicit counts/errors, and an important caveat that 100 unique papers is not guaranteed. It does not cover auth, rate limits, or API failure handling, which keeps it from 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?

The core behavior and default are front-loaded in the first two sentences, and each following sentence carries a distinct piece of information (param semantics, return handling, caveats) with no filler. Line breaks aid scanning rather than 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?

There is no output schema or annotations, so the description must cover both invocation and result semantics; it covers returns, reranking handoff, counts, errors, and a key guarantee caveat. What is missing is only secondary: failure behavior if one source errors and how to paginate beyond the candidate cap.

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 does: it distinguishes query ('a concise keyword search') from question ('the full research question') and explains per_source_limit's default and totals (100 candidates across both sources). This is meaningful semantic detail beyond the bare schema types, though formats/lengths are unstated.

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 and names both upstream sources ('Get up to 50 DOI-bearing candidates each from OpenAlex and Semantic Scholar'), which makes the retrieval behavior concrete. It does not explicitly contrast itself with siblings such as index_papers or retrieve_evidence, so an agent must infer the boundary, keeping it below 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?

It gives clear guidance on one parameter's usage ('Default to per_source_limit=50... Reduce only when the user explicitly requests a smaller search'), which is useful operational context. However, it never says when to choose this tool over the sibling search/retrieval tools, leaving the main routing question implied.

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