Skip to main content
Glama

Passage Data — cited environmental limits

Check a table of values against cited limits

check_values
Read-onlyIdempotent

Which results in a lab table are over the limit? A lab table in one call: up to 200 rows of parameter, value and unit, checked against the limits held for one place (and a medium or statistic). Each row is answered by check_value itself: its verdicts (over, within, under, not_comparable with a why), counts and says, or its own coded refusal (an unknown parameter, a value below detection such as <0.005, an ambiguous unit). Each held limit is sent once, in limits, and a verdict names it by index: joined, they are check_value's row, with its cite. summary counts the rows over a limit, under a floor, within every limit, with no comparable limit, and refused by code. max_rows pages each row's verdicts (over first); ask check_value with offset for more.

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": {
      "place": "<place>",
      "rows": "<rows>"
    },
    "name": "check_values"
  }
}

Input Schema

NameRequiredDescriptionDefault
rowsYesThe table's rows, in order; the answer keeps the order.
placeYesISO 3166 code of where the rule binds: a country (US, CA, DE, FR, IT), a state or province (US-OH, CA-QC), or EU. A place also searches every place above it: US-OH searches US-OH and US; DE searches DE and EU. One place for the whole table.
mediumNoWhat the limits govern: an effluent (water_discharge), the receiving water (surface_water), groundwater, ...
max_rowsNoVerdicts returned for each row (its counts cover all).
statisticNoOnly limits under this statistic: daily_max, monthly_avg, instant, ...

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only cover the read-only/idempotent/no-destruction profile, and the description goes well beyond them: per-row verdict vocabulary (over, within, under, not_comparable with a `why`), coded refusals for unknown parameters, below-detection values like <0.005, and ambiguous units. It also discloses that identical limits are deduplicated into `limits` and referenced by index, plus the max_rows paging order (over first) and offset continuation.

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 core question and the table-in-one-call constraint, and almost every sentence carries distinct information (verdicts, refusals, index referencing, summary, paging). The prose is dense and slightly riddling in places, which costs a point on readability, but there is no filler.

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?

With no output schema, the description carries the return-value burden and does it well: verdicts, a `why` per row, `counts`, `says`, `cite`, and `summary` buckets are all described. The only shortfall is that the exact response shape and the meaning of a per-row `counts` versus the top-level `summary` are implied rather than spelled out.

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 already 100%, so the baseline is 3, but the description adds real meaning: rows are processed and answered in order, limits are sent once and named by index, and max_rows pages each row's verdicts while counts cover all rows. It loses a point because it refers to a `limits` parameter that does not appear in the input schema, which could confuse a caller about what to pass.

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?

Opens with a concrete question and states the verb+resource precisely: a whole lab table of up to 200 rows checked against limits held for one place. It also distinguishes itself from the sibling check_value (rows are answered by check_value, which handles single values and paging), so an agent can route 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 Guidelines4/5

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

Usage is clearly scoped to batch checking ('a lab table in one call') and it routes the agent to check_value when it needs more pages or a single value's verdict. There is no explicit 'do not use this for X' exclusion, but the batch-vs-single split with the named sibling is strong enough to select correctly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.