check_setup

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds a valuable behavioral boundary: 'Settings are shown as present or absent, never their values.' This tells the agent it will not receive sensitive configuration values, which meaningfully shapes expectations. It also implies a status-report style output without exposing internals.

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 exactly two sentences with no fluff. The first sentence states the core functionality and scope; the second explains the output behavior and when to invoke the tool. Every clause carries information useful to an agent, and the most important action verb is front-loaded.

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 zero-parameter diagnostic tool with no output schema, the description is complete: it states what is reported, which categories are covered, how settings are represented (present/absent), and when to call it. There is no return-format expectation to document beyond the stated behavior. The tool's role among siblings is clear, so an agent can invoke it correctly.

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 tool has zero parameters and the input schema is empty, so the description cannot add parameter-level meaning. The baseline for zero parameters is 4, and the description appropriately focuses on what the tool reports rather than inputs. Nothing is missing here.

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 opens with a specific verb and resource: 'Report which data sources this server will use and which settings are missing.' It enumerates the covered data categories (price data, financial statements, inflation, news), making the tool's scope unmistakable. The tool is clearly a setup/diagnostics tool, distinct from the data-retrieval siblings.

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 when-to-use guidance: 'Call it when a tool says a source is not configured, or before a first report.' This gives clear trigger conditions for an agent. It does not explicitly name alternatives or when-not-to-use conditions, but the context of sibling tools makes the distinction implicit, so it earns a 4 rather than a 5.

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