Evidenceline

Tidy lab results

tidy_lab_files

Read-onlyIdempotent

Combines lab results, chain of custody, and field sheets into one table, converts units, and runs six QA checks to flag review items for environmental scientists.

Instructions

Tidy one site's lab results, chain of custody and field sheet into one table, and list what needs review.

Converts units exactly (ug/L for water, mg/kg for soil; ng/L, mg/L and the spellings ug/L, µg/L, μg/L are understood), reads every date day first, matches sample ids across the three files, and runs six QA checks: sample ids, units, field duplicate RPD, holding times to extraction, blank detections linked through the field sheet's equipment column, and LOR against investigation levels (soil HIL A; both drinking-water rules for water, side by side).

Returns counts by matrix and analyte, numbered review items (what was found, the evidence rows, the rule and its source, and what the scientist decides), everything that was checked and not flagged, and what was not checked. The combined rows (one per lab result, with file and row numbers) are included only with include_rows=true; row_count always says how many there are. Show the person every review item and the checked list; never describe the result as "no issues". The tool never merges, rejects or corrects a result, and a guideline value is an investigation level, not a finding that a site is contaminated. The data is synthetic.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`site`	No	Site id. Only the synthetic site 'FDS-01' is available.	FDS-01
`include_rows`	No	Include the full combined table (73 rows for FDS-01, about 25 KB). Default false: review items, checks and counts only.

Output Schema

TableJSON Schema

Name	Required	Description
`rows`	Yes	The combined table, one row per lab result. Empty unless include_rows is true; row_count says how many rows there are.
`site`	Yes
`files`	Yes
`notes`	Yes
`checks`	Yes	Every check that ran, what it looked at and what it raised.
`counts`	Yes	Results by matrix and analyte.
`results`	Yes
`samples`	Yes	Lab samples with results.
`summary`	Yes
`settings`	Yes
`row_count`	Yes	How many combined rows the site has, whether or not they are included.
`synthetic`	Yes
`not_checked`	Yes
`review_items`	Yes
`rows_included`	Yes
`checked_not_flagged`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 24, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description goes far beyond the readOnly/idempotent annotations: it explains exact unit conversions, date parsing, QA checks, output contents, the include_rows behavior, and important caveats such as 'never merges, rejects or corrects a result' and 'never describe the result as no issues.' This gives the agent a detailed behavioral contract.

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?

The description is dense but well-structured, with the core purpose front-loaded and supporting details organized logically. Every sentence contributes meaningful information about behavior, output, limits, or usage, with no filler or repetition.

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

Completeness5/5

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

For a tool with this complexity, the description covers the transformation, QA rules, return semantics, parameter behavior, and safety limitations. The presence of an output schema means return values need not be spelled out further; an agent has everything needed to invoke the tool correctly.

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

Parameters4/5

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

The input schema already documents both parameters fully, so the baseline is 3. The description adds useful semantic detail beyond the schema, especially that include_rows=true returns the full combined table (73 rows, about 25 KB) and that site only supports the synthetic site FDS-01.

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?

The description opens with a specific verb and resource: 'Tidy one site's lab results, chain of custody and field sheet into one table, and list what needs review.' This clearly distinguishes the tool from siblings like get_results or lookup_limit by stating the combining/tidying operation and the review-item output.

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

Usage Guidelines4/5

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

The description gives clear context for when to use the tool: whenever a consolidated lab table and review items are needed for one site. It does not explicitly name alternatives or state when not to use it, but the unique purpose is obvious enough that an agent should select it correctly without further guidance.

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

Deploy Server