rca_provider_list_configs

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces this by calling the operation a documentation lookup. It adds behavioral context by enumerating the supported providers and stating the return type, which goes beyond the annotations. No contradiction with annotations.

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 well-structured and front-loaded with the core purpose, followed by a useful enumerated provider listches, an Args summary, and a return type. Every section earns its place and the length is justified by the provider enumeration.

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 documentation-lookup tool with readOnly/idempotent annotations, the description is complete: it gives the use case, provider list, parameter behavior, and return type. The output schema exists, and the safety profile is fully covered by annotations, so no critical operational information is missing.

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 description explains the key 'provider' parameter and the omit-to-list-all behavior, but it does not mention the required 'token' parameter or 'client_id' in the Args section. The nested schema does define these fields, but with schema description coverage reported as 0%, the description only partially compensates for the low coverage.

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 states a specific action ('Get MCP client configuration and setup instructions') and a clear resource ('for a specific provider or list all supported providers'). It also distinguishes itself from sibling tools by noting this is documentation lookup and does not affect RCA-MCP's own behavior.

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?

It gives an explicit trigger condition: 'Use this when a user asks how do I connect RCA-MCP to X'. It also clarifies what the tool is not for ('not something that affects RCA-MCP's own behavior'), providing a clear context. It does not explicitly name alternative sibling tools, but the use case is sufficiently scoped.

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