BioCosm
Server Details
Biotech intelligence for AI agents: drugs, targets, diagnostics, PoS estimates, and writeups.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 13 of 13 tools scored. Lowest: 2.9/5.
Each tool targets a distinct query or retrieval purpose: finding by phase, target, related entities, company portfolio, coverage, node details, freshness, probability of success, staleness, stats, writeups, listing by therapeutic area, and general search. There is minimal overlap, and any potential confusion (e.g., search_nodes vs find_by_target) is resolved by explicit descriptions.
Tool names follow a consistent verb_noun pattern using snake_case (e.g., find_by_phase, get_node, list_by_therapeutic_area). Prepositions like 'by' and 'for' are used uniformly. No mixing of conventions like camelCase or inconsistent verb forms.
With 13 tools, the count is within the ideal range for a focused biomedical database API. Each tool addresses a specific query or retrieval need without redundancy, making the set cohesive and manageable for an agent.
The tool set covers the full lifecycle of querying the BioCosm database: search, list by various criteria, retrieve detailed node information, freshness and staleness metrics, probability-of-success scores, writeups, and overall stats. No obvious gaps are present for a read-only knowledge graph API.
Available Tools
13 toolsfind_by_phaseBInspect
List drugs/diagnostics at a specific clinical phase.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (default 100, max 500) | |
| phase | Yes | One of "approved", "on_market", "phase3", "phase2", "phase1", "in_development", "cleared", "ldt", "ruo" | |
| node_type | No | Optional filter — "drug", "pipeline", "diagnostic", "target" |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only states 'List' but does not disclose behavioral traits such as pagination default (limit), performance implications, or whether results are limited to a single phase. Output schema exists but description does not hint at return format or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information. No wasted words. Efficient and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, an output schema, and no annotations, the description is minimal. It covers the primary purpose but omits usage context (e.g., node_type optional filter, default limit) that would help an agent avoid errors. Siblings are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add extra meaning beyond what the schema already provides for parameters like 'phase', 'limit', and 'node_type'. It does not explain the relationship between phase and other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List' and resource 'drugs/diagnostics', with clear focus on 'specific clinical phase'. This directly distinguishes from sibling tools like 'find_by_target' (which filters by target) and 'search_nodes' (which is broader).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention that it's only for phase-based filtering, nor does it point to siblings like 'find_by_target' for other filter types. The description assumes the agent already knows the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_by_targetBInspect
Find all drugs that target a specific gene/protein.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (default 50, max 200) | |
| target_gene | Yes | Gene symbol or target name (e.g. "EGFR", "KRAS", "PD-1") |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It only states the basic action, omitting details like read-only nature, pagination, ordering, or what happens with no results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words. Front-loaded with the key action and input.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and two well-documented parameters, the description lacks context on result format, usage scenarios, or how it differs from similar tools given 12 siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds drugs targeting a specific gene/protein, using a specific verb ('Find') and resource ('drugs'). It distinguishes from siblings like find_by_phase which filter by phase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like find_by_phase or search_nodes. Implicit but lacking 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.
get_company_portfolioCInspect
Get a company's full drug/diagnostic portfolio from BioCosm.
| Name | Required | Description | Default |
|---|---|---|---|
| company_name | Yes | Company name (e.g. "Merck", "Roche", "Illumina") |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states 'Get' without clarifying behavioral aspects such as read-only nature, authorization requirements, or data freshness. The term 'full' is ambiguous and could imply different scopes (all phases? all research stages?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that conveys the core purpose. It is front-loaded with the action and object. However, it could be slightly more structured by adding a brief note on what the portfolio includes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter) and existence of an output schema, the description is minimally adequate. However, it lacks details on the scope of the portfolio (e.g., includes diagnostics? all therapeutic areas?) which an output schema might cover, but the description should clarify.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, so the schema already provides semantic meaning. The description adds 'company's full drug/diagnostic portfolio' context but does not elaborate on what 'full' entails beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a company's full drug/diagnostic portfolio from BioCosm. It specifies the resource (portfolio), action (get), and source (BioCosm). While not explicitly differentiating from siblings, the sibling tools focus on other aspects (phases, targets, coverage), so this tool's purpose is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., list_by_therapeutic_area, search_nodes). There are no prerequisites, context, or examples to help the agent decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_coverageAInspect
Report BioCosm's actual data coverage so you never mistake missing data for a real-world zero. An empty or absent field on a node means "not in BioCosm's data," never a true zero. BioCosm is AI-generated and may contain errors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that BioCosm is AI-generated and may contain errors, and that empty fields are not zeros. This provides important behavioral context beyond what annotations would cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences that get straight to the point, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (no parameters, output schema exists), the description fully covers the essential nuance. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description logically adds no parameter info. Schema coverage is 100%, baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: reporting BioCosm's actual data coverage, and distinguishes it from siblings by specifying the nuance about missing data not being zeros.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: to check if data is missing or a real zero, and warns against mistaking absent data for zeros.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_nodeAInspect
Get full details for a single BioCosm node: identity and all name aliases, classification, gene targets and mechanism, therapeutic areas, companies, revenue history where available (sparse: ~100 drugs, mostly blockbusters, as annualized quarterly estimates; source links when present), probability-of- success predictions for pipeline drugs (with confidence intervals and contributing factors), structured clinical trial outcomes, external cross-references, and writeup availability. Empty fields mean "not in BioCosm's coverage," NOT zero or absent in reality.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes | The node identifier (e.g. "pembrolizumab", "trastuzumab") |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that revenue history is sparse and incomplete, explains that empty fields indicate lack of coverage not actual values, and notes data sources. This provides good transparency about data quality and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence conveys essential information. It is front-loaded with the core purpose and then lists specifics. Not overly verbose, though minor trimming could be possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-node detail retrieval tool with an output schema (external), the description covers all important aspects: what data is returned, caveats about sparseness and coverage, and cross-references. It is fully 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter (node_id) with examples, achieving 100% coverage. The description adds no further semantic detail about the parameter beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get full details for a single BioCosm node' and enumerates the specific data fields (identity, aliases, classification, etc.), making the tool's purpose clear and distinct from siblings that focus on search, listing, or filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when full details for a single node are needed, but does not provide explicit guidance on when to choose this over sibling tools like search_nodes or find_by_target, nor does it mention 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.
get_node_freshnessAInspect
Get freshness details for a single node: writeup age, enrichment hash match, staleness score, validation score.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes | The node identifier (e.g. "pembrolizumab") |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like side effects or permissions; it only lists output components, leaving safety profile and constraints unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the purpose, no wasted words; appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param) and presence of output schema, the description adequately summarizes what the tool provides, though it omits prerequisites like node existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and provides an example; the description adds value by enumerating the freshness components returned, giving more meaning than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets 'freshness details for a single node' and lists specific metrics (writeup age, enrichment hash match, staleness score, validation score), clearly distinguishing it from siblings like get_node or get_staleness_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives such as get_node or get_staleness_report; context signals show many siblings but the description offers no selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pos_scoreAInspect
Get the Probability of Success estimate for a node, including the base rate, adjustment factors with reasoning, confidence interval, and model version.
Returns None for nodes without a PoS score (typically only late-stage pipeline drugs are scored).
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes | Node identifier |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
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 behavior (including None case) and components of the estimate, but does not mention side effects, required permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence defines the main purpose, and the second sentence clarifies a critical edge case (None returns).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool returns structured data with an output schema, the description adequately explains return components and the None scenario. It might benefit from mentioning prerequisites or error handling, but overall is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'node_id' is described in schema with 100% coverage. The description adds no extra semantic details about the parameter beyond what the schema provides, though the context of what the tool returns indirectly aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the specific resource 'Probability of Success estimate for a node'. It lists the included components and distinguishes from sibling tools that focus on searching or listing nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions when the tool returns None (nodes without PoS, typically late-stage), implying context for use. However, it does not explicitly state when to use this tool over alternatives like get_node or get_writeup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_staleness_reportCInspect
Get writeup staleness report: overall stats, top stale nodes, data source freshness.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of top stale nodes to return (default 20) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only lists the report contents but omits any details about side effects, permissions, causality, or output behavior. It does not clarify whether the tool is read-only or has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. However, it is so brief that it omits potentially helpful details that could be included without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, output schema present), the description covers the main output components. However, it lacks context about the report's scope (e.g., workspace-level or global) and does not integrate with sibling tools. The output schema likely provides return structure, so the description is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to add extra meaning for the parameter. The schema already explains 'limit' as the number of top stale nodes. The description adds no additional parameter context beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'writeup staleness report' with three specific components (overall stats, top stale nodes, data source freshness). It uses a specific verb and resource, but does not explicitly distinguish itself from siblings like 'get_node_freshness' or 'get_stats'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or when not to use it. The usage context is entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statsAInspect
Get a high-level overview of the BioCosm database: total nodes, writeups, companies, breakdowns by type/status/domain, validation scores, and recent pipeline runs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
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 output but does not mention side effects, permissions, or rate limits; however, the tool is clearly a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys what the tool does without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description fully specifies the tool's purpose and the kind of data it returns, which is sufficient for a summary endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100%. The description does not need to add parameter info; the baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a high-level overview of the BioCosm database, listing specific data points like nodes, writeups, companies, and breakdowns, which distinguishes it from sibling tools that focus on specific filters or details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for broad overviews, but does not explicitly contrast with sibling tools or state when to use this versus alternatives like find_by_phase or get_node.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_writeupAInspect
Get the full writeup for a BioCosm node, including all sections, citations, structured data, and validation score.
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes | The node identifier (e.g. "pembrolizumab") |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It indicates the tool returns a full writeup, but does not mention if it is read-only, any side effects, or performance implications. This is insufficient for a safe retrieval operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with front-loaded purpose. It is concise with zero wasted words, effectively summarizing the tool's functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, output schema exists), the description is mostly complete. It lists key components of the writeup. However, it could benefit from noting that the operation is safe and idempotent, especially since no annotations are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the param (node_id with example). The description does not add any additional semantic meaning beyond what the schema provides, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full writeup for a BioCosm node, listing specific components (sections, citations, structured data, validation score). This distinguishes it from siblings like get_node (likely basic node info) and get_staleness_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for obtaining a comprehensive writeup, but does not specify exclusions or alternative tools for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_by_therapeutic_areaBInspect
List all nodes in a given therapeutic area.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | Therapeutic area to search (e.g. "breast cancer", "non-small cell lung cancer") | |
| limit | No | Maximum results (default 50) |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic function. It does not disclose whether the operation is read-only, what the response size might be, or any side effects. The name implies a listing, but behavioral traits are not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is efficiently written, though it could benefit from front-loading the key action. Still, it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward listing tool with an output schema and only two parameters, the description is largely sufficient. It could mention that results may be large or that the tool is a broad query, but overall it captures the essential functionality given the context of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both parameters are described in the input schema. The description adds 'in a given therapeutic area' which aligns with the 'area' parameter but does not provide additional meaning beyond the schema. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists 'all nodes' in a given therapeutic area, with a specific verb and resource. However, it does not explicitly differentiate it from sibling tools like 'find_by_phase' or 'find_by_target', which could also filter by therapeutic area indirectly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or when another tool might be more appropriate, such as for filtering by phase or target.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_nodesAInspect
Search BioCosm nodes by name, gene symbol, target, therapeutic area, or company.
Results are ranked: exact name/brand matches first, then partial name
matches, with a node-type prior (canonical drug/diagnostic nodes rank above
gene-target nodes, which rank above ChEMBL salt-form duplicates). Nodes
matched only via description/company/area rank last. Each result includes a
name field for disambiguation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return (default 20, max 100) | |
| query | Yes | Search term (e.g. "breast cancer", "pembrolizumab", "Merck") |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details ranking logic and result fields (name for disambiguation), but omits potential issues like pagination, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Purpose stated upfront, ranked behavior clearly summarized. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and schema covers parameters, description explains ranking and disambiguation. Could mention output format but likely complemented by schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by listing searchable fields (name, gene symbol, target, etc.) beyond the schema's 'Search term', clarifying acceptable inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches BioCosm nodes by multiple fields (name, gene symbol, target, etc.) and distinguishes from sibling tools that filter by specific criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like find_by_phase or find_by_target. The description implies general search but does not mention exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!