List Local MySQL Instances

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds the useful scope fact that remote connections and stored credentials are excluded from results, but says nothing about what an instance record contains or how paging behaves on a multi-node environment.

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 short sentences with the subject and scope front-loaded, and no filler. The second sentence is a genuine scope qualifier rather than padding, so the length is well matched to the content.

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 read-only, optional-parameter list tool with no output schema and annotations covering the safety profile, this is close to complete. The residual gaps (page_size being undocumented, no hint about result contents or pagination limits) are minor rather than blocking.

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 coverage is 67%, with nodeId and page documented in the schema; page_size is undocumented in both places. The phrase 'on the selected node' reinforces nodeId semantics but adds no syntax or behavior beyond the schema's own description of 'local' versus numeric IDs from list_nodes.

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 states a specific verb and resource ('List local MySQL/MariaDB server instances'), scoped to 'the selected node', which cleanly separates it from the PostgreSQL sibling and from database-level tools. It stops short of naming any sibling explicitly, so an agent must still infer that list_databases and get_mysql_status are different calls.

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?

Usage is implied by the wording 'local ... instances' plus the exclusion of remote connections and credentials, which tells the agent this tool will not surface remote DBs. There is no explicit when-to-use versus when-not statement and no pointer to an alternative for remote or database-level queries.

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