Open Dashboard

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

Annotations mark it non-read-only, non-destructive, non-idempotent, but the description adds the traits that actually matter: the browser launches on the server host rather than the caller's machine, this is the only path for entering API keys/provider credentials and strict-free mode, and it errors under --no-dashboard. That is substantive disclosure beyond the structured hints.

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?

Dense and front-loaded — the purpose and the 'for a human' qualifier come first, alternatives second, caveats last. It is a single long run-on sentence with some redundancy, but nearly every clause carries a distinct constraint.

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 parameters and no output schema, the description carries the full burden and does so: it covers what happens on invocation, where the browser opens, the error case, and when to prefer sibling tools.

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 takes zero parameters, so the baseline is 4. The description adds meaning by explaining what the dashboard UI is for (credentials, port, access token, usage/quota/history views), which is more than an empty schema conveys.

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?

States a specific verb ('Open') and resource ('the local dashboard of this server') plus the crucial scope nuance that the browser opens on the server host, not the client. An agent can distinguish it from get_engine_status and update_engine_config without reading any schema.

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?

Explicitly routes: use this for credential/network settings and when a human should view the data, and use get_engine_status or update_engine_config instead for machine-readable reads/writes. It also names the failure condition (server started with --no-dashboard returns an error).

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