x_status

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

Even though annotations already declare readOnlyHint=true and idempotentHint=true, the description adds valuable behavioral context by stating 'Does not make live probes' and clarifying that health is 'recorded' rather than actively checked. This prevents an agent from expecting network probing or real-time health checks.

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 three short sentences with no filler. It front-loads the core purpose, then adds the schema-mode detail positionally tight to the parameter pair, ending with a crucial caveat about live probes. Every sentence earns its place.

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 2-parameter introspection tool with an output schema and read-only annotations, the description covers the essential behavior, the non-live nature, and the schema view mode. The main remaining gap is a precise specification of what tool=null does outside schema view, though the schema defaults and enums partially mitigate this.

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 coverage is 0%, so the description must carry parameter meaning. It does clarify the view=schema behavior and the role of tool=NAME, and the schema's enums add value for the remaining options. However, it does not explain the default behavior for tool=null or the exact meaning of each view value beyond the schema view.

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 verb ('Inspect') and resource ('capabilities/configuration or recorded provider health'), and it distinguishes the tool from the operation-focused siblings by defining it as a meta/introspection tool. The view=schema mode is explicitly tied to returning another tool's input rules, making its role unmistakable.

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 clear context for when to use the tool: to inspect capabilities, configuration, provider health, or another tool's input schema. It does not explicitly name alternatives, but none of the siblings serve this introspection purpose, so the implied usage is sufficiently clear.

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