BioContextAI Knowledgebase MCP

Official

by biocontext-ai

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct database and operation. Even within the same database (e.g., FDA drugs: count, get, search, statistics), the purposes are clearly differentiated by the verb and noun combination, leaving no ambiguity.
Naming Consistency5/5
All tools follow a strict 'bc_verb_noun' pattern in snake_case, using common verbs (get, search, query, count) and specific nouns. The naming is entirely predictable and consistent.
Tool Count4/5
With 24 tools, the server covers a broad range of biomedical databases. While slightly above the typical 3-15 range, each tool has a clear purpose and the count is justified by the number of integrated resources.
Completeness4/5
The tool surface covers core operations for each database (retrieval, search, statistics). Minor gaps exist, such as missing STRING functional enrichment or direct cross-database queries, but the core workflows are supported.
Average 3.8/5 across 24 of 24 tools scored. Lowest: 3.1/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
- Last stable release on December 14, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
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?
With no annotations provided, the description carries the full burden. It describes a read-only search but does not explicitly state that it is non-destructive or safe. No mention of side effects, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: first the action, then the return. It is front-loaded and to the point, though it could benefit from brief usage context.
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 that an output schema exists, the return value explanation is partially covered. However, the description does not mention pagination behavior or error handling, leaving some gaps for a list-search tool.
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 100%, so the description adds little beyond what the schema already provides. The description lists return fields but does not augment parameter descriptions (e.g., format or constraints). Baseline 3 is appropriate.
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 it searches the Antibody Registry for antibodies and lists the return fields (catalog numbers, vendors, etc.). This distinguishes it from sibling tools like bc_get_antibody_information, which likely gets details on a specific antibody. However, it could explicitly contrast with that tool.
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 on when to use this tool versus alternatives such as bc_get_antibody_information. Missing any when-to-use or when-not-to-use context, even though a sibling tool exists that might be confused.
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?
With no annotations provided, the description carries full burden. It mentions the return structure but does not disclose that the operation is read-only, nor does it discuss pagination behavior, rate limits, or potential side effects. Safety profile is unclear.
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 only two sentences plus a return note, very concise. Purpose is front-loaded. Every sentence earns its place without redundancy.
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 12 optional parameters and an output schema, so the description need not detail return values. However, it lacks guidance on combining parameters or typical use cases. Given the sibling tools, more context on when to use multiple search fields would improve completeness.
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 description coverage is 100%, so the baseline is 3. The description adds 'Supports multiple search criteria' but does not elaborate on parameter semantics beyond what the schema provides. No extra value.
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 searches the FDA Drugs@FDA database for approved drug products, which is a specific verb and resource. It is distinguishable from siblings like bc_search_drugs_by_therapeutic_class, though it does not explicitly differentiate. The mention of 'approved drug products' adds specificity.
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 on when to use this tool versus siblings (e.g., therapeutic class search, application number lookup). There is no mention of when not to use it or prerequisites. The description leaves the agent to infer from 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?
No annotations are provided, so the description must convey behavioral traits. It mentions return format (dict or error) but does not disclose behavior on failure, required permissions, or rate limits. Minimal 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 extremely concise: two sentences plus a return format note. Every part is necessary, with no redundancy. Well-structured for quick parsing.
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's simplicity and full schema coverage, the description is largely complete. It specifies return format and error indications. Could benefit from an example, but outputs are implied by schema.
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 100% with descriptions for both parameters. The description adds no new information beyond restating the purpose—no elaboration on parameter usage, default behavior, or constraints. Baseline 3 is appropriate.
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 gets an Ensembl gene ID from a gene symbol, with a specific return format. It is distinguishable from sibling tools like bc_get_kegg_id_by_gene_symbol by naming, but does not explicitly differentiate its purpose for Ensembl ID mapping.
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 (e.g., other gene ID lookups). The description implies its use for mapping gene symbols to Ensembl IDs but lacks 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions return format and error messages but lacks behavioral details such as rate limits, authorization, or side effects. For a read-only search tool, this is minimal 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 concise with two sentences: purpose and return format. It is front-loaded and efficient.
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 existence of an output schema and full schema coverage, the description summarizes return values sufficiently. However, it lacks context about usage constraints and does not differentiate from related ontology search tools.
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?
Input schema has 100% description coverage, so baseline is 3. The description adds no extra semantic information beyond the schema's 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 clearly states the tool searches for ChEBI terms for a chemical/drug name, specifies the source (OLS), and outlines the return structure. This is specific and differentiates from sibling 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 like bc_search_ontology_terms or other chemical search tools. No when/when-not criteria or context for choosing this tool.
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?
With no annotations, the description carries full burden for behavioral disclosure. It mentions the return format (dict with results or error message) but does not address authentication, rate limits, or what happens when parameters are all missing. The description is too sparse for a tool with no annotation support.
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 very concise, with two sentences covering purpose and included data, plus a separate line for return format. It is front-loaded and contains no redundant or extraneous information.
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 that an output schema exists (so return format is partially covered), the description is fairly complete. It specifies the source, coverage, and return type. However, it could mention that at least one parameter is typically required for meaningful results, even though all are optional in schema.
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 description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema's parameter descriptions; it focuses on output content. No enhancement is needed, but also no degradation.
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 comprehensive drug labeling information from the FDA, with specific examples of included data (active ingredients, dosage forms, administration routes). This is a specific verb+resource combination that distinguishes it from sibling tools that focus on other drug-related 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?
No guidance is provided on when to use this tool versus its siblings (e.g., bc_search_drugs_fda, bc_get_drug_by_application_number). It does not state prerequisites, when-not-to-use, or alternatives, leaving the agent without context for selection.
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?
With no annotations, the description carries the full burden. It states the tool retrieves metadata and returns a dict, which implies a read-only operation, but does not disclose error handling (e.g., invalid DOI), authentication needs, or rate limits. The behavioral traits are minimally covered.
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 fairly concise with two clear sentences. The first sentence states the purpose, the second lists return fields. Slight redundancy in the returns line but overall efficient.
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 an output schema exists, the description sufficiently covers the main return fields. It does not explain error handling or pagination, but these are not critical for a simple retrieval tool. The description is complete enough for basic use.
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 description coverage is 100%, so baseline is 3. The description does not add extra meaning to the parameters beyond the schema; it only lists return fields. No additional syntax or format details are provided for 'doi' or 'server'.
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 detailed preprint metadata by DOI, listing specific fields (title, authors, abstract, etc.). This distinguishes it from sibling tools like bc_get_recent_biorxiv_preprints, which focuses on recent preprints rather than metadata by DOI.
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 bc_get_recent_biorxiv_preprints for listing recent preprints or other search tools. No when-not-to-use instructions or context for choosing 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool returns a dict with API response or error, which is helpful. However, it omits critical details such as idempotency, side effects, authentication requirements, rate limits, or the nature of the API call (GET vs POST). The focus is heavily on parameters rather than behavior.
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 well-structured with a front-loaded purpose sentence followed by an Args section. However, the Args section is a verbose list that largely duplicates the schema's property descriptions, making it longer than necessary. Every sentence could be more concise; for example, the parameter details could be summarized or omitted given the schema.
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's complexity (15 parameters, 1 required) and that an output schema exists, the description covers the basic purpose and parameter details. However, it lacks guidance on when to use this tool versus siblings, does not explain error handling beyond 'error information', and misses behavioral constraints. The output schema may cover return structure, but the description's contextual gaps remain.
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 description coverage is 100%, so the baseline is 3. The description repeats the schema's parameter descriptions almost verbatim without adding new semantic information beyond the usage tip about species. While it lists all parameters, it does not provide deeper meaning or contextualize parameter interactions beyond what the schema already offers.
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 queries the Reactome API identifier endpoint to retrieve pathways for a given identifier, using a specific verb ('Query') and resource ('Reactome API identifier endpoint'). It distinguishes from sibling tools like bc_query_kegg (different database) and bc_get_string_id, as it targets Reactome pathways.
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 advises to always provide the species parameter for correct results, which is a useful usage condition. However, it does not explicitly mention when not to use this tool or compare it with alternatives among the many sibling tools (e.g., bc_query_kegg for KEGG pathways). This limits guidance for an agent choosing among similar 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 description mentions pagination and return format (summary breakdowns), which provides some behavioral context. However, without annotations, it lacks details on data freshness, required permissions, or error handling beyond a brief 'or error message'.
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 short and front-loaded with the purpose. The returns section is somewhat redundant given the presence of an output schema, slightly reducing conciseness.
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 tool with rich schema and pagination, the description covers key points: location-based search, recruiting filter, pagination, and return summary. It is missing explicit differentiation from siblings but is otherwise adequate.
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?
The input schema has 100% coverage with descriptions for all 7 parameters. The description does not add additional semantic meaning beyond what the schema already provides, meeting the baseline expectation.
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 finds recruiting clinical trials by geographic location, specifying the verb and resource. It distinguishes itself from sibling tools like bc_get_studies_by_condition by focusing on location-based filtering.
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 is provided on when to use this tool versus alternatives. With many sibling tools (e.g., bc_search_studies, bc_get_studies_by_condition), the description should mention when to prefer this location-based search over other methods.
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?
No annotations are provided, so the description must disclose behavioral traits. It only mentions the return type (dict with fields) but does not state whether the operation is read-only, any side effects, rate limits, or error cases. This is insufficient for a search tool without annotations.
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 two sentences: the first states the purpose, the second lists return fields. It is concise without wordiness, though the structure could be improved by front-loading the purpose more prominently.
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 7 parameters with full schema coverage and an output schema described, the description covers the basics. However, it lacks details on pagination behavior (beyond page_size), combination logic for filters, and absence of any mention of error handling, which would be beneficial for completeness.
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 description coverage is 100% (all 7 parameters have descriptions). The description adds no extra meaning beyond the schema, merely listing top-level return fields. Baseline is 3 due to high coverage, and no additional parameter context is provided.
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: searching the PRIDE database for mass spectrometry proteomics projects using keywords and filters. It is distinct from sibling tools like bc_get_pride_project (retrieves a single project) and bc_search_pride_proteins (searches proteins), providing specific verb+resource differentiation.
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 searching PRIDE projects but does not provide explicit guidance on when to use this tool versus alternatives. No exclusions or context for sibling tools are mentioned, leaving the agent to infer based on 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?
No annotations are provided, so the description carries the burden. It discloses the return type (dict) and structure (class_type, field, available_classes, total_found/error). However, it does not mention if the operation is read-only or any prerequisites. The behavioral info is partial.
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 concise at three sentences, with the purpose stated first. Every sentence adds value: purpose, usage hint, and return format. No redundant or missing information, though minor trimming could be 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?
Given the simplicity of the tool (2 optional parameters) and the presence of an output schema, the description is largely complete. It covers the return structure and guidance to use first. However, it could elaborate on the source (FDA database) or typical use cases to fully compensate for the lack of annotations.
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?
Both parameters ('limit' and 'class_type') have comprehensive descriptions in the input schema (100% coverage). The description does not add additional meaning beyond the schema, so it meets the baseline. No extra elaboration on parameter usage is needed.
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: 'Get available pharmacologic classes from FDA database'. It uses a specific verb-resource pair and includes a usage hint. While it distinguishes from sibling tools by focusing on pharmacologic classes, it could be more explicit about its unique role.
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 explicitly suggests a usage order: 'Call this first to see available options.' This provides context for when to use the tool, though it does not include when-not-to-use or alternative tools. The hint is valuable for task sequencing.
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?
No annotations provided, so description carries full burden. It mentions return format with error handling, but does not disclose authentication needs, rate limits, or data volume. 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?
Two concise sentences with front-loaded action. No superfluous 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?
Low complexity with one parameter and output schema present. Description covers the essential but could mention XML parsing or size limits.
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 100% with description for pmc_id including an example format. The description adds no further semantics beyond the schema, so baseline score of 3 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 clearly states 'Get full-text XML for a PMC ID' with the specific verb 'Get' and resource 'full-text XML'. It distinguishes from sibling tools like bc_get_europepmc_articles which likely returns metadata.
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 on when to use this tool versus alternatives such as bc_get_europepmc_articles. No prerequisites or exclusions mentioned.
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?
With no annotations provided, the description should disclose behavioral traits like idempotency or authorization needs. It only describes return format, lacking context on side effects, rate limits, or 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 two sentences: purpose and return format. No wasted words, front-loaded, and efficient for rapid scanning.
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's simplicity (3 params, output schema exists), the description covers key aspects. However, the return description could be more detailed about error cases or pagination.
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 100% with each parameter described. The description adds marginal value beyond schema (e.g., example gene names) but does not significantly deepen 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 clearly states it searches OLS for GO terms related to a gene name, using structured vocabularies. It is specific and distinguishes from sibling tools like search_ontology_terms.
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 GO term lookups but does not explicitly state when to use this tool versus alternatives like bc_search_ontology_terms or provide exclusion criteria.
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?
No annotations are provided, so the description carries full burden. It discloses return format (dict with interpro_matches, domain_architecture, optionally structure data) but lacks details on performance, rate limits, or side effects. The read-only nature is implied but not explicit.
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 two sentences plus a return format snippet, providing essential information without unnecessary words. Information is front-loaded with the purpose.
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 full schema coverage and the presence of an output schema, the description adequately explains the tool's function and return structure. However, it could be more complete by explaining how it differs from related protein tools.
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?
All 4 parameters are described in the input schema (100% coverage). The description adds no additional meaning beyond reiterating that protein_id is required. Baseline score of 3 is appropriate.
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 retrieves protein domain architecture and InterPro matches, specifying the output includes interpro_matches, functional sites, and domain architecture. This distinguishes it from sibling tools like bc_get_uniprot_protein_info or bc_get_interpro_entry by focusing on domain architecture.
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 (e.g., bc_get_interpro_entry or bc_get_uniprot_protein_info). The description only states what it does, not context for selection.
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 indicates the tool returns paginated results with summaries and error messages, implying a read-only operation. However, with no annotations, it does not explicitly state whether it is safe (non-destructive), authentication needs, or rate limits, which are important for behavioral 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 concise with two sentences followed by a return format. The first sentence clearly states the purpose, and every piece of information contributes meaningfully 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?
Given the tool's moderate complexity (6 parameters, 1 required), full schema coverage, and presence of an output schema, the description covers the essential purpose and return structure. However, it lacks details on pagination behavior and error handling, which could be supplemented by the output schema.
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 100%, so the baseline is 3. The description adds little beyond the schema, only reiterating the condition parameter and summary output. It does not explain parameter interactions or provide examples, failing to add significant 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 verb 'search' and the resource 'trials by condition', and mentions summary statistics with breakdowns by status, study type, and phase. It differentiates from sibling tools like bc_search_studies or bc_get_studies_by_intervention by focusing on condition-based search with aggregated statistics.
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 over alternatives such as bc_search_studies or bc_get_recruiting_studies_by_location. It does not mention when not to use it or prerequisites, leaving the agent to infer usage from the name and 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?
Describes pagination and return dict structure (intervention, total studies, breakdowns, error message) but no annotations exist. Lacks details on data freshness, authorization, or side effects. Adequate but not comprehensive.
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?
Two sentences: first states purpose and filters, second describes return. No wasted words, highly efficient.
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 7 parameters and output schema existence, the description covers core functionality (intervention search, filters, paginated results with breakdowns). Could mention sort or intervention_type but those are in schema. Nearly complete.
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 100%, so parameters are documented. Description adds no additional meaning beyond schema, but reinforces that 'intervention' is the primary filter. Baseline 3 is appropriate.
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?
Clearly states 'Search trials by intervention' with specific filters (condition, phase), distinguishing it from siblings like bc_get_studies_by_condition and bc_search_studies. The verb 'Search' and resource 'trials' are explicit.
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 on when to use this tool versus alternatives such as bc_get_studies_by_condition or bc_recruiting_studies_by_location. Does not mention 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?
No annotations are provided, placing burden on the description. It states the tool queries an API and returns a dict, implying read-only operation, but does not explicitly mention side effects, authentication, or rate limits. Acceptable but 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 two sentences plus a return note, front-loaded with purpose. No redundant or missing information for the described functionality.
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 that an output schema exists (not shown but indicated), the description covers the essential return format. The tool is straightforward, and the description, while minimal, is complete enough for the intended use case.
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 100% and both parameters have adequate descriptions. The description does not add additional semantic information beyond what the schema provides, so baseline score applies.
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 'Execute GraphQL queries against the Open Targets API' with a clear verb and resource. It also directs to helper tools, but does not explicitly differentiate from sibling tools, which are more specialized.
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 advises using helper functions first, giving a prerequisite order. However, it lacks explicit guidance on when to use this tool versus sibling tools (e.g., for ad-hoc queries vs. dedicated get/search functions).
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?
With no annotations, the description carries the full burden. It discloses return format and rate-limiting risk, but does not state whether the operation is read-only, authentication requirements, or other behavioral aspects.
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 plus a warning and return type line, front-loaded with purpose, 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?
Given 3 parameters all documented and a return field list, the description is fairly complete. However, it lacks details on pagination or error handling, but is sufficient for most use cases.
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?
Input schema has 100% coverage with parameter descriptions. The description adds context about author syntax and warning, but adds little meaning beyond what the schema already provides.
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 'Search Google Scholar for publications' and highlights the specific author search syntax, making the tool's purpose distinct from sibling tools that focus on drugs and biomedical 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 includes a warning about responsible use and rate limiting, but does not provide explicit guidance on when to use this tool versus other alternatives or when not to use 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?
With no annotations, the description carries full burden. It states the tool searches OLS and returns a dict with efo_ids array or error message, indicating safe, read-only behavior. But it lacks details on rate limits, authentication requirements, or potential side effects, which is acceptable for this simple search but not fully transparent.
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 extremely concise: two short sentences and a returns section. It front-loads the primary action and purpose with no extraneous information. Every sentence earns its place.
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's simplicity (search, 3 parameters, no annotations, output schema present), the description covers the essential behavior and return format. It mentions error handling. The presence of an output schema likely provides additional details, so the description is sufficient without being verbose.
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?
All parameters are described in the input schema (100% coverage), but the description adds value by specifying that the search returns EFO/Mondo/HP IDs, which is not in the param descriptions. It frames the purpose of the parameters (e.g., search for disease name) effectively.
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 it searches OLS for EFO/Mondo/HP IDs related to a disease name and is used to get EFO IDs for Open Targets queries. However, it does not explicitly distinguish itself from similar sibling tools like bc_search_ontology_terms, which might also search for ontology IDs.
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?
It provides context by stating 'Use this to get EFO IDs for Open Targets queries,' implying when to use. However, it does not mention when not to use or provide alternatives, leaving room for confusion with other search 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?
With no annotations provided, the description carries the full burden. It discloses the return type (str or dict with error) and gives an example, but does not discuss potential behaviors such as handling multiple matches, rate limits, or authentication. The description is moderately transparent but could be more detailed.
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 concise with two sentences and a return specification. It front-loads the purpose and includes a brief justification. No unnecessary words, though the return format could be omitted if output schema is present.
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's simplicity and the presence of an output schema, the description covers the core functionality well. It explains what the tool does and what it returns, but could mention error handling or the role of the limit parameter. Overall, fairly complete.
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?
Input schema has 100% description coverage, so the schema already documents each parameter. The description adds no additional meaning beyond stating the function. Baseline score of 3 is appropriate.
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 maps protein identifiers to STRING database IDs, with specific input types and an example output. This distinguishes it from sibling tools that focus on interactions, networks, or other operations.
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 one needs a STRING ID, stating 'Using STRING IDs improves reliability.' However, it does not explicitly state when to use this tool versus alternatives like bc_get_kegg_id, nor does it provide 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?
No annotations are provided, so the description must fully convey behavioral traits. It states the return type (dict) and lists fields, which is good. However, it does not mention any side effects (likely none), rate limits, authentication needs, pagination, or error handling beyond 'error message'. The presence of an output schema (context signal) helps, but the description lacks depth on 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 extremely concise: two sentences and a return type line. It front-loads the main action and includes no unnecessary words. Every sentence provides essential information.
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 has 8 optional parameters, a description that mentions only 'keyword, agency, or other criteria' is somewhat vague. The output schema is present (context signal), but the description does not clarify how multiple filters interact (AND/OR), default behavior, or search scope. It is minimally complete for a search tool but lacks some contextual details.
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 description coverage is 100%, so the input schema already documents all 8 parameters. The description only adds 'keyword, agency, or other criteria' and does not elaborate on parameter usage, formatting, or constraints beyond what the schema provides. With full schema coverage, baseline is 3.
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 searches grants.gov by keyword, agency, or other criteria, and returns opportunity listings. It uses a specific verb 'Search' and resource 'grants.gov', and the tool's domain (grants) distinctly sets it apart from all sibling tools which focus on biomedical/drug/gene 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 does not explicitly state when to use this tool or when not to, nor does it mention alternatives. However, given the distinct domain of grants.gov compared to all sibling tools (which are about drugs, proteins, studies, etc.), usage is implicitly clear. No exclusions or preconditions are provided, so a score of 3 is appropriate.
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?
No annotations are provided, so the description must disclose behavioral traits. It states the return type (dict with paginated studies or error) and notes it's a search with filtering. However, it does not cover potential rate limits, authentication requirements, data freshness, or other behavioral aspects. The description is adequate but lacks depth.
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 extremely concise: two sentences plus a return type specification. Every sentence adds meaningful information with no superfluous content. The structure is clear and front-loaded with the main purpose.
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 complexity of 12 parameters and no required fields, the description provides the essential constraint and return format. An output schema is present, so return values are covered. However, it lacks guidance on pagination (e.g., how to get next page) and integration with other tools. It is nearly complete for a search tool.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by explicitly stating 'Specify at least one search parameter,' which enforces a constraint not present in the schema. This helps clarify usage beyond the parameter descriptions themselves.
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 it's an 'Advanced search for trials with flexible multi-field filtering,' which defines the purpose well. However, it does not explicitly differentiate from sibling tools like bc_get_studies_by_condition or bc_get_recruiting_studies_by_location, which are more specific. The name and description imply it's a general search, but no direct comparison is made.
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 provides the constraint 'Specify at least one search parameter,' which is a useful guideline. However, it does not mention when to use this tool versus the more specific sibling tools, nor does it provide any exclusions or prerequisites. Usage context is implied but not explicit.
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?
With no annotations, the description carries full burden and effectively discloses the two-step workflow, return type (dict with URLs, scores, metadata, or error). It clearly describes the behavior beyond just 'get info' by detailing the conversion and prediction steps.
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 very concise: two sentences state purpose and process, followed by a structured returns block. No unnecessary words; front-loaded with the main action.
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 description covers purpose, process, and output structure. It mentions error handling ('or error message'). However, it could explicitly note that it requires network access to query an external database, but this is implied. Overall complete for a query tool with a clear output schema.
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 100%, providing descriptions for both parameters. The tool description does not add additional parameter semantics beyond what the schema already offers (e.g., specifying that protein_symbol is used for UniProt conversion). Baseline 3 is appropriate.
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 queries AlphaFold using a protein name and explains the two-step process (converting symbol to UniProt ID, then fetching predictions). This distinguishes it from sibling tools like bc_get_uniprot_id_by_protein_symbol which only convert to UniProt 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 on when to use this tool vs alternatives like bc_get_uniprot_id_by_protein_symbol or bc_get_uniprot_protein_info. The description does not mention that this tool includes the UniProt lookup, so an agent might not know when to choose this over a simpler ID lookup.
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 mentions it returns a dict with counts or an error message, but it lacks explicit disclosure of side effects like being read-only, requiring authentication, or having rate limits. Since no annotations are provided, the description should cover these behavioral 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?
The description is extremely concise: two sentences plus a returns line. Every word adds value, no filler.
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 no parameters and an output schema, the description provides sufficient context on the return format. It could mention if any setup is needed, but overall it's complete enough.
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?
There are no input parameters, so the description's listing of output fields adds clarity beyond the empty schema. This compensates well for the lack of parameter 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 it returns general statistics about the FDA Drugs@FDA database and lists the specific fields included (sponsors, dosage forms, routes, marketing status). This distinguishes it from sibling tools that query specific drugs or fields, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for obtaining aggregate statistics, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., bc_count_drugs_by_field). No when-not-to-use or prerequisite information is given.
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?
No annotations provided, so description carries full burden. Only mentions return type (str or dict) without detailing error handling, side effects, or network 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?
Two concise sentences: first states purpose, second states return type. 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 two-parameter conversion tool, the description covers purpose and return type. Output schema exists, but description does not enumerate all possible responses. Still adequate.
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?
Input schema covers both parameters with descriptions. Tool description adds no extra meaning beyond schema, which is already descriptive. Baseline 3 due to high 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?
Clearly states the verb 'convert' and resource 'gene symbol to KEGG ID'. Emphasizes prerequisite role for query_kegg, distinguishing it from sibling tools like bc_get_string_id.
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?
Indicates use before query_kegg, providing clear context. No explicit when-not or alternatives, but sibling differentiation is implicit.
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?
With no annotations, the description must disclose behavioral traits. It specifies the return format (dict with markers array including gene symbols, cell types, organs, scores) and mentions error messages, but does not cover side effects, authentication, rate limits, or pagination. It is adequate but not comprehensive.
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 concise, with a clear first sentence stating the core function, followed by a list of filters and a return description. No unnecessary words, well-structured for quick parsing.
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 6 parameters with optional filters and an output schema, the description covers the return format and filter options well. However, it does not mention behavior when filters yield no results, defaults, or error handling specifics, leaving minor gaps.
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 description coverage is 100%, so the description adds little beyond restating the filter types (species, scores, organ, cell type, gene symbol). It does not provide examples or explain relationships between parameters, making it baseline adequate.
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 retrieves marker genes from the PanglaoDB dataset, specifying the data source and optional filters. It distinguishes itself from sibling tools that focus on drugs, proteins, and other biomedical data, leaving no ambiguity about its purpose.
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 retrieving marker genes with filters but does not explicitly state when to use this tool versus alternatives, nor does it provide context on appropriate use cases or limitations. The purpose is clear from sibling names, but explicit guidance is lacking.
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?
With no annotations, the description carries full burden. It discloses the return format (list/dict with specific fields) and mentions possible error messages. However, it does not state that the tool is read-only, whether it calls an external API, or any side effects. The behavior is inferable but not explicitly transparent.
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 two sentences plus a returns section, all front-loaded. Every sentence provides necessary information without extraneous words. The structure is efficient 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?
Given the tool has 3 parameters and no output schema, the description adequately explains the return fields (stringId_A, score, etc.) and usage requirement (species). It could be improved by naming the underlying database (STRING) to better distinguish from other protein interaction tools, but overall it is fairly complete.
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?
Input schema has 100% coverage for all three parameters. The description adds little beyond the schema: it reiterates the species requirement and implies the threshold concept, but these are already covered. No new parameter meaning is added, so baseline score of 3 is appropriate.
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 protein-protein interactions for a given protein with a score threshold, which distinguishes it from siblings like bc_get_string_id (ID lookup) and bc_get_string_network_image (image generation). The verb 'retrieve' and resource 'protein-protein interactions' are specific and 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 instructs 'Always provide species parameter', which is a usage guideline. However, it does not explain when to use this tool versus alternatives like bc_get_string_similarity_scores or bc_get_string_network_image, nor does it mention conditions where it should not be used.
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?
No annotations are provided, so the description bears full burden. It discloses the return type (image or dict/error) and the mandatory parameter. However, it lacks details on potential side effects, authentication requirements, or rate limits. Given the simplicity of the tool, the transparency is adequate but not comprehensive.
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 extremely concise: two sentences and a return line with no extraneous information. Every part adds value, and it is front-loaded with the core purpose.
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 there is no output schema, the description adequately explains the return format (image or dict error). The tool is simple, and the description covers the essential behavioral context. It could mention the flavor and min_score parameters, but those are already fully described in the schema.
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?
All 4 parameters have descriptions in the input schema, resulting in 100% schema coverage. The description does not add significant new meaning beyond restating the need for the species parameter. Per criteria, baseline is 3 when schema coverage is high.
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 'Generate protein-protein interaction network image from STRING database', specifying both the action and the resource. It distinguishes from sibling tools like bc_get_string_interactions (returns data) and bc_get_string_similarity_scores (returns scores), making it easy to select for visual output.
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 provides one guideline: 'Always provide species parameter.' However, it does not explicitly state when to use this tool versus alternatives like bc_get_string_interactions for data or bc_get_string_id for identifiers. The context is implied but not directly 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?
No annotations provided, so description carries full burden. It discloses the score threshold and return types (list or dict) but omits details like authentication, rate limits, or side effects. Adequate but not comprehensive.
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?
Description is very concise: three sentences with no redundant information. First sentence front-loads the core purpose. Every sentence adds value without extraneous text.
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 3 parameters, 2 required, and an output schema exists, the description covers key aspects: purpose, threshold, and return structure. Minor gaps like missing example usage or format details prevent a perfect score.
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 100% with clear descriptions for each parameter (e.g., 'First protein symbol (TP53)'). The description adds context about Smith-Waterman bit scores but does not enhance parameter meaning significantly, so baseline 3 is appropriate.
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 'Retrieve' and specifies the resource: protein homology similarity scores from STRING database. It distinguishes from sibling tools like bc_get_string_interactions by focusing on Smith-Waterman bit scores with a threshold.
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 on when to use this tool vs alternatives. The threshold constraint ('Only scores above 50 reported') is mentioned but not tied to usage contexts. Implied purpose but lacks comparative directives.
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?
Without annotations, the description solely bears the responsibility for behavioral disclosure. It states the tool retrieves study details and returns a dictionary, which implies a read-only operation. However, it does not mention any potential side effects, authentication needs, rate limits, or other behavioral traits beyond the basic read action.
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 very concise, consisting of two sentences and a return type definition. It is front-loaded with the main action and avoids unnecessary words or repetition.
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 presence of an output schema, complete schema descriptions, and only two parameters, the description covers the essential aspects. It clearly states the purpose and return structure. A minor gap is the lack of mention that it is for a single study and requires an exact NCT ID, but overall it is sufficiently complete.
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?
With 100% schema description coverage, the baseline is 3. The description adds minimal value beyond the schema; it reiterates that the tool retrieves details by NCT ID but does not explain the fields parameter in more detail or provide usage examples. The schema already documents the parameters sufficiently.
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 explicitly states the verb 'Get', the resource 'complete trial details', and the method 'by NCT ID'. It lists the types of data retrieved (study design, eligibility, etc.), distinguishing it from sibling tools like bc_search_studies that return lists rather than complete details.
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 mentions using an NCT ID but does not provide guidance on when to use this tool versus alternatives such as bc_search_studies or bc_get_recruiting_studies_by_location. No exclusions or prerequisite information is given, leaving the agent to infer the appropriate 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?
No annotations are provided, so the description must cover behavioral traits. It explains that the tool returns a dict with parent term, children array, total_children, page_info, or error message. However, it does not disclose potential large payloads, rate limits, authentication needs, or details about pagination beyond mentioning 'page_info'. The description is adequate but could be more transparent.
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 extremely concise: a single sentence for purpose and a short list for return values. No unnecessary words, and the most critical information is front-loaded. Every sentence contributes value.
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 that an output schema exists (per context signals), the description's coverage of return structure is good. It explains the main components but could elaborate on what 'hierarchical children' entails (e.g., subclasses vs. other relationships). For a simple retrieval tool, it is mostly complete.
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?
Input schema coverage is 100% with good descriptions for all three parameters. The description does not add new meaning beyond the schema; it only restates the return structure that includes page_info, which indirectly relates to the 'size' parameter. With high schema coverage, baseline is 3, and no extra semantic value is provided.
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 hierarchical children of an ontology term from OLS, using specific verbs and resource. It is easily distinguishable from sibling tools like bc_get_term_details (which likely returns flat details) and bc_search_ontology_terms (which searches for terms).
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 getting hierarchical children but provides no explicit guidance on when to use this tool over alternatives, nor does it mention exclusions or prerequisites. Sibling tools exist but no comparative advice 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?
No annotations provided, so description must cover behavioral traits. Returns primary accession or None, but does not disclose behavior on multiple matches or error cases. Adequate but 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?
Two sentences, front-loaded with purpose, no wasted words. Perfectly concise.
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 simple 2-parameter tool with output schema, description covers the essential purpose and return value. Could mention default species behavior, but overall complete.
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 100%, so description adds little beyond schema. It restates that it uses protein name and species, but no additional formatting or constraints beyond 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?
Clearly states it retrieves a UniProt accession ID from protein name and species, specifies return type as string or None, and the name differentiates it from sibling bc_get_uniprot_protein_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?
Implied usage: when you need an accession ID from protein name. No explicit when-not-to-use or alternatives mentioned, which would be helpful given siblings like bc_get_uniprot_protein_info.
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?
No annotations are provided, so the description carries full burden. It describes the return format (results, count, total_available, search_criteria or error) but does not explicitly state the tool's read-only nature or any side effects, which is adequate for a search tool.
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 two sentences plus a Returns section, front-loaded with the main purpose, concise with no wasted words, and effectively communicates 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?
Given the tool's complexity (6 optional parameters) and presence of an output schema, the description covers the main search functionality and output structure. However, it omits mention of pagination (page_size parameter) and how filters combine, leaving minor gaps.
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?
With 100% schema coverage and parameter descriptions, the description adds modest value by listing searchable criteria (name, type, database, GO term, species) that correspond to parameters, but does not significantly enhance understanding 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 clearly states 'Search InterPro entries' with specific criteria (name, type, database, GO term, or species), distinguishing it from sibling tools like bc_get_interpro_entry which retrieves a single entry.
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 searching by various criteria but does not explicitly address when to use this tool versus alternatives, nor does it provide when-not-to-use guidance or mention bc_get_interpro_entry as a better fit for known entries.
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?
With no annotations provided, the description carries the full burden. It clearly states the output format (dict with term and count) and indicates it operates on FDA-approved drugs. Though it doesn't discuss side effects, the operation is inherently non-destructive.
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 extremely concise with two sentences plus a return note. Every sentence adds value: purpose and utility upfront, then output format. No wasted words.
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, the description covers the essential behavior and output. The presence of an output schema (indicated by context) reduces the need for additional detail. The description is complete for an agent to understand and invoke the tool.
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 description coverage is 100%, so the description adds little beyond what the schema already provides. The description does not elaborate on parameter behavior or constraints beyond the schema examples.
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 ('Count unique values') and resource ('in a field across FDA-approved drugs'), with a hint of utility ('Useful for statistical analysis'). It does not explicitly distinguish from sibling tools, but the purpose is 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 usage for statistical analysis but lacks explicit guidance on when to use this tool versus alternatives like bc_get_drug_statistics or bc_search_drugs_fda. No exclusions or context 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?
With no annotations, the description carries full burden. It only describes return structure (dict mapping categories), lacking side effects, rate limits, or authorization needs. The read-only nature is implied but not confirmed.
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?
Two sentences plus return type line, front-loaded with key info. No redundant or missing words.
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 output schema exists, the description adequately covers the tool's purpose and return format. The tool is simple (no parameters), and nothing critical is omitted.
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?
No parameters exist, so baseline is 4. Description adds value by specifying the return shape (mapped by category) and listing example categories, which aids understanding 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 clearly states the verb 'retrieve' and resource 'example GraphQL queries for the Open Targets API', distinguishing it from siblings like bc_query_open_targets_graphql and bc_get_open_targets_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 use for obtaining example queries, but does not explicitly state when to use this tool versus alternatives like executing queries or getting schema. No exclusions are 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?
With no annotations, the description must fully disclose behavior. It states it returns a dict or error message, which is adequate for a simple retrieval tool with no parameters. However, it does not mention side effects, authentication needs, or rate limits, which are likely not applicable but not explicitly 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 two sentences: the first sentence states the purpose, the second describes the return value. No unnecessary words, front-loaded, and easy to parse.
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 has zero parameters, an output schema, and a straightforward purpose, the description fully covers its functionality. The return type and source (PanglaoDB dataset) are mentioned, making it complete for selection and invocation.
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?
There are no parameters, and schema coverage is 100% (vacuous). Per rules, baseline is 3. The description adds no parameter information because none is 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 states the verb 'Retrieve' and resource 'available filter options for PanglaoDB marker genes', and specifies the return values 'organs and cell types'. It is specific and clearly distinguishes from sibling tools like bc_get_panglaodb_marker_genes.
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 provides filter options, likely for use before querying marker genes, but does not explicitly state when to use it versus alternatives such as bc_get_panglaodb_marker_genes. No direct usage or exclusion instructions are 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?
No annotations, and the description does not disclose safety or side effects. It is a read operation but lacks explicit statements about permissions or data freshness.
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?
Two sentences, clear and to the point. Slight redundancy with return type paragraph but overall efficient.
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?
Covers key return fields and optional parameters. Lacks detail on error conditions, but acceptable for a simple retrieval tool.
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?
Schema coverage is 100%, but the description adds useful limits for include_files (first 20 files) and include_similar_projects (limited to 10), which are not 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 states it retrieves detailed information about a specific PRIDE project by accession. It distinguishes from sibling search tools that find projects by query.
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 on when to use this tool versus search tools. Usage is implied but not directly stated.
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?
No annotations are provided, so the description carries full burden. It mentions using OLS, a controlled vocabulary, and specifies the return structure (dict with cl_terms array). However, it does not discuss error cases or rate limits, which would enhance 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 very concise: a single sentence stating purpose, followed by a bullet list of return fields. No redundant information, and the purpose is front-loaded.
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 3 parameters and an output schema, the description adequately covers purpose, source (OLS), and return format. It mentions controlled vocabulary. With output schema present, no need to detail return values further. Could mention search behavior nuances, but sufficient overall.
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 100%, so the description does not add parameter semantics beyond what the schema provides. The schema descriptions are clear, so the baseline score of 3 is appropriate.
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 searches OLS for Cell Ontology (CL) terms, specifying the controlled vocabulary for cell types. This distinguishes it from sibling tools like bc_search_ontology_terms (which searches all ontologies) and bc_get_term_details (which retrieves specific term details).
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 indicates use for cell type terms but provides no explicit guidance on when to use vs alternatives (e.g., other ontology search tools). No when-not-to-use or alternative recommendations are given, which is a gap given many sibling tools.
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?
No annotations are provided, so the description carries full burden. It does not disclose if the operation is read-only, authentication requirements, or behavior on invalid input. The return type is mentioned but lacks deeper 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states action and output types, second specifies parameter condition. No fluff, front-loaded with key info, and includes return structure.
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?
Has output schema (summarized in description), parameter descriptions are complete, and usage condition is clear. Lacks examples or edge-case handling, but is sufficient for a simple retrieval tool.
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?
Schema descriptions already cover both parameters (100% coverage). The description adds value by clarifying the mutual exclusivity ('either') role, which is not captured in the required array (which lists both).
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 resource ('Human Protein Atlas information'), and clearly distinguishes this tool from sibling tools that deal with drugs, KEGG, STRING, etc.
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?
It states 'Provide either gene_id or gene_symbol,' giving clear parameter usage condition. While it doesn't explicitly list when not to use, the unique domain makes it clear that this tool is for Human Protein Atlas queries only.
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?
With no annotations provided, the description carries the burden of disclosing behaviors. It clearly states that the tool returns metadata and optionally includes interactions, pathways, and cross-references based on parameters. It also mentions an error message in the return dict. While it does not explicitly state read-only behavior or rate limits, it sufficiently describes the tool's operation and output for an agent to understand its effects.
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 very concise: two sentences plus a short bulleted return list. The first sentence front-loads the core purpose and resource, the second adds context about member databases, and the returns section is clearly formatted. Every sentence earns its place without waste.
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 that an output schema exists, the description appropriately covers return values with a high-level summary. It describes the main fields (name, type, description, member databases, optional extras, error message). For a tool with 4 parameters and no nested objects, this is sufficiently complete. Minor omissions like error handling details are acceptable.
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 100%, so description adds minimal extra meaning beyond the schema. The description mentions optional inclusions (interactions, pathways, cross-references) which correspond to the boolean parameters, but this information is already present in the schema descriptions. No deeper semantics or usage tips are provided.
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 gets InterPro entry details for families, domains, or functional sites, and specifies the resource (InterPro entry) and action (get). It implicitly distinguishes from sibling tool bc_search_interpro_entries which is for searching, making the purpose specific and unique.
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 a specific InterPro ID is known to retrieve metadata, but does not explicitly state when to use this tool versus alternatives like bc_search_interpro_entries. No guidance on prerequisites or exclusion criteria is provided, leaving usage context largely implied.
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?
No annotations are provided, so the description carries the full burden. It discloses the return type (dict with listed fields) and mentions possible error messages, but does not state whether the operation is read-only, requires authentication, or how it handles missing data. Acceptable for a retrieval tool but could be more explicit.
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?
Description is extremely concise: two sentences plus a returns line. No redundant information. Every sentence serves a purpose, and the key constraint is front-loaded. Ideal length for quick understanding.
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 presence of an output schema (context signal), the description does not need to fully explain return values, but it still lists key fields. However, it could mention the usage of the 'species' parameter to narrow results. Overall, adequate for the tool's complexity.
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?
Schema description coverage is 100% (all 5 parameters have descriptions). The description adds value by specifying that at least one of protein_id, protein_name, or gene_symbol must be provided, which is not enforced by the schema (all optional). This helps the agent understand the constraint.
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 action ('Retrieve protein information') and the resource ('UniProt database'). It specifies the key parameters (protein_id, protein_name, gene_symbol) and differentiates from sibling tools like bc_get_uniprot_id_by_protein_symbol by focusing on full info retrieval.
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?
Description advises 'Provide at least one of protein_id, protein_name, or gene_symbol', which is a usage constraint. However, it does not explicitly compare to sibling tools or state when to use this tool versus alternatives (e.g., bc_get_protein_domains, bc_get_human_protein_atlas_info).
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?
With no annotations, the description carries the full burden. It mentions the return structure (Terms array, etc.) and that it can return an error message, but does not state whether it is read-only or has side effects. Some transparency is added, but more context on behavior would be beneficial.
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 two sentences plus a returns block, all front-loaded with the main action. No extraneous words, and the structure efficiently conveys purpose, precondition, and output format.
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 an output schema and 100% parameter coverage, the description is fairly complete: it states the action, necessary prerequisite, and high-level return structure. It could mention read-only nature, but overall it is sufficient for an agent.
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 100%, and the schema descriptions are already detailed (e.g., 'Comma-separated ontology IDs...'). The description does not add new parameter-level meaning beyond what the schema provides, so baseline 3 is appropriate.
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 starts with 'Search for terms across multiple ontologies in OLS,' which is a specific verb+resource. It also instructs to use get_available_ontologies() first, distinguishing it from tools that search within a single ontology or retrieve details for a known term.
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 explicitly tells the agent to use get_available_ontologies() first, providing a clear precondition. It does not explicitly state when not to use it (e.g., for known ontology-specific searches), but the sibling tools imply alternatives.
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?
No annotations are provided, so the description carries full burden. It describes the return format as a dict but does not disclose potential side effects, error conditions, or read-only nature. It is adequate but lacks detail on behavior beyond the return.
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 very concise: two sentences and a return type line. Every sentence is valuable and front-loaded with the main purpose. 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?
Given 5 parameters, an output schema, and no annotations, the description is mostly complete: it explains the main purpose and return format. It does not explain how optional parameters like keyword or sorting work, but these are covered by schema. Slightly lacking in contextual depth.
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 description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema descriptions; it does not elaborate on how parameters interact or provide examples.
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 identifies the tool as searching for proteins within a specific PRIDE mass spectrometry project. It uses specific verbs ('Search for') and resources ('proteins identified in a specific PRIDE mass spectrometry project'), and it is well-distinguished from sibling tools like bc_search_pride_projects and bc_get_pride_project.
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 states the tool is 'useful for finding specific proteins in proteomics datasets,' which implies when to use it. However, it does not explicitly mention when not to use it or provide alternatives among siblings, lacking full 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?
No annotations are provided, so the description bears the burden. It states that a dict of details is returned, but does not disclose read-only behavior, permissions, rate limits, or failure modes. The tool is likely read-only, but this is not explicitly 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?
Two concise sentences plus a Returns section with no filler. Information is front-loaded and each sentence adds value.
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 (one parameter), output schema existence, and lack of complex behavior, the description fully covers what an agent needs to select and invoke it correctly.
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 description coverage is 100%, so the schema already explains the parameter. The description adds no new meaning about `ab_id` beyond 'by ID', which is redundant. The return value list is helpful but does not enhance 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 clearly states it retrieves detailed antibody information by ID, listing specific fields like catalog number and vendor. It distinguishes from sibling bc_get_antibody_list, which likely provides a list rather than details.
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 use when an antibody ID is available, but does not explicitly mention when not to use it or suggest alternatives like bc_get_antibody_list for searching. However, the context is clear enough for a focused 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 description discloses it searches ANDA entries, implying a read operation. However, it does not detail any behavioral traits like required permissions or limitations, such as requiring exact brand name matching.
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 concise with two clear sentences: one for purpose and one for return structure. No unnecessary words.
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, the description explains the return format and the search logic, making it complete for the agent's selection and invocation.
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 100%, and the description adds context ('brand name drug') but does not significantly enhance meaning beyond the schema's description.
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 'Find generic equivalents for a brand name drug' and specifies the resource (ANDA entries). It effectively distinguishes from sibling tools like bc_get_drug_by_application_number and bc_search_drugs_fda.
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 indicates when to use the tool (when you have a brand name drug and need generics), but lacks explicit guidance on when not to use it or alternatives.
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?
No annotations are provided, so the description carries full burden. It details the return structure (dict with server, search_params, etc.) and mentions pagination. However, it omits potential rate limits, error conditions, or any read-only guarantees.
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 concise with two paragraphs: first states purpose, second explains return. It is front-loaded and efficient, though a more structured format (e.g., bullet points) could improve clarity.
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 8 parameters and an output schema, the description adequately covers search methods and return format. However, it could be more complete by mentioning error handling, edge cases, or how this tool relates to bc_get_biorxiv_preprint_details given the many sibling tools.
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?
Schema description coverage is 100%, so baseline is 3. The description adds value by specifying the mutual exclusivity of search methods (date range, days, recent_count) and summarizing the return format, which is not 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 states the tool searches bioRxiv/medRxiv preprints by date range or recent count, with a specific verb and resource. It differentiates from sibling tools like bc_get_biorxiv_preprint_details, which likely handles individual preprint details.
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 instructs to specify one search method (date range, days, or recent_count) but does not provide explicit context on when to use this tool over siblings or what not to do. No alternatives are mentioned, leaving the agent to infer usage.
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?
No annotations are provided, so the description must convey behavioral traits. It discloses the return format (dict with details or error message) and hints at read-only behavior by listing fields. However, it does not explicitly state it is a non-destructive read operation or note any authentication requirements.
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 concise, with two sentences and a return type specification. No unnecessary words; the purpose is front-loaded.
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 that output schema exists (not shown but context confirms), the description is complete for a simple retrieval tool with two well-documented parameters. It lists all relevant fields returned and mentions error handling.
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 100%, so the description adds little beyond what the schema already provides. The schema already describes term_id as CURIE format and ontology_id with examples. The description does not introduce new parameter 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 clearly states it retrieves comprehensive details about a specific ontology term, listing definition, synonyms, hierarchical relationships, and num_descendants. This distinguishes it from sibling tools like 'bc_search_ontology_terms' (search-oriented) and 'bc_get_term_hierarchical_children' (only children).
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 a term_id and ontology_id are known, but it does not explicitly state when to use this tool versus alternatives, nor does it provide conditions or exclusions. For example, it could mention to use 'bc_search_ontology_terms' if the term ID is unknown.
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 description discloses return type ('Raw text response... or error dict'), which is helpful. No annotations exist, so description carries burden; it mentions the dependency which is a behavioral trait. Could be improved by noting potential side effects or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus return statement; no wasted words. Front-loaded with purpose and prerequisite. Highly concise.
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's complexity (7 parameters, many enums) and existence of output schema, the description is adequate but lacks guidance on parameter combinations or query construction. It covers basic use but leaves gaps for complex scenarios.
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 description coverage is 100%, so parameters are well documented in schema. The description adds minimal extra meaning beyond stating the tool's flexibility and prerequisite, so baseline 3 is appropriate.
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 'Execute flexible KEGG API queries across pathways, genes, compounds, diseases, drugs,' using specific verb and resource. It distinguishes from sibling tools by referencing get_kegg_id_by_gene_symbol() as a prerequisite.
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 instructs use of get_kegg_id_by_gene_symbol() first, providing prerequisite context. However, it lacks explicit when-not scenarios or alternative tools for specific operations.
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?
No annotations are provided, so the description carries the full burden. It describes the return data but does not disclose behavioral traits like idempotency, external dependencies, or error handling beyond mentioning an error message. This is adequate but 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 extremely concise: two purpose-oriented sentences plus a return format. It is front-loaded and contains zero 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?
Given the lack of parameters and the existence of an output schema, the description is fairly complete. It covers purpose, usage order, and return structure. It could mention potential latency or external service dependencies, but it is sufficient for a simple listing tool.
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?
With zero parameters and 100% schema coverage, the description does not need to add parameter information. Baseline for 0 parameters is 4, and the description is sufficient.
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 queries OLS for all available ontologies with metadata, and explicitly positions it as a first step to discover ontologies, distinguishing it from sibling tools that require an ontology ID.
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 says 'Use this first to discover available ontologies,' providing clear context for when to use it. It does not explicitly mention alternatives or when not to use it, but the sibling tools context implies it is for discovery before other ontology-specific operations.
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?
No annotations are provided, so the description carries full burden for behavioral transparency. It discloses that the tool returns search results with specific fields (title, authors, abstract, etc.) and error messages, but it does not mention rate limiting, pagination behavior, or handling of empty results. The disclosure is basic but not fully comprehensive.
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 very concise, with only two sentences for the purpose and a clear list of return values. Every sentence is necessary and no fluff.
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 that there is an output schema, the description sufficiently covers the core functionality of searching articles across multiple fields. It mentions the return structure (resultList with article details) and the ability to combine terms. However, it omits details about the sort_by parameter and the maximum page_size, which are covered in the schema. Overall, it is complete for a search tool of moderate complexity.
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?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining how to combine search terms and what the return format contains, going beyond the individual parameter descriptions in the schema. However, it does not add detailed semantics for each parameter, such as sort_by options.
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: 'Search Europe PMC articles by query, title, abstract, or author.' It uses specific verbs ('Search') and resources ('Europe PMC articles'), distinguishing it from siblings like bc_get_europepmc_fulltext which retrieves full text rather than searching.
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 usage guidance by mentioning combining search terms with 'and'/'or' logic, but it does not explicitly state when to use this tool versus sibling search tools like bc_search_studies or bc_search_google_scholar_publications. The guidance is present but lacks exclusions or alternatives.
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?
No annotations are provided, so the description is the sole source of behavioral info. It mentions returning a dictionary with FDA results or an error, but does not disclose rate limits, authentication needs, or what happens with invalid terms. Adequate but not comprehensive.
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 extremely concise: two sentences covering purpose, prerequisite, and return value. No unnecessary words, 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?
Given the sibling tools, this focused search is well-defined. The output schema exists (though not visible), and the description indicates the content of the return object. Minor gaps (pagination, error types) but overall sufficient.
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?
Input schema has 100% coverage, so baseline is 3. The description adds value by reiterating the prerequisite for the therapeutic_class parameter, which is not in the schema, thus enhancing understanding beyond the schema alone.
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 searches for drugs by therapeutic or pharmacologic class, distinguishing from siblings like bc_search_drugs_fda by specifying the search criterion.
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 explicitly advises using get_available_pharmacologic_classes() first for exact terms, providing clear context on prerequisites. It lacks explicit when-not-to-use guidance but is otherwise helpful.
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?
Describes return format (dict with 'schema' key or error message). No annotations, but simple read operation; no side effects mentioned but no hidden behaviors expected.
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?
Two sentences, front-loaded purpose, no waste. Highly concise and well-structured.
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?
Describes purpose and return value adequately. Simple tool with no parameters; output schema existence adds structure but description covers it.
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?
No parameters, so schema coverage is irrelevant. Description adds no param detail but also no need, baseline 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?
Clearly states the action ('Retrieve') and resource ('Open Targets GraphQL schema'), with context 'for query construction' distinguishing it from siblings like bc_query_open_targets_graphql.
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?
Implies usage via 'for query construction' but lacks explicit when-to-use or alternatives. No guidance on when not to use.
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?
With no annotations, the description carries the burden. It discloses that the tool returns a dict with application details, products, sponsor info, or an error message. It does not explicitly state it's read-only, but the 'Get' verb implies a safe read operation. The return type and possible error are mentioned.
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?
Two sentences: first states purpose and input format, second describes return. No redundant words. Front-loaded with key information.
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 (single parameter, simple lookup) and presence of an output schema (so return structure can be inferred), the description is complete. It covers input format, what the tool does, and the type of output.
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 schema already describes the parameter with examples. The description adds the formatting rule 'NDA/ANDA/BLA followed by 6 digits', which adds clarity beyond the schema examples. Schema coverage is 100%, so the baseline is 3; the added format specifier raises it to 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 clearly states the verb 'Get' and resource 'detailed information about an FDA-approved drug', and specifies the input format (application number with prefix and 6 digits). It distinguishes from sibling search tools (e.g., bc_search_drugs_fda) by indicating this is a direct lookup by application number.
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 use when you have an application number in the correct format. It does not explicitly state when not to use or provide alternatives, but the sibling tools include search functions, making the context clear.
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:

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

Score Badge

Copy to your README.md:

[![knowledgebase-mcp MCP server](https://glama.ai/mcp/servers/biocontext-ai/knowledgebase-mcp/badges/score.svg)](https://glama.ai/mcp/servers/biocontext-ai/knowledgebase-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/biocontext-ai/knowledgebase-mcp'

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