Skip to main content
Glama

Passage Data — cited environmental limits

Get a US NPDES permit

get_permit
Read-onlyIdempotent

What are a US facility's discharge permit limits, when is its renewal due, and has it gone over a limit lately? One US NPDES discharge permit as EPA's national file (ECHO / ICIS-NPDES) holds it: facility, place, every limit by outfall, parameter, statistic and months, the renewal due date, and the last 12 months' record of values over a limit. When its renewal is near, overdue or the permit has expired, renewal_check names a free renewal check a person can order on the permit's page. sector names the list of the state's permits in its industry (EPA's SIC group), one list_permits call. over_limits gives each parameter it went over on with the address of find_limits' cited state and federal limits for it; one the record names that is not there is one we hold no water limit for. upcoming names the limits already written into the permit that take effect later, each with its begin date and the plant's median reported value today.

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>"
    },
    "name": "get_permit"
  }
}

Input Schema

NameRequiredDescriptionDefault
permitYesThe NPDES permit number: two letters and seven letters or digits, e.g. PA0228061.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety/idempotency profile is covered. The description adds some value by disclosing returned data (last 12 months of over-limit records, upcoming limits with median values, a free renewal check a person can order) but says nothing about auth, rate limits, or freshness beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with a clear scoping question, but the bulk is a dense, run-on block that mixes response-field descriptions (`renewal_check`, `sector`, `over_limits`, `upcoming`) with sibling-tool references, making it easy to misread fields as tools. Given no output schema exists, describing return content is warranted, but the phrasing is more sprawling than an agent needs.

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 burden of describing returns and does so thoroughly, covering facility data, outfall/parameter limits, renewal timing, over-limit history, and upcoming limits. It is nearly complete for a read-only lookup, with the only gap being explicit use-vs-sibling guidance.

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% and the single `permit` parameter already documents the required format with an example (PA0228061). The description adds no format, casing, or validation detail beyond the schema, so the baseline of 3 for a fully-covered parameter is correct.

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 names a specific verb+resource (retrieve one US NPDES discharge permit from EPA's ECHO/ICIS-NPDES file) and enumerates the resource's contents (facility, place, limits by outfall/parameter/statistic, renewal due date). It distinguishes itself from the plural siblings it references: `sector` maps to a `list_permits` call, and `over_limits` points at `find_limits`, so an agent can tell this single-permit lookup apart from the list/search tools.

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

Usage Guidelines3/5

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

Usage is only implied. It references `list_permits` and `find_limits` as places to get the state's permit list and the cited limits, which gestures at when a sibling is appropriate, but it never states plainly when to call get_permit versus list_permits or find_limits. No prerequisites or exclusions are given.

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.