ecp_mysql_change_db_user

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

With no annotations, the description carries the burden of behavioral disclosure. It does disclose a key constraint: both database and user must already exist within the account, which prevents an agent from using this tool to create cross-account or new objects. However, it does not describe side effects such as whether previous privileges are removed, whether the old owner loses access, or what happens if the target user already owns the database.

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 a single sentence with no filler. The core action is stated first, and the essential precondition is given in a parenthetical. Every word contributes to understanding what the tool does and when it can be used.

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 simple two-parameter ownership-transfer tool, the description provides the action, the parameter roles, and the key prerequisite. With no output schema and no annotations, it doesn't explain return values or side effects, but the core invocation context is sufficiently complete for an agent to select and call 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?

The input schema provides no descriptions for db_name or db_username, so the description must compensate. It does this by mapping the action to the parameters: db_name is the database being reassigned and db_username is the target owner. It also adds the account-scoping constraint, which is meaningful semantic information not present in the schema.

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 and resource: it says the tool will 'reassign a database to be owned by a different MySQL user.' This clearly distinguishes it from sibling tools that create, delete, list, or grant privileges on MySQL databases and users. It also disambiguates the ambiguous tool name by clarifying this is about ownership, not changing a user's credentials.

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 gives clear context for use: it is for reassigning MySQL database ownership, and it adds a strong precondition that both the database and the user must already belong to the account. It doesn't explicitly name alternative tools for creating users or managing privileges, but the engine-specific wording and the 'must already belong' constraint provide enough directional guidance for an agent.

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