get_dashboard

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

With no annotations provided, the description carries the full burden of disclosure. The verb 'Get' implies a read-only operation, and specifying the return content is helpful. However, it doesn't mention potential errors, permissions, or any edge cases. For a simple read tool this is adequate though not rich.

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 one short sentence, immediately stating the action and the object. There is no filler, repetition, or unnecessary detail, making it highly efficient.

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?

Given the tool's simplicity (one parameter, no output schema), the description gives a high-level summary of the return value (cards and layout) that is likely sufficient for an agent to understand the tool's purpose. It could be more detailed about the exact response structure, but for a getter this is reasonably complete.

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 input schema already fully covers the single parameter (dashboard_id) with a description. The tool description adds no additional semantic value to the parameter itself, so the 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 uses a specific verb 'Get' and clearly identifies the resource (a dashboard) plus the exact content returned (cards and layout). This distinguishes it from sibling tools like list_dashboards (which lists dashboards) and get_card_metadata (which fetches a single card).

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 clear context: use this when you need a specific dashboard's cards and layout. It doesn't explicitly name alternatives or exclusions, but the intent is unambiguous and fits well among the sibling tools.

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