Skip to main content
Glama
Sign In
gnomancer

gnomancer

by codebase
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

clinvar_watch

Re-check ClinVar for new releases, rescan your DNA sites, and report only classification changes. First run saves a baseline for later comparisons.

Instructions

Re-check ClinVar for this report: downloads a new ClinVar release if NCBI published one, rescans the user's sites and reports only classification changes (newly pathogenic, downgraded, review-status changes). The first run writes a baseline. Health-sensitive: run when the user asks.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "clinvar_watch"
  }
}

Input Schema

NameRequiredDescriptionDefault
forceNo
report_dirNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

B3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden. It does well on core behavior (conditional release download, rescan scope, change-only output, first-run baseline creation), but says nothing about that the baseline write mutates state in report_dir, how long a run takes, network/auth requirements, or what happens if NCBI is unreachable or the report is out of date.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with the action sequence and the stateful caveats front-loaded ahead of the health-sensitive warning. Little waste, though the opening clause partially restates the tool name before adding value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema means return values needn't be explained, and the change-reporting semantics are covered. But for a stateful, network-dependent tool with zero annotations and zero parameter documentation, missing details on the 'force'/'report_dir' parameters and on side effects leave real gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and neither of the two parameters is mentioned. The meaning of 'force' (presumably re-download even without a new release) and of 'report_dir' (which report to re-check vs. where state is stored) are entirely left to guesswork, so the description adds nothing over the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ('Re-check ClinVar for this report') and enumerates the concrete actions: download a new release if published, rescan the user's sites, report only classification changes. It is clearly a stateful change-detection tool rather than a plain lookup, which implicitly separates it from clinvar_findings, though that sibling is never named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It supplies a trigger ('run when the user asks') and warns that the tool is health-sensitive, which is useful gating context. However, it never says when NOT to use it or points to clinvar_findings/lookup for users who just want current classifications without a change diff, leaving that routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools