epa_enforcement

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by specifying the case types and return fields (case name, primary law, penalties, settlement dates, outcomes), which is valuable beyond the annotations. It does not mention pagination or rate limits, but that is minor given the read-only nature.

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

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

The description is concise at four sentences and front-loads the core purpose. The inclusion of case types and return fields is valuable, and the cross-referencing note is a useful contextual pointer. No fluff or redundant phrasing; the only slight deviation is the cross-reference sentence, which is off-topic but still relevant for investigation workflows.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (3 params, read-only, no output schema), the description adequately covers the main aspects: purpose, case types, and return fields. It lacks explicit mention of pagination or limit behavior, but the schema's limit parameter with default covers that. The description is sufficient for an agent to know what to expect and how to use it.

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

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

The input schema has 100% coverage for all three parameters (state, law, limit) with descriptions. The tool description does not add any additional semantics beyond the schema; it does not mention that state is required (though schema already does) or provide extra format details for law codes. Since schema coverage is complete, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches EPA enforcement cases, specifies it covers civil and criminal actions, and lists the types of data returned (penalties, settlements, outcomes). It also names the case types (JDC, AFR), distinguishing it from other EPA tools like epa_facilities or epa_superfund that focus on facilities or sites. The verb 'Search' and resource are specific and unambiguous.

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

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

The description implies its use for enforcement-related investigations and suggests cross-referencing with DOJ, SEC, lobbying, and FEC data, which gives context on when to combine it with other tools. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions, though among EPA siblings, none cover enforcement cases, so the differentiation is implicit.

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