Skip to main content
Glama

lookup

Retrieves the genotype and reading for a single rsID from the curated panel or the user's raw DNA file, and reports when the chip did not type that site.

Instructions

Genotype and reading for one rsID. Uses the curated panel when the site is in it; otherwise reads the single site from the user's raw file (nothing else is read or returned). Says so if the chip did not type the site.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "rsid": "<rsid>"
    },
    "name": "lookup"
  }
}

Input Schema

NameRequiredDescriptionDefault
rsidYes
report_dirNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does real work: it discloses the two data sources and their precedence, explicitly bounds data exposure ("nothing else is read or returned"), and covers the untested-site case. It omits error behavior, permissions, and what happens when neither source has the site.

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 short sentences, front-loaded with the operation and followed by the resolution behavior. Every clause carries information; only the quoted privacy parenthetical is slightly editorial.

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

Completeness4/5

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

With no output schema, the description still communicates the shape of the return (genotype plus reading) and the not-typed case, which is the key completeness risk for this tool. The remaining gap is report_dir, which an agent cannot resolve from either the schema or the description.

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

Parameters3/5

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 conveys the meaning of rsid (one site, one genotype) but leaves report_dir entirely undefined — its purpose, format, and whether it is needed to locate the raw file are all unstated.

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?

"Genotype and reading for one rsID" gives a concrete output and a concrete scope (single site), which is enough to separate it from aggregate siblings like summary, analyze, and section. It stops short of explicitly naming what it is not, so the differentiation is inferred rather than stated.

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?

The description implies usage (single-site lookup, curated panel vs raw file) but never states when an agent should pick lookup over analyze or clinvar_findings, nor any prerequisites. The routing logic it describes is internal behavior, not caller guidance.

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