Server Quality Checklist
- Disambiguation4/5
The 12 query_* tools target distinct databases (ClinVar, GWAS, PharmGKB, etc.) with clear descriptive names, though the sheer volume requires agents to carefully select the appropriate resource. Pharmacogenomics tools (get_pharmacogenomics, get_all_pharmacogenomics, get_cpic_drugs) have distinct scopes (single gene vs panel vs drug table) that are well-differentiated in descriptions.
Naming Consistency5/5Excellent consistent patterns throughout: query_* for database lookups, get_* for data retrieval, and specific action verbs (log_, prioritize_, publish_, send_) for operations. All use snake_case with clear verb_noun structure.
Tool Count3/5At 24 tools, this falls in the heavy range (16-25). While the genomic domain legitimately requires access to many distinct databases, the count approaches the threshold where agent selection accuracy may degrade. The 6 agent coordination tools add significant surface area alongside the 12 database query tools.
Completeness4/5Comprehensive coverage of genomic interpretation workflows: patient genotype access, variant prioritization (Exomiser), major clinical databases (ClinVar, CIViC, AlphaMissense), pharmacogenomics (CPIC, PharmGKB), and multi-agent coordination. Minor gaps in structural variant analysis or coverage metrics, but core SNP/variant discovery workflows are well-covered.
Average 4.1/5 across 24 of 24 tools scored. Lowest: 3.5/5.
See the tool scores section below for per-tool breakdowns.
This repository includes a README.md file.
This repository includes a LICENSE file.
Latest release: v0.1.0
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
- This server provides 24 tools. View schema
No known security issues or vulnerabilities reported.
This server has been verified by its author.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully adds domain context by explaining that HPO terms represent 'clinical phenotypes (symptoms, findings)' and mentions they are 'linked to variants,' helping the agent understand the data relationship. However, it lacks disclosure about return format, pagination, or data freshness that would be valuable given the absence of annotations and output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences. The first establishes the core function, and the second provides essential domain context (defining HPO terms as clinical phenotypes/symptoms). Every sentence earns its place; there is no redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter query tool with full schema coverage, the description adequately explains the tool's purpose and domain. However, given the lack of output schema and annotations, the description could be improved by briefly characterizing the return value (e.g., a list of phenotype terms) to complete the agent's understanding of the tool's contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (the 'gene' parameter is documented as 'Gene symbol'). The description references 'a gene' and 'variants in this gene' which aligns with the parameter usage, but does not add significant semantic depth beyond the schema's 'Gene symbol' definition. Baseline 3 is appropriate since the schema already fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Find[s] Human Phenotype Ontology terms associated with a gene' and explains that these are 'clinical phenotypes (symptoms, findings).' It uses specific verbs (find, shows) and resources (HPO terms), and explicitly references the clinical/symptom domain, distinguishing it from sibling tools like query_gene or query_disease_genes that may return general or disease-specific gene data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies usage context by mentioning 'clinical phenotypes' and 'symptoms,' it provides no explicit guidance on when to use this tool versus alternatives like query_gene or query_disease_genes. It does not state prerequisites, exclusions, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It successfully indicates this is a read-only search operation and details the categories of evidence returned (therapeutic, diagnostic, prognostic). However, it omits operational details like pagination behavior, result limits, or whether the search supports wildcards/partial matches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient two-sentence structure. First sentence establishes the database and action; second sentence specifies return value categories. No redundant phrases or filler content. Information density is high with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a simple single-parameter search tool. Given the lack of output schema, the description adequately characterizes the return value types (clinical evidence categories). For this complexity level and 100% schema coverage, no additional operational warnings or elaborations are strictly necessary, though mentioning result format would be a plus.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameter is already well-documented as accepting 'Gene name, disease, or variant.' The description does not add syntax details (e.g., HGVS format support) or search behavior specifics beyond what the schema provides, meeting the baseline expectation for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the target resource (CIViC database) and expands the acronym. Specifies the three types of annotations returned (therapeutic, diagnostic, prognostic). The 'cancer-relevant' qualifier distinguishes it from general variant databases like query_clinvar or pathogenicity predictors like query_alphamissense, though it could more explicitly contrast with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context through 'cancer-relevant variants,' suggesting this is the appropriate tool for oncology-specific clinical interpretation. However, it lacks explicit guidance on when to prefer this over query_clinvar (general clinical significance) or query_pharmgkb (drug response), which are close siblings in the tool set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds valuable behavioral context by specifying the return format ('predicted pathogenicity class and score (0-1)'), but omits other behavioral traits like error handling when rsID is not found, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with zero waste. The first sentence states purpose immediately; the second discloses return values. Every word earns its place and the structure is optimally front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with 100% schema coverage, the description is complete. It compensates for the missing output schema by describing the return values (class and score). Could be improved by mentioning error cases (e.g., rsID not found), but sufficient for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'rsid' parameter fully documented as 'dbSNP rsID'. The description implies input by referencing 'missense variant' but does not explicitly discuss the rsid parameter or add semantic details beyond the schema. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Look up') and identifies the exact resource ('AlphaMissense AI pathogenicity prediction') and context ('for a missense variant'). It clearly distinguishes from sibling query tools by specifying the AlphaMissense algorithm specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the AlphaMissense algorithm, but provides no explicit when-to-use guidance compared to siblings like query_cadd, query_clinvar, or query_civic that also provide pathogenicity predictions. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It successfully adds interpretation context for the return values (score thresholds), but omits operational details such as error handling for invalid rsIDs, data source limitations, or whether the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first front-loads the core purpose (lookup), while the second provides essential interpretation context. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup tool without output schema, the description is nearly complete. The critical addition of score interpretation (PHRED >20 meaning) compensates somewhat for the lack of return value documentation. Could be improved by noting error cases or return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('dbSNP rsID'), the schema fully documents the single parameter. The description mentions 'variant' which aligns with the rsID parameter, but adds no additional semantic detail about parameter format or validation beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the specific action ('Look up'), resource ('CADD score'), and target ('variant'). It expands the acronym CADD and specifies the exact biological database being queried, distinguishing it from sibling query tools like query_alphamissense or query_clinvar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides valuable interpretation guidance ('PHRED-scaled scores above 20 suggest top 1% most deleterious variants') that helps the agent understand result significance, but lacks explicit guidance on when to choose this tool over sibling variant annotation tools like query_alphamissense or prioritize_variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Look up' and 'Shows' imply read-only behavior, and the description compensates for missing output schema by listing return fields (pathogenicity, phenotypes, review status). However, lacks explicit safety declarations, auth requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence establishes purpose; second sentence details output. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with full schema coverage and no output schema, the description adequately compensates by detailing the three specific data categories returned. Missing annotations slightly lower the score, but sufficient for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with 'rsid' described as 'dbSNP rsID'. Description mentions 'variant' which aligns with the parameter semantics, but does not add syntax details, format constraints, or examples beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb ('Look up') + resource ('ClinVar clinical significance') + scope ('for a variant'). Naming the specific database 'ClinVar' distinguishes it from sibling tools like query_alphamissense or query_cadd.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage by specifying the unique data returned (pathogenicity classifications, star ratings), allowing inference that this is for clinical significance queries. However, lacks explicit when-to-use guidance or contrasts with sibling variant query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses what data fields are returned (traits, p-values, effect sizes), providing output transparency. However, lacks details on error handling (e.g., invalid rsID), authentication requirements, or rate limiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with zero redundancy. Front-loaded with the core action ('Look up GWAS Catalog associations'), followed by specific return value documentation. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool without output schema, the description adequately compensates by listing specific return fields (traits, p-values, effect sizes). Would benefit from mentioning error cases (e.g., rsID not found) or data coverage limitations, but sufficient for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with 'rsid' fully described as 'dbSNP rsID'. Description mentions 'variant' which loosely maps to the parameter, but adds no additional format constraints, examples, or validation rules beyond the schema. Baseline 3 appropriate for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Look up' + resource 'GWAS Catalog associations' + target 'variant' clearly defines scope. The enumeration of returned data types (traits, p-values, effect sizes, study references) distinguishes it from clinical interpretation siblings like query_clinvar or query_civic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies the domain (GWAS Catalog, genome-wide association studies) which implies usage for population genetics research, but lacks explicit when-to-use guidance or contrasts with alternative tools like query_snpedia or query_civic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return data types (drug-gene interactions, dosing guidelines, clinical annotations) but omits operational details like error handling, 'not found' behavior, rate limits, or authorization requirements. 'Look up' implies read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first establishes action and resource, second specifies output content. Front-loaded with verb, no filler words, appropriate length for single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with 1 parameter and no output schema, description adequately compensates by enumerating return data categories. Would benefit from mentioning error cases or empty result handling, but sufficient for complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% ('dbSNP rsID' fully documented), establishing baseline 3. Description mentions 'for a variant' which loosely maps to the rsid parameter but adds no validation rules, format examples, or semantic constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Look up' with explicit resource 'PharmGKB pharmacogenomic annotations' and distinguishes from siblings like query_clinvar/query_civic by naming the specific PharmGKB database and unique data types (dosing guidelines, drug-gene interactions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage domain through 'PharmGKB' specificity and clinical annotation focus, but lacks explicit when-to-use guidance or comparison to sibling pharmacogenomic tools (get_pharmacogenomics, get_cpic_drugs, query_civic). No exclusions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It successfully discloses the output style ('plain-language explanations') and data source characteristics ('community-curated'), but fails to mention safety properties (read-only), error handling (invalid rsIDs), rate limits, or whether it returns structured data vs free text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The two-sentence structure is optimally front-loaded: sentence one defines the core action, sentence two provides essential domain context. No words are wasted, and the density of information (resource type, content style, data provenance) is high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with no output schema, the description adequately compensates by explaining the return value type ('plain-language explanations'). Given the tool's simplicity and clear scope, the description is sufficiently complete, though explicit error behavior would strengthen it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'rsid' parameter, including a clear example. The description does not add parameter-specific semantics beyond the schema, meeting the baseline expectation for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (look up), resource (SNPedia summary), and scope (variant). It effectively distinguishes from technical siblings like query_clinvar or query_cadd by emphasizing 'plain-language explanations' and 'community-curated wiki,' signaling this is for human-readable interpretations rather than clinical or computational data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description characterizes SNPedia as providing 'plain-language explanations' (implying use when interpretable summaries are needed), it lacks explicit when-to-use guidance contrasting it with the 20+ sibling query tools. No alternatives are named, and there are no exclusion criteria or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses return content ('pharmacogenes mapped to their affected medications with clinical guideline levels'). However, it omits operational details like data freshness, caching behavior, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficiently structured sentences with zero waste: the first defines the resource and return structure, the second specifies the clinical use case. Information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Strong coverage given no output schema exists: the description compensates by detailing the return structure (genes mapped to medications with guideline levels). Minor gap in not explaining what 'CPIC' stands for or the significance of 'clinical guideline levels' for users unfamiliar with pharmacogenomics nomenclature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single optional 'gene' parameter. The description does not add parameter-specific semantics, but the guidelines specify a baseline of 3 when schema coverage is high (>80%) and the schema already documents the filtering behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('CPIC gene-drug interaction lookup table'), clearly distinguishing it from sibling tools like get_pharmacogenomics or query_pharmgkb by specifying the CPIC (Clinical Pharmacogenetics Implementation Consortium) guideline source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context ('Use this to identify drug interaction risks for a patient's metabolizer profile'), but lacks explicit comparison to alternatives like get_pharmacogenomics or query_pharmgkb, or guidance on when CPIC guidelines are preferred over other databases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds valuable context about CPIC table querying and genotype checking at defining positions, but omits critical safety disclosure (read-only vs destructive), error handling for invalid gene symbols, and whether results are cached or real-time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. Front-loaded with core action ('Get pharmacogenomic results'), followed by implementation details (CPIC queries, genotype checking). Every clause provides distinct information about data source, content type, or mechanism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Strong coverage given no output schema: explicitly lists return content (allele definitions, drug recommendations, genotypes) and data source. Deducted one point for missing safety profile (read-only status) which is critical in pharmacogenomic contexts and absent from annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter description. Description adds substantial value by explaining how the gene parameter is used: to query CPIC allele definitions and check patient genotypes at 'defining variant positions'—context not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb-resource combination ('Get pharmacogenomic results') and explicitly scopes to 'a specific gene', clearly distinguishing from sibling get_all_pharmacogenomics. Details data sources (CPIC tables) and outputs (allele definitions, drug recommendations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies scope limitation (single gene vs comprehensive) which helps differentiate from get_all_pharmacogenomics, but lacks explicit when-to-use guidance or comparison to query_pharmgkb/query_civic alternatives. No mention of prerequisites like patient consent or available genotype data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and successfully discloses return structure ('chromosome, position, and the patient's alleles') with concrete examples ('AG', 'CC', 'TT'). However, it omits error handling (e.g., rsID not found behavior) and authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first states purpose, second discloses return format. Every word earns its place and the description is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool without output schema, the description adequately compensates by detailing return values. Lacks only error-condition disclosure to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the rsid parameter fully documented as 'dbSNP rsID, e.g. 'rs1234567''. The description adds no additional parameter semantics beyond the schema, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Look up'), resource ('patient's genotype'), and scope ('for a specific rsID'). The 'specific rsID' phrasing effectively distinguishes this from the sibling tool query_genotypes_batch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies singular use via 'specific rsID', but provides no explicit guidance on when to prefer query_genotypes_batch for multiple variants, nor any prerequisites for accessing patient genomic data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It adds efficiency comparison context but omits behavioral details like return format, error handling for invalid rsIDs, or privacy implications of accessing patient genotype data. The 'up to 200' limit duplicates schema maxItems.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence states purpose and limits; second provides usage guidance. Information is front-loaded and dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter batch lookup tool. Given no output schema, could benefit from brief mention of return structure (e.g., mapping of rsIDs to genotypes), but the clinical sensitivity of 'patient genotypes' makes this sufficiently complete for selection purposes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is met. The description reinforces the batch nature of the rsids parameter but does not add semantic details beyond the schema's 'Array of rsIDs to look up' (e.g., rsID format, validation rules).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Look up' with clear resource 'patient genotypes' and scope 'multiple rsIDs at once (up to 200)'. It effectively distinguishes from sibling tool query_genotype by emphasizing batch processing efficiency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use ('when checking many variants') and implicitly references the alternative ('individual lookups'), suggesting when the singular query_genotype is more appropriate. Lacks explicit 'when-not' exclusion statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It adds valuable context about internal behavior (retrieves genotypes at 'key defining variant positions' and performs CPIC allele lookup to derive star alleles), but lacks disclosure on performance characteristics, idempotency, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with zero waste: sentence 1 establishes scope (all 34 genes), sentence 2 explains mechanism (genotype retrieval and allele derivation), and sentence 3 provides usage positioning (starting point). Information is front-loaded and dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex domain (pharmacogenomics), no output schema, and zero annotations, the description adequately explains the conceptual return value (star alleles, genotypes) and scope. It could be improved by mentioning output structure or payload size implications given the 'all 34 genes' scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters. Per the scoring rules, zero parameters establishes a baseline score of 4, as there are no parameter semantics to describe beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it retrieves a 'complete pharmacogenomics panel across all 34 CPIC pharmacogenes' and derives 'star alleles'. It clearly distinguishes from sibling 'get_pharmacogenomics' by emphasizing 'complete', 'all 34', and 'comprehensive' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It positions the tool as 'the comprehensive starting point for pharmacogenomic analysis', providing clear context for when to use it (initial broad screening). However, it does not explicitly name alternatives like 'get_pharmacogenomics' for targeted single-gene queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses the polling pattern and return filtering ('addressed to you or broadcast'), compensating partially for missing output schema. However, it omits whether messages are consumed/destructively removed or persistent, and lacks safety/permission context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. First sentence states purpose; second combines usage frequency with return value description. Efficiently front-loaded with no redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a zero-parameter read operation. Description compensates for missing output schema by documenting return content (filtered messages). Lacks annotations but covers essential behavioral context for coordination use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present, establishing baseline 4 per rubric. Description appropriately focuses on behavior rather than parameters, requiring no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Check' with resource 'agent chatroom for messages'. Clearly distinguishes from sibling 'send_message' (outbound vs inbound) and all genetic/medical query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit polling frequency guidance ('Call every 5-10 tool uses') and explains coordination purpose. Lacks explicit 'when not to use' or alternative comparison, but the frequency directive strongly guides invocation timing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses specific methodology (sex determination from X chromosome heterozygosity) and return content, but omits operational details like whether this is read-only, caching behavior, or computational cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences: first defines functionality and outputs, second provides usage timing. Zero redundancy. Information density is high with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter summary tool without output schema, the description adequately covers what data is returned. Could be improved by mentioning output format structure or indicating if the summary is cached/updated in real-time.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters (coverage 100%), establishing baseline 4. Description correctly implies no filtering is possible (returns overall patient summary), which aligns with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' with clear resource 'patient's genotype data' and enumerates exact outputs (variant count, chromosome distribution, sex from X heterozygosity). Clearly positions itself as a summary/overview tool distinct from sibling query tools like query_genotype or get_acmg_genes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Call this first to understand the scope of data available,' providing clear workflow positioning. However, it does not explicitly name alternatives for when NOT to use it (e.g., when detailed variant data is needed instead of summary stats).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Read' implies a safe, non-destructive operation, but the description lacks specifics about return format, filtering capabilities, or whether findings are cached versus real-time. Adequate but minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences: the first declares functionality, the second declares utility. No redundant phrases or tautologies. Information density is high with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter input schema and lack of output schema, the description adequately covers the tool's purpose and intent. Could be improved by briefly describing the structure of returned findings or any scope limitations (e.g., temporal range).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, which per guidelines establishes a baseline of 4. The description correctly implies no filtering parameters are available ('Read all findings'), consistent with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Read') and resource ('findings published by other agents'). It effectively distinguishes this tool from siblings like 'publish_finding' (write vs read) and database query tools by emphasizing cross-agent research aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases ('understand cross-domain patterns, avoid duplicating research, and build on others' discoveries') that clarify when to invoke the tool. Lacks explicit 'when not to use' guidance or named alternatives, though the use cases sufficiently imply appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It successfully discloses scope ('all agents') but lacks operational details like pagination, data retention periods, rate limits, or response format that would help an agent handle the results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first states function, second states value proposition. Appropriately front-loaded and sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with no output schema, the description adequately covers essential context. Could be improved by mentioning return format or relationship to log_web_search, but sufficient for complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters with 100% schema description coverage (empty object). Per rubric, 0 params warrants baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'See' with clear resource 'web searches' and scope 'all agents', distinguishing it from sibling tools like log_web_search and various gene query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases ('avoid duplicating research', 'discover what others have already looked up') but does not explicitly name alternatives like log_web_search or indicate when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and successfully discloses critical behavioral traits: deduplication logic and the consequence of duplicates ('asked to find a new angle'), plus volume constraints. Does not clarify persistence scope or return value, but covers the essential operational quirks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: purpose statement, volume constraint, and deduplication warning. Information is front-loaded and every clause earns its place. Appropriate length for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and no output schema, the description adequately covers operational constraints (volume, deduplication) that an agent needs to use the tool correctly. Minor gap regarding visibility/persistence scope of published findings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high at 83%, establishing a baseline of 3. The description adds contextual guidance that findings should be 'significant' and unique (due to deduplication), indirectly guiding the 'finding' parameter content, but does not elaborate on the 'type' enum values or 'variants' format beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Share... with other agents') and resource (findings/discoveries), clearly distinguishing this publishing tool from the numerous 'query_' and 'get_' retrieval siblings, as well as from 'send_message' by specifying research findings rather than generic communication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit volume guidance ('3-5 most significant discoveries per analysis') implying quality thresholds, and explains deduplication behavior. Lacks explicit named alternatives or 'when not to use' exclusions (e.g., vs. logging or messaging), but the volume constraint effectively guides appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses the external data source (DisGeNET) and ranking behavior (association score). It implies read-only behavior via 'Find' and 'Returns', though it omits error handling or rate limit details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: sentence 1 states core function and data source, sentence 2 provides usage context, and sentence 3 describes output ordering. Information is front-loaded and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter query tool without output schema, the description adequately covers the essential behavioral contract: input (disease), process (DisGeNET lookup), and output (ranked genes). It could improve by describing the return structure (e.g., gene symbols vs. IDs) or empty-result behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies. The description does not explicitly discuss the 'disease' parameter, but the schema fully documents it with examples ('breast cancer', 'diabetes'), making additional description unnecessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds genes associated with diseases using DisGeNET, providing specific verb (Find), resource (genes), and distinguishing the data source. It also clarifies the output is ranked by association score, differentiating it from siblings like query_gene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context ('Useful to discover which genes to investigate for a particular health concern'), establishing when to use the tool. However, it lacks explicit contrast with alternatives like query_gene (gene-centric lookup) or query_hpo (phenotype-based).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses critical behavioral details: multi-database cross-referencing and the two-step workflow (find variants → check patient carriage). Missing safety/performance traits (rate limits, auth requirements), but core behavioral logic is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: sentence 1 defines core action, sentence 2 defines patient-specific filtering, sentence 3 provides usage guidance. Perfectly front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately explains the multi-source aggregation workflow for a moderately complex tool. Given no output schema exists, absence of return value documentation is acceptable, though inclusion would strengthen completeness further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage with clear examples ('BRCA1', 'CYP2D6'). Description mentions 'gene' in context but adds no semantic information beyond the schema. Baseline 3 appropriate when schema documentation is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Find ALL known variants') and resources (ClinVar, GWAS, AlphaMissense). Explicitly distinguishes from siblings like query_clinvar or query_gwas by emphasizing the cross-referencing/aggregation behavior across all three sources simultaneously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly positions the tool as 'the best starting point for investigating a specific gene,' providing clear entry-point guidance. However, lacks explicit 'when not to use' guidance or named alternatives for specific use cases (e.g., when you only need single-database data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses the key behavioral trait: returning a warning if duplicate research exists. It implies write-side effects through 'Log' but could explicitly state this creates a persistent record. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: sentence 1 states purpose, sentence 2 gives timing instruction, sentence 3 explains return behavior. Information is perfectly front-loaded and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema and lack of output schema, the description adequately compensates by describing the return value behavior ('warning if...similar'). Minor gap in not describing the success case (what happens when no duplicate exists).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the query parameter fully documented. The description aligns with the schema ('search query or URL') but adds no additional syntax details or examples beyond what the schema already provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Log') with a clear resource ('web search') and explicitly distinguishes from sibling 'get_web_searches' by emphasizing this is a proactive logging action ('you are about to perform') versus retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit temporal guidance ('Call BEFORE every web search') and clear value proposition ('avoid duplicate research across agents'). It effectively communicates when to use this tool versus skipping it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It successfully adds critical behavioral context about visibility ('Messages appear in a shared chatroom visible to all agents and the human operator') that is not inferable from the schema. Lacks details on persistence or delivery guarantees, but covers the essential social/visibility dynamics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with zero redundancy: core function (sentence 1), usage patterns (sentence 2), and side effects/visibility (sentence 3). Information is front-loaded with the essential action, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a 3-parameter communication tool without output schema. Covers functional purpose, usage scenarios, and visibility side effects. Could be improved by mentioning error handling (e.g., invalid agent IDs) or message persistence, but adequately covers the essential operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage (baseline 3). Description adds domain-specific value by guiding message content ('include specific variants/genes/findings') appropriate to the bioinformatics toolset context, and reinforces the broadcast capability mentioned in the 'to' parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb-noun pair ('Send a message') and immediately clarifies scope ('to another agent or broadcast to all'). It effectively distinguishes from sibling 'get_messages' by specifying this is an outbound communication action rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use-case guidance ('Use to share discoveries, ask questions, or alert others to important cross-domain connections') establishing when to invoke the tool. However, it lacks explicit exclusions or differentiation from close sibling 'publish_finding', leaving ambiguity about when to publish versus send messages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It compensates well by specifying the return format (gene name, condition, inheritance pattern) and data volume (73 genes), and notes the specific version (v3.2) for reproducibility. Could mention caching behavior or data freshness, but covers essential behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: first defines the resource and version, second discloses return fields, third provides usage intent. No redundant text or boilerplate. Well front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter retrieval of a static standard list, the description is complete. It compensates for the missing output schema by detailing what fields are returned. The version number (v3.2) and gene count provide necessary context for clinical reproducibility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters. Per scoring rules, zero-parameter tools receive a baseline score of 4. The description correctly implies no filtering is needed by stating it returns the complete list of 73 genes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies exact resource (ACMG Secondary Findings v3.2 gene list), action (Get), and scope (73 genes). The specific reference to 'medically actionable genes' clearly distinguishes this from sibling tools like query_gene or query_disease_genes which handle general gene queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context ('Use this to systematically check all medically actionable genes'), indicating when to use the tool for clinical screening. Lacks explicit naming of alternatives (e.g., 'use query_gene for non-ACMG genes'), but the specific ACMG scope makes the appropriate use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses the external dependency (Exomiser), installation requirement, and silent failure mode ('Returns nothing'). Minor gap in not describing the success return format or safety profile (read-only vs destructive) given the lack of output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with zero waste: purpose (sentence 1), usage/params (sentence 2), authority/context (sentence 3), and prerequisites/failure modes (sentence 4). Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately covers prerequisites, failure modes, and sibling alternatives. Minor gap in not describing the structure of successful return values (e.g., ranked gene list format), though it implies ranking behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. The description adds clinical context for hpo_terms ('describing the patient's symptoms/conditions'), enhancing understanding of what the parameter represents beyond the technical schema definition. Does not address inheritance or max_results, but adds significant value for the required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('prioritize') and resource ('patient variants'), explicitly names the underlying algorithm ('Exomiser'), and distinguishes this from sibling tools by specifying it matches phenotypes to variants for rare disease cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('gold-standard tool for rare disease variant prioritization'), prerequisites ('Requires Exomiser to be installed'), and fallback strategy ('Returns nothing if Exomiser is not available — use other query tools instead'), providing clear decision boundaries against the many sibling query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
How to claim the server?
If you are the author of the server, you simply need to authenticate using GitHub.
However, if the MCP server belongs to an organization, you need to first add glama.json to the root of your repository.
{
"$schema": "https://glama.ai/mcp/schemas/server.json",
"maintainers": [
"your-github-username"
]
}Then, authenticate using GitHub.
Browse examples.
How to make a release?
A "release" on Glama is not the same as a GitHub release. To create a Glama release:
- Claim the server if you haven't already.
- Go to the Dockerfile admin page, configure the build spec, and click Deploy.
- Once the build test succeeds, click Make Release, enter a version, and publish.
This process allows Glama to run security checks on your server and enables users to deploy it.
How to add a LICENSE?
Please follow the instructions in the GitHub documentation.
Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear on the server after some time, you can manually trigger a new scan using the MCP server admin interface.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level description quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.