Skip to main content
Glama

Get the permit requirements for a site

get_requirements
Read-onlyIdempotent

The requirements for a site: inspection frequency, stabilisation deadlines, Notice of Intent and Notice of Termination deadlines, corrective-action windows, record retention and buffer rules, each citing the permit section it came from. Same engine and same parser as determine_permit, projected down. The coverage verdict, the eligibility screens and the notices come with it, because a requirement list detached from whether coverage is triggered at all is a half-answer. An empty requirements array with a notice means we have not read that jurisdiction's permit, NOT that nothing is required. Free, no API key needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
acresNoAlias for disturbedAcres.
stateYesTwo-letter state, territory or DC code, e.g. "CA".
endDateNoISO yyyy-mm-dd. Recorded on the determination.
activityYesRequired. Construction and industrial sites are governed by different permits and neither is assumed. "industrial" returns coverage "verify": EPA's Multi-Sector General Permit expired on 28 February 2026 and new operators cannot currently obtain coverage.
startDateNoISO yyyy-mm-dd. Recorded on the determination.
sectorCodeNoMSGP industrial sector code. Industrial sites only.
aridClimateNoArid, semi-arid or drought-stricken area, which may allow a reduced inspection frequency during the seasonally dry period.
onTribalLandNoEPA retains NPDES authority in Indian country even inside a state that runs its own programme.
disturbedAcresNoTOTAL acres the project will disturb over its life. This is what the 1-acre coverage threshold is measured against. `acres` is accepted as an alias.
federalFacilityNoEPA's permit covers federal facilities in some delegated states.
partOfLargerPlanNoWhether the project is part of a larger common plan of development or sale. Defaults to false. Send it explicitly: a half-acre lot inside a 40-acre subdivision IS covered, and this is the most commonly missed trigger in the permit.
dischargesToTier2WaterNoDischarges to a Tier 2, 2.5 or 3 water. Same tri-state handling as dischargesToImpairedWater.
dischargesToImpairedWaterNoDischarges to a sediment or nutrient impaired water. OMIT IT if you do not know: it is never assumed false, and the determination reports the answer as unknown instead. It changes both the inspection frequency and the stabilisation deadline.
maxDisturbedAcresAtOneTimeNoGreatest acreage disturbed AT ANY ONE TIME. A different quantity from disturbedAcres, and the one the stabilisation deadline actually turns on (2022 CGP Table 2): a project over five acres in total still gets the longer 14-day deadline if it phases the work so no more than five acres are open at once. OMIT IT if you do not know, and the determination assumes an unphased site and says so, rather than asserting phasing it was not told about.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which the description does not contradict. The description adds behavioral detail: 'free, no API key needed,' explains the meaning of an empty requirements array ('NOT that nothing is required'), and clarifies that the tool does not assume certain values (e.g., dischargesToImpairedWater is never assumed false). This exceeds the annotation baseline.

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 description is a single paragraph that covers multiple aspects efficiently, front-loading the key output (requirements details). It is moderately concise but could be slightly more terse without losing meaning. The structure is logical, moving from output content to caveats to cost.

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?

Given 14 parameters (100% schema coverage), no output schema, and the presence of annotations, the description is thorough. It explains the output structure, param semantics, usage constraints, and even addresses edge cases (empty array meaning). This is complete for an AI agent to use the tool correctly.

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?

Schema description coverage is 100%, so baseline is 3. The description adds significant value by explaining relationships (e.g., 'disturbedAcres is the 1-acre coverage threshold measure'), usage nuances (e.g., 'maxDisturbedAcresAtOneTime: OMIT IT if you do not know'), and context for tricky parameters (e.g., partOfLargerPlan: 'most commonly missed trigger'). This goes well beyond the schema.

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 clearly states the tool returns permit requirements (inspection frequency, deadlines, etc.) and distinguishes it from the sibling determine_permit by mentioning 'same engine and same parser as determine_permit, projected down.' It also explains what comes with the requirements (coverage verdict, eligibility screens, notices), making the purpose precise.

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?

The description provides context for when to use this tool (getting detailed requirements after a permit determination) and offers parameter-level guidance (e.g., 'OMIT IT if you do not know' for some fields). However, it does not explicitly contrast when to use get_requirements versus determine_permit or other siblings, leaving some ambiguity.

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.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: permit determination, credential gate check, requirements retrieval, usage info, and jurisdiction listing. No overlaps or confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., determine_permit, get_usage, list_jurisdictions), making them predictable and readable.

Tool Count5/5

With 5 tools, the server is well-scoped for its domain of NPDES permit compliance, covering essential operations without unnecessary bloat.

Completeness4/5

The set covers permit determination, requirements, credential gates, jurisdiction info, and usage—leaving minor gaps like direct document submission or status tracking, but core workflows are well-supported.

Resources