AWS MCP Server

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

With no annotations provided, the description carries the full burden of behavioral disclosure but fails to provide it. It does not disclose whether the operation is read-only (implied by 'List' but not explicit), whether results are paginated (the AWS ListSteps API supports pagination), or what happens if the cluster_id does not exist.

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 extremely concise at five words with no filler. However, given the complexity of AWS EMR operations and the four parameters involved, the description is arguably too terse to provide adequate context, though the single sentence does efficiently convey the core purpose.

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 4-parameter AWS service tool with no annotations and no output schema, the description is incomplete. It omits authentication context (AWS profiles), pagination behavior, the meaning of step states, and error conditions (e.g., invalid cluster ID).

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% description coverage, with each parameter (profile, region, cluster_id, step_states) fully documented in the schema itself. Since the schema descriptions are complete, the baseline score applies even though the description text mentions no parameters explicitly.

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 identifies the action ('List') and resource ('steps in an EMR cluster'), distinguishing it from siblings like aws_emr_list_clusters (which lists clusters) and aws_emr_describe_cluster (which describes cluster metadata). However, it lacks scope clarification (e.g., whether it lists all steps or supports pagination) and doesn't define what constitutes an 'EMR step' for users unfamiliar with the service.

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 no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as requiring a valid cluster_id from an existing cluster, AWS credentials, or specific IAM permissions needed to view steps.

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