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

Annotations already declare readOnlyHint=true and idempotent=true; the description adds meaningful context: 'Display-only: feeds no institution score and no watchlist tier', 'Channels that cannot be read are listed in cannot_see, never reported as calm', and the 'falling never scores' rule. It also clarifies default vs full payload behavior, going beyond the 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 dense but every sentence contributes: scope, alternatives, data sources, methodology caveats, and return format. It is front-loaded with the core question and structured logically, though slightly long. It earns a 4 rather than a 5 due to minor redundancy (e.g., 'US HOUSEHOLD' and 'household balance sheets' repeated).

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?

With no output schema, the description carries the full burden of explaining return semantics, and it does so: 'Returns ~4KB slim by default; pass full:true for thresholds, method prose and full sparklines.' It also explains what data is included, what is unscored context, and how missing channels are handled, making it complete for a read-only board tool.

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 single boolean parameter 'full' has 100% schema coverage with a description in the schema. The tool description echoes the same information ('pass full:true for thresholds, method prose and full sparklines') without adding new constraints or value beyond the schema, so a baseline score of 3 is appropriate.

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 'Answers ONE question: whether stress is reaching US HOUSEHOLD balance sheets' — a specific verb, resource, and scope. It explicitly contrasts with siblings (corporate_transmission_board, failure_radar_board, Seiche money-market plumbing), making the purpose unambiguous.

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?

Provides explicit guidance: 'Read the Household Credit board: is stress transmitting through US household balance sheets?' and clearly states what it is not for (not firms, not banks, not money-market). It also notes the tool is display-only and does not feed scores or watchlist tiers, helping agents decide when to avoid it.

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