Genomics MCP

Official

Overview Schema Source Related Servers Discussions Admin

get_pileup

Read-only

Generate per-position base counts across a genomic interval from indexed BAM or CRAM files for coverage and variant inspection.

Instructions

Per-position base counts over an interval from indexed BAM/CRAM. Available for: bam, cram.

Input Schema

TableJSON Schema

Name	Required	Description
`file`	Yes
`interval`	Yes
`max_depth`	No
`reference`	No
`max_records`	No	Lower the record limit.
`exclude_flags`	No
`min_base_quality`	No
`min_mapping_quality`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No
`error`	No	Set when status is error.
`errors`	No	Per-source failures in partial results.
`limits`	No
`status`	Yes
`warnings`	No
`operation`	Yes
`provenance`	No
`truncation`	No
`source_status`	No
`schema_version`	No		1
`metadata_omitted`	No	Entries dropped from provenance/source_status/errors/warnings (or text shortened) to fit max_response_bytes. Absent when metadata is complete.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.1Sep 28, 2026

addedOutput schema / properties / metadata_omitted

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "type": "integer"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Entries dropped from provenance/source_status/errors/warnings (or text shortened) to fit max_response_bytes. Absent when metadata is complete.",
+  "title": "Metadata Omitted"
+}

First observedv0.1.0Sep 24, 2026

TDQS

B3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds a real behavioral constraint (requires indexed BAM/CRAM) and the output nature, but says nothing about auth, rate limits, or what happens with low-quality/flagged reads.

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

Conciseness5/5

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

Two sentences, no filler, with the core output statement front-loaded before the format constraint. Every sentence earns its place.

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

Completeness2/5

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

For an 8-parameter tool with very low schema coverage and no output-schema gap, the description is too sparse: it provides no usage routing and no parameter semantics, leaving an agent under-equipped to call it correctly versus siblings like get_coverage.

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 only 13% across 8 parameters, so the description should compensate heavily. It mentions only 'interval' and implicitly the file, leaving max_depth, exclude_flags, min_base_quality, min_mapping_quality, max_records, and reference entirely unexplained beyond their bare schema defaults.

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 states the output precisely: per-position base counts over an interval, restricted to BAM/CRAM. This distinguishes it from coverage-depth or read-listing tools, but it never names a sibling such as get_coverage or get_reads, leaving the agent to infer the boundary.

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

Usage Guidelines2/5

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

The only guidance is a format restriction ('Available for: bam, cram'). There is no explicit when-to-use, when-not-to-use, or routing to alternatives like get_reads or get_coverage, which share the same locus/interval domain.

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