Cure Cancer With AI
Server Details
Free oncology data (research, trials, FDA approvals, news) plus IBM MAMMAL biomedical predictions.
- 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.9/5 across 13 of 13 tools scored. Lowest: 3.2/5.
Each tool targets a distinct purpose: retrieving different content types (blog posts, clinical trials, research papers, news, FDA approvals), running specific AI predictions, or performing a cross-dataset search. There is no overlap or ambiguity.
Most tools follow a verb_noun pattern (get_, list_, search_, predict_), but 'mammal_health' breaks this pattern with a noun_noun format. While the majority are consistent, the outlier reduces clarity.
13 tools is well-scoped for a server covering content retrieval (5 list tools, 3 get tools, 1 search tool) and AI predictions (3 predict tools + 1 health check). Each tool has a clear role without redundancy.
The tool set covers the major workflows: broad search, detailed retrieval of individual records, and three key prediction tasks. Minor gaps exist, such as no tool for user management or submission of new data, but these are outside the declared scope.
Available Tools
15 toolsget_blog_postGet a blog postAInspect
Fetch a single blog post by slug, including the full article content.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Blog post slug, e.g. "immunotherapy-breakthroughs". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description alone must disclose behavior. It clearly states a read operation ('fetch') with full content, which is transparent for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence (13 words) that front-loads the action and resource, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no nested objects), the description fully captures its functionality and is sufficient for an AI agent to understand its use.
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 slug parameter. The description adds no extra parameter-specific meaning beyond what the schema provides.
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 specifies the exact action (fetch), resource (blog post), and identifier (slug), clearly distinguishing it from sibling tools like get_clinical_trial or get_research_paper.
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 implicitly indicates use for retrieving a single blog post by slug, and sibling tools cover different resources, providing clear context. However, it lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_clinical_trialGet a clinical trialAInspect
Fetch a single clinical trial by NCT id (or internal id), including eligibility criteria and locations.
| Name | Required | Description | Default |
|---|---|---|---|
| nctId | Yes | NCT id or internal id, e.g. "NCT01234567". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses that the tool fetches a single trial including eligibility criteria and locations, implying a read operation. However, it lacks details on error handling (e.g., if ID not found), authentication needs, or rate limits. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and key details. No extraneous words or repetition; every word is functional.
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 simple single-parameter fetch tool without an output schema, the description covers the essential purpose and what is returned (eligibility criteria, locations). It could additionally note that the response is a clinical trial object, but given low complexity, it is sufficiently 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 input schema has 100% coverage with a description for nctId that includes an example format ('NCT01234567'). The tool description also mentions 'by NCT id (or internal id)', reinforcing the parameter. However, the description adds no new semantic meaning beyond what the schema already 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 verb 'Fetch', the resource 'single clinical trial', and the method (by NCT id or internal id), including what is returned (eligibility criteria and locations). It distinguishes from sibling tools like list_clinical_trials which retrieve multiple trials.
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 usage when you need a single trial by ID, but does not explicitly state when to use this tool versus alternatives like list_clinical_trials for broader searches. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_research_paperGet a research paperAInspect
Fetch a single research paper by its internal id or PubMed id.
| Name | Required | Description | Default |
|---|---|---|---|
| idOrPubmedId | Yes | Internal id or PubMed id, e.g. "38123456". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only states 'Fetch', implying a read operation. It discloses no side effects, authentication needs, or behavior on missing IDs. The transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb and resource. All content is relevant; 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 low complexity (1 param, no nested objects), the description is adequate but lacks any mention of return value or output format. Since there is no output schema, some hint about the return would improve completeness.
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 covers the parameter with a description and example. The description's mention of 'internal id or PubMed id' adds minimal extra value beyond the schema. Baseline 3 is appropriate due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch'), resource ('research paper'), and clarifies it operates by internal id or PubMed id. It clearly distinguishes from sibling tools like get_blog_post and get_clinical_trial.
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 usage (when you need a single paper by ID) but provides no explicit guidance on when not to use or alternatives. For a simple fetch tool, this is adequate but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_blog_postsList blog postsAInspect
List editorial blog articles (excerpts). Use get_blog_post for full content. Filter by category, cancer-type tag, or keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1–100, default 20). | |
| offset | No | Number of results to skip (default 0). | |
| search | No | Keyword search across title, excerpt, and content. | |
| category | No | Filter by primary category. | |
| cancerType | No | Filter by cancer-type tag. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the tool lists excerpts; it does not mention auth requirements, rate limits, or imply read-only safety beyond the verb 'list'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the core purpose and immediately provides a key alternative and filter summary.
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 a simple listing tool with fully documented parameters and no output schema, the description covers the essential purpose, alternative, and filter hints. It omits return format details, but that is acceptable without an output 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?
With 100% schema description coverage, the schema already documents all 5 parameters well. The description adds minimal value by summarizing filter options (category, cancer-type, keyword), but does not provide deeper semantics 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 verb 'List' and the resource 'editorial blog articles (excerpts)', and explicitly distinguishes from sibling 'get_blog_post' by noting that it returns excerpts only.
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 directs users to 'get_blog_post' for full content, providing a clear when-not scenario. However, it does not address other sibling tools or broader usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_clinical_trialsList clinical trialsBInspect
List clinical trials from public registries (conditions, status, intervention type). Filter by condition, status (e.g. RECRUITING), or keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1–100, default 20). | |
| offset | No | Number of results to skip (default 0). | |
| search | No | Keyword search across title and description. | |
| status | No | Filter by trial status, e.g. RECRUITING. | |
| condition | No | Filter by condition. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions 'public registries' as data source but does not disclose pagination behavior, data freshness, or any limitations. Schema already covers parameters; description adds little transparency.
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, concise and to the point. Could front-load the critical verb and object more prominently, but no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, description does not explain return format or container. Given 5 optional parameters, does not clarify default behavior (e.g., what happens with no filters). Context signals indicate moderate complexity, but description leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description reiterates some parameters (condition, status, keyword) but adds no new semantic detail beyond what the parameter names imply. No examples or format guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists clinical trials from public registries and lists filters (condition, status, keyword). Distinguishes from siblings like 'get_clinical_trial' (single) and 'list_fda_approvals' (different domain). However, mentions 'intervention type' not in parameters, slightly confusing.
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?
Describes filters available but does not provide when-to-use guidance or alternatives. No mention of when not to use or relative strengths versus sibling tools like 'search_oncology'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_compound_characteristicsList compound characteristicsAInspect
List the pharmaceutical-compound characteristics (each scored on the −4…+4 scale) that can be used as preference keys in search_compounds.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description only states the tool lists scored characteristics. It lacks details about return format, ordering, or whether all characteristics are returned. Adequate but 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, no 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?
For a simple list tool with no parameters and no output schema, the description is sufficient to understand its purpose and usage context. Could mention output format but not necessary.
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 has zero parameters, so baseline is 4. Description adds no parameter info, but none is needed.
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 lists pharmaceutical-compound characteristics with a specific score scale, and explicitly links it to search_compounds, distinguishing it from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It indicates the output is used as preference keys in search_compounds, providing context for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_fda_approvalsList FDA approvalsAInspect
List FDA-approved oncology drugs with indication, company, approval date, and label links. Filter by cancer type, keyword, or approval date.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO date upper bound (e.g. 2024-12-31). | |
| from | No | ISO date lower bound (e.g. 2024-01-01). | |
| limit | No | Results per page (1–100, default 20). | |
| offset | No | Number of results to skip (default 0). | |
| search | No | Keyword search across drug name, generic name, and indication. | |
| cancerType | No | Filter by cancer type, e.g. lung, breast, prostate, colorectal, melanoma, leukemia, lymphoma. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool returns a list with the mentioned fields and supports filtering. However, it omits behavior like pagination (limit/offset in schema) and potential limitations, which is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences (16 words) front-load the purpose and immediately state filtering capabilities. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low complexity, the description covers core purpose and filtering but lacks details on pagination, response format, or ordering. It is minimally complete for a list tool with optional parameters.
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 baseline is 3. The description adds value by grouping parameters into meaningful filter categories (cancerType, search, to/from), which is not evident from individual schema descriptions. It does not explain limit/offset, but the added context justifies a 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 verb 'List' and the resource 'FDA-approved oncology drugs' with specific fields (indication, company, approval date, label links). The resource name itself distinguishes it from sibling tools like list_clinical_trials, but no explicit sibling differentiation is provided.
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 three filter types (cancer type, keyword, approval date), giving clear context for usage. However, it does not specify when to use this tool versus alternatives like search_oncology, nor does it provide any when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_newsList cancer newsAInspect
List curated cancer news articles aggregated from trusted sources. Filter by cancer type, keyword, or published date.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO date upper bound (e.g. 2024-12-31). | |
| from | No | ISO date lower bound (e.g. 2024-01-01). | |
| limit | No | Results per page (1–100, default 20). | |
| offset | No | Number of results to skip (default 0). | |
| search | No | Keyword search across title, summary, and content. | |
| cancerType | No | Filter by cancer type, e.g. lung, breast, prostate, colorectal, melanoma, leukemia, lymphoma. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond listing and filtering. For a tool with no annotation safety net, the description should include read-only status, pagination behavior, or data recency, which are missing.
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 concise sentences that front-load the purpose and key filters. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema and fully described parameters, the description provides all necessary context for an agent to select and use the tool effectively.
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 parameters are already described. The description adds a high-level summary and the source quality ('aggregated from trusted sources'), which provides useful context not in 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 lists curated cancer news articles. The sibling tools (e.g., list_blog_posts, list_clinical_trials) show distinct resource types, so this tool is well differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies filtering by cancer type, keyword, or published date, giving clear usage context. Sibling tool names imply when not to use it (e.g., for blog posts or clinical trials), but no explicit when-not or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_researchList research papersAInspect
List peer-reviewed oncology research papers ingested from PubMed (abstracts, authors, journal, plain-language summaries). Filter by cancer type, treatment type, keyword, or publication date.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO date upper bound (e.g. 2024-12-31). | |
| from | No | ISO date lower bound (e.g. 2024-01-01). | |
| limit | No | Results per page (1–100, default 20). | |
| offset | No | Number of results to skip (default 0). | |
| search | No | Keyword search across title and abstract. | |
| cancerType | No | Filter by cancer type, e.g. lung, breast, prostate, colorectal, melanoma, leukemia, lymphoma. | |
| treatmentType | No | Filter by treatment type. |
Tool Definition Quality
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 does not mention response format, pagination behavior (e.g., default limit, sorting), error handling, or rate limits. However, the schema provides some details on parameters like limit and offset, partially mitigating the gap.
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, focused sentence that front-loads the primary purpose and includes all key elements without unnecessary words. It is well-structured for quick understanding.
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 listing tool with no output schema, the description covers input parameters and implies output content (abstracts, authors, etc.). It could be more complete by explicitly stating default pagination or sorting order, but overall it provides sufficient context for an agent to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described. The description adds minimal new meaning by grouping them as filters ('Filter by cancer type, treatment type, keyword, or publication date'), but does not provide additional context beyond what the schema already states.
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 specifies the tool lists peer-reviewed oncology research papers from PubMed, including specific content (abstracts, authors, journal, plain-language summaries) and available filters. It distinguishes from sibling tools like list_clinical_trials and get_research_paper by focusing on multiple research papers and oncology context.
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 implicitly suggests when to use this tool (for listing oncology research papers) but does not explicitly state when not to use it or compare to alternatives. The context of sibling tools helps, but explicit guidance would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mammal_healthCheck MAMMAL model healthAInspect
Check whether the IBM MAMMAL prediction model is loaded and ready. No API key required. Call this before predict_* tools if a prior prediction timed out.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 discloses no API key needed and that it is a non-destructive readiness check. Lacks detail on return value, but sufficient for a simple check.
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. First sentence states purpose directly; second adds usage guidance. Perfectly concise and 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?
For a parameterless health check tool with no output schema, the description is complete: it tells what it does, prerequisites (none), and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% by default. The description adds no parameter info, but baseline for 0 params 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 checks whether the IBM MAMMAL prediction model is loaded and ready, using specific verb and resource. It distinguishes from sibling predict_* tools by being a readiness check.
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 recommends calling this before predict_* tools if a prior prediction timed out, providing clear context. It also notes no API key required, but does not cover 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.
predict_clintoxPredict clinical-trial toxicity (ClinTox)AInspect
Predict clinical-trial toxicity for a compound using IBM MAMMAL. Returns pred 1 (toxic / likely to fail trials) or 0 (not toxic) plus a raw score. Inference is CPU-bound and may take up to ~60s.
| Name | Required | Description | Default |
|---|---|---|---|
| smiles | Yes | Compound structure in SMILES notation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses CPU-bound inference and ~60s timeout, adding behavioral context beyond the purpose. However, missing details on error handling or authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, output format, performance note. No redundant information, well front-loaded.
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 simple prediction tool with one parameter, the description covers purpose, output, and a performance characteristic. Missing error handling details but adequate overall.
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 has 100% coverage for the single parameter (smiles), so the description adds no additional semantics beyond the schema definition of SMILES notation.
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 predicts clinical-trial toxicity using IBM MAMMAL, specifies binary output (1 or 0) and a raw score, distinguishing it from sibling prediction tools like predict_dti or predict_ppi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description (toxicity prediction), but no explicit guidance on when or when not to use this tool versus sibling tools like predict_dti or predict_ppi.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_dtiPredict drug–target interaction (pKd)AInspect
Predict drug–target binding affinity as pKd (−log10 Kd; higher = stronger binding) using IBM MAMMAL. Inference is CPU-bound and may take up to ~60s.
| Name | Required | Description | Default |
|---|---|---|---|
| drug_seq | Yes | Drug structure in SMILES notation. | |
| norm_y_std | No | Optional normalization standard-deviation override. | |
| target_seq | Yes | Target protein amino-acid sequence (single-letter codes). | |
| norm_y_mean | No | Optional normalization mean override. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully convey behavior. Only mentions CPU-bound and ~60s latency. Lacks side effects, error behavior, or read-only status.
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, zero waste, front-loaded with main purpose. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should detail return value. Missing output format (e.g., numeric pKd), interpretation, or error handling. Adequate for simple tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage on parameter descriptions. Description adds no extra meaning beyond schema's existing descriptions. Baseline score applies.
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 clearly states specific verb+resource: 'Predict drug–target binding affinity as pKd'. Mentions model (IBM MAMMAL) and units, distinguishing from sibling tools like predict_clintox or predict_ppi.
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 when-to-use or when-not-to-use guidance. Implied by name and sibling context but not stated. Lacks alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predict_ppiPredict protein–protein interactionAInspect
Predict the binding-affinity class for a pair of proteins using the IBM MAMMAL biomedical foundation model. Returns label "1" (interacting) or "0" (non-interacting). Inference is CPU-bound and may take up to ~60s.
| Name | Required | Description | Default |
|---|---|---|---|
| protein_a | Yes | Amino-acid sequence, single-letter codes (ACDEFGHIKLMNPQRSTVWY), no FASTA header. | |
| protein_b | Yes | Amino-acid sequence, single-letter codes. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses CPU-bound nature and ~60s runtime, but with no annotations, the description carries full burden. Missing details on idempotency, side effects, error handling, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy: purpose, output format, and runtime constraint. Every sentence adds unique value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return labels. Parameter details are clear. However, fails to mention failure modes or provide an example.
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 provides descriptions (100% coverage), but description adds value by clarifying 'single-letter codes' and 'no FASTA header', which prevent common input errors.
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?
Clearly states the verb 'Predict' and the resource 'protein–protein interaction', specifies the model (IBM MAMMAL), and defines output labels '1' (interacting) or '0' (non-interacting). Distinct from sibling tools like predict_clintox and predict_dti.
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?
Implied usage from the description, but no explicit guidance on when to use this tool versus alternatives (e.g., predict_dti). No prerequisites or exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_compoundsSearch pharmaceutical compoundsAInspect
Find pharmaceutical compounds two ways: by example drugs you already know (fuzzy-matched), or by setting target characteristics on a −4…+4 scale. Provide exactly one of examples or preferences. Use list_compound_characteristics for the available preference names.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1–100, default 20). | |
| examples | No | Known drug names to find similar compounds for, e.g. ["aspirin","ibuprofen"]. Mutually exclusive with preferences. | |
| preferences | No | Map of characteristic name to desired value on the −4…+4 scale, e.g. {"Neuroactive":3,"Immunoactive":-2}. Omit a characteristic to ignore it. Mutually exclusive with examples. | |
| include_characteristics | No | Include each result’s characteristic scores in the response. |
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 for behavioral transparency. It discloses fuzzy matching and the -4 to +4 scale, but does not mention return format, error handling, or whether the operation is read-only. This is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—three sentences that front-load the core purpose and usage rules. Every sentence adds essential information without redundancy or unnecessary detail.
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 complexity (4 parameters, nested object, no output schema), the description effectively explains the two search modes and mutual exclusivity. It references a sibling tool for characteristics, but does not describe the return structure, which would be helpful for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, baseline is 3. The description adds value by reinforcing the mutual exclusivity of 'examples' and 'preferences' and suggesting the use of a sibling tool for available characteristic names, which is not covered by 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 clearly states the tool finds pharmaceutical compounds via two distinct modes (fuzzy-matched examples or characteristic preferences). It specifies the verb 'Find' and the resource 'pharmaceutical compounds', and distinguishes between the two modes, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that exactly one of 'examples' or 'preferences' should be provided, and directs users to 'list_compound_characteristics' for available preference names. This provides clear usage guidance, though it does not explicitly describe when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_oncologySearch all oncology datasetsAInspect
Search a keyword across every Cure Cancer With AI dataset at once — research papers, news, blog posts, FDA approvals, and clinical trials — with results grouped by type. Use this first for broad discovery, then fetch a single record by id/slug/nctId for full detail.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | The keyword to search for, e.g. "osimertinib". | |
| limit | No | Max results per dataset (1–100, default 5). | |
| types | No | Optional comma-separated datasets to narrow to: research,news,blog,fdaApprovals,clinicalTrials. | |
| cancerType | No | Filter by cancer type, e.g. lung, breast, prostate, colorectal, melanoma, leukemia, lymphoma. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full disclosure burden. It mentions grouping by type but omits details on rate limits, pagination, authentication, or empty result handling. Provides moderate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded purpose and usage. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should hint at return format (e.g., grouped results). It mentions grouping but not structure. Lacks pagination or error info. Adequate but not complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100% coverage), but description adds value by explaining q keyword, limit default (5), types options (comma-separated), and cancerType filtering. Goes beyond schema with workflow context.
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?
Clearly states it searches a keyword across multiple oncology datasets (research, news, blog, FDA, trials) and groups by type. Explicitly distinguishes from sibling tools by positioning it as a broad discovery tool, contrasting with get_* tools for fetching single records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use this first for broad discovery, then fetch a single record by id/slug/nctId for full detail.' This provides clear when-to-use and alternatives guidance.
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!