Passage Data — cited environmental limits

Check a DMR against its permit

check_dmr

Read-onlyIdempotent

Will EPA flag this period's Discharge Monitoring Report (DMR)? A US NPDES permit's Discharge Monitoring Report for one period, checked before it is filed: each value you send (outfall, parameter, statistic, value, unit) is set beside the permit's own limit for that period, from EPA's national limits file (ICIS-NPDES), with EPA's violation rule's verdict: flagged (EPA records a violation), ok, undecidable (a less-than result against a lower limit: EPA does not flag it, nor does it show compliance), no_data (a NODI code), not_graded (an alert or stayed limit), unreadable. A row we cannot place on one value due is refused by its code (outfall.not_in_permit, parameter.not_limited, statistic.not_limited, unit.not_on_form, period.not_due, row.ambiguous with the candidates), never put on the nearest limit. Every value due this period is in limits once with its limit_value_id (the cite into EPA's file); not_sent lists those you did not send, which EPA records as missing (D90) when filed blank. headline and tally are the forms as filed with exactly the values placed. netdmr: true adds the NetDMR "Import DMRs" file as text (not yet validated by NetDMR's own import check). The values reach our server to be checked and are not kept: only how many were sent, flagged and refused is counted.

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": {
      "permit": "<permit>",
      "period_end": "<period_end>",
      "values": "<values>"
    },
    "name": "check_dmr"
  }
}

Input Schema

Name	Required	Description
`netdmr`	No	Also return the NetDMR "Import DMRs" file (CSV text) for the values placed.
`permit`	Yes	The NPDES permit number, e.g. PA0228061.
`values`	Yes	The period's values, one a row, as the DMR prints them.
`period_end`	Yes	The reporting period: its month (2026-09) or its last day (2026-09-30). A quarterly form is due on the period ending its quarter.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 14, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior on top: the full verdict taxonomy, the per-field refusal codes that prevent near-limit guessing, what not_sent means when filed blank (D90), and the data-handling guarantee that sent values are not retained and only counts are kept.

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?

Front-loaded with the agent's actual question ('Will EPA flag this period's DMR?') and then organized as verdicts, refusals, output sections, and the netdmr flag. It is dense and the refusal-code list is packed into one long sentence, but nearly every clause carries operational information.

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?

No output schema exists here, and the description compensates by enumerating the return sections (limits, not_sent, headline, tally) and the verdict/refusal vocabularies. It also flags the netdmr caveat that the Import DMRs text is not validated by NetDMR's own check, which an agent would otherwise misjudge.

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?

Schema coverage is 100% so the schema already documents each field, but the description adds real meaning: how a row is matched to a limit, that limit_value_id substitutes for four fields, how period_end maps to quarterly due dates, and the unit distinction between concentration and loading. That exceeds the baseline-3 expectation for full schema coverage.

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 states a specific verb (check) and resource (a period's DMR values against the permit's own limits) and frames the outcome as EPA's verdict, which clearly separates it from siblings like fill_dmr, find_limits, and check_value. An agent can tell exactly what this returns without opening the schema.

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 places the tool clearly in context ('checked before it is filed') and routes the agent to related calls (limit_value_id comes from an earlier check_dmr or fill_dmr answer, parameter codes come from get_permit). It stops short of naming an explicit alternative such as check_values for bulk use or a case where this tool should not be used.

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

All Passage Data — cited environmental limits tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.