opentargets-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.0
Disambiguation4/5
Tools are systematically organized by entity type (disease, drug, target, variant, study) and data category, which makes most purposes clear. However, some inverse relationships like get_disease_known_drugs vs get_drug_linked_diseases and get_disease_associated_targets vs get_target_associated_diseases could initially confuse an agent, though descriptions clarify them.
Naming Consistency5/5
All tool names use snake_case with a consistent verb_noun pattern (get_*, search_*, map_*, graphql_*). Entity prefixes are uniform, making it predictable to infer a tool's function from its name even without reading the description.
Tool Count2/5
With 68 tools, the set far exceeds the 25+ threshold, making navigation and selection challenging for an agent. While the Open Targets domain is broad, this many tools likely bundles what could be a smaller set of higher-level operations or requires aggressive grouping.
Completeness5/5
The toolset covers the full spectrum of Open Targets data access: entity metadata, associations, evidence, literature, phenotypes, expression, safety, and advanced GraphQL. Search and batch utilities address bulk needs, and no major query need appears missing, making the surface extremely thorough.
Average 3.3/5 across 68 of 68 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so no need for that disclosure. However, the description adds little beyond the generic 'flexible filtering options'. It does not disclose behavior such as pagination, how filters combine, or what kind of results are returned. Given the low bar set by annotations, the description still fails to add substantive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is under-specified. A one-sentence overview that omits essential details is not concise in a useful sense; it is merely brief. The structure does not convey enough information to guide invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has 8 optional parameters and multiple sibling tools with overlapping purposes. The description gives no context on how to use the filtering parameters, what 'fields' means, or how pagination works. This is far from complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 by explaining parameter meanings. It does not mention any of the eight parameters (fields, regions, page_size, study_ids, etc.) or how they interact. The phrase 'flexible filtering options' is a placeholder that adds no specific meaning beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Query' and names the resource 'credible sets', which is clear enough, but it does not specify the scope (e.g., all credible sets or filtered across studies/variants) nor does it differentiate from siblings like get_study_credible_sets or get_variant_credible_sets. The phrase 'flexible filtering options' is vague and doesn't clarify what kind of filtering is supported.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its alternatives. Sibling tools such as get_credible_set_by_id, get_study_credible_sets, and get_variant_credible_sets suggest distinct use cases, but the description does not mention any of them or provide exclusion criteria. This leaves the agent without clues for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation, and the description's 'Retrieve' is consistent. However, the description adds no additional behavioral context such as pagination behavior, output format, or any constraints beyond the annotation. Since the description does not enrich the annotation, it falls short of the lower bar set for annotated tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is efficient and avoids fluff. However, it is almost too sparse, providing the bare minimum information. It is not a tautology and states a clear action, but it sacrifices detail for brevity, earning a mid-range score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description is still very incomplete. It does not explain what constitutes an 'adverse event signal,' how to properly supply chembl_id, or the meaning of pagination parameters. For a tool with a specific scientific domain, this level of context is insufficient for an agent to use it correctly, especially given the 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters (e.g., chembl_id, page_size, page_index). The description does not compensate for the schema's lack of docs, leaving the agent to infer parameter meanings from names alone. This is a significant gap for a tool with three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and identifies the resource as 'adverse event signals associated with a drug,' which clearly distinguishes it from many sibling tools like get_drug_info or get_drug_literature_occurrences. However, it could be more explicit in differentiating from get_drug_pharmacovigilance, which might have overlapping semantics, so it doesn't fully achieve a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its siblings, such as get_drug_pharmacovigilance or get_drug_warnings. The description merely states the function without providing context, alternatives, or exclusions, leaving the agent without decision-support information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the readOnlyHint annotation. It doesn't mention parameters like enable_indirect or pagination behavior, which could significantly affect results. The annotation already covers read-only nature, and the description adds no further behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than genuine conciseness. It lacks essential details about parameters and behavior, making it too sparse to be helpful for an agent deciding on tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and a readOnlyHint, the description is far from complete. It fails to explain key behaviors such as indirect matching, pagination, or field selection. The absence of any parameter semantics or usage guidance makes the description insufficient for effective tool selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate, but it only hints at disease_ids via 'linked to one or more diseases.' Other parameters (fields, page_size, enable_indirect) are left unexplained, leaving the agent to infer their meaning from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List studies linked to one or more diseases.' It specifies a verb (list) and a resource (studies) with a scope (by disease). While it doesn't explicitly compare to sibling tools like get_study_info, the unique combination of studies and diseases makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It merely states what it does without any context about suitable scenarios, prerequisites, or exclusions. The usage is only implied by the tool's name and basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already states the operation is read-only, and the description adds no extra behavioral details such as pagination (cursor, size), date filtering, or handling of additional_entity_ids. It merely restates the tool's primary function without enriching the agent's understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, but it is too sparse to be considered well-structured for a tool with this complexity. It front-loads the action but fails to elaborate, resulting in under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, a required EFO ID, and no parameter documentation, the description is grossly inadequate for an agent to invoke the tool correctly. Even though an output schema exists, the input side is completely unexplained, making successful invocation largely guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for the 8 parameters. The only potential link is that 'disease' implies efo_id, but it does not explicitly define EFO IDs nor mention the other parameters (size, cursor, months, years, additional_entity_ids), leaving the agent without necessary invocation details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('literature co-occurrence records'), with the scope 'mentioning a disease' clearly distinguishing it from sibling tools like get_drug_literature_occurrences and get_target_literature_occurrences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, use cases, or explicitly exclude other tools; the only differentiation comes from the tool name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals safety, and the description adds no additional behavioral traits. It does not mention pagination, filtering, or defaults for parameters like cursor, size, or year filters. The description contributes little beyond what the annotation already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is front-loaded with the main verb and resource. It contains no redundant words and provides maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and readOnly annotation, the tool has eight parameters including pagination and filtering. The description does not explain the purpose of these parameters or the nature of co-occurrence records. This is insufficient for a tool of this complexity, as the agent must rely entirely on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the eight parameters. The only subtle hint is that chembl_id refers to a drug identifier, but no clarification is given for cursor, size, additional_entity_ids, or date filters. The description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Return' and clearly identifies the resource as 'literature co-occurrence records' and the entity as 'a drug'. This distinguishes it from sibling tools like get_disease_literature_occurrences and get_target_literature_occurrences, but it is terse and does not elaborate on what co-occurrence means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or recommend sibling tools for other entity types. While the purpose is clear, the lack of any contextual usage cues means the agent is left without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates safe read-only operation. The description adds no extra behavioral context, such as pagination behavior or the meaning of 'known activity,' so it provides minimal value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and an output schema, the description is too sparse. It lacks parameter explanations, usage context, and pagination notes. While the output schema covers return values, the lack of param semantics and usage guidelines leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (ensembl_id, fields, page_size, page_index). It does not indicate that ensembl_id identifies the target or how pagination works, leaving the agent without essential information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns compounds with known activity on a target, using a specific verb and resource. It distinguishes from sibling get_disease_known_drugs by focusing on a target rather than a disease, though it does not explicitly mention the target is identified by ensembl_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention related tools like get_target_chemical_probes or get_disease_known_drugs, nor does it specify scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds little behavioral context. It does not mention error handling, batch size limits, input format requirements beyond the schema, or any other operational nuance. For a batch endpoint, critical details like whether invalid IDs are ignored or cause the entire request to fail are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose. It contains no filler words or redundant information, and its brevity aligns with the simplicity of the tool. It earns every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the output schema is present, the return format is defined elsewhere, but the description fails to provide essential usage context such as why batching is beneficial, how this relates to get_disease_info, or any constraints on the input array. A batch tool should at least hint at the intended use case to avoid misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the burden of explaining the parameter, but it only says 'diseases' without explicitly mapping efo_ids to disease identifiers. The parameter name already conveys that it expects EFO IDs, so the description adds minimal semantic value beyond the schema field itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves multiple diseases in a single request, which clearly identifies the action (retrieve) and resource (diseases) with a batch modifier. It distinguishes itself from single-disease tools like get_disease_info through the explicit mention of 'multiple' and 'single request,' though it does not name any sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It implies use for multiple diseases via 'in a single request,' but does not state when not to use it, nor does it suggest the single-disease counterpart get_disease_info for individual queries. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include readOnlyHint=true, which already establishes that this is a safe read operation. The description adds no further behavioral context, such as result format, sorting, pagination, or scope of suggestions. It essentially restates the tool's name, providing minimal value beyond the structured annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core purpose. It is appropriately sized for a simple tool and contains no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the tool has three parameters with no descriptions in the schema or the tool description. The sparse description does not adequately support correct invocation, particularly for the optional parameters entity_names and max_suggestions. The tool is simple, so the minimal guidance falls short.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description does not explain any parameters. 'Partially typed queries' only implicitly references query_prefix, leaving entity_names and max_suggestions without any semantic guidance. The description fails to compensate for the absence of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return autocomplete suggestions for partially typed queries.' This specifies the verb (return) and resource (autocomplete suggestions), distinguishing it from the many data-lookup siblings. However, it does not explicitly contrast it with search_entities, so it is clear but not maximally differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like search_entities or search_facets. The only usage hint is 'partially typed queries,' which implies an autocomplete scenario, but there are no explicit context, exclusions, or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe read-only nature is established. The description adds little beyond that, not explaining what 'core identity details' includes, any required identifier format, or potential errors. No contradictory behavior is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no extraneous information. It is front-loaded with the action and object, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists to document return values, the description fails to provide sufficient guidance for using this tool among numerous similarly named siblings. The lack of parameter semantics and usage guidelines means the agent may not know how to configure fields or when to select this tool over get_target_class or get_target_hallmarks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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, but it does not mention the ensembl_id or fields parameters at all. There is no indication that fields selects which identity details to return or what valid values exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' with a clear resource 'core identity details for a target gene', which distinguishes it from sibling tools like get_target_associated_diseases or get_target_class that focus on specific aspects. It clearly states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context about when to prefer this tool over alternatives such as get_target_class or get_target_associated_diseases. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation, describing a non-mutating 'Return' operation. However, it adds no behavioral context beyond the annotation, such as pagination behavior, filtering semantics, or what 'co-occurrence records' include.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler or redundancy. While concise, the brevity borders on under-specification for such a parameter-rich tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no parameter semantics in the description, and only readOnly annotation plus an output schema, the single sentence does not cover key usage details like pagination via size/cursor, date-range filters, or additional entity IDs. The output schema mitigates return-value ambiguity, but the description leaves too much to the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 8 parameters with 0% description coverage, and the description fails to mention any of them (ensembl_id, size, cursor, start/end year/month, additional_entity_ids). The only vague reference is 'a target', which does not explain that ensembl_id is required or how pagination or filtering works.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and names the resource 'literature co-occurrence records for a target', clearly identifying a query operation scoped to a target. It distinguishes from sibling tools like get_disease_literature_occurrences and get_drug_literature_occurrences, though it is terse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a target' implies this is the target-specific literature occurrence lookup, but it provides no explicit guidance on when to choose it over the disease or drug variants, nor any exclusions or alternatives. The usage is only implied, not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so the safety profile is known, but the description adds no behavioral context beyond the basic retrieve action. It does not mention pagination behavior, return format, or any constraints. The description is consistent with the annotation, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no redundant words. It is appropriately sized for a simple retrieval operation and meets the standard for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and annotations, the description is too terse to orient the agent. It lacks any details about the nature of the pharmacogenomic annotations, pagination defaults, or how this tool fits among the many variant-related siblings. The overall context is incomplete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no explanations for variant_id, page_size, or page_index. The description mentions 'variant' but does not clarify parameter roles or syntax, leaving the agent without necessary semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve pharmacogenomic annotations for a variant' uses a specific verb and resource, clearly distinguishing this tool from siblings like get_variant_info or get_drug_pharmacogenomics. It precisely states the action and the subject matter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_variant_evidences or get_drug_pharmacogenomics. There are no explicit exclusions, prerequisites, or contextual hints about appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds the behavioral detail that results include association scores, which is useful. However, it does not disclose pagination behavior, field selection effects, or other operational traits. Given the annotation covers safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the main verb and clearly states the core action and result. This is appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema and readOnly annotation exist, the description lacks usage guidelines and parameter semantics. With four parameters and many sibling tools, the description is too minimal to allow an agent to select and invoke the tool correctly in all circumstances. It does not cover pagination, field selection, or how it differs from similar target-disease endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for the four parameters. It does not explain ensembl_id, fields, page_size, or page_index, nor does it map them to the concept of 'target'. The parameter names are somewhat self-explanatory, but the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and names the resource 'diseases linked to a target', plus mentions 'association scores'. This clearly communicates the primary function. However, it does not explicitly distinguish from sibling tools like get_target_disease_evidence or get_disease_associated_targets, so it falls 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or compare with sibling tools such as get_target_disease_evidence or get_disease_associated_targets. There is no 'when to use' statement, so it offers no directional help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which is consistent with 'Inspect' and covers the safety profile. The description adds no further behavioral details (e.g., pagination behavior, empty results, or data source nuances), but the output schema provides return structure. Given annotation coverage, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It is front-loaded with the action and resource, making it highly concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no parameter descriptions, the description is too sparse. It does not explain what counts as 'evidence,' how pagination works, or what fields can be requested. The output schema exists but the description still lacks essential usage context for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for explaining parameters. It only implicitly references target and disease via the phrase 'target and disease,' but provides no details on size, cursor, or fields. The description adds minimal value beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Inspect evidence for biomarker annotations') and a clear resource ('linking a target and disease'). It adequately differentiates from sibling tools like get_target_disease_evidence by focusing on biomarker annotations, though it could be even more explicit about the unique output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies use when interested in biomarker annotations for a target-disease pair, but does not mention exclusions or competing tools such as get_target_disease_evidence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, so the description does not need to repeat that. However, the description adds little behavioral context beyond the resource, such as how pagination or filtering works, though annotations cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is appropriately concise and front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, 0% schema coverage, and no parameter explanations in the description, the description is inadequate for an agent to correctly invoke the tool. It fails to explain key concepts such as datasource_ids or cursor behavior, making it incomplete for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for missing parameter details. It only implicitly maps 'target' and 'disease' to ensembl_id and efo_id, while leaving the optional parameters (size, cursor, fields, datasource_ids) unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and the resource ('evidence strings linking a target to a disease'). It is specific enough to distinguish from most sibling tools, though it does not explicitly differentiate from similar evidence-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or preferred scenarios, leaving the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation, which already indicates a safe read operation. However, no additional behavioral details are disclosed (e.g., response shape, error conditions, or pagination). The presence of an output schema somewhat mitigates the need for return details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. There is no repetition, empty filler, or unnecessary detail—appropriate for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, output schema present, readOnlyHint), the description is minimally viable but lacks usage guidelines and deeper parameter semantics. It is sufficient for a straightforward fetch, but not as rich as it could be for disambiguation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for study_locus_id, and the description only says 'specific study locus credible set,' which adds minimal meaning beyond the parameter name itself. It does not explain the ID format, what constitutes a 'study locus credible set,' or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the specific resource ('detailed information for a specific study locus credible set'). It distinguishes from siblings like get_credible_sets or get_credible_set_colocalisation by implying a single, ID-based lookup, though it does not explicitly mention the ID parameter or contrast with list endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not state prerequisites (e.g., needing a study_locus_id) or mention other related credible-set endpoints, leaving the agent to infer usage from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that it returns cross-database identifiers, which gives some context about the output type. However, it does not disclose details like whether the identifiers come from specific databases, pagination, or error conditions, so it stays at a baseline 3 with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that gets straight to the point. Every word is informative, and there is no wasted text. This is an ideal length for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, a readOnly annotation, and an output schema present, the description is minimally sufficient. However, in a context with many sibling drug-related tools, it would benefit from adding what types of cross-references are included (e.g., PubChem IDs, InChI) to help an agent choose correctly. The current description is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It fails to explicitly mention that the input parameter `chembl_id` is a drug identifier, though it is implied by 'related to a drug.' The parameter name itself is self-explanatory, but the description adds little meaning beyond the schema and does not clarify format or expected values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'retrieve' and a clear resource 'cross-database identifiers related to a drug.' This distinguishes it from sibling tools like get_drug_info by focusing on cross-database identifiers rather than general information. However, it does not explicitly differentiate from other identifier-related tools, so it is not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of specific situations, prerequisites, or exclusions. Users must infer from the tool name and description, which is not explicit enough for an agent to decide without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description aligns with that. The description adds that the data links genetic variants to drug response, but it does not disclose pagination behavior or response structure. Since an output schema exists, the lack of explicit return details is somewhat mitigated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the primary action and resource, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with an output schema and readOnly annotation, the description is minimal but covers the core purpose. However, it lacks usage guidance and parameter semantics, and does not clarify the difference from the variant-focused sibling tool. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It does not explain that chembl_id is likely a drug identifier, nor does it clarify the semantics of page_size and page_index. The tool name implies drug context, but the description itself is silent on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and the resource ('pharmacogenomics data linking genetic variants to drug response'). It is specific enough to distinguish from similar sibling tools like get_drug_info, though it does not explicitly name alternatives like get_variant_pharmacogenomics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_variant_pharmacogenomics or get_drug_info. The description does not mention preferred contexts, exclusions, or relationships to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, lowering the bar for additional disclosure. The description adds that similarity is based on PubMed embeddings, providing some behavioral context, but does not mention result limits, threshold interpretation, or how the embeddings are used beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single sentence, highly concise and front-loaded. Every word is meaningful and directly communicates the core function without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, a required chembl_id, and an output schema, the description is far too brief. It lacks any explanation of how parameters like size or threshold affect results, what entity_names means, or what the output represents beyond the schema's structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the five parameters. The agent must infer the meaning of chembl_id, size, threshold, entity_names, and additional_entity_ids solely from their names and schema defaults, which is inadequate for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Find' and resource 'semantically similar drugs', with a clear method 'PubMed embeddings'. It distinguishes this tool from sibling tools like get_disease_similar_entities or get_similar_targets by explicitly focusing on drugs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other drug-related tools such as get_drug_info or get_drug_adverse_events. It does not mention alternatives, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true indicates a safe read operation, and the description's 'Retrieve' is consistent with this. However, the description adds no additional behavioral context beyond the annotation, such as pagination behavior, data coverage limits, or how results are ordered. It does not contradict the annotation but also does not enrich the agent's understanding of side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or repetition. It is front-loaded with the action and resource, making it easy to parse. Every word contributes to the core meaning, and nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description is incomplete for a tool with three parameters and zero schema descriptions. It lacks usage guidance and parameter semantics, which are essential for an agent to select and invoke the tool correctly. For a simple lookup, it might be acceptable, but within the rich sibling tool landscape and given the missing parameter details, it falls short of being contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 parameters with 0% description coverage, and the tool description fails to compensate. It mentions 'target' but does not explicitly map this to the required ensembl_id parameter, nor does it explain page_size or page_index. This leaves the agent without any guidance on parameter formatting, the meaning of 'target', or pagination semantics, making correct invocation difficult.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' and identifies the distinct resource 'mouse knockout phenotypes' associated with a target. This clearly differentiates it from sibling tools like get_target_associated_diseases or get_target_hallmarks, which cover different data types. It is not a tautology and directly states the function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool relative to the many sibling tools. It only states what it retrieves, without mentioning alternatives, exclusions, or ideal contexts. There is no indication of when a user would prefer this over related target-related data queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, which already communicates the safety profile. The description adds 'single request' as a behavioral detail, but doesn't disclose other aspects like response size, batching limits, or error behavior. Since annotations cover the main safety concern, this is adequate but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It earns its place by stating the core action and scope, making it as concise as possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter tool with an output schema and read-only annotation, so the description doesn't need to explain return values. However, it lacks guidance on batch limits, when to use it over alternatives, and what constitutes a 'target'. The description is minimally sufficient but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for parameter meaning. It doesn't mention ensembl_ids at all, leaving the agent to infer from the schema property name. The description's 'targets' is less specific than 'Ensembl IDs', failing to clarify what identifiers are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve multiple targets in a single request' with a specific verb and resource. It distinguishes itself from single-target tools like get_target_info by emphasizing 'multiple' and 'single request', though it doesn't name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies batch usage but provides no explicit guidance on when to use this tool versus alternatives. It doesn't mention when not to use it or name a sibling like get_target_info, so the agent receives no clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation indicates the operation is safe, but the description adds no extra behavioral context beyond that. It does not disclose pagination behavior, the structure of results, or any filtering semantics; it merely restates the tool's name in sentence form.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It efficiently conveys the core purpose, making excellent use of word count.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only nature, readOnlyHint, and presence of an output schema, the description is minimally viable. However, it lacks usage context and parameter elaboration, making it incomplete enough to be merely average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fails to compensate. It mentions 'credible set' but never clarifies that study_locus_id is the identifier, nor does it explain page_size and page_index, though these are relatively self-explanatory from their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Retrieve colocalisation results for a credible set.' This is a specific verb+resource pair that distinguishes it from sibling tools like get_credible_set_by_id, which retrieves credible sets themselves, and other tools for diseases, drugs, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, edge cases, or relationship to sibling tools such as get_credible_set_by_id or get_credible_sets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares a safe read operation, and the description's 'Summarise' is consistent. The description adds the 'high-level' qualifier, implying a summary rather than granular data, but does not disclose what specific pharmacovigilance data is included or how results are structured. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It immediately states the action and object, making it highly concise and well-structured for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with an output schema, the description covers the essential purpose adequately. It clearly indicates what the tool does, and the output schema handles return details. However, the lack of parameter explanation and the vague 'pharmacovigilance data' could be slightly more explicit, though not critical for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for chembl_id, and the description does not mention or explain the parameter. While chembl_id's meaning may be inferable from the tool name, the description provides no value beyond the schema, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Summarise' and a specific resource 'pharmacovigilance data for a drug', clarifying the tool's scope. The term 'high-level' helps distinguish it from detailed event tools like get_drug_adverse_events, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling tools such as get_drug_adverse_events or get_drug_pharmacogenomics. There is no mention of context, exclusions, or alternatives, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful context about the content (regulatory warnings, withdrawals, boxed labels) but does not disclose any additional behavioral traits such as error handling, availability, or rate limits. With annotations lowering the bar, this is adequate but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core function without any filler. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter, read-only, has output schema), and the description captures its purpose. However, it lacks parameter semantics and usage guidance, which are important for an agent to correctly invoke it. The output schema and annotation cover some gaps, but the missing param explanation leaves it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single required parameter (chembl_id) with no description, and the tool description omits any explanation of what this identifier is or how it should be formatted. With 0% schema description coverage, this is a significant gap that the description fails to fill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and clearly identifies the resource ('detailed regulatory warnings') with illustrative examples ('withdrawals and boxed labels'). This distinguishes it from sibling tools like get_drug_adverse_events or get_drug_pharmacovigilance, which cover related but distinct safety data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over similar drug-related tools. It does not mention alternatives, exclusions, or scenarios, leaving the agent to infer its use case from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation declares the safe read operation, but the description adds no additional behavioral context beyond its purpose. It does not mention pagination parameters, field selection, or any quirks. The description simply restates the tool's purpose without enriching the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the core function. There is no redundancy or filler, and it is front-loaded with the key action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, and the annotation covers read-only safety. However, the description lacks usage differentiation and parameter semantics. Given the large sibling set, the tool is not fully contextualized, though the basic purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 0%, and the description does not compensate. It only implies the study_id parameter via 'for a study', but provides no meaning for 'fields', 'page_size', or 'page_index'. The parameter names are self-descriptive, but the description adds no explicit guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Retrieve') and resource ('credible sets') scoped to a study. It distinguishes from siblings like get_variant_credible_sets (variant-scoped) and get_credible_sets (generic list) by explicitly mentioning 'for a study'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With several sibling tools for credible sets (e.g., get_credible_sets, get_variant_credible_sets), the absence of any use-case differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, but the description adds no behavioral context beyond that. It doesn't mention anything about the return format, potential limitations (e.g., species restrictions), or other traits that would help the agent anticipate behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the verb and resource. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, and the read-only annotation covers safety. However, the description lacks usage guidance and parameter semantics, making it only minimally complete. It adequately states the core action but leaves out important context an agent would need for smooth invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 only says 'for a target gene', which weakly implies ensembl_id is a gene identifier, but doesn't specify the format (e.g., Ensembl gene ID pattern) or any expected type details beyond the schema's 'string'. This is minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and clearly defines the resource as 'cross-species homologues for a target gene'. This uniquely distinguishes it from sibling tools such as get_target_interactions or get_similar_targets, none of which mention homologues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, exclusions, or context. It only states what the tool does, not when or why to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation. The description adds minimal behavioral context beyond the basic function, such as the fact that it covers 'modalities', but does not disclose edge cases, error behavior, or what the output contains (though an output schema exists). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the tool's purpose without any filler. It is clear and front-loaded, and every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with one parameter and an existing output schema, the description is sufficiently complete for an agent to select and invoke the tool. It conveys the core function, and the output schema covers return values. However, it lacks contextual hints about how tractability relates to other target assessments, which is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter (ensembl_id) with 0% description coverage. The description only refers to 'a target' which implies the parameter is a target identifier, but does not explain that it must be an Ensembl ID, the expected format, or any constraints. The description adds minimal value over the parameter name itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: returning tractability assessments for a target, specifying the domain (tractability) and the entity type (target). It distinguishes itself from sibling tools like get_target_info or get_target_prioritization by focusing on tractability, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other target-related tools. It does not mention prerequisites, such as requiring an Ensembl ID, or scenarios where this tool would be preferred over get_target_safety_information or get_target_prioritization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: true already communicates safety, and the description's 'Retrieve' adds no further behavioral detail. It omits information about pagination, potential empty results, or any processing quirks beyond what the annotation already signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and avoids any unnecessary wording. It is concise while still conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and the annotation covers the read-only nature, the description lacks parameter semantics and usage context for a 3-parameter tool. It is minimally viable for a simple retrieval, but significant gaps remain in how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the three parameters. With 0% schema coverage, it fails entirely to clarify the meaning of variant_id (beyond the name) or the pagination parameters page_size and page_index, leaving the agent without useful parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and a distinct resource ('protein-level consequences for a variant'), clearly differentiating it from sibling tools like get_variant_info or get_variant_evidences. It precisely states the output type, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when protein-level consequences are needed) but does not explicitly mention alternatives or exclusion conditions. No guidance is provided on how this relates to other variant-specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds a modest clarification that the tool returns counts rather than results. However, it does not disclose any additional behavioral traits such as aggregation logic or dependency on specific parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise, though slightly under-specified, so it does not receive a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 5-parameter complexity and zero schema descriptions, the description is far too brief. It does not explain return value structure (even though an output schema exists), nor does it provide usage alternatives or parameter behavior, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage, and the description provides no information about how any parameter affects the facet counts. The agent is left without guidance on what query_string, entity_names, category_id, etc., do.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('return'), resource ('facet counts'), and purpose ('to help filter search results'), clearly distinguishing it from sibling tools like search_entities and search_suggestions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to help filter search results' implies a usage context, but there is no explicit guidance on when to use this tool instead of alternatives, and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds 'core metadata' but discloses no other behavioral traits such as pagination, filtering, or side effects. It doesn't contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler words, immediately stating what the tool does. It is well-structured and appropriately sized for a simple retrieval operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description fails to mention the optional fields parameter or any usage caveats. This makes the tool feel incomplete for an AI agent, especially given the large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of efo_id or the fields parameter. The agent is left to infer the meaning, which is inadequate for a required parameter plus an optional fields selector.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and identifies the resource as 'core metadata for an Open Targets disease entity', clearly distinguishing it from sibling tools like get_disease_known_drugs or get_disease_ontology that target specific data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for general disease metadata but provides no explicit guidance on when to use it over alternatives or any exclusion criteria. There is no mention of sibling tools or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, and the description does not contradict this. However, the description adds no additional behavioral context beyond the annotation, such as pagination behavior or result format, so it provides minimal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It efficiently communicates the tool's core function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description covers the primary purpose. However, it does not mention pagination or the required efo_id parameter, which are present in the schema but not described. For a basic list-fetching tool, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description does not mention or explain any parameters. It does not clarify that efo_id is required or what page_size/page_index control. The parameter names are somewhat self-explanatory, but the description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and specifies the resource 'HPO phenotype annotations' linked to 'a disease', making it clear what the tool does. It distinguishes itself from sibling tools like get_disease_info or get_disease_known_drugs by naming the exact data type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives. There is no mention of prerequisites, such as needing an EFO ID, or when to prefer other disease-related tools. The description simply states the action without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already discloses the safe read-only nature, and the description aligns with that. However, it adds no behavioral context beyond listing data categories—no input requirements, no rate limits, and no caveats. It does not contradict the annotation, but also does not enrich it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and scope. Every word earns its place, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema and readOnlyHint provide some structural context, the description leaves the fields parameter and the required chembl_id identifier unexplained. With only 2 parameters and 0% schema description coverage, this is a meaningful gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for parameter semantics. It does not mention the required chembl_id parameter or the optional fields parameter at all, leaving their meaning and usage completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' and identifies the resource as 'a drug,' then lists concrete data categories: 'identity, indication, and mechanism data.' This clearly distinguishes it from sibling tools like get_drug_adverse_events or get_drug_linked_diseases, which target more specific facets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The data categories imply when to use the tool, but there is no explicit guidance on when not to use it or mention of alternatives. It does not distinguish itself from overlapping siblings such as get_drug_linked_diseases or get_drug_literature_occurrences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation, so the description does not need to repeat that. The term 'chaining' adds some behavioral context (it traverses disease-target-drug evidence), but it does not disclose details like latency, rate limits, or the nature of the output. This is acceptable for a read-only tool with annotations, but not rich enough for a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the purpose without any fluff. It is concise and earns its place, though it could provide more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, 0% schema coverage, and an output schema present, the description still fails to provide necessary context for correct usage. It does not explain how the chaining works, what the parameters control, or what the output represents. The output schema reduces the need to explain return values, but the parameter side remains severely under-documented for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 8 parameters with 0% description coverage, so the description must compensate. However, it does not explain any of the parameter meanings except indirectly implying that 'disease' refers to the required efo_id. No guidance is given for max_targets, min_association_score, approved_only, etc., leaving the agent to guess. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to find drug repurposing candidates by chaining disease, target, and drug evidence. The specific verb 'Find' and resource 'repurposing candidates' distinguish it from sibling tools like get_disease_known_drugs or get_drug_linked_diseases, which focus on known associations rather than candidate generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by chaining disease, target, and drug evidence' implies when to use this tool, but it does not explicitly state when not to use it or name alternative tools. There is no clear exclusion criteria, so the guidance is only implicit rather than definitive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, and the description adds no additional behavioral context such as concurrency behavior, error handling, rate limits, or result structure. The batch nature is already captured in the purpose, leaving the agent without insight into how the tool operates beyond being read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action, and contains no filler or redundant information. Every word contributes to understanding the tool's primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which reduces need to explain return values), the tool has 5 parameters and zero schema descriptions. The description is too sparse to fully support correct invocation: it omits optional parameter semantics, usage context, and any note on how batch execution behaves. The agent would likely need to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for explaining parameters. It implicitly covers query_string and variables_list via the phrase 'query against many variable sets', but completely ignores key_field, operation_name, and max_concurrency. Parameter names alone are insufficient for correct invocation, especially for key_field which is ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute one GraphQL query against many variable sets' uses a specific verb ('Execute'), identifies the resource ('GraphQL query'), and clarifies the scope ('many variable sets'), which clearly distinguishes it from single-query tools like graphql_query and schema retrieval tools like graphql_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch execution when there are many variable sets, but it does not explicitly state when to use this tool over graphql_query or other alternatives, nor does it provide any exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already covers the read-only nature. The description adds that the output includes evidence scores, which is useful but does not disclose pagination behavior, default parameters, or any edge cases. It does not contradict the annotation, but also does not add substantial behavioral context beyond what the schema and annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes: 'List targets associated with a disease, including evidence scores.' It is concise and immediately clear about the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with four parameters and an output schema, the description gives the essential purpose but omits details like how to use page_size/page_index, what 'fields' controls, and any output structure nuances. It is adequate as a minimal description but not rich enough to be fully self-sufficient, especially given the lack of parameter descriptions in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for the four parameters (efo_id, fields, page_size, page_index). It only hints that a disease identifier is needed (efo_id) and mentions evidence scores, but does not explain the 'fields' parameter, pagination defaults, or value formats. This is insufficient for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('targets'), and the context ('associated with a disease'). It distinguishes from sibling tools like get_disease_info (disease info) and get_target_associated_diseases (reverse relationship). Including 'evidence scores' adds specific output detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention that get_target_associated_diseases exists for the reverse lookup, nor does it provide prerequisites (e.g., needing an EFO ID). The usage context is only implied by the verb and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint already discloses that this is a safe read operation. The description's verb 'Retrieve' is consistent and adds no additional behavioral traits, such as pagination, field selection behavior, or response structure. It neither contradicts annotations nor adds significant transparency context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose without redundant phrasing or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, read-only, and has an output schema, so the description doesn't need to detail return values. However, it lacks usage guidance and parameter semantics, which are partially compensated by the schema's parameter names but not by descriptions. The description is minimally viable but leaves room for improvement in guiding an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining the parameters. 'study_id' is relatively self-explanatory, but 'fields' is ambiguous—it could mean field selection, filtering, or something else. The description offers no hints about what 'fields' controls or how to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Retrieve') and resource ('metadata and cohort details for a GWAS study'), making the tool's purpose immediately identifiable. It also distinguishes itself from sibling tools by focusing on study-level metadata rather than credible sets, diseases, or drugs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or context like 'use for study-level metadata; for variant info use get_variant_info.' The only implicit cue is the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, indicating a read-only operation. The description adds that the output includes quality metrics, but it does not disclose other behavioral aspects such as pagination, rate limits, or whether all probes are returned. Given the annotation, the bar is lower, and the description adds minimal value beyond annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core purpose. There is no wasted wording, and it front-loads the action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, and the presence of an output schema covers return values. The description is sufficient to understand the tool's role and context, though it could benefit from naming the parameter relation to the tool's purpose. Overall, it is a complete enough description for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, ensembl_id, with no description, and the tool description does not explicitly explain it. The description implies the probes are for a target but does not clarify the meaning, format, or examples of ensembl_id. With 0% schema description coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available chemical probes and their quality metrics, using the specific verb 'list' with the resource 'chemical probes'. It is distinct among the many get_target_* siblings because it focuses specifically on probes, not drugs or other target info, but it does not explicitly differentiate itself from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: to list chemical probes for a given target (identified by ensembl_id), this tool is appropriate. However, it provides no explicit guidance on when to use this tool versus alternatives like get_target_known_drugs, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description's 'Fetch' is consistent with a read-only operation. However, the description adds no additional behavioral context beyond what the annotation already provides, such as data provenance, response size, or pagination behavior. It does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every phrase ('DepMap', 'CRISPR essentiality scores', 'across cell lines') contributes directly to understanding what the tool does, achieving high clarity in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are likely documented there, and the read-only annotation covers safety. However, the description lacks parameter semantics and usage guidance, and there are no details about dataset versions or expected output format in the description. For a simple one-parameter tool with these structured fields, the description is adequate but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes only the parameter name 'ensembl_id' with no description (coverage 0%). The description does not clarify that this parameter specifies the target/gene for which essentiality scores are retrieved, nor does it indicate the expected format (e.g., Ensembl Gene ID). The meaning must be inferred from the tool name, which is a significant gap for a schema with zero parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch'), identifies the resource ('DepMap CRISPR essentiality scores'), and mentions the scope ('across cell lines'). This clearly distinguishes it from sibling tools like get_target_expression or get_target_info, which address different target-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives, no exclusion scenarios, and no mention of related tools. The intended context (e.g., 'when you need essentiality data for a target') must be inferred entirely from the tool name and description, which is insufficient for a tool with many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates the safe, non-mutating nature. The description adds the behavioral scope (listing pathway memberships and GO annotations) but does not disclose pagination behavior, default limits, or any filtering constraints. Since annotations cover the safety profile, this is acceptable but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It immediately states the verb and the resource, and avoids any filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema and the readOnlyHint reduces the need to describe return values. Still, the description lacks usage context and does not mention pagination, which is relevant given the page_size and page_index parameters. It is minimally complete for a simple read-only list tool but has clear gaps in guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (ensembl_id, page_size, page_index). While parameter names are somewhat self-explanatory, the description does not compensate for the lack of schema documentation or clarify that ensembl_id is the target identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List'), a resource ('pathway memberships and Gene Ontology annotations'), and a scope ('for a target'). This distinguishes it from sibling tools like get_gene_ontology_terms, which likely returns GO terms without pathway context, and other get_target_* tools that focus on different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as get_target_info or get_gene_ontology_terms. It does not state exclusions, prerequisites, or situations where a different tool would be more appropriate. The usage context is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true covers the read-only safety aspect. The description adds a small behavioral detail: the scores are 'compiled across data sources,' indicating an aggregation process. However, it doesn't disclose potential issues like ID format requirements, error behavior, or what the scores represent. With annotations present, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that communicates the core function without any wasted words. It is front-loaded with the main action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required param) and has an output schema (so return values are presumed documented), but the description leaves gaps: it doesn't explain what 'prioritisation scores' are, how they are calculated, or why a user would want them. The phrase 'compiled across data sources' is vague and could be expanded to indicate which data sources or how scores should be interpreted. Still, for a simple retrieval tool with one param, it's minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning of ensembl_id. While the parameter name is a standard identifier and likely self-explanatory, the description fails to explicitly connect it to the tool's purpose or provide any additional semantics beyond what the name itself conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Return target prioritisation scores compiled across data sources.' It has a specific verb (Return) and resource (target prioritisation scores), and the phrase 'compiled across data sources' helps distinguish it from other target-related tools that return raw data. No other sibling tool mentions prioritisation, making it uniquely identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus its many siblings. It doesn't mention typical use cases, prerequisites, or alternatives. The only hint is the name, but there is no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation, and the description's 'Fetch' is consistent with that. However, the description adds no additional behavioral context such as output format, performance, or edge cases, so it does not go beyond what the annotation provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. It contains no extraneous words and is easily parsed by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple—one parameter, read-only annotation, and an output schema—so the description is minimally sufficient for a basic lookup. However, it does not explain what TEP information includes or when to prefer this tool over the many sibling tools, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists one required parameter 'ensembl_id' with 0% description coverage. The description's 'for a gene' only implicitly relates the parameter but does not explain the expected format, that it should be an Ensembl ID, or provide any example. This fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Fetch') and resource ('TEP information for a gene'). It distinguishes this from sibling target tools by the unique 'Target Enabling Package' concept, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other target-related tools. It lacks any mention of alternatives, prerequisites, or use cases, leaving the agent without selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile. The description adds no extra behavioral context (e.g., pagination behavior, filtering nuances, or empty result handling) beyond what the name and annotation imply, providing little value beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the verb, object, and scope without any filler. Every word serves a purpose, and the description is appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and annotations, the description covers the core purpose but falls short in parameter semantics and usage guidance. It is adequate for a simple tool yet has clear gaps in explaining pagination and how this tool fits among its siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 only implicitly covers 'variant_id' through 'variant', but says nothing about 'page_size' or 'page_index'. The pagination parameters are left unexplained, relying entirely on the schema's defaults and names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves enhancer-to-gene predictions for a variant, with a specific verb ('Retrieve') and resource ('enhancer-to-gene predictions'). It distinguishes itself from other variant tools like get_variant_info or get_variant_evidences by focusing on E2G predictions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the description and tool name—when you need E2G predictions for a variant—but no explicit alternatives or when-not-to-use guidance is provided. Lacks the clear alternative references seen in higher-scoring descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the safety profile, but the description adds no additional behavioral context such as matching behavior, entity scope, or handling of unmatchable terms. It merely restates the purpose without enriching understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately sized for the tool's function and every phrase contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but the description omits details about entity_names and the breadth of entity types covered. While the core purpose is clear, the agent would need additional clarification for full correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate. It hints that query_terms are the free-text terms but leaves entity_names undefined. The phrase 'canonical Open Targets identifiers' does not explain how entity_names influences the mapping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'map' and the resource 'free-text terms to canonical Open Targets identifiers', which distinctly differentiates it from sibling tools that fetch entity data. It is a specific and unambiguous statement of the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when free-text terms need canonical identifiers, but it does not explicitly state when to use this tool versus alternatives like search_entities or provide exclusions. No sibling comparisons are made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description simply restates the read-only nature without adding additional behavioral context such as error handling, data coverage, or prerequisites. No new information beyond the annotation and the tool's name is disclosed, so the description adds minimal value for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. Every word ('Return', 'ChEMBL target class annotations', 'gene') earns its place, making it maximally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, a readOnlyHint, and an output schema present, the tool is simple. The description sufficiently conveys the core purpose, and the output schema reduces the need to explain return values. However, a brief note about the expected format of ensembl_id would make it fully complete given the lack of schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears the burden of explaining the parameter. It only says 'for a gene', which is redundant with the parameter name ensembl_id. It does not clarify that Ensembl gene IDs typically follow a format like ENSG000001..., nor does it explain what the identifier represents beyond 'gene'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return ChEMBL target class annotations for a gene' uses a specific verb ('Return') and a clear resource ('ChEMBL target class annotations') scoped to a gene. This clearly distinguishes it from sibling tools like get_target_info or get_gene_ontology_terms by the specific type of annotation returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a gene's ChEMBL target class is needed, but provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or alternatives among the many sibling get_target_* tools, leaving the agent to infer applicability from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read. The description adds no behavioral details such as output format, pagination, or prerequisites, so it provides minimal value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It is well-structured and immediately conveys the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema and readOnly annotation provide substantial context. For a single-parameter read-only tool, the description is largely complete, though it could be improved by explicitly stating the ensembl_id is a gene identifier.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only loosely equates 'target' with the ensembl_id parameter. It does not explain accepted formats, examples, or what a target is, leaving the parameter underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns cancer hallmark annotations for a target, using a specific verb and resource. It distinguishes itself from sibling tools like get_target_info or get_target_class by focusing on hallmarks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when cancer hallmark annotations are needed, but provides no explicit when-not conditions or mention of alternative tools. It does not guide selection among the many get_target_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers safety, so the description does not need to restate that. It adds minimal behavioral context ('from curated databases') but does not disclose pagination behavior, filtering mechanics, or any caveats. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clean sentence that efficiently conveys the core purpose. It is front-loaded with the verb and resource, contains no filler, and is appropriately sized for a straightforward retrieval operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too sparse for a tool with six parameters and no schema-level descriptions. It omits guidance on pagination, threshold filtering, source database selection, and the optional fields parameter, leaving the agent with insufficient context to invoke the tool correctly beyond the required ensembl_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides almost no parameter information. The phrase 'for a target' hints at ensembl_id, but fields, page_size, page_index, score_threshold, and source_database are left unexplained, forcing the agent to rely solely on property names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (Retrieve) and resource (protein interaction partners for a target), and the phrase 'from curated databases' distinguishes it from other target-focused tools like get_target_info or get_target_associated_diseases. There is no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests use when needing interaction partners for a target, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like get_interaction_resources. The usage context is implied but lacks exclusion criteria or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, so the agent knows it is a safe read operation. The description adds minimal behavioral context beyond that, such as the filtering by variant, but does not mention pagination, return format, or other traits. It does not contradict annotations, and with annotations covering the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It directly states the purpose without filler, scoring high on conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, an output schema, and read-only annotation, the description is too brief. It does not explain pagination (page_size/page_index), the optional study_types filter, or any details about the response. While the output schema exists, the lack of usage context makes the tool difficult to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. The description only implies the role of variant_id ('specific variant') but provides no meaning for page_size, page_index, or study_types. This leaves significant gaps for the other three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List credible sets that include a specific variant' uses a specific verb ('List') and resource ('credible sets') with a clear filter (specific variant). It distinguishes from sibling tools like get_credible_sets (all sets), get_study_credible_sets (by study), and get_credible_set_by_id (by ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative exclusions are provided. The usage is implied: when you have a variant and want the credible sets containing it. The description gives clear context but does not mention when not to use it or point to alternatives, so it falls at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description is consistent with a read operation. However, the description adds no extra behavioral context such as pagination behavior, filtering effects, or output structure beyond what annotations and output schema provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no schema descriptions, the description lacks essential context about pagination, filtering, and field selection. The output schema covers return values, but the parameter behavior is undocumented and the description does not compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only implicitly references variant_id and does not clarify size, cursor, fields, or datasource_ids, leaving the agent without necessary details for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Retrieve' and the resource 'evidence strings linking a variant to targets or diseases'. This distinguishes it from sibling tools like get_variant_info and get_target_disease_evidence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a variant_id is available and evidence strings linking to targets/diseases are needed, but it does not explicitly mention alternatives or exclusions. No when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this as a safe read operation. The description adds the fact that it executes 'raw GraphQL', which implies arbitrary query complexity, but it does not disclose rate limits, response size limitations, or how to obtain the GraphQL schema. This is adequate but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the key information. Every word earns its place, and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an advanced tool with high flexibility, the description is extremely minimal. It does not guide the user on constructing queries, point to graphql_schema for the schema, or mention any constraints. While the output schema covers return values, the overall context for effective use is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining parameters. It only mentions 'GraphQL query', which maps to query_string, but variables and operation_name are left entirely to the schema. No additional meaning is provided for these GraphQL conventions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Execute' and the resource 'raw GraphQL query against Open Targets', distinguishing it from the many specific get_* tools and from graphql_batch_query. The 'ADVANCED' prefix helps emphasize it's a low-level interface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'ADVANCED' label implies use for non-standard queries, but there is no explicit guidance on when to use this over the specialized endpoints or which alternatives exist. The description does not mention graphql_schema or other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint is provided, so the safe-read behavior is already known. The description adds that synonyms will be resolved to canonical IDs, which is useful behavioral context beyond the annotation. However, it does not disclose pagination behavior, output format, or other potential quirks. Given the annotation, this is adequate but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose and a differentiating behavior. Every word is useful, and there is no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too sparse for a tool with 4 parameters and 0% schema coverage. It fails to explain how to use the parameters, what pagination does, or how entity filtering works. The tool is more complex than the one-sentence description suggests.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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, but it does not. The description gives no details about query_string, page_size, page_index, or entity_names. The only hint is that 'search' implies a query string, but it adds no meaningful parameter-level semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'search' and names the resource 'Open Targets entities', and further clarifies a key behavior: 'resolve synonyms to canonical IDs'. This distinguishes it from the many get_* sibling tools and search_suggestions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for searching entities and resolving synonyms, but it does not explicitly state when to use it over alternatives like search_suggestions or map_ids, nor does it provide any exclusion criteria. The context is clear enough for a generic search, but no alternatives are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the agent knows it's a safe read operation. The description adds the detail about 'investigational or approved indications,' which narrows the semantics, but it does not disclose pagination behavior, required parameter specifics, or any other non-obvious traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no filler. It earns its place and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists and the purpose is clear, the description is incomplete for a 4-parameter tool. It fails to mention the free-text query or pagination controls, and it does not position the tool relative to siblings. However, the read-only annotation and output schema fill some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter documentation. It only implicitly covers efo_id via 'for a disease,' leaving size, cursor, and free_text_query entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Retrieve'), specifies the resource ('drugs'), and scopes it to a disease with a specific indication status ('investigational or approved'). This distinguishes it from sibling tools like get_target_known_drugs (drugs for a target) or get_drug_linked_diseases (diseases for a drug).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use (when you need drugs for a disease) but does not explicitly state when to prefer this tool over alternatives or mention exclusions. No alternative tools are referenced, so the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the operation safe, and the description's 'List' is consistent. However, no additional behavioral context (such as response shape, filtering, or error cases) is disclosed, though nothing contradicts the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, but the description lacks explicit parameter semantics and usage guidance. It is minimally complete but could be enhanced by specifying that efo_id is an EFO identifier and when to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly clarify that 'efo_id' is the disease identifier or provide format details. The phrase 'linked to a disease' is a weak implicit hint, leaving the agent without sufficient parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List') and resource ('Open Targets Associated Research (OTAR) projects') with the context 'linked to a disease'. This clearly distinguishes it from sibling tools like get_disease_info or get_disease_associated_targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies use for retrieving OTAR projects for a disease, but no exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds the context of using mechanism-of-action data, which is useful. However, it does not disclose any other behavioral traits like pagination, filtering, or return format. The description is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It earns its place by clearly stating the function in a concise manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple getter with one required parameter and an output schema (which likely describes the target objects), the description is adequate for basic understanding. However, it lacks guidance on the expected input format (e.g., ChEMBL ID format) and does not clarify what 'fields' controls. The description is not misleading but is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (chembl_id required, fields optional) with zero description coverage. The description does not mention either parameter or add any meaning beyond the schema. The tool name hints that chembl_id is the drug identifier, but the optional 'fields' parameter is unexplained, leaving an agent without enough semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and the resource ('targets linked to a drug'), and specifies the mechanism ('via mechanism-of-action data'). This distinguishes it from sibling tools like get_drug_linked_diseases and get_drug_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need targets linked to a drug via MoA) but does not explicitly mention alternatives or provide exclusion criteria. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description does not contradict this. The description adds the batching behavior ('in a single request') but omits details on limits, error handling, or response specifics. It is minimally transparent beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is seven words in one sentence, entirely front-loaded and free of filler. It is maximally concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema and readOnly annotation, the description is minimally sufficient for selection but lacks parameter clarification. An agent must infer that chembl_ids refers to ChEMBL identifiers, which is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter chembl_ids is not described in the schema (0% coverage) and the description does not explain that it accepts an array of ChEMBL IDs or any constraints. With low schema coverage, the description should compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves multiple drugs in a single request, clearly distinguishing it from single-drug tools like get_drug_info and other batch tools. The verb 'retrieve' and resource 'drugs' are specific and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies batch usage via 'in a single request' but does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling tools like get_drug_info indicate the batch variant, but the description itself offers no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, and the description adds the concept of 'association profiles' but does not elaborate on the similarity metric, threshold semantics, or pagination behavior. It provides some context but no significant behavioral detail beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence with no filler. Every word contributes to defining the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and readOnlyHint is set, but the description does not explain the meaning of size and threshold, nor the nature of 'association profiles'. For a similarity tool, understanding the similarity measure and parameter effects is crucial, so the description is only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention parameters. While entity_id is self-explanatory, size and threshold are ambiguous (e.g., what does threshold mean? inclusive/exclusive?), and the description offers no clarification. The parameter names provide partial hints but are insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Identify targets with similar association profiles to the seed target.' It uses a specific verb ('Identify') and a specific resource ('targets'), and the phrase 'similar association profiles' distinguishes it from sibling tools like get_disease_similar_entities and get_drug_similar_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you have a seed target and want to find similar targets, but it does not explicitly state when to use this over alternatives like get_disease_similar_entities or get_drug_similar_entities. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint annotation by stating 'List', indicating a safe read operation. It adds scoping about what is listed (alternate symbols and cross-references) but does not disclose additional behavioral traits such as data source, pagination, or response format. This is acceptable given the readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the tool's purpose with no redundant words. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and a readOnlyHint, the description is sufficient for a simple one-parameter tool. It explains the main output (alternate symbols and cross-references) and does not need to elaborate return values. However, it could be slightly more explicit about the target gene context, resulting in a small deduction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter clarity. The description mentions 'for a target', implying ensembl_id identifies the gene, but does not explicitly state that ensembl_id is an Ensembl gene identifier or provide format details. The parameter name is self-explanatory, but the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and specifies the resource as 'alternate gene symbols and database cross-references for a target.' This clearly differentiates it from sibling tools like get_target_info or get_target_homologues, which cover other aspects of target data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or scenarios where other target-related tools would be more appropriate, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true, and the description's verb 'Retrieve' is consistent, so there is no contradiction. However, the description adds no extra behavioral context beyond the annotation—no mention of data sources, rate limits, or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource, with no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so basic retrieval is covered. However, it lacks guidance on use cases or what constitutes 'safety liabilities,' and does not differentiate from many sibling target tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the ensembl_id parameter. It only refers to 'a target,' implying the parameter identifies the target, but gives no format or example. The parameter name is self-explanatory, but the description offers minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and the resource ('documented safety liabilities' for a target), which is distinct from sibling tools like get_target_info or get_target_known_drugs. The phrasing is specific enough to convey that this returns safety-related liability data for a given target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives such as get_target_info or get_target_tep. The context implies usage when safety liability information is needed, but it does not mention exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description is consistent with a read-only operation. It adds context about the type of data returned but does not disclose additional behavioral traits such as rate limits, authorization needs, or handling of optional parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words, making it efficient and easy to scan. It is appropriately sized for the tool's apparent simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema likely covers return values, the description lacks parameter usage guidance and does not help an agent decide between this tool and the many variant-specific alternatives. It provides minimal context within the broader API surface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not explain the 'fields' parameter or the expected format for 'variant_id'. It only references 'variant' in general, leaving the optional fields parameter completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' and identifies the resource as 'core metadata and functional annotations for a variant.' This clearly distinguishes it from sibling tools that target specific variant data types like credible sets, evidences, or intervals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The intended usage is implied from the tool name and sibling context, but the description does not name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this as a safe read operation. The description adds that it returns RNA and protein profiles across tissues, but does not disclose operational details like error handling or response size. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed 11-word sentence. It is front-loaded with the action and resource, containing no redundant words or phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description leaves critical gaps: it does not explain what 'fields' controls, nor does it confirm that ensembl_id is the target identifier. For a two-parameter tool with zero schema descriptions, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning of ensembl_id or fields. The agent must infer that ensembl_id refers to a target identifier from context, and the 'fields' parameter remains unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and clearly identifies the resource as 'RNA and protein expression profiles' for a target, with the scope 'across tissues'. This distinguishes it from sibling tools like get_target_info or get_target_tep, which focus on other target attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies clear usage context: when you need expression data across tissues for a target. However, it does not explicitly mention any alternatives or exclusion criteria, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals that this is a safe read operation. The description adds minimal behavioral context beyond the obvious, simply restating that it returns annotations. No additional details are provided about result cardinality, empty results, or matching semantics, but with the annotation covering safety, the description is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. Every word contributes, with no redundancy or filler. It reads well and is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, output schema present, read-only annotation), the description is largely sufficient. It tells the agent what the tool returns and for which kind of entity. However, it lacks any note about the expected ID format or potential limitations, which would make it fully complete. Still, for a straightforward lookup, it covers most of the necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter 'ensembl_id' with no description (schema_description_coverage=0%). The tool description does not mention this parameter at all, saying only 'for a target.' This does not compensate for the lack of schema documentation, leaving the agent to infer that ensembl_id is a gene/product identifier. A brief note on expected ID format or examples would have improved clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and clearly identifies the resource as 'subcellular localisation annotations for a target.' This distinguishes it from sibling tools like get_target_class or get_target_expression, which focus on other aspects of target data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to retrieve subcellular localisation annotations, but it does not explicitly state when to use it versus other target-related tools or mention any alternatives/exclusions. The intended usage is fairly clear from the name and context, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, and the description aligns by saying 'List.' It adds context about the domain (target–disease evidence) but discloses no further behavioral traits like aggregation, ordering, or pagination. The output schema likely covers return structure, so this is sufficient though minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently conveys the action and subject in ten words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema and read-only annotation, the description is adequately complete. It clearly states the purpose, and the output schema will detail the return format. Slightly more context about what 'sources' means could be useful, but it is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. This matches the 0-parameter baseline expectation of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'sources' contributing to 'target–disease association evidence,' clearly distinguishing it from siblings like get_target_disease_evidence which provide evidence data. It precisely states the scope and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, with no mention of appropriate contexts, exclusions, or relation to sibling tools such as get_target_disease_evidence or get_disease_associated_targets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's addition of 'based on PubMed embeddings' provides useful methodological context beyond the annotation. It does not contradict annotations, and it clarifies that results are semantic similarities rather than exact matches, though it does not detail threshold or sorting behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without wasted words. Every element ('find', 'semantically similar', 'diseases', 'PubMed embeddings') adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, which partially covers return values, but the description lacks parameter semantics and usage alternatives. Given five parameters with no schema descriptions, the description is not rich enough to fully compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the five parameters. 'efo_id' is implied by the tool name, but 'threshold', 'entity_names', 'additional_entity_ids', and 'size' remain undocumented, leaving the agent to guess their meanings and relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'find' and clearly identifies the resource 'diseases' plus the method 'based on PubMed embeddings'. It distinguishes this from sibling tools like get_drug_similar_entities and get_similar_targets by focusing on diseases and semantic similarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when semantically similar diseases are needed, but it does not explicitly state when to use this tool over alternatives or provide any exclusions. The disease-focused wording provides clear context, but no alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes the safe read-only nature, and the description adds the elements returned. However, it does not discuss additional behaviors like recursion depth or error handling. With annotations present, the description adds some value but not comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with a clear verb, object, and scope. It is front-loaded with 'Retrieve' and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description adequately states what is returned. However, it does not place the tool in a broader workflow or explain how it relates to other disease-related tools, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the sole parameter 'efo_id', and the tool description does not mention the parameter or its format. The name implies an EFO identifier, but the description fails to compensate for the missing schema-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' and clearly names the resource as 'ontology structure for a disease' with explicit elements (parents, children, ancestors). This distinctly differentiates it from sibling tools like get_disease_info or get_disease_phenotypes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use this tool (when you need the disease ontology hierarchy) but does not explicitly mention alternatives or when-not-to-use cases. It provides clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known to be a safe read operation. The description adds useful context about the kind of diseases included ('indications and mechanisms'), but does not disclose pagination, return structure, or other behavioral details. This is sufficient given the annotation coverage, but not exceptionally rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core purpose and scope efficiently, earning its place without redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, 1 required), has an output schema, and a readOnly annotation. The description covers purpose and scope adequately. However, the unexplained 'fields' parameter and lack of any parameter descriptions prevent a perfect score, though the output schema mitigates the need for return-value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 not explain the 'fields' parameter at all. The word 'drug' implicitly maps to 'chembl_id', but the optional 'fields' parameter (likely for selecting output fields) remains completely undocumented, leaving a gap for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('diseases connected to a drug') with a clear scope ('across indications and mechanisms'). It clearly distinguishes from sibling tools like get_drug_linked_targets or get_disease_known_drugs by focusing on the drug-to-disease relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to retrieve diseases linked to a drug. It does not explicitly mention alternatives or exclusions, but the scope ('across indications and mechanisms') helps an agent infer the use case relative to other drug-focused tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already provides readOnlyHint=true, so the description doesn't need to state that. The description adds the source (gnomAD) and the concept of metrics, but doesn't elaborate on return format or any limitations. With annotations covering safety, this is adequate but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the tool's purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with an output schema and a readOnly annotation, the description is largely complete. However, it omits explicit guidance on parameter semantics and alternative tool selection, which would make it fully robust. Overall, it's sufficient for the intended functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or format of the ensembl_id parameter. The parameter name is self-explanatory, but the description fails to compensate for the missing schema description, leaving the agent to infer the mapping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetch' with the resource 'genetic constraint metrics (gnomAD)' for a target. This clearly distinguishes it from sibling tools like get_target_info or get_target_expression by specifying the unique data type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the context: fetching genetic constraint metrics. While it doesn't explicitly name alternatives or exclusions, the purpose is specific enough that a user would know when to choose this tool. No overlap with siblings is apparent, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals this is a safe read operation, and the description adds no additional behavioral traits such as output format, pagination, or side effects. For a simple enumeration tool with an output schema, the minimal disclosure is acceptable but not richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and object with no redundant or filler content. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, a readOnlyHint, and an output schema, the description is adequate for its simplicity. The only minor gap is a slight ambiguity about what 'interaction databases' specifically includes, but this is likely resolved by the output schema, so the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline score is 4. The description does not need to explain parameters but does clarify that the tool enumerates interaction databases, which provides the context for what the output will contain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'enumerate' with a clear object ('interaction databases integrated into Open Targets'), which unambiguously differentiates this tool from sibling tools that query specific entities like diseases, drugs, targets, or variants. It states both the action and the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives or any exclusions. However, the purpose of enumerating interaction databases implies a discovery use case, and the tool is clearly distinct from the entity-specific siblings, so the usage context is partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description's 'Return' aligns with a read-only operation. The description adds the useful behavioral detail that the output is in SDL format, which is not conveyed by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. The 'ADVANCED' prefix adds a succinct caveat without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only, output schema exists), the description sufficiently communicates the tool's purpose and output format. No additional detail is necessary for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to elaborate on parameter meanings. The empty schema is fully covered, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and clearly identifies the resource ('GraphQL schema in SDL format'). It distinguishes itself from siblings like graphql_query and graphql_batch_query by specifying the schema rather than executing queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. The 'ADVANCED' label hints at intended audience but does not clarify conditions or contrast with other GraphQL-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation. The description adds behavioral context by specifying that the output is human-readable labels, which is not captured by the annotation or schema. No contradictions or missing behavioral disclosures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is perfectly concise and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter), the presence of readOnlyHint annotation, and an output schema (though not shown), the description is complete for its purpose. It fully communicates what the tool does, and the output schema covers return-value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds little beyond the parameter name 'go_ids' — it merely restates 'Gene Ontology identifiers' without providing examples, format constraints, or batch handling details. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resolve Gene Ontology identifiers to human-readable labels' uses a specific verb ('Resolve') and resource ('Gene Ontology identifiers'), clearly distinguishing it from sibling tools that focus on diseases, drugs, or targets. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the exact usage scenario: whenever GO identifiers need to be converted to readable labels. While no explicit alternatives or exclusions are stated, the tool's specificity makes its use case clear, and no sibling tool competes for this function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds no additional behavioral context such as side effects, rate limits, or authorization requirements. It is consistent with the annotation but does not go beyond it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. Every word contributes meaning, and the key resource is front-loaded. It is an model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's minimal complexity (zero parameters) and the availability of an output schema, the description is fully complete. It states exactly what the tool returns, and the output schema handles details of the response structure. No other context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty and there is nothing to explain. Per the rubric, a 0-parameter tool earns a baseline of 4. The description correctly implies no arguments are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a clear resource ('Open Targets Platform release metadata'), which precisely defines its scope. It distinguishes itself from all sibling tools, which focus on diseases, drugs, targets, or variants, by pointing unambiguously to platform-level metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The resource is self-explanatory: this tool is for obtaining release metadata. While it does not explicitly state when to use it over alternatives, the context makes it obvious that no other sibling tool provides this kind of platform-level information. The description gives clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![opentargets-mcp MCP server](https://glama.ai/mcp/servers/nickzren/opentargets-mcp/badges/card.svg)](https://glama.ai/mcp/servers/nickzren/opentargets-mcp)

Score Badge

Copy to your README.md:

[![opentargets-mcp MCP server](https://glama.ai/mcp/servers/nickzren/opentargets-mcp/badges/score.svg)](https://glama.ai/mcp/servers/nickzren/opentargets-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nickzren/opentargets-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server