Skip to main content
Glama

Passage Data — cited environmental limits

Read a laboratory certificate

read_certificate
Read-onlyIdempotent

What does a laboratory certificate report, and is any result over the limit? The rows a laboratory certificate prints, read by rules (no AI writes a row): a PDF certificate, or the laboratory's own export as XLSX, XLS or CSV. Each row gives the sample, the parameter, the value as printed, its unit, a qualifier (<, >, ND), the detection limit, and the page (or sheet) it was read from; a sample's date, matrix and lab ID are in samples. Give a place (and best a medium) and every row with a value is checked by check_values itself: exceedances lists the rows over a limit or under a floor, each limit once in limits with its cite; a result below detection is not compared and says so. summary counts the rows by outcome. Rows page by max_rows and offset. Anything but a PDF, XLSX, XLS or CSV is refused format.not_handled before it is read. The file is read and discarded: it is not kept, and nothing is learned from it. Each caller has 3 free reads a UTC day; past that a read costs 0.10 USDC on Base Sepolia, a testnet (eip155:84532), paid by x402 version 2: the call answers HTTP 402 (over MCP an error result) with the requirements, and the same call carrying the payment is read. A refused read is never charged. A call with a key (Authorization: Bearer pdk_…) never pays here: it draws on the key's free dollars of the month.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "read_certificate"
  }
}

Input Schema

NameRequiredDescriptionDefault
placeNoISO 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. Omit to read the rows without checking them.
mediumNoWhat the sample is checked as: an effluent (water_discharge), the receiving water (surface_water), groundwater, soil, ... Omit to compare against every medium held.
offsetNoWhere the next page starts (the answer's next_offset); the file is read again.
call_idNoOnly after a `read.pending` answer: its call_id, to collect the reading without sending the file again.
file_urlNoAn https address the file can be fetched from (not a private network). Give this or content_base64.
filenameNoOptional: the file's name, as the laboratory sent it.
max_rowsNoCertificate rows on this page (the summary and exceedances cover every row).
statisticNoOnly limits under this statistic: daily_max, monthly_avg, instant, ...
content_base64NoThe file's bytes, base64-encoded (at most 10 MB). Give this or file_url.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations cover only the safety profile (readOnly/idempotent/openWorld/non-destructive), and the description adds substantial beyond it: accepted formats and the refusal code, results below detection are not compared, the file is read and discarded and nothing is retained, per-caller free reads and metered pricing on x402/Base Sepolia, HTTP 402 behavior and the fact that a refused read is never charged, plus API-key billing bypass. This is exactly the behavioral context an agent needs.

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?

The content is dense but nearly every sentence carries needed information (formats, extraction fields, checking behavior, pagination, payment, auth). It is front-loaded with the purpose via a framing question and the core mechanics follow, though the payment/rate-limit block makes it a long wall of text rather than cleanly sectioned prose.

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, so the description carries the full burden of describing returns, and it does: the per-row fields (sample, parameter, printed value, unit, qualifier, detection limit, page/sheet), the sample-level fields held in `samples`, the exceedances/limits/cite structure, the summary counts, and pagination. An agent can call this correctly and interpret the result without additional documentation.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description mostly mirrors the schema (pagination by max_rows/offset, place/medium defaults, file sources), adding only the nuance that summary and exceedances span every row while only rows page, which the schema text already states. No meaningful syntax or format detail is added beyond the structured fields.

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 (read) and resource (the rows a laboratory certificate prints) and immediately frames the tool's two outputs: the extracted rows and the limit check. It is clearly distinguishable from siblings like fetch, cite_document or check_dmr, and the supported formats (PDF/XLSX/XLS/CSV) sharpen the scope.

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 explains the trigger conditions well: supply a `place` (best also a `medium`) to have rows checked by check_values, omit `place` to read without checking, and use `call_id` after a `read.pending` answer. It also states which inputs are refused (`format.not_handled`). It does not, however, explicitly contrast itself with sibling tools such as fetch or check_values, so a routing-by-alternative is left implicit.

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.