Oliver's mTOR Atlas

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds useful content-level disclosure (it returns version, snapshot date, counts, legend, citation info), but says nothing about format or size of the payload. Some added value, not rich.

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, and the most important content (version/snapshot) leads. It is a sentence fragment rather than a full statement, but every element 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?

For a no-param, read-only metadata tool with no output schema, the description covers what an agent needs to know it is the provenance/legend source. Only the return shape is unspecified, which is a minor gap given the enumerated contents.

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 to document; the baseline of 4 applies. No parameter confusion is possible.

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 enumerates exactly what the tool exposes — dataset version, snapshot date, counts, evidence-code legend, citation guidance — so an agent knows this is the dataset's metadata/about endpoint. It lacks an explicit verb, but the content list is specific enough to distinguish it from every sibling, which are all entity/study/relation query 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?

Usage is only implied: the mention of 'how to cite the dataset' and 'evidence-code legend' signals it is for provenance/interpretation rather than data retrieval, but there is no explicit when-to-use or when-not-to-use statement. Adequate minimum-viable guidance for a trivial no-arg 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 cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower. The description still adds genuine context: retrieval is direction-agnostic ("either direction") and the payload includes full study cards split into supporting and conflicting evidence, which is meaningful given there is no 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?

Two sentences, purpose front-loaded, no filler. There is mild overlap between the opening clause and the embedded example question, but the structure 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?

No output schema exists, so the description does some of the work by naming the returned supporting/conflicting cards, but it omits input identifier format and any cardinality/pagination behavior. For a two-parameter evidence lookup this is adequate but leaves gaps an agent would need to guess around.

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 two parameters a and b, so the description must carry the burden. It implies a and b are two entities whose order does not matter, but it never specifies the identifier format (name vs. CURIE vs. internal ID) or what distinguishes the two slots, leaving a real 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 and resource: it returns direct curated relations between two entities, plus their supporting/conflicting studies. It does not distinguish itself from the sibling tools find_relations or get_relation, which look closely related, so an agent cannot fully disambiguate among them from the text alone.

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 through the example question "what is the evidence that A acts on B?", which conveys the flavor of a query but names no alternative or exclusion. Nothing tells the agent when to prefer this over find_relations or find_contradictions.

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=false, so safety and repeatability are covered. The description adds useful return semantics ('with both sides of the evidence'), but says nothing about result ordering, truncation, or how the default/maximum limit affects output.

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 carries purpose, scope, and return content without padding. It is efficient, though slightly dense and could separate the optional-filter clause for readability.

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 no output schema, the description carries return-value burden and does describe the payload (contested relations plus both sides of evidence). Combined with annotations covering the safety profile, an agent has enough to call it correctly; only limit/pagination behavior is left 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 description coverage is 0%, so the schema gives types and bounds only. The description explains the 'entity' filter but adds nothing about 'limit' (why 20 is the default, what happens past 50), leaving half the parameters semantically thin.

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 resource ('relations the Atlas marks as contested or that carry conflicting studies') plus what accompanies it ('both sides of the evidence'), which is far more than a restatement of the name. It implicitly distinguishes itself from the generic sibling find_relations, but never names that sibling to make the distinction explicit.

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?

'Optionally limited to one entity' indicates one usage mode, so an agent can infer scoping behavior. However, there is no explicit guidance on when to reach for this versus find_relations or evidence_between, and no stated preconditions.

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 (readOnlyHint=true, idempotentHint=true, openWorldHint=false), so the lower bar applies. The description adds meaningful domain context beyond that: relations are 'signed' and 'evidence-linked', and contested status is a first-class concept. It omits pagination/return-size behavior, but the offset parameter's schema description partly covers that.

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, no filler: the first defines the resource with an illustrative example, the second enumerates the filtering surface. Front-loaded and information-dense.

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 an eight-parameter, read-only search tool with no output schema, the description conveys what a result represents and the full filter surface. The absence of output-shape detail is acceptable given no output schema is declared, though the 'contested' and strength-code concepts could be elaborated slightly more.

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?

With schema description coverage at only 50%, the description must compensate, and it does: it explains the semantics of entity (either end), source, target, effect, contested status, and minimum strength of best supporting evidence, mapping to six of the eight parameters. It does not clarify the effect enum values or the strength-code ordering, but the schema carries those.

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 resource ('signed, evidence-linked pathway relations') with a concrete example claim ('Rheb activates mTORC1'), making the returned data type unambiguous. It distinguishes itself functionally from siblings like get_relation and evidence_between via the multi-filter framing, but never names an alternative explicitly, which is the only gap.

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 list of filterable dimensions ('entity on either end, by source/target, effect, contested status or minimum strength') implies how to query but gives no when-to-use guidance, no prerequisites, and no routing to sibling tools like get_relation or find_contradictions. Usage is inferable rather than stated.

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 readOnly, idempotent, and closed-world, so the safety profile is covered. The description earns credit by disclosing the return shape (studies as short cards, pathway relations as one-line claims) and the truncation behavior tied to studies_limit, which no annotation or schema conveys. It does not say what happens when the entity is not found.

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 dense sentence that front-loads the payload (entity plus studies plus pathway relations) before the input note. Nothing is wasted, though the parenthetical type list makes it slightly packed.

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 no output schema, the description carries the return-value burden and does so adequately, and annotations handle the safety profile. Remaining gaps (not-found behavior, whether pathway relations carry direction) are minor for a single-record lookup tool.

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?

At 50% schema coverage, the description compensates: it explains that the entity argument accepts an id, a name, or a synonym (beyond the schema's bare examples), and that studies_limit caps the number of study cards returned as 'first studies_limit'. The schema's default/min/max for studies_limit are not restated, but the semantic intent is clear.

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 concrete resource (one entity) and enumerates exactly what comes back: linked studies as short cards and every pathway relation as a one-line claim. The singular framing implicitly contrasts with the search_entities sibling, but no sibling is named, 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?

Usage is only implied by the singular/plural contrast with search_entities; there is no explicit statement of when to pick this over search_entities, find_relations, or evidence_between. The closing sentence about accepted identifier forms is input guidance, not usage guidance.

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 a closed-world scope, so the safety profile is covered. The description adds the ID format hint ('H1', 'F2') which is genuinely useful context, but says nothing about failure behavior for unknown IDs.

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 dense sentence, front-loaded with resource and identification, then the returned payload contents. 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 read tool with annotations and no output schema, the description covers what the returned object contains (gap, change, open status, testability, linked studies) and the ID format. Missing only failure/not-found behavior and the ID scheme's boundaries.

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% and there is one required string parameter with no schema documentation. The description partially compensates by giving example ID values ('H1', 'F2'), which is the most useful thing it could say here, but does not describe the ID scheme or valid ranges.

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 (get) and resource (question), and even disambiguates it as 'open or frontier' — meaningful given the sibling list_questions. It does not name the alternative (list_questions) explicitly, 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?

Usage is implied: the tool takes an ID (e.g. 'H1', 'F2') and fetches one question, while the sibling list_questions presumably enumerates them. But the description never states when to use this vs list_questions or search, leaving the agent to infer.

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=false, so the safety profile is covered. The description adds genuine value by disclosing the returned content categories (mechanism, boundary conditions, confidence, supporting and conflicting studies), which is important with no output schema — only missing behavior on missing/ambiguous IDs.

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 compact sentence that front-loads the operation, then the example, then the payload. 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?

With no output schema and 0% parameter coverage, the description does the necessary work by naming the returned fields and exemplifying the ID format. It would be complete if it also addressed not-found 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 coverage is 0% and the lone 'id' property has no description, so the description must compensate — and it does by giving a concrete example identifier ('RHEB-MTORC1') that reveals the expected format. It stops short of stating whether the ID is case-sensitive or what a valid ID pool looks like.

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 ('One pathway relation by ID') and enumerates the payload (mechanism, boundary conditions, confidence, supporting/conflicting studies). It is clearly the single-item fetch counterpart to the search-style siblings, though it never names find_relations or get_entity explicitly.

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 phrase 'by ID' implies you need a known identifier, which implicitly routes discovery to find_relations/search_entities, but the description never states when to use this over those alternatives or what happens with an unknown ID.

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=false, so the safety profile is covered by structured data. The description adds genuine value by disclosing what the record contains (abstract excerpt, extracted findings, linked entities, supported/contradicted relations, open questions), which is exactly the kind of return-shape context an agent needs when there is no 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?

A single front-loaded sentence that leads with the resource and key, then enumerates contents. Every clause earns its place given the absence of an output schema.

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 one fully documented parameter, rich annotations and no output schema, the description does the heavy lifting by listing the returned fields. It could go slightly further on error behavior for an unknown ID or on record size, but it is essentially complete for a simple read.

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% and the single parameter is fully documented in the schema itself, so the baseline is 3. The description's example ID ('SAB1994') merely echoes the schema's own example and adds no new syntax or format guidance.

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 (get) and resource (one study) plus the lookup key (Atlas ID), and enumerates the record's contents. An agent can immediately distinguish this single-record fetch from search_studies.

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 implied by 'by Atlas ID' — an agent knows to call this when it already has a study identifier and wants the full record rather than a search result. However, it never explicitly contrasts with search_studies or states prerequisites (e.g. that the 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=false, so the safety profile is covered. The description adds domain context about what the listed items are, but says nothing about result volume, ordering, or pagination behavior for what may be a long list.

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 tight sentence-fragment that front-loads the resource and parenthetically explains the key term. No waste, though the missing verb makes it slightly less self-contained than it could be.

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-required-parameter, read-only list tool with no output schema and full annotation coverage, the description adequately conveys what is returned. Only the filter semantics and result scale are left implicit, which is a minor gap at this complexity.

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 single parameter is an enum, so the description is the only place explaining meaning. It names the two categories ('open questions' and 'frontier questions'), which loosely maps to the enum values, but never explicitly ties the kind parameter to those values or states that omitting it returns both.

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?

Names the concrete resource (the Atlas's open questions and frontier questions) and adds a useful gloss defining open questions as 'evidence gaps with testable hypotheses'. The listing intent is clear from the title and plural resource, though the description itself never states the verb 'list' nor explicitly distinguishes itself from sibling get_question.

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 mention of the alternative get_question for a single question, and no conditions under which the kind filter should be applied. The agent must infer usage entirely from the name.

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 readOnly, idempotent, and closed-world behavior, so safety is covered. The description adds the meaningful behavioral detail that matching is by name or synonym, but says nothing about ranking, fuzzy matching, or what happens with partial/ambiguous names.

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 sentence that front-loads the verb and scope with zero filler. Nothing could be removed without losing information.

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 no output schema, the description should explain what a result looks like (entity ids? scores? types?) but omits return shape entirely, and also omits pagination/limit behavior. For a search tool usable as an entry point, that is a real gap.

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 only 67% — 'limit' has no schema description at all and 'type' is only exemplified, not enumerated. The description adds no parameter meaning (no valid type values, no limit semantics, no query-matching rules), so it fails to compensate for the 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 (Find) plus the resource types it searches (genes/proteins, complexes, drugs, diseases, processes, nutrients, outcomes) and the matching basis (name or synonym). This clearly separates it from siblings like get_entity (id lookup) and search_studies (different corpus), though it never names an alternative explicitly.

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 mention of prerequisites, and no routing to alternatives such as get_entity once an entity is known. Usage is only implied by 'Find ... by name or synonym'.

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=false, so safety is covered. The description adds return-shape context that annotations cannot — summary records with evidence codes and URLs — which is meaningful because no output schema exists. It omits pagination behavior, but offset is documented in the 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?

Two dense sentences with no filler. The search scope comes first, filters second, return shape last — a correctly front-loaded order for a search 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?

For a 7-parameter read-only search with no output schema, the description covers the searchable fields, the optional filter dimensions, and the shape of results. It could say more about how results are ranked or what happens when no filters or query are given, but nothing essential to invoking it correctly 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?

With 57% schema description coverage, the description compensates by naming the keyword scope (title, finding, authors, journal, model system) and the entity filter targets (gene, drug, disease), which the terse schema entry for query does not. It does not clarify limit or year range handling, but those are self-evident or schema-described.

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) plus resource (curated studies) and enumerates the searchable facets (title, finding, authors, journal, model system) along with optional filters. It is clearly distinguishable from get_study (single-record retrieval) and search_entities, though it never names a sibling to sharpen the boundary.

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 'optionally filtered by' phrasing implies how to narrow a search, and the schema notes that query can be omitted to list by filters only. However there is no explicit guidance on when to prefer this tool over search_entities, find_relations, or get_study, so the agent must infer routing.

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