EPA Air Quality System (AQS) MCP Server

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

With no annotations provided, the description carries full burden and does well: it discloses that this is a registration/mutation operation (not read-only), that it sends something to an email address, and that the output is an API key. However, it doesn't mention potential rate limits, confirmation requirements, or what happens if email is invalid.

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?

Two tightly focused sentences with zero waste. First sentence states purpose and parameters, second provides crucial prerequisite context. Every word earns its place in this efficient description.

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?

For a single-parameter registration tool with no output schema, the description is quite complete: it explains what the tool does, when to use it, and what happens. The main gap is lack of output format details (though 'API key will be sent' gives some indication), and no mention of error conditions or processing time.

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?

Schema description coverage is 100%, so the schema already documents the single parameter. The description adds marginal value by reinforcing that the email is where 'the API key will be sent,' but doesn't provide format requirements or validation rules beyond what the schema implies.

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 specific action ('Register for an EPA Air Quality System (AQS) API key') and resource ('API key'), distinguishing it from all sibling tools which are data query operations. It explicitly mentions this is for obtaining credentials needed for other operations.

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 provides explicit usage guidance: 'This key is required for all other AQS API operations' tells the agent when to use this tool (before any other AQS operations) and establishes its prerequisite role versus the data retrieval siblings.

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