regionVariants in a genomic region (≤25kb recommended).
| Name | Required | Description | Default |
|---|---|---|---|
| stop | Yes | ||
| chrom | Yes | e.g. "1", "X", "MT" | |
| start | Yes | ||
| dataset | No |
| Name | Required | Description | Default |
|---|---|---|---|
| region | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / examplesAdded value: +[
+ {
+ "chrom": "1",
+ "start": 55000000,
+ "stop": 55025000
+ },
+ {
+ "chrom": "X",
+ "dataset": "gnomad_r4",
+ "start": 123400000,
+ "stop": 123420000
+ }
+]Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "region": {
+ "properties": {
+ "variants": {
+ "items": {
+ "properties": {
+ "consequence": {
+ "description": "VEP consequence",
+ "type": "string"
+ },
+ "exome": {
+ "properties": {
+ "ac": {
+ "description": "Allele count",
+ "type": "number"
+ },
+ "af": {
+ "description": "Allele frequency",
+ "type": "number"
+ },
+ "an": {
+ "description": "Allele number",
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "genome": {
+ "properties": {
+ "ac": {
+ "description": "Allele count",
+ "type": "number"
+ },
+ "af": {
+ "description": "Allele frequency",
+ "type": "number"
+ },
+ "an": {
+ "description": "Allele number",
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "rsids": {
+ "description": "rsID identifiers",
+ "type": [
+ "array",
+ "null"
+ ]
+ },
+ "variant_id": {
+ "description": "Variant identifier",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds the 25kb size recommendation, which is a useful performance/completeness constraint. However, it does not disclose coordinate system (e.g., hg19 vs hg38), what happens for larger regions, or dataset-specific behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler words. Every part ('Variants in a genomic region' and '≤25kb recommended') adds essential information, making it perfectly concise.
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 presence of an output schema and rich annotations reduces the burden on the description. The size recommendation is helpful, but the description omits critical context such as the reference genome build, coordinate convention, and dataset semantics. Overall, it is minimally adequate but leaves gaps that could cause incorrect usage.
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 only 25% (only 'chrom' has a description). The description adds that start/stop define a genomic region and recommends a maximum size of 25kb, giving some meaning to those coordinates. Yet it does not specify units or coordinate convention, and the 'dataset' parameter is entirely unexplained, so the description only partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns variants within a genomic region, which distinguishes it from 'variant' (likely a single variant) and 'gene' tools. However, it lacks an explicit verb like 'retrieve' or 'list,' and the title 'Region' is generic, making the purpose slightly less crisp than it could be.
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 only usage guidance is the '≤25kb recommended' size limit, which implies a constraint but does not explain when to prefer this tool over alternatives such as 'variant' or 'search.' No sibling tools are named, and there is no guidance for larger regions or dataset selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The set mixes several overlapping query surfaces: ask_pipeworx and ask_pipeworx_beta are currently identical, ask_pipeworx_grounded/deep_research/discover_tools/suggest_questions all serve related retrieval/discovery purposes, and the five polymarket_* tools have similar opportunity-finding goals. Only the unusually detailed descriptions save some tools from misselection; an agent would struggle to quickly pick the right one.
Names are uniformly snake_case and mostly follow a verb_noun or prefixed_noun pattern (ask_pipeworx, validate_claim, polymarket_edges, scan_dependency). Minor inconsistencies exist — bare nouns like gene/variant/search sit alongside compound names like generate_llms_txt, and the pipeworx_ prefix isn't applied to ask_pipeworx/deep_research — but the overall style is recognizable and predictable.
36 tools is too many for a coherent server, especially since the domains are largely unrelated: 5 gnomAD genomics tools, 20+ Pipeworx/Polymarket data tools, memory CRUD, subscription management, and a couple of web-dev utilities. The count doesn't align with a single obvious scope and would overwhelm an agent selecting among them.
Within the major subdomains coverage is strong: memory has remember/recall/forget, subscriptions have full lifecycle tools, and Polymarket has edge detection plus fill-risk checking. However, there are notable gaps — no tool to fetch a pipeworx:// citation URI despite deep_research promising resolvable citations, and the gnomAD surface lacks batch queries, coverage, or constraint data for a server named Gnomad.