readback

describe

Read-onlyIdempotent

Inspect one table to get its grain, column types, units, cited definitions, manifest readers, and first five grain-sorted rows after search_catalog names it.

Instructions

Describe one table: its grain, every column with its type, unit and definition (cited to the build's definitions file where one exists), the manifest figures that read it, and its first five rows sorted by the grain. Call it for one table at a time, after search_catalog has named the table.

Input Schema

Name	Required	Description	Default
`table`	Yes
`warehouse`	Yes

Output Schema

Name	Required	Description	Default
`rows`	Yes
`grain`	Yes
`table`	Yes
`columns`	Yes
`examples`	Yes	the first five rows sorted by the grain
`statement`	No		Answers are drawn from the published tables of three portfolio builds by Ajay Mekala: doorstep (public housing data from FHFA, the Census Bureau, HUD, the CFPB and Freddie Mac), turnaround (public flight data from the Bureau of Transportation Statistics, the FAA and OurAirports, with weather from Open-Meteo under CC BY 4.0) and ledger (a fictional bank, Harborline, with public HMDA, CFPB, FDIC and macro series). No person appears in any table, and questions are redacted before a model sees them. Every number is read back to the warehouse before it is shown. This is a portfolio demonstration, not financial, travel or lending advice.
`warehouse`	Yes
`source_step`	Yes
`manifest_keys`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 24, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real substance beyond that — that definitions are cited to a build definitions file 'where one exists' (signalling the citation may be absent) and that the row sample is grain-sorted and limited to five. It stops short of anything on cost, latency, or size of wide tables.

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 returned payload front-loaded and the invocation constraint in the second sentence. Every clause carries information an agent needs.

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?

An output schema exists, so the return shape is documented structurally, and the description is thorough about sequencing against search_catalog. The only real hole is the undisclosed meaning of the `warehouse` enum, which matters because table names may not be unique across the three warehouses.

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%, so the description must carry both parameters and only carries one: it clarifies that `table` is a single table name sourced from search_catalog. The `warehouse` parameter is never mentioned, and its enum values (doorstep, turnaround, ledger) are opaque without any explanation of what each warehouse contains.

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

Purpose5/5

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

States a specific verb and resource ('Describe one table') and enumerates exactly what comes back: grain, every column with type/unit/definition, manifest figures that read it, and first five grain-sorted rows. That makes it distinguishable from search_catalog (naming) and run_sql (querying) without opening either schema.

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

Usage Guidelines5/5

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

'Call it for one table at a time, after search_catalog has named the table' gives an explicit prerequisite and ordering relative to a named sibling. The one-at-a-time constraint tells the agent to loop rather than batch, which is the key usage decision for this tool.

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

Deploy Server