sniff-mcp
Server Details
Canine genomics for agents: breed allele frequencies + AI pathogenicity over the open Sniff Atlas
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 13 of 13 tools scored. Lowest: 2.7/5.
Some tools overlap in purpose, such as ask_variant_context and variant_lookup both providing single-variant information, and breed_similarity and nearest_breeds both dealing with genetic distances. The descriptions do help differentiate them, but the similarities may cause confusion.
Most tools follow a verb_noun or noun_noun pattern with underscores (e.g., breed_similarity, variant_search). The only outlier is ask_variant_context, which uses a different convention. Overall, the naming is mostly consistent.
With 13 tools, the server covers a well-scoped domain of canine genetics queries. Each tool serves a clear purpose, and the count is neither too few nor too many for the intended functionality.
The tool set covers core query operations for variants, breeds, and genes. Minor gaps exist: disease_links is marked as incomplete, a full gene list is missing, and there is no direct way to compare multiple breeds. However, these gaps are not critical for basic usage.
Available Tools
13 toolsask_variant_contextAInspect
THE headline query. Given a CanFam4 position (e.g. '5:56189113'), return the variant's global + popmax frequency, breed-stratified cross-breed frequencies, ESM2/Pangolin/phyloP pathogenicity, gene context, linked diseases (v1.1), provenance, and deep links — in one call. Pass breed_context to also get that breed's AF + rank. cross_breed_full=True returns all 188 breeds (default: top_n).
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | ||
| position | Yes | ||
| breed_context | No | ||
| cross_breed_full | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It describes the returned data and optional parameters but does not explicitly state read-only behavior, error handling, or prerequisites like genome build validity. The description is clear but lacks explicit safety disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence is dense but clear, and the second concisely explains optional parameters. All information is front-loaded and relevant.
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 complexity and the presence of an output schema, the description provides a solid overview of what is returned. It specifies the genome build (CanFam4) and optional tuning. Minor omissions include no mention of output format or error cases, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning for 3 of 4 parameters: position format (example given), breed_context (effect explained), cross_breed_full (behavior described). top_n is not described, but defaults are noted. The description compensates well for missing 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 clearly states the tool returns comprehensive variant information given a CanFam4 position, including frequencies, pathogenicity, gene context, diseases, and more. It distinguishes itself from sibling tools (e.g., variant_lookup, breed_variant_frequency) by being a one-call aggregator, marked as 'THE headline query'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage is for comprehensive variant info, and the description hints it's the primary query. However, no explicit when-not-to-use or alternative recommendations are given, though sibling tool names suggest alternatives for focused needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
breed_similarityBInspect
Genetic distance between two breeds (top-10-PC Euclidean). Lower = more genetically similar.
| Name | Required | Description | Default |
|---|---|---|---|
| breed_a | Yes | ||
| breed_b | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the metric and interpretation, which adds behavioral context beyond missing annotations. However, it does not disclose limitations, assumptions, or output format (though output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with a parenthetical clarification is concise and front-loaded. However, it might be too terse; could include more details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and an output schema, the description covers purpose and metric but omits interpretation details (e.g., range of values) and constraints (e.g., which breeds are valid). Adequate but not comprehensive.
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 description adds meaning that the parameters are breeds and that the tool computes genetic distance, compensating for 0% schema coverage. However, it does not specify breed naming conventions or valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes genetic distance between two breeds using top-10-PC Euclidean distance, and interprets lower values as more genetically similar. It distinguishes itself from siblings like 'nearest_breeds' by explicitly being pairwise.
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 over alternatives such as 'nearest_breeds' or 'breed_summary'. No prerequisites or context provided for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
breeds_in_atlasAInspect
List all 188 breeds with breed-stratified frequencies in the atlas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose any behavioral traits (e.g., caching, limitations). It only states output content.
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, no wasted words, front-loaded with key action and scope.
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?
Complete for a simple list tool with output schema; explains both content (breeds and frequencies) and scope (all 188 breeds).
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?
Zero parameters; baseline is 4. Description correctly implies no input needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List' and resource 'breeds', adds detail about output ('with breed-stratified frequencies'), and distinguishes from siblings like breed_summary and breed_variant_frequency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; given many sibling tools, explicit context would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
breed_summaryAInspect
Breed profile: top damaging common variants (ESM2<=-5 & breed AF>=5%), n_dogs, breed group. Descriptive only — not a health ranking.
| Name | Required | Description | Default |
|---|---|---|---|
| breed | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses the output fields and the filtering criteria for variants, and explicitly states the tool is descriptive (not evaluative). This is transparent about behavior, though it does not mention idempotency 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 two sentences, front-loaded with key content, and contains no filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and an output schema exists, the description is fairly complete. It explains the selection criteria for variants and the fields returned, and warns that it is not a health ranking. It could be slightly improved by noting that the breed must match atlas breed names.
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?
There is only one parameter 'breed' of type string. With 0% schema description coverage and no enum values, the description should compensate by clarifying allowed values or format, but it does not. The description focuses entirely on output, not input semantics.
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 provides a breed profile with specific content: top damaging common variants (with explicit criteria ESM2<=-5 & breed AF>=5%), n_dogs, and breed group. It distinguishes itself from sibling tools like disease_links and breed_variant_frequency by emphasizing it is descriptive only, not a health ranking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by stating 'Descriptive only — not a health ranking,' which implicitly tells when not to use it (health ranking). However, it does not explicitly mention when to use this tool over alternatives like breed_variant_frequency or semantic_search, nor does it provide prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
breed_variant_frequencyAInspect
Breed-stratified allele frequency. Give a breed (e.g. 'bernese_mountain_dog') plus either a variant position or a gene symbol. Returns AF (+ rank) for the variant, or per-variant AFs in the gene.
| Name | Required | Description | Default |
|---|---|---|---|
| gene | No | ||
| breed | Yes | ||
| variant | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description does a fair job explaining that it returns AF and rank for a variant or per-variant AFs for a gene. It does not disclose any permissions, error behaviors, or data freshness, but covers the core behavior sufficiently.
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—two sentences no waste—with the key information front-loaded. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and the existence of an output schema, the description sufficiently explains the two operating modes and return values. It could elaborate on edge cases like missing breed, but overall it is complete for an AI agent to use the tool correctly.
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 0%, so the description must compensate. It explains the roles of breed, variant, and gene, but does not clarify mutual exclusivity or the format of the variant string. The description adds some meaning but leaves ambiguity about what happens if both variant and gene are provided.
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 'Breed-stratified allele frequency' and explains two modes (by variant or gene). It uses specific verbs ('Give', 'Returns') and distinguishes from sibling tools like variant_lookup by specializing to breed stratification.
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 tells the agent to provide a breed and either a variant or gene symbol, which defines when to use the tool. However, it does not explicitly state when not to use it or mention alternatives among siblings for non-breed-stratified queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
disease_linksBInspect
Disease -> genes/variants/breeds. NOTE: the v1 public release is OMIA-free; the disease/clinical layer ships in v1.1. For now use gene/variant/breed RPCs.
| Name | Required | Description | Default |
|---|---|---|---|
| disease | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses the version constraint but omits details about empty parameter behavior. Output schema exists but not described.
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; the first is concise but cryptic, the second is a necessary note. Could be clearer with better structure.
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?
Has output schema, reducing return value burden. Missing basic parameter guidance, but version note is helpful. Adequate 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 description coverage is 0% and the description adds no semantics for the 'disease' parameter—no format, example, or usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps diseases to genes, variants, and breeds. It distinguishes from sibling tools that focus on specific entities. However, the arrow notation is slightly cryptic.
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 notes the current version lacks OMIA/clinical data and advises using alternative RPCs, providing 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.
genes_indexedCInspect
Top genes by number of variants in the atlas (discovery aid).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose whether results are sorted descending, pagination limits, or any side effects. Only a vague functional statement.
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 is efficient and front-loaded with key information. However, it could be expanded slightly to improve clarity without losing 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?
Despite having an output schema, the description lacks details about what 'top genes' means, how the atlas is defined, and whether results include metadata. Insufficient for confident tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description must compensate. But it makes no mention of the 'limit' parameter, leaving agents to infer its meaning from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns top genes by variant count, which is distinct from siblings like gene_summary. 'Discovery aid' adds context but could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. 'Discovery aid' hints at exploratory use but lacks detail on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gene_summaryAInspect
Variants in a gene (by gene symbol), ranked by impact then ESM2 damage. Paginated (limit, default 25); returns total_variants. Use af_min to filter by global AF.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| af_min | No | ||
| gene_symbol | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses pagination and a filter but fails to mention other behaviors like authorization needs, rate limits, or whether operations are read-only. Basic but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with purpose and key details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential usage (pagination, filter) for a tool with output schema; but missing behavioral details and usage guidelines, leaving gaps for an agent.
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?
Description explains limit default and af_min as global AF filter, but gene_symbol is not elaborated beyond 'by gene symbol' in purpose. Schema coverage 0% means description adds some value but not full.
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 returns variants for a given gene symbol, ranked by impact and ESM2 damage, with pagination. Differentiates from siblings like variant_search which searches across variants.
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?
Implies usage for retrieving variants per gene; mentions af_min filter but gives no explicit when-to-use vs alternatives. No when-not or alternatives given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
metadataAInspect
Atlas metadata: release, DOI, assembly, variant/breed counts, scope banner, and the RPC catalog.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits; it only lists metadata contents, omitting side effects, auth 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?
Single sentence, front-loaded with purpose, lists specific items efficiently—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 zero parameters and an existing output schema, the description is adequate for a simple metadata retrieval tool; could mention return format but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% trivially; baseline for 0 parameters is 4, and the description adds no parameter info beyond what's implied.
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 'Atlas metadata' and lists specific items (release, DOI, assembly, etc.), distinguishing it from sibling tools that handle specific queries like variant context or breed similarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives; no context about prerequisites or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
nearest_breedsAInspect
Genetically nearest breeds to the given breed (top-10-PC Euclidean in canine genetic space). Answers 'what breeds are most genetically similar to X?' via the PCA-256 breed co-embedding.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| breed | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the computation (Euclidean distance in PCA-256 space) but omits behavioral aspects like side effects, authorization requirements, or performance characteristics. As a readonly computation tool, the description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (context signal), the description does not need to explain return values. It sufficiently describes the tool's function, though it could be slightly more explicit about the 'k' parameter and the number of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'breed' and 'top-10' which correspond to the 'breed' parameter and default 'k' value, but does not explicitly describe the 'k' parameter or its range. The description adds context (genetic space) but does not fully explain parameter semantics.
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 genetically nearest breeds using PCA-256 breed co-embedding, specifying 'top-10-PC Euclidean in canine genetic space'. This distinguishes it from sibling tools like 'breed_similarity' (which might use different similarity measures) and 'breeds_in_atlas'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('answers what breeds are most genetically similar to X?') but does not explicitly state when not to use it or mention alternatives. The sibling tool 'breed_similarity' suggests a possible alternative, but no contrast is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
semantic_searchAInspect
Faceted hybrid + semantic-ranker search over the whole knowledge base (diseases, breeds, Scout discoveries). Use for fuzzy/thematic intent ('drug sensitivity in herding dogs', 'breeds prone to eye disease', 'genetically diverse breeds'). entity_type filters to 'disease'|'breed'|'discovery'. filters is an OData facet expression for cross-dimension queries, e.g. "breed_group eq 'herding' and cohort_n ge 30" or "diversity_tier eq 'severe_bottleneck'" (facets: type, breed, breed_group, gene, evidence_tier, confidence_tier, diversity_tier, cohort_n). Returns ranked entities with snippets, dimension fields, links.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| filters | No | ||
| entity_type | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description covers behavior well: it indicates the tool searches the whole knowledge base, returns ranked entities with snippets and dimension fields, and explains filter syntax. It does not mention any destructive behavior or auth requirements, which is acceptable for a read-only search.
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 dense paragraph that front-loads the purpose and provides examples. It contains no fluff, but could be slightly more structured (e.g., bullet points) for readability. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with no schema descriptions, no annotations, and an output schema exists, the description explains the overall functionality and two parameter uses well. However, it does not detail the return format beyond a brief mention, and lacks coverage for query and top_k.
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 0%, and the description adds meaning for filters and entity_type with examples and facet list. However, query and top_k are not explained beyond what the schema provides (name and type). The description partially compensates for the lack of schema descriptions but not fully.
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 performs 'Faceted hybrid + semantic-ranker search' over the entire knowledge base, listing example intents and distinguishing it from sibling tools like variant_search. It specifies the scope and type of search.
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 says 'Use for fuzzy/thematic intent' with example queries. It explains how to use entity_type and filters with patterns. However, it does not explicitly state when to use alternative tools or provide a when-not-to-use section.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
variant_lookupBInspect
Single-variant lookup by CanFam4 position: ref/alt, global + popmax AF, consequence, gene, ESM2/Pangolin/phyloP, deleteriousness tier, canonical URL, provenance.
| Name | Required | Description | Default |
|---|---|---|---|
| position | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It lists return fields but does not disclose behaviors such as required permissions, rate limits, or error handling for invalid positions. As a lookup tool, it is likely read-only, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and key outputs. No extraneous words, and the main action 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?
The tool is simple (one parameter, has output schema). The description covers the main return fields and purpose. However, it lacks usage guidance and error context, but overall sufficient for a straightforward lookup 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 description coverage is 0%, so the description must compensate. It specifies 'by CanFam4 position', giving genome assembly context, but does not detail the exact format expected (e.g., 'chr:pos' or 'ref/alt'). Partial guidance, but could be more precise.
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 is a single-variant lookup by CanFam4 position, listing specific outputs (ref/alt, AF, consequence, etc.). This distinguishes it from sibling tools like variant_search (which likely searches multiple variants) and ask_variant_context (which may provide broader context).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for a specific variant by genomic position, but does not mention scenarios where variant_search or ask_variant_context might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
variant_searchAInspect
Filtered discovery over all 9.67M variants. Predicates (combine freely): esm_max (ESM2 LLR <=), phylop_min (phyloP >=), popmax_min (popmax AF >=), gene_in (list of gene symbols), consequence, impact (HIGH/MODERATE/LOW/MODIFIER). Returns total_count + a capped list (max 200). Note: popmax may be in a wild population (dingo/village) — check popmax_breed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| impact | No | ||
| esm_max | No | ||
| gene_in | No | ||
| phylop_min | No | ||
| popmax_min | No | ||
| consequence | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses return format (total_count + capped list max 200) and a nuanced note about popmax breed. However, it doesn't mention if the operation is read-only or any potential side effects, but 'discovery' implies read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 3 sentences, front-loading the purpose. It uses a colon and list format for predicates, which is efficient. However, it could be slightly more structured with line breaks.
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 (9.67M variants, 7 optional parameters), the description covers key aspects: filter predicates, return format, and a special note. Output schema exists, so return values are handled. Missing details on sorting or pagination beyond the cap, but acceptable.
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 0%, so the description compensates well. It explains the meaning of esm_max, phylop_min, popmax_min, gene_in, consequence, and impact (with allowed values). Only 'limit' is not explained, which is common.
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 'Filtered discovery over all 9.67M variants' with specific verb and resource. It lists all filter predicates, differentiating it from sibling tools like variant_lookup.
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 states predicates can be combined freely but does not explicitly guide when to use this tool vs alternatives or when not to use it. It implies usage for filtering discovery, but no exclusions or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!