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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the description is not redundant. It adds critical lifecycle info: 'Not persisted to disk, but kept for the rest of the session under an alias', which explains the tool's side effects beyond safety. This is valuable transparency.

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 that leads with the primary action and follows with essential caveats. It avoids fluff and is appropriately front-loaded, though slightly long. It earns its place with no wasted words.

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 description covers the tool's purpose, lifecycle, and alias persistence, which is sufficient for an agent to decide to call it. It does not describe what happens on failure or whether the connection becomes active immediately, but given no output schema and the simple nature of connection establishment, these gaps are minor.

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 description coverage is 100%, so all six parameters (host, port, user, alias, database, password) are fully documented in the schema. The description mentions 'explicit credentials' and 'alias' but does not add parameter-level detail beyond what the schema already provides. Baseline 3 applies.

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 verb 'Connect' and the resource 'any MySQL server at runtime with explicit credentials'. It also explains the session-scoped alias behavior, which distinguishes it from siblings like use_connection. The purpose is unambiguous and actionable.

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 usage for establishing new connections and mentions alias for use_connection later, but does not explicitly say 'use use_connection for existing aliases' or provide exclusion criteria. While the context is clear, it leaves the agent to infer when not to use this tool.

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

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

Annotations already cover the read-only and idempotent nature of the tool, so the description's main contribution is clarifying that the connection shown is the one used by read-only tools. This adds useful shared-state context beyond the annotations.

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 that leads with the action and specifies exactly what the tool reports. It contains no filler, no repetition of the title, and no unnecessary detail.

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 zero-parameter status tool with no output schema, the description fully conveys what the agent will learn (the current server and database) and the relevant scope (read-only tools). Nothing essential is missing for correct invocation.

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 is empty, so there are no parameters to document. Per the baseline for a zero-parameter tool, a score of 4 applies because the description does not need to add parameter meaning that does not exist.

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 precise operation ('Show') and a concrete object: which MySQL server and database the read-only tools are currently pointed at. This differentiates it from siblings like list_connections and list_databases, which concern available connections and databases rather than the active context.

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 clearly implies when to use the tool: when an agent needs to know the current MySQL server and database context for read-only tools. It does not explicitly name alternatives or exclusions, but for a zero-parameter status check the context is sufficient.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds no extra behavioral context, such as whether the result includes column types, default values, or indexes. Given the annotations, a score of 3 is appropriate because the description doesn't contradict but also doesn't enrich beyond the annotation-set baseline.

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, focused sentence that front-loads the primary action ('Show columns and schema') and specifies the target ('a specific table'). There is no redundancy or filler, making it highly efficient and easy to parse.

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, read-only schema inspection tool, the description combined with the schema and annotations provides sufficient information. The schema fully documents the two parameters, and annotations cover safety and idempotency. While the description doesn't explicitly mention the optional 'database' parameter or return details, these are covered elsewhere, so the definition is complete enough for an agent to invoke it 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 coverage is 100%, with both 'table' and 'database' clearly described in the schema. The description mentions 'a specific table' which aligns with the required 'table' parameter but adds no additional meaning beyond the schema. With high coverage, the baseline of 3 holds; the description doesn't need to compensate for undocumented parameters.

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's function: 'Show columns and schema for a specific table'. The verb 'Show' and the resource 'columns and schema' are specific, and it differentiates from siblings like list_tables (which lists table names) and get_table_sample (which returns data). An agent can immediately distinguish this from other schema-related tools without ambiguity.

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?

There is no guidance on when to use this tool versus alternatives such as get_table_indexes or get_foreign_keys. The description does not mention any conditions, exclusions, or recommended contexts. An agent is left to infer usage from the name and schema alone, with no explicit routing to this tool over others.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral context beyond the basic 'show' operation, such as error behavior or output structure, but it does not contradict the annotations.

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, tightly worded sentence with no filler. It front-loads the core action and resource, making the purpose immediately apparent. Every word contributes to the meaning.

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 tool with strong annotations and full schema coverage, the description is mostly complete. The only gap is that with no output schema, a brief note about the result format (e.g., a list of FK relationships) would improve completeness, but it is not critical for correct invocation.

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 description coverage is 100%, so both parameters ('table' and 'database') are already documented with clear descriptions. The phrase 'for a specific table' in the description maps to the 'table' parameter but adds no new semantic detail beyond 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 ('Show') and a specific resource ('foreign key relationships') scoped to a specific table. This clearly differentiates it from sibling tools like get_table_indexes and describe_table, which target different structures, so an agent can distinguish it without ambiguity.

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 no guidance on when to use this tool versus alternatives, when not to use it, or any prerequisites. There is no mention of preferring this over run_query or describe_table for FK-related needs, leaving the agent to infer the appropriate context.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is well covered. The description adds only the scoping detail that a specific table is required, which is consistent but not a major behavioral disclosure.

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 with no filler, front-loading the action and target. Every word contributes meaning.

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 read-only metadata query, the description plus schema and annotations are adequate: the required parameter is clear and the return concept is implied by 'indexes'. No output schema is present, but the tool's purpose is simple enough that this is not a significant gap.

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 description coverage is 100%, so both parameters are already documented in the schema. The description's mention of 'a specific table' aligns with the required 'table' parameter but does not add extra meaning beyond 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 ('Show') and resource ('indexes for a specific table'), making the tool's function immediately clear. It is clearly distinguishable from sibling tools like get_foreign_keys and describe_table, which target different metadata.

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 provides no guidance about when to choose this tool over alternatives such as describe_table or get_foreign_keys. There are no exclusions, prerequisites, or context cues beyond the general idea of showing indexes.

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

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

Annotations already declare the operation read-only, idempotent, and non-destructive, so no safety contradiction exists. The description adds only the word 'sample', which hints at subset behavior, but does not explain whether rows are random, ordered, or arbitrary.

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 focused sentence with no filler. It is appropriately front-loaded and easy for an agent to parse quickly.

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 itself is simple and the annotations cover safety, but no output schema exists and the description does not clarify the nature of the sample or distinguish it from running a query. An agent could invoke it correctly, yet the ambiguity about ordering and randomness remains a gap.

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 description coverage is 100%, so the parameters are already well documented in the input schema. The description adds no additional parameter-level meaning beyond what the schema provides.

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 identifies the resource ('sample rows from a table'), making the core function clear. It does not explicitly distinguish this from siblings like describe_table or run_query, but the phrase 'sample rows' communicates the idea of a lightweight preview.

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?

No guidance is given about when to prefer this tool over alternatives such as run_query or describe_table. The description implies quick data preview but never states the intended context or mentions exclusions.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering safety and side-effect expectations. The description adds meaningful context by noting that the list includes profiles added during the current session, which is a behavioral detail not derivable from annotations or schema.

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?

A single sentence delivers the core purpose first and appends the only important extra behavior. Every word earns its place, and the structure is immediately scannable for an agent.

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 zero-parameter, read-only list operation, the description provides enough context to invoke it correctly: it lists connection profiles and notes session additions. While there is no output schema, the description does not detail the returned profile fields, but for this simple listing tool that is a minor gap rather than a blocker.

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 has zero parameters, so the description is not required to add parameter-level detail. The baseline of 4 is appropriate because there is no parameter surface to clarify.

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 ('List') and resource ('connection profiles'), and clarifies the purpose is to find profiles to switch to. The phrase 'including any added during this session' adds scope that separates this from a static registry, and the tool is clearly distinct from siblings like current_connection or use_connection.

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 communicates a clear usage context: call this when you need to see which connection profiles are available to switch to, including session-created ones. It does not explicitly name alternatives or exclusions, but the simple read-only nature and obvious contrast with siblings like current_connection make the intended use clear.

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

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

Annotations clearly indicate read-only, idempotent, and non-destructive behavior, so the description doesn't need to reiterate safety. The description adds the modifier 'currently connected MySQL server', which clarifies that it operates on a specific connection context, giving more detail than the annotations alone. It doesn't mention output format, but that's fine for a simple list tool and is not a contradiction.

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 concise sentence with no filler. It is front-loaded with the main action and resource, and the contextual modifier is added naturally. Every word earns its place, making it highly readable.

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 optional boolean parameter, no output schema, low complexity), the description is nearly complete. It mentions the connection context, which is useful. The only minor gap is that it doesn't explicitly note that the default behavior excludes system databases, but that is implied by the include_system parameter and its default value. All essential information for correct invocation is present.

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 schema description coverage is 100%, meaning the parameter 'include_system' is fully described in the schema. The description of the tool does not add extra clarification about this parameter, but it doesn't need to because the schema is sufficient. Baseline 3 is appropriate here.

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 action ('list') and the resource ('databases') on the currently connected MySQL server. It distinguishes itself from sibling tools like list_tables and get_table_sample by being specific to databases. This is unambiguous and sufficient.

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 mentions 'on the currently connected MySQL server', which implies a prerequisite that a connection is active, but does not explicitly state when not to use this tool or name alternatives. However, the sibling names like list_connections or use_database provide implicit context, and the scope of 'databases' is clear. Could be improved by noting that it is not for listing tables or connections, but the current phrasing is clean and workable.

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

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds the 'active database' scoping context but does not describe return shape, pagination, or the optional database override behavior, which keeps it at the baseline for an annotation-covered tool.

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?

A single front-loaded sentence conveys the core action and scope with no filler. It is appropriately sized for a simple listing operation.

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 low-complexity read-only tool with rich annotations and a fully documented schema, the description is sufficient for correct invocation. It could have mentioned the optional database parameter or return format, but those are either in the schema or obvious from the verb.

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 has 100% description coverage for the single optional database parameter, including its 'call only / without changing active connection' semantics. The description does not add parameter meaning beyond that, so the baseline 3 applies.

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 all tables') and scopes it to the active database, distinguishing it from siblings like list_databases and describe_table. The word 'all' also communicates full enumeration, so the agent knows the scope without opening the 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?

No guidance is provided about when to choose this tool over siblings such as list_databases or describe_table. There are no stated prerequisites, exclusions, or alternative routing; usage must be inferred entirely from the tool name.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the allowed statement set and the active-connection scope, which is useful behavioral context, but it doesn't disclose error behavior, result size limits, or the consequence of having no active connection.

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?

A single sentence that front-loads the core operation ('Execute a read-only SQL query'), immediately constrains allowed statements, and states the target. There is no filler, repetition, or unnecessary detail.

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 description, combined with rich annotations and fully described parameters, covers the essential invocation details: required query, allowed statement types, optional database override, and the active-connection prerequisite. It omits result format and pagination, which is a minor gap for a query execution tool, but overall an agent has enough to call it 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 description coverage is 100%, so the baseline is 3. The description adds meaning by constraining the 'query' parameter to SELECT, WITH, SHOW, DESCRIBE, and EXPLAIN, which is stronger than the schema's generic 'SQL query to execute'. The 'database' parameter is already well described in the schema, so the net addition is moderate but valuable.

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 ('Execute'), a precise resource ('read-only SQL query'), enumerates the allowed SQL statement types, and anchors it to the active connection. This clearly differentiates it from sibling metadata tools like describe_table or list_tables by framing it as arbitrary SQL rather than a structured listing.

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 when to use the tool: whenever a read-only SQL query needs to run against the active connection.page The explicit allowlist of SQL verbs provides implicit exclusion of write queries Mend. However, it does not name sibling alternatives or state when to prefer them, so it stops short of fully explicit routing.

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

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

Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context by stating 'Takes effect immediately, no restart needed', which is not covered by annotations. This clarifies the impact and side effects of switching profiles.

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 two concise sentences with no wasted words. It front-loads the core purpose and immediately adds a key behavioral detail. Every sentence earns its place.

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 tool with two parameters and no output schema, the description covers the essential purpose and a critical behavioral trait. It lacks details about error handling or side effects on the current session, but given the annotation coverage and schema richness, it 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?

Schema description coverage is 100%, with both 'profile' and 'database' documented. The description adds no additional parameter information beyond what the schema provides, 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 clearly states the verb 'Switch' and the resource 'named connection profile', making the tool's purpose unambiguous. It distinguishes from sibling tools like 'use_database' (switches database, not profile) and 'connect' (likely establishes a new connection rather than switching profiles).

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 provides no guidance on when to use this tool versus alternatives such as 'connect' or 'use_database'. It does not mention any conditions or exclusions, leaving the agent to infer the appropriate context from the tool name alone.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds 'Takes effect immediately, no restart needed', which conveys that the operation is a live runtime change without requiring server restart—useful behavioral context beyond what the annotations capture.

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 zero filler. The core action is front-loaded first, and the immediate-effect note earns its place by providing behavioral nuance. Every word contributes to the agent's understanding.

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 one-parameter switch operation with no output schema and comprehensive annotations, the description is nearly complete. It could explicitly mention that the target database must already exist or that the change is session-scoped, but these are minor gaps given the tool's simplicity and context from sibling list_databases.

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 has 100% description coverage: the single 'database' parameter is clearly documented as 'Database name to switch to'. The tool description does not add syntax, format, or existence requirements beyond the schema, so the baseline score of 3 is appropriate; nothing is missing, but nothing extra is contributed.

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 ('Switch'), a clear resource ('the active database'), and scopes it to 'the current MySQL server'. This distinguishes it from sibling tools like use_connection, which operates on connections, and list_databases, which only lists. No ambiguity remains about the tool's function.

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 usage context by stating 'current MySQL server' and 'Takes effect immediately', suggesting it changes the session's default schema for subsequent operations. However, it does not explicitly name alternatives, exclusion conditions, or when to prefer run_query or use_connection instead. Guidance is present but left to inference.

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