Pharmacogenomics for AI agents: cited drug–gene, gene and rsID lookups plus a medication screen.
Scored across 5 tools
The tools mostly target clearly distinct resources: batch medication coverage, gene listing, gene detail, drug-gene guidance, and variant detail. There is some overlap between lookup_gene (which includes drug interactions) and lookup_drug_gene, but the descriptions make the intended use cases reasonably distinguishable.
All tool names follow a consistent snake_case verb_noun pattern: check_medications, list_genes, lookup_drug_gene, lookup_gene, lookup_variant. No mixed conventions or vague standalone verbs.
Five tools is well-scoped for a focused pharmacogenomics knowledge base, and each tool covers a distinct query pattern. Nothing feels redundant or missing at the count level.
The set covers gene listing, gene detail, drug-gene guidance, variant lookup, and medication coverage checks. A minor gap is the lack of a direct drug-centric lookup returning full guidance across all interacting genes, though check_medications partially fills this.
Given a list of generic drug names, say which ones have a curated drug–gene record, with which genes and what each record rests on (a CPIC or DPWG guideline, a drug label, or the primary literature), and which are not covered. Needs no genotype.
| Name | Required | Description | Default |
|---|---|---|---|
| medications | Yes | Generic names, e.g. ["clopidogrel", "simvastatin"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, closed-world behavior, and the description adds meaningful context beyond that: the evidence provenance returned (CPIC/DPWG guideline, drug label, primary literature) and the fact that genotype input is not required. It goes beyond the safety profile into actual result semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that names the input, the three returned facets, and the genotype constraint without filler. Slightly dense with clauses, but every clause carries 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 one-parameter read tool with no output schema, the description explains what comes back conceptually (genes, evidence basis, uncovered drugs) and that no genotype is needed. Only the batch-size limit is left to the schema, which is appropriate.
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 documents the medications array with an example and min/max constraints. The description reinforces 'generic drug names', which adds a small amount of meaning (generic vs. brand) but largely restates 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?
Specific verb (screen a list) plus a precise statement of the output: which drugs have a curated drug–gene record, the associated genes, the evidence basis, and which are not covered. This clearly separates it from the single-item siblings like lookup_drug_gene.
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 conveys the batch-screening context ('Given a list of generic drug names') and states the precondition 'Needs no genotype', which is useful. However, it never explicitly contrasts with lookup_drug_gene or list_genes, so the agent must infer that this is the bulk variant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the genes in the DeepDNA knowledge base, with a one-line summary and category for each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds real value by describing what each returned item contains (summary + category), but says nothing about result volume, pagination, or whether the full list is returned in one call.
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 with zero waste, front-loaded with the verb and resource and finishing with the shape of each result. Nothing is redundant with the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry return-value semantics; it names the per-item fields but omits size, ordering, and pagination behavior — important for a full-enumeration tool over a knowledge base. Adequate but with a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description correctly implies no filtering inputs are needed — it lists the entire knowledge base — which is consistent with the empty 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?
States a specific verb ('List') and resource ('genes in the DeepDNA knowledge base') and previews the per-item payload (one-line summary and category). The plural 'list' implicitly contrasts with the sibling lookup_gene, but it never names or explicitly distinguishes itself from that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is the enumerate-everything tool versus lookup_gene for a single gene. There is no explicit 'use this when…' guidance, no mention of when to prefer lookup_gene, and no prerequisites or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pharmacogenomic guidance for a gene, optionally for one drug: guideline (CPIC or DPWG, "drug label", or null when the record rests on the primary literature), summary of the recommendation, phenotypes and sources. Omit drug to list every drug curated for that gene.
| Name | Required | Description | Default |
|---|---|---|---|
| drug | No | Generic drug name, e.g. clopidogrel. Optional. | |
| gene | Yes | Pharmacogene symbol, e.g. CYP2C19. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value by disclosing the returned fields and clarifying that a null guideline means the record rests on primary literature, giving the agent a way to interpret output it would otherwise misread.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with the resource stated first, the optional-parameter behavior second, and the enumeration of returned fields nested in the middle. No filler and nothing repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing return values, and it does so (guideline, recommendation summary, phenotypes, sources). Combined with 100% parameter coverage and full annotations, an agent has everything needed to call and interpret the result.
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 the baseline is 3, but the description goes beyond the schema by explaining the consequence of omitting drug (enumerate all curated drugs) and by defining one of the guideline values as null. That adds interpretive meaning the parameter descriptions do not contain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource (pharmacogenomic guidance) and scope (one gene, optionally one drug), and enumerates what the record contains (guideline, recommendation summary, phenotypes, sources). It does not explicitly differentiate itself from siblings like lookup_gene or check_medications, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The clause 'Omit drug to list every drug curated for that gene' tells the agent exactly how to choose between the two usage modes. There are no explicit exclusions or named alternatives among siblings, which keeps it at 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything curated about one gene: function, key variants with rsIDs, metabolizer or function phenotypes, drug interactions, what a consumer genotyping array can and cannot tell you, and sources.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | HGNC gene symbol, e.g. CYP2C19. Case-insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds value the annotations cannot: it discloses the shape of what comes back (variant rsIDs, phenotypes, array coverage limits) and hints at caveats with 'what a consumer genotyping array can and cannot tell you'. It does not cover behavior on an unknown or ambiguous symbol, which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no preamble or filler; every item in the enumeration describes a distinct category of returned data. It is a dense list rather than prose, but nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing return values, and it does so explicitly by listing the content categories. For a one-parameter read tool with full annotation coverage, little else is essential; only error/ambiguity behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already states 'HGNC gene symbol, e.g. CYP2C19. Case-insensitive.' The description adds nothing about the symbol parameter — no mention of accepted aliases, what happens on an invalid symbol, or lookup precision. Baseline 3 is correct where the schema does all the work.
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 names the resource (one gene) and enumerates the curated content returned: function, variants with rsIDs, phenotypes, drug interactions, array coverage, sources. That is concrete enough for an agent to know what it retrieves. It does not, however, distinguish itself from siblings like lookup_variant or lookup_drug_gene, which plausibly return overlapping data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the content list — an agent infers it should call this when it has a gene symbol and wants a broad summary. There is no explicit when-to-use, no exclusion, and no pointer to lookup_drug_gene or lookup_variant for narrower questions. The single required symbol parameter hints at the entry condition but that is left to the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One variant by dbSNP rsID: gene, star-allele or common name, alleles, functional effect, population frequency and sources. Send the rsID only, never the user's genotype. A single variant is not a phenotype or metabolizer status.
| Name | Required | Description | Default |
|---|---|---|---|
| rsid | Yes | dbSNP identifier, e.g. rs4244285. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior; the description adds the important constraint never to send the user's genotype and lists what the lookup returns. It does not discuss rate limits or error behavior, but given annotation coverage this is solid.
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 compact sentences: return scope first, input/privacy constraint second, scope limit third. No filler, and critical constraints are 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 one-parameter read-only lookup with no output schema, the description gives enough return-field detail, input constraint, and scope caveat for an agent to call it correctly. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the rsID parameter with an example, and the description reinforces that only the rsID should be sent—never genotype. That adds meaningful privacy and semantic guidance beyond the schema's type description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States that the tool returns one variant identified by dbSNP rsID and enumerates the fields returned, so the resource and scope are clear. It also distinguishes the output from phenotype/metabolizer status, though it does not explicitly name sibling tools such as lookup_gene.
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?
Provides clear usage context (one variant, rsID input) and a key exclusion (not a phenotype or metabolizer status), plus the privacy constraint to send rsID only. It stops short of explicitly naming alternative sibling tools for phenotype or gene-level questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
request_beta_accesslookup_variant1 field changedInput schema / properties / genotypeRemoved value: -{
- "description": "Optional. The genotype at this position, e.g. AG, A/G, or one letter on X, Y or MT. Not stored.",
- "type": "string"
-}check_medicationslookup_variant1 field changedInput schema / properties / genotypeAdded value: +{
+ "description": "Optional. The genotype at this position, e.g. AG, A/G, or one letter on X, Y or MT. Not stored.",
+ "type": "string"
+}request_beta_accesslist_geneslookup_drug_genelookup_genelookup_variantFind pharmacogenomics guidelines, translate diplotypes, and retrieve prescribing recommendations.
Drug-drug interaction checker for clinical LLMs using RxNorm and DailyMed.
Medical RAG: semantic search for clinical guidelines, drug interactions, diagnoses & EHR data.
Medical RAG: semantic search for clinical guidelines, drug interactions, diagnoses & EHR data.
Add one secure layer between your agents and this server.
