Evidenceline

Fill in the numbers

fill_numbers

Read-onlyIdempotent

Replace placeholders in draft report text with exact measured values, detection limits, guideline comparisons, and changes from lab data or guideline tables, returning cited, traceable numbers ready for verification.

Instructions

Fill in the numbers: replace each placeholder in a draft paragraph with the exact value and unit, by code.

Never type a concentration yourself. Write a placeholder where each number goes, then call this tool. Fields are separated by '|'; case and spaces around fields do not matter:

{ANALYTE|WELL|DATE}: measured result, e.g. {PFOS|MB2|Sep 2025} gives '0.038 ug/L'. A non-detect gives the result as reported, e.g. '<0.001 ug/L'; describe it as not detected.
{sum PFOS+PFHxS|WELL|DATE}: the sum of PFOS and PFHxS, e.g. {sum PFOS+PFHxS|MB2|2025-09-16} gives '0.057 ug/L'.
{lor|ANALYTE|WELL|DATE}: the detection limit, e.g. {lor|PFOA|MB2|Sep 2025} gives '0.001 ug/L'.
{limit|ANALYTE|RULE}: a guideline value. RULE is 'nemp-3.0' or 'current' and is required, e.g. {limit|PFOS|current} or {limit|PFOS+PFHxS|nemp-3.0}. Under nemp-3.0 use the PFOS+PFHxS form: its 0.07 ug/L applies to PFOS alone, PFHxS alone and the sum (Table 4, footnote a), so say which one the sentence compares.
{change|ANALYTE|WELL|FROM|TO}: change from the earlier round FROM to the later round TO, with direction and percent, e.g. {change|PFOS|MB2|Nov 2024|Sep 2025} gives 'a fall of 0.003 ug/L (7.3%)'. Write the sentence so the phrase fits, e.g. 'PFOS showed {change|...} between November 2024 and September 2025.' Dates: '2025-09-16', '16 September 2025' or 'Sep 2025'. One well per call.

Returns the filled text, the same text with [n] source markers, each value with its offsets and explanation, and a numbered source list (lab file and row, or guideline document, table and page). If any placeholder is unknown or ambiguous, nothing is filled and the error lists every problem and the valid forms. Afterwards, call check_paragraph on the filled text: it checks the words around the numbers.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`text`	Yes	The draft paragraph, with every number written as a placeholder such as {PFOS\|MB2\|Sep 2025}.
`well`	Yes	Monitoring well id, for example 'MB2'. Placeholders must name this well.

Output Schema

TableJSON Schema

Name	Required	Description
`text`	Yes	The text with every placeholder replaced. Pass this to check_paragraph.
`well`	Yes
`notes`	Yes
`values`	Yes
`sources`	Yes
`next_step`	Yes
`annotated_text`	Yes	The same text with source numbers in brackets after each value.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses failure behavior (nothing is filled if a placeholder is unknown or ambiguous, with an error listing every problem and valid forms), return structure (filled text, markers, offsets, explanations, source list), and constraints such as RULE being required and nemp-3.0 semantics. No overreach or contradiction with annotations.

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 definition is long but necessary; every section (instruction, placeholder grammar, date formats, error behavior, follow-up step) earns its place. The core purpose and the 'never type a concentration' instruction are front-loaded before the detailed grammar.

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 many placeholder variants and rules, the description covers all needed call-time knowledge: exact formats, unit conventions, the nemp-3.0/current rule, return payload, error handling, and the follow-up check_paragraph call. An output schema exists, but the description explains behavior rather than duplicating it.

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

Parameters5/5

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

Although the schema already documents text and well at 100%, the description enriches them: placeholders must name the well, well is a monitoring-well id, fields are '|'-separated, case/spacing do not matter, and each placeholder form is exemplified. This goes well beyond the schema's terse 'draft paragraph' and 'Monitoring well id'.

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 precise statement: replace each placeholder in a draft paragraph with the exact value and unit, by code. It further explains the placeholder grammar and the 'Never type a concentration yourself' rule, making it distinct from sibling check/read tools. The purpose is unambiguous.

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?

It explicitly tells the agent to write placeholders and then call this tool instead of typing values, and instructs calling check_paragraph afterwards. It defines one well per call, but it does not name alternative tools or situations when another sibling should be preferred, stopping short of full when-not guidance.

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

Deploy Server