Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@openpgx Can I take Ozempic?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
OpenPGx is an open, AI-readable standard for pharmacogenomic data. It defines how genetic variants, drug responses, disease risks, and traits should be structured so that any AI system can understand and reason about them.
The standard is delivered today through an MCP Server — plug it into Claude, Cursor, or any MCP-compatible AI and start asking questions about your DNA.
"Can I take Ozempic?" → Checks GLP1R variants against your genotype
"How about Vyvanse?" → Cross-references CYP2D6 + COMT studies
"What's my Alzheimer risk?" → 19 disease conditions analyzed with odds ratiosPrivacy-first: your data never leaves your computer. No cloud, no account, no tracking.
Pharmacogenomic data is trapped in formats that AI can't use. FHIR is verbose and hospital-centric. PharmCAT is great but not designed for AI consumption. Research papers are unstructured text.
OpenPGx is different:
AI-readable — structured JSON that any LLM can parse and reason about
Study-driven — every interpretation traces back to a published study with PMID/DOI
Open source — add a study by dropping a JSON file and opening a PR
FHIR-compatible — not a replacement, but an intelligence layer that exports to FHIR resources
One JSON file = one gene-drug study. This is the atomic unit of pharmacogenomic knowledge in OpenPGx:
{
"gene": "ALDH2",
"category": "drug_metabolism",
"gene_description": "Alcohol metabolism, nitroglycerin bioactivation",
"drugs": ["nitroglycerin", "ethanol"],
"source": {
"pmid": "16395407",
"doi": "10.1172/JCI26564",
"source_type": "pubmed",
"title": "ALDH2 Glu504Lys polymorphism and nitroglycerin efficacy",
"journal": "Journal of Clinical Investigation",
"year": 2006,
"cohort_size": 986,
"url": "https://pubmed.ncbi.nlm.nih.gov/16395407/",
"finding": "ALDH2*2 carriers show reduced nitroglycerin bioactivation."
},
"snps": [
{
"rsid": "rs671",
"risk_allele": "A",
"reference_allele": "G",
"interpretations": {
"AA": { "phenotype": "ALDH2 Deficient", "effect": "Nitroglycerin ineffective", "severity": "severe" },
"AG": { "phenotype": "Reduced Activity", "effect": "33-40% less efficacy", "severity": "moderate" },
"GG": { "phenotype": "Normal", "effect": "Standard response", "severity": "info" }
}
}
],
"evidence_level": "established"
}Want to contribute a new drug-gene study? Create a file like this in data/pgx/studies/ and open a PR. No code changes needed.
Related MCP server: Genomic-Agent-Discovery
Add to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/claude/claude_desktop_config.json
{
"mcpServers": {
"openpgx": {
"command": "npx",
"args": ["-y", "openpgx"]
}
}
}Restart Claude Desktop. Done.
claude mcp add openpgx -- npx -y openpgxOpen Settings > MCP > Add new MCP Server:
{
"mcpServers": {
"openpgx": {
"command": "npx",
"args": ["-y", "openpgx"]
}
}
}Same configuration. OpenPGx uses stdio transport — any MCP-compatible client works:
npx openpgxDon't want to install anything? Use the hosted server directly:
{
"mcpServers": {
"openpgx": {
"type": "streamable-http",
"url": "https://mcp.openpgx.ai/mcp"
}
}
}This connects to our remote MCP server via Streamable HTTP — same 9 tools, zero local setup. Your genome is parsed server-side and stored temporarily in memory (30-minute session TTL).
Privacy note: For maximum privacy, prefer the
npxinstall — everything stays on your machine. The remote server processes your data but does not store it permanently.
"Upload my genome" → parse your raw DNA file
"Can I take Ozempic?" → check semaglutide + GLP1R
"What about Venvanse?" → brand names work (60+ brands mapped)
"Is modafinil right for me?" → checks COMT + CYP2C19 interactions
"Compare sertraline vs escitalopram" → head-to-head comparison
"Weight loss medications" → search by category
"antidepressivo" → Portuguese works too
"ozmpic" → typos are auto-corrected"What's my cancer risk?" → check specific conditions
"Full risk report" → all 19 conditions analyzed
"Do I have the Alzheimer gene?" → APOE status
"Am I at risk for blood clots?" → Factor V Leiden check"Trait report" → all 25+ traits
"Am I lactose intolerant?" → lactose persistence check
"Am I a morning person?" → chronotype analysis"Supplement protocol" → MTHFR, COMT, VDR, BCMO1, FUT2, CBS
"Should I take methylfolate?" → based on your MTHFR status118 studies · 109 genes · 219 drugs · 19 disease risks · 31 traits — all backed by published research with PMID/DOI.
Every gene is backed by at least one published study with interpretations per genotype. The authoritative list is the set of gene fields in data/pgx/studies/*.json; the table below groups major clinical themes (some genes appear in more than one theme in the data).
Category | Genes (representative) |
Drug Metabolism | CYP2D6, CYP2C19, CYP2C9, CYP2B6, CYP3A4, CYP3A5, CYP1A2, CYP2E1, ALDH2, BCHE, CES1, FAAH, NAT2, UGT1A1, UGT1A4, UGT1A9, GSTP1, ACE, ADRB1, ADRB2, AGTR1, HMGCR, PCSK9 |
Drug Targets & Response | VKORC1, DRD2, DRD3, DRD4, HTR1A, HTR2A, HTR2C, GABRA2, GABRA6, GLP1R, GRIK4, SCN1A, SCN9A, MC1R, RYR1, TPMT, NUDT15, DPYD, FKBP5, ESR1, SHBG, COMT, OPRM1, TCF7L2, CLOCK |
ADHD / Stimulants | ADRA2A, SLC6A2, SLC6A3, SLC6A4, SNAP25 |
Drug Transport | SLCO1B1, ABCB1, ABCG2, SLC22A1, SLC22A2 |
Immune / HLA | HLA-B, HLA-A, HLA-C, HLA-DQB1, IL23R |
GLP-1 / Incretin | GLP1R, GIPR, MC4R, PCSK1 |
Methylation & Vitamins | MTHFR, COMT, VDR, BCMO1, FUT2, CBS, DHCR7, SLC23A1, GC, TCN2, NBPF3 |
Lipid Metabolism | PNPLA3, TM6SF2, APOE, APOA5, APOB, LDLR, LIPC, LPL, SORT1, PPARG |
Energy Balance / Obesity | FTO, MC4R, GHSR, BDNF, PCSK1, TMEM18, FABP2, LYPLAL1 |
Glucose / Insulin | GCKR, SLC2A2, PPM1K, MTNR1B, IL6, C11ORF65 |
Circadian Rhythm | PER2, CRY2, NR1D1, CLOCK |
Coagulation | F2, F5 |
Cannabinoid / Related | CNR1, AKT1, CYP2C9 |
Salt Sensitivity | GRK4, CLCNKA |
Therapeutic Area | Medications |
Cardiology & Anticoagulation | warfarin, clopidogrel, rivaroxaban, apixaban, dabigatran, enoxaparin, heparin, nitroglycerin, isosorbide dinitrate, digoxin, amlodipine, losartan, hydrochlorothiazide, chlorthalidone, furosemide |
Statins & Lipid-Lowering | simvastatin, atorvastatin, rosuvastatin, pravastatin, ezetimibe, fenofibrate, gemfibrozil, niacin, evolocumab, alirocumab, mipomersen |
Psychiatry & Neurology | clozapine, olanzapine, risperidone, haloperidol, aripiprazole, quetiapine, fluoxetine, paroxetine, escitalopram, citalopram, venlafaxine, bupropion, carbamazepine, oxcarbazepine, eslicarbazepine, phenytoin, donepezil, memantine, lecanemab |
ADHD & Wakefulness | modafinil, armodafinil, methylphenidate, lisdexamfetamine, amphetamine, atomoxetine, caffeine |
Pain & Opioids | codeine, tramadol, fentanyl, morphine, methadone |
Oncology | capecitabine, fluorouracil, cisplatin, carboplatin, oxaliplatin, paclitaxel, topotecan, methotrexate, tamoxifen |
Immunosuppressants | tacrolimus, azathioprine, mercaptopurine, thioguanine, sulfasalazine |
Metabolic & GLP-1 | semaglutide, liraglutide, tirzepatide, dulaglutide, setmelanotide, metformin, pioglitazone, rosiglitazone, insulin, orlistat, empagliflozin, dapagliflozin |
Infectious Disease | abacavir, efavirenz |
Supplements & Vitamins | omega-3/fish oil/EPA/DHA, vitamin D (cholecalciferol, ergocalciferol, calcitriol), vitamin C (ascorbic acid), folic acid, methylfolate, methylcobalamin, beta-carotene, retinol, resveratrol, nicotinamide riboside, NMN, melatonin, pyridoxine |
Other | allopurinol, febuxostat, theophylline, tizanidine, cannabidiol, ethanol, disulfiram, celecoxib, ibuprofen, naproxen |
Category | Conditions |
Oncology | Prostate Cancer, Breast Cancer (BRCA), Colorectal Cancer, Melanoma |
Cardiovascular | Coronary Artery Disease, Atrial Fibrillation |
Neurological | Alzheimer's Disease, Parkinson's Disease |
Metabolic | Type 2 Diabetes, Hereditary Hemochromatosis, Gout |
Autoimmune | Celiac Disease, Psoriasis, Rheumatoid Arthritis, Lupus (SLE) |
Hematological | Venous Thromboembolism (Factor V Leiden) |
Musculoskeletal | Osteoporosis |
Respiratory | Asthma |
Ophthalmological | Age-Related Macular Degeneration |
Caffeine metabolism, alcohol flush, lactose tolerance, muscle composition, chronotype, eye color, and more.
Beyond disease risk SNPs, the gene studies provide pharmacogenomic guidance across these clinical areas:
Area | What OpenPGx covers |
Blood Clotting | Factor V Leiden (F5), Prothrombin mutation (F2), warfarin sensitivity (VKORC1, CYP2C9) |
Drug Hypersensitivity | HLA-B57:01 → abacavir, HLA-A31:01 → carbamazepine DRESS, HLA-B*15:02 → SJS/TEN |
Statin Myopathy | SLCO1B1 poor transport → simvastatin muscle toxicity |
Chemotherapy Toxicity | DPYD deficiency → fluorouracil/capecitabine, TPMT/NUDT15 → thiopurines, GSTP1 → platinum agents |
Opioid Response | CYP2D6 poor/ultrarapid → codeine, tramadol, fentanyl dosing |
Antipsychotic Side Effects | HTR2C → weight gain risk, DRD2 → efficacy, CYP2D6 → metabolism |
Obesity & Weight Loss | FTO, MC4R, BDNF, PCSK1, GHSR, CLOCK, SIRT1, LYPLAL1 — 9 genes affecting appetite, metabolism, fat distribution |
Cardiovascular Lipids | APOE, APOA5, APOB, LDLR, LIPC, LPL, SORT1, PNPLA3, TM6SF2 — LDL, HDL, triglycerides, fatty liver |
Diabetes & Glucose | GCKR, SLC2A2, MTNR1B, PPM1K, PPARG, IL6 — insulin secretion, glucose sensing, BCAA metabolism |
Salt Sensitivity & Hypertension | GRK4, CLCNKA — sodium handling, diuretic response |
Circadian & Sleep | PER2, CRY2, NR1D1, CLOCK — chronotype, shift work risk, melatonin response |
Vitamin Metabolism | MTHFR → folate, DHCR7 → vitamin D synthesis, BCMO1 → beta-carotene, VDR → vitamin D receptor, SLC23A1 → vitamin C, FUT2 → B12 |
Omega-3 & Fat Absorption | FADS1 → DHA/EPA conversion, FABP2 → dietary fat absorption |
GLP-1 Drug Response | GLP1R, GIPR → semaglutide/tirzepatide efficacy prediction |
Tool | Description |
| Parse raw DNA data (23andMe, Genera) |
| Smart drug lookup — brand names, generics, typos, categories |
| Complete pharmacogenomic report |
| Supplement optimization based on gene variants |
| Head-to-head drug comparison |
| Check genetic risk for a specific disease |
| Comprehensive disease risk report |
| All genetic traits analysis |
| Everything combined: medications + risks + traits |
OpenPGx is designed for open source contribution. Adding a new drug-gene study requires zero code changes — just a JSON file.
Find a pharmacogenomic study (PubMed, CPIC guidelines, PharmGKB)
Create a JSON file in data/pgx/studies/ following the naming pattern: {gene}_{year}_{slug}.json
Open a PR
The system automatically:
Creates the gene if it doesn't exist in the catalog
Registers all rsIDs for DNA parsing
Builds the drug-to-gene index
Makes the interpretations available in all reports
{
"gene": "GENE_SYMBOL",
"category": "drug_metabolism",
"gene_description": "What this gene does",
"drugs": ["generic_drug_name"],
"source": {
"pmid": "12345678",
"doi": "10.xxxx/xxxxx",
"source_type": "pubmed",
"title": "Study title",
"journal": "Journal name",
"year": 2024,
"cohort_size": 1000,
"url": "https://pubmed.ncbi.nlm.nih.gov/12345678/",
"finding": "One-line summary of the key finding"
},
"snps": [
{
"rsid": "rs12345",
"risk_allele": "A",
"reference_allele": "G",
"interpretations": {
"AA": { "phenotype": "Poor Metabolizer", "effect": "...", "recommendation": "...", "severity": "severe" },
"AG": { "phenotype": "Intermediate", "effect": "...", "recommendation": "...", "severity": "moderate" },
"GG": { "phenotype": "Normal", "effect": "...", "recommendation": "...", "severity": "info" }
}
}
],
"evidence_level": "established"
}Full schema: openpgx.schema.json (see $defs/study_contribution)
Patient-facing OpenPGx files are a single JSON object. The only required top-level field is openpgx_version (must be "0.4.0"). Everything else follows openpgx.schema.json.
Top-level structure:
Field | Required | Role |
| yes | Specification version; const |
| no |
|
| no | Audit trail: |
| no | Profile only (no genotypes): |
| no | Raw measurements: each item has |
| no | Per-drug blocks: |
| no | Disease risk: |
| no |
|
| no | Hints for FHIR: |
Minimal valid skeleton (only the required field):
{
"openpgx_version": "0.4.0"
}Example with the main optional sections (names shortened; see schema for full $defs):
{
"openpgx_version": "0.4.0",
"metadata": {
"generated_at": "2026-04-12T12:00:00Z",
"generator": "openpgx-mcp/1.x",
"sources": ["CPIC", "PharmGKB"]
},
"patient": {
"raw_data_source": "23andMe",
"ancestry": "european"
},
"observations": [
{
"gene": "CYP2C19",
"rsid": "rs4244285",
"genotype": "AG"
}
],
"medications": [
{
"drug": { "name": "clopidogrel", "class": "antiplatelet" },
"pgx_associations": [
{
"gene": "CYP2C19",
"rsid": "rs4244285",
"effect": "Reduced active metabolite formation",
"evidence": { "level": "established", "sources": [] },
"clinical_recommendation": "Consider alternative antiplatelet per guideline"
}
],
"parsed_at": "2026-04-12T12:00:00Z",
"parse_source": "cpic_guideline",
"confidence": { "score": 0.9, "evidence_level": "established" }
}
],
"fhir_mapping": {
"resource_mappings": {
"observations": "Observation (code: LOINC 81247-9 'Master HL7 genetic variant reporting panel')",
"medications": "DiagnosticReport (code: LOINC 51969-4 'Genetic analysis report') + MolecularSequence",
"risks": "RiskAssessment (method: LOINC 75321-0 'Clinical genomics report')",
"traits": "Observation (category: genomics)"
}
}
}Full schema: openpgx.schema.json
Raw DNA file (23andMe .txt / Genera .csv)
|
v
+------------------+
| Parser | --> Extracts relevant SNPs from 600K+ raw data
| (local, private) |
+------------------+
|
v
+------------------+
| Study Catalog | --> 118 studies x 109 genes x 219 drugs
| (data/pgx/ | Auto-creates gene definitions
| studies/*.json) | Builds drug-gene index at runtime
+------------------+
|
v
+------------------+
| MCP Tools | --> 9 tools for AI interaction
| (server-core.ts) | Falls back to AI web search when needed
+------------------+
|
v
AI Assistant (Claude, Cursor, ChatGPT, etc.)All processing happens locally. No data is sent to any server.
23andMe (.txt) — fully supported
Genera (.csv) — fully supported
AncestryDNA — coming soon
VCF — coming soon
OpenPGx resolves drug names through 6 layers:
Brand > Generic — "Ozempic" > semaglutide (60+ brands including Venvanse, Rivotril, Marevan, Provigil, Stavigile)
Generic exact match — "semaglutide" > found
Fuzzy brand match — "ozmpic" > Ozempic > semaglutide
Fuzzy generic match — "sertralina" > sertraline
Category search — "weight loss", "antidepressant", "antidepressivo" > list of drugs
Semantic search — pre-computed TF-IDF embeddings (289KB)
git clone https://github.com/open-pgx/open-pgx.git
cd open-pgx/mcp-server
npm install
npm run build
npm startmcp-server/
├── src/
│ ├── index.ts # Entry point (stdio transport)
│ ├── server-core.ts # MCP tools (11 tools)
│ ├── pgx-catalog.ts # Study loader, gene index, phenotype inference
│ ├── parsers.ts # 23andMe & Genera raw data parsers
│ ├── pharmacogenes.ts # Barrel re-exports
│ ├── drug-resolver.ts # 6-layer smart drug resolution
│ ├── risk-catalog.ts # Disease risk definitions
│ ├── trait-catalog.ts # Trait definitions
│ └── types.ts # Shared TypeScript interfaces
├── data/
│ ├── pgx/studies/ # 118 study files (the knowledge base)
│ ├── risks/ # Disease risk condition definitions
│ ├── traits/ # Trait definitions
│ ├── drugs_embeddings.json # TF-IDF vectors for semantic search
│ └── tfidf_vocab.json # TF-IDF vocabulary
├── genomes/ # Safe gitignored dir for your DNA files
└── package.jsonYour genetic data never leaves your computer
No cloud upload, no account, no tracking
Pre-commit hook prevents accidentally committing DNA files
.gitignore blocks all genetic file patterns
The code is open source — audit it yourself
Specification (OpenPGx format): Apache License 2.0
Code (MCP server, parsers): MIT License
OpenPGx is for educational and research purposes only. It does not replace professional medical advice. Always consult your physician before making decisions about medications or supplements. Genetic risk is probabilistic, not deterministic. Evidence levels and source publications are provided for every association.
OpenPGx — The open standard for AI-readable pharmacogenomics.
openpgx.ai · GitHub · npm
Check how your genes affect a medication. Supports brand names ("Ozempic"), generic names ("semaglutide"), typos ("ozmpic"), and natural language ("weight loss injection", "antidepressivo").
| Name | Required | Description | Default |
|---|---|---|---|
| drug_name | Yes | Medication name, brand name, or description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds behavioral information about handling typos and natural language, which is not covered by annotations. No contradictions.
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. The main purpose is front-loaded, followed by specific examples of supported inputs. Every word earns its place.
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 tool with one parameter and no output schema, the description is complete. It tells the user what to expect (checking genetic effects) and what inputs are accepted, leaving no 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?
The single parameter 'drug_name' is fully described in the schema (100% coverage). The description enriches it by explicitly listing supported input forms: brand names, generic names, typos, and natural language, adding meaning 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's purpose: checking genetic effects on a medication. It specifies supported input types (brand names, generics, typos, natural language), distinguishing it from sibling tools like 'check_risk' and 'compare_medications'.
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 when to use the tool (for genetic effect queries), but does not explicitly state when not to use it or suggest alternatives. Context from sibling tools provides some differentiation, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your genetic risk for a specific disease or condition. Supports: cancer, alzheimer's, diabetes, heart disease, celiac, hemochromatosis, macular degeneration, blood clots, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| condition | Yes | Disease or condition name (e.g., 'prostate cancer', 'alzheimer', 'diabetes', 'celiac') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which cover the key behavioral traits. The description adds some context (list of conditions) but does not disclose additional behaviors like authentication requirements or response format. With strong annotations, the description's marginal contribution is sufficient.
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 extremely concise, consisting of two short sentences. The first sentence states the core purpose, and the second lists examples. Every word earns its place, and the structure is front-loaded with the main action.
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 low complexity (single parameter, no output schema, no nested objects), the description is fairly complete. It covers the purpose and supported inputs. However, it does not describe the return format or behavior when a condition is not supported, which 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 already describes the 'condition' parameter with examples, and schema description coverage is 100%, earning a baseline of 3. The description adds value by enumerating specific supported conditions (cancer, alzheimer's, diabetes, etc.), enhancing the agent's understanding beyond the schema's brief example.
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's purpose: checking genetic risk for a specific disease or condition. It uses a specific verb ('check') and resource ('genetic risk'), and the list of supported conditions distinguishes it from sibling tools like 'check_medication' or 'full_risk_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?
The description implies when to use the tool by listing supported conditions, but it does not provide explicit guidance on when not to use it or alternatives. For example, it doesn't differentiate this from the related 'full_risk_report' tool. The guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two medications head-to-head based on your genetic profile. Supports brand names.
| Name | Required | Description | Default |
|---|---|---|---|
| drug1 | Yes | First medication (generic or brand) | |
| drug2 | Yes | Second medication (generic or brand) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool's safe read nature is clear. The description adds critical context that the comparison is personalized (based on genetic profile), which is beyond annotations. No contradictions.
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 extraneous information. The purpose is front-loaded and every word is informative. Ideal conciseness.
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 does not explain the return format (e.g., side-by-side comparison, scores, or textual analysis). Annotations cover safety but not result structure. For a comparison tool, some indication of output 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?
Both parameters have descriptions in the schema (e.g., 'First medication (generic or brand)'). The description reinforces 'Supports brand names' but adds no new semantics beyond the schema. With 100% schema coverage, 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 the tool compares two medications head-to-head using genetic profile, with specific verb 'compare' and resource 'medications'. It also notes support for brand names, which distinguishes it from siblings like check_medication that likely handle single drugs.
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 over siblings such as check_medication or search_drug_pgx. The description implies comparison use case but fails to specify exclusions or prerequisites like requiring a loaded genetic profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate the most comprehensive genomic report available. Runs ALL modules at once: pharmacogenomics (all genes + clinical context), disease risk assessment (all 19 conditions with study citations and PMIDs), and genetic traits (all 30+ traits with studies). Includes odds ratios, evidence levels, risk allele counts, and full bibliography. This is the 'one-click full diagnostic' — the user does NOT need to ask condition by condition.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds details about report contents (odds ratios, evidence levels, bibliography). No contradictions, and provides sufficient behavioral context for a report generation 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?
Description is informative yet reasonably concise. Key information front-loaded ('most comprehensive genomic report'). Could trim excess examples but overall well-structured and earns its length.
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 no output schema, description details what the report contains (specific numbers: 19 conditions, 30+ traits, all genes, bibliography). Provides complete mental model of tool's output. No 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?
No parameters; schema coverage is 100%. Description doesn't need to add parameter info. Baseline of 4 for zero-parameter tools 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?
Description clearly states it generates the most comprehensive genomic report by running all modules at once, listing specific components (pharmacogenomics, disease risk, traits). Distinct from siblings that focus on subsets (e.g., full_pgx_report, trait_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?
Explicitly states this is the 'one-click full diagnostic' and user does not need to ask condition by condition, implying it should be used instead of calling individual condition checks. Does not explicitly state when not to use, but context suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a complete pharmacogenomic report with all your genes, phenotypes, and affected medication categories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds context about report content (genes, phenotypes, medications) but no additional behavioral traits such as authentication needs or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose. Every word earns its place with no 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 parameters, no output schema, and clear annotations, the description adequately covers what the tool does. It could optionally elaborate on output format, but the current level is sufficient for an agent to understand the tool's role.
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 schema coverage is 100% trivially. The description adds no parameter information, which is acceptable given zero parameters; a baseline of 4 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 generates a complete pharmacogenomic report covering genes, phenotypes, and medication categories. This verb-resource combination is specific and distinguishes it from siblings like 'check_medication' or 'full_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?
The description implies usage for obtaining a comprehensive pharmacogenomic report, but offers no explicit guidance on when to use this tool over alternatives (e.g., 'check_medication' for specific drugs) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a complete genomic intelligence report covering all three modules: medications (PGx), disease risks, and traits. The most comprehensive analysis available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so description adds minimal behavioral context beyond content scope. It does not mention potential data staleness, generation time, or format, but does not contradict annotations.
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: first states purpose and scope, second emphasizes comprehensiveness. No unnecessary words or repetition.
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 no parameters and well-covered annotations, the description is mostly complete. However, it lacks info about output format or how the report is delivered (e.g., text, file), and with many sibling tools, more context on selection could help.
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 in the input schema, and schema coverage is 100%. Description does not need to elaborate on parameters; baseline score of 4 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 the tool generates a comprehensive genomic report covering medications, disease risks, and traits. It explicitly distinguishes from sibling tools like full_pgx_report and full_risk_report by mentioning 'all three modules' and 'most comprehensive analysis'.
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 a full overview is needed, and 'most comprehensive analysis' suggests this is the broadest option among siblings. However, it does not explicitly state when to use alternatives or when not to use this tool, missing some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a comprehensive genetic disease risk report covering all analyzed conditions: cancer, cardiovascular, neurological, metabolic, autoimmune, and more.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly and idempotent hints. The description adds coverage scope but omits behavioral details like output size or processing time.
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 effectively conveys purpose, though slightly wordy with 'and more' enumeration. Front-loaded with verb 'generate'.
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, the description adequately lists condition categories but lacks info on output format, size, or performance implications.
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?
Input schema has zero parameters with full coverage. The description does not explicitly state no input needed, but it's clear from context. Baseline 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 generates a comprehensive genetic disease risk report and lists specific condition categories, distinguishing it from sibling tools like 'trait_report' or 'diagnostic_all'.
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 'full_report' or 'check_risk'. Lacks explicit when-not-to-use or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a ready-to-run curl command that uploads a genome file directly to the OpenPGx server. Execute this command in your code execution sandbox or tell the user to run it in their terminal. The command sends the file WITHOUT reading it into context. After running it, use load_profile with the returned code.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the genome file (e.g., /uploads/genome.txt or the path shown in the user's message) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the command does not read the file into context, which is critical and beyond annotations. No contradictions with annotations (readOnlyHint=true, idempotentHint=true).
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 covering what, how, and next steps. No fluff, every sentence earns its place.
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, description adequately explains the return value (curl command with code) and the subsequent tool to use. Sufficient for a simple 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 adequate description. Tool description does not add new semantic meaning beyond the schema, meeting baseline but not exceeding.
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 returns a curl command to upload a genome file. Distinguishes from sibling upload tools by specifying it returns a command string rather than performing the upload directly.
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 execution instructions (sandbox or user terminal) and next step (use load_profile). Lacks explicit comparison to sibling upload tools like upload_genome, but usage is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RECOMMENDED for remote server. Load a genome profile using a code (e.g., pgx-a7b3c) from the /upload endpoint. The user ran a curl command (from get_upload_command) in their terminal or sandbox and received this code. This is the primary way to load genome data on the remote server without reading file contents into context.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Profile code from the upload command (e.g., pgx-a7b3c) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true and no destructive read/write hints. Description adds context about loading from code without file reading, and being the primary way on remote server. No contradictions.
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 wasted words. First sentence gives recommendation and action, second explains provenance. Front-loaded with key 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?
With only one parameter, no output schema, and clear annotations, the description fully covers usage context, workflow, and prerequisites.
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 already describes code parameter with 100% coverage. Description adds practical example format (pgx-a7b3c) and explains origin from upload command, adding value beyond 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?
Clearly states the tool loads a genome profile using a code from the upload endpoint. Specifies verb 'load' and resource 'genome profile'. Distinguishes from siblings by being the primary remote server method and referencing get_upload_command.
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?
Recommends for remote server and explains the workflow: user runs curl command and receives code. Provides context by mentioning get_upload_command as a prerequisite. Lacks explicit when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save pharmacogenomic research from web search as a local study. Validates the data, caches it, and returns the medication check result.
| Name | Required | Description | Default |
|---|---|---|---|
| study_json | Yes | Complete study JSON following the OpenPGx study schema |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations exist but are minimal (readOnlyHint=false, destructiveHint=false). The description adds that it validates and caches data, and returns a medication check result. It does not elaborate on side effects 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?
Two sentences totaling 20 words, conveying the purpose, actions, and output. No redundant or extraneous information. Excellent conciseness.
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?
The description explains the tool's actions (save, validate, cache) and output (medication check result). However, without an output schema, it would be beneficial to describe the return format. The annotations provide basic safety info.
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% for the single parameter study_json. The description mentions validation, but the parameter description already states it must follow the OpenPGx schema. No additional semantic value 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 explicitly states 'Save pharmacogenomic research from web search as a local study,' clearly identifying the verb and resource. It distinguishes from siblings like check_medication by focusing on saving research. However, it could be more specific about the scope.
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 like search_drug_pgx or check_medication. The description does not mention prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When no local study data exists for a drug, this tool returns a structured research prompt. Use YOUR web search capability to find pharmacogenomic data, then call save_drug_research with the results.
| Name | Required | Description | Default |
|---|---|---|---|
| drug_name | Yes | Generic drug name to research |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint, idempotentHint, openWorldHint) and adds clarity that the output is a structured prompt to be used with web search, enhancing transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded with purpose and clear instructions, free of 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?
For a simple tool with one parameter and rich annotations, the description fully covers what the tool does, its output nature, and the next step, leaving no 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?
With 100% schema description coverage, the baseline is 3. The description adds value by specifying the drug name should be generic and linking it to the missing local data context, slightly exceeding baseline.
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 structured research prompt when no local study data exists, using specific verbs and distinguishing from sibling tools by its focused use case.
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 when to use the tool ('when no local study data exists') and provides follow-up steps (use web search, then call save_drug_research), but does not explicitly exclude other scenarios or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze genes related to supplement metabolism: MTHFR, COMT, VDR, BCMO1, FUT2, CBS. Returns personalized suggestions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, destructive, and idempotent. The description adds value by specifying the genes analyzed and that it returns personalized suggestions. No contradictions with annotations; the description enriches the behavioral context beyond the structured fields.
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, well-structured sentence that front-loads the key action and resource. It names specific genes and the output, with no extraneous information. Every word earns its place.
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 has no parameters and annotations are present, the description is mostly complete. However, it lacks details on the output format (e.g., returns text, scores, or structured data) which could help the agent interpret results. Still sufficient for a simple 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?
With 0 parameters, the schema coverage is 100% and the description does not need to add parameter details. The baseline is 4 according to the rules, and the description provides sufficient context for a parameterless tool.
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 analyzes specific genes (MTHFR, COMT, VDR, BCMO1, FUT2, CBS) related to supplement metabolism and returns personalized suggestions. This clearly defines the tool's focus and distinguishes it from sibling tools like check_medication (drug-related) or trait_report (broader traits).
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 supplement-related queries but does not explicitly state when to use it over alternatives like check_medication or check_risk. No when-not or comparative guidance is provided, leaving the agent to infer based on the tool's name and focus.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover your genetic traits: caffeine metabolism, lactose tolerance, muscle type, bitter taste, sleep chronotype, alcohol flush, sun sensitivity, and more.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's main addition is listing specific traits. It does not contradict annotations and provides useful context about the tool's scope.
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 communicates the tool's purpose and key details without waste.
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 parameters or output schema, the description adequately explains the tool's purpose and differentiates it from siblings. Missing details about output format or limitations, but acceptable for a read-only 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?
No parameters exist, so the description is not required to document them. The description adds value by explaining what genetic traits are covered, meeting the baseline expectation.
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 reports genetic traits, listing specific examples like caffeine metabolism, lactose tolerance, etc. It effectively distinguishes itself from sibling tools focused on medications, risks, diagnostics, etc.
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 for exploring genetic traits but does not explicitly exclude alternative tools or specify when not to use. However, the trait focus is distinct from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse raw DNA data. Supports: 23andMe (.txt), Genera (.csv). CRITICAL: Genome files are 15-25MB (600k+ lines). NEVER read, inline, or chunk genome file contents — this WILL exceed your context window and crash the session. For REMOTE server (mcp.openpgx.ai): use get_upload_command to get a curl/python command, execute it in your code execution sandbox (or tell the user to run it in their terminal), then call load_profile with the returned code. For LOCAL server (stdio/npx): use file_path only. The url parameter is for direct download links (Google Drive, Dropbox, S3).
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No | Local file path (stdio mode ONLY — remote server cannot access local files) | |
| url | No | Direct download URL to the raw data file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true, but description adds critical behavioral details: genome files are 15-25MB (600k+ lines) and must not be read inline. No contradiction with annotations. Warns about context window overflow, which is essential for safe execution.
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 somewhat long but front-loaded with purpose and critical warnings. Every sentence earns its place, covering purpose, supported formats, size warning, mode-specific instructions, and parameter clarification. Could be slightly tighter but overall efficient.
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 (two modes, large files, multi-step upload), the description covers key use cases, constraints, and required follow-up actions (load_profile). No output schema, but the tool's return is not critical for the agent to proceed. Provides sufficient context for safe and correct invocation.
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 distinguishing file_path (local only) and url (direct download links like Google Drive, Dropbox, S3). Explains the context for each parameter beyond schema descriptions.
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 'Parse raw DNA data' and lists supported formats (23andMe .txt, Genera .csv), clearly defining its purpose. It distinguishes from siblings like upload_genome_chunk and upload_genome_start by explaining the different modes (remote vs local) and the required workflow.
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 explicit guidance: for remote server, use get_upload_command, execute in sandbox, then call load_profile; for local, use file_path. Warns against reading genome files inline, which prevents common mistakes. Covers both modes and gives step-by-step instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FOR PROGRAMMATIC MCP CLIENTS ONLY (not for LLM agents). LLM agents: use get_upload_command + load_profile instead. Sends a chunk of genome data for a chunked upload session.
| Name | Required | Description | Default |
|---|---|---|---|
| upload_id | Yes | Upload session ID from upload_genome_start | |
| chunk_index | Yes | 0-based sequential chunk index | |
| data | Yes | Chunk of raw genome file content (plain text lines, NOT base64) | |
| is_last | No | Set to true on the final chunk to trigger parsing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and readOnlyHint=false, so the description's claim of sending a chunk is consistent. The description adds the context that is_last triggers parsing, but does not mention ordering constraints or data size limits. Overall, adequate but could add more behavioral details.
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 unnecessary words. The audience restriction is front-loaded, making the most critical information immediately visible.
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 chunked upload flow, the description places the tool correctly. It references upload_genome_start indirectly via upload_id parameter. No output schema means the agent must infer return type, but for a simple chunk upload tool this is acceptable. A mention of the required prior call to upload_genome_start could enhance 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?
Input schema has 100% description coverage for all 4 parameters. The tool description does not add new semantic information beyond what is in the schema (e.g., upload_id from start, chunk_index 0-based, data raw text). Baseline 3 applies as schema does the heavy lifting.
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 sends a chunk of genome data for a chunked upload session. It also distinguishes from sibling tools like get_upload_command and load_profile by specifying the audience (programmatic clients vs. LLM agents).
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 this tool is for programmatic MCP clients only, and provides direct alternatives for LLM agents (get_upload_command + load_profile). This gives clear when-to-use and 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.
FOR PROGRAMMATIC MCP CLIENTS ONLY (not for LLM agents). LLM agents: use get_upload_command + load_profile instead. This starts a chunked upload session for clients that can stream file contents without loading into context.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Original filename (for logging only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are unremarkable (no readOnly, destructive, etc.). Description adds some behavioral context (streaming without loading into context) but omits details about session lifecycle, returned session ID, or failure modes.
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 efficiently convey audience restriction and purpose, with no unnecessary words. The critical audience warning is 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?
Despite low complexity, the description fails to mention what the tool returns (e.g., session_id) and does not guide on required subsequent steps (e.g., upload_genome_chunk). The absence of output schema makes this omission significant.
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% for the single parameter 'filename', with existing description 'Original filename (for logging only)'. The tool description adds no further semantic meaning beyond this.
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 starts a chunked upload session for programmatic MCP clients, using specific verbs and resources. It distinguishes from sibling tools like get_upload_command and load_profile.
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 specifies that it is for programmatic MCP clients only, not LLM agents, and directs LLM agents to alternative tools (get_upload_command + load_profile).
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. Dates show when Glama detected each change.
v0.4.0check_medicationcheck_riskcompare_medicationsdiagnostic_allfull_pgx_reportfull_reportfull_risk_reportget_upload_commandload_profilesave_drug_researchsearch_drug_pgxsupplement_protocoltrait_reportupload_genomeupload_genome_chunkupload_genome_startSeveral tools have overlapping purposes, notably the multiple 'full' report tools (diagnostic_all, full_pgx_report, full_report, full_risk_report) and multiple upload-related tools (upload_genome, upload_genome_chunk, upload_genome_start, get_upload_command, load_profile). Descriptions help but an agent could select the wrong one.
Naming patterns are inconsistent: some use 'verb_noun' (check_medication, upload_genome), others use 'adjective_noun' (full_report, trait_report), and some are compound (get_upload_command, upload_genome_start). No coherent pattern across the set.
16 tools cover a complex domain (pharmacogenomics, disease risk, traits, upload workflows) without being excessive. Each tool has a distinct role, though a few could potentially be consolidated.
The tool set covers major workflows: genome upload, medication and risk checking, comprehensive reports, and trait discovery. Minor gaps exist (e.g., no update/delete for saved research), but core needs are met.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Medical RAG: semantic search for clinical guidelines, drug interactions, diagnoses & EHR data.
Medical RAG: semantic search for clinical guidelines, drug interactions, diagnoses & EHR data.
Your DNA wellness report for AI: caffeine, sleep, training, nutrients. Hand-checked, no diagnoses.
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/open-pgx/openpgx'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
