list_dashboards

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

The description adds behavioral detail beyond the name by explaining the pagination mechanism (use 'next' token) and specifying the response contents. With no annotations provided, this is useful disclosure for a read operation, though it stops short of discussing permissions or rate limits.

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?

Two sentences, front-loaded with purpose, no filler. The pagination instruction is efficiently integrated.

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?

The tool is simple and the output schema is present, so the description need not detail return values. It explains the pagination workflow sufficiently for an agent to use the tool 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?

Schema covers both parameters with descriptions (limit and token). The description reinforces the token's role in pagination but adds little beyond the schema; it mentions the response field 'next' but that's more about the output. Baseline of 3 applies due to high schema 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 clearly states the tool lists dashboards with pagination and specifies the return fields (titles, IDs, descriptions). This distinguishes it from sibling tools like get_dashboard (which likely retrieves a single dashboard) and create/update/delete dashboard operations.

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 implies a listing use case but provides no explicit guidance on when to use it versus alternatives. No mention of using get_dashboard for a single dashboard or differences from list_monitors. Usage is implied by the verb 'list'.

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