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

With annotations empty, the description carries the full burden. It usefully discloses two behavioral traits — the connection is session-scoped/not written to disk, and activation is optional. However it says nothing about permissions, connection failure behavior, or what happens to an already-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, well-formed sentence that front-loads the core action and appends the scope constraint and optional activation. No wasted text, though it leaves too much unsaid for a 9-parameter tool.

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 9-parameter mutation tool with no annotations, no output schema, and near-zero schema coverage, the description is far too thin. An agent gets no guidance on credentials, readOnly semantics, defaults, or return/error behavior.

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?

Nine parameters with only 11% schema description coverage (just 'activate'), so the description must compensate for eight undocumented fields (name, host, user, password, port, ssl, database, readOnly) and does not. It only echoes the optional-activation behavior the schema already describes.

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 and resource ('Registra una conexión nueva') and adds the key scope qualifier that it is session-only and not persisted to disk. This distinguishes it from persistent-connection siblings, though it does not explicitly contrast with select_connection or list_connections.

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 'solo para esta sesión (no se guarda en disco)' clause implies when this tool is appropriate (ephemeral connections), but no alternative tool is named and there is no explicit when-not guidance. Usage must be inferred from the session-scope hint.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the operation optionally selects the new database as current, which is useful, but it omits important behaviors: what happens if the database already exists (ifNotExists), required privileges, and whether creation is reversible. The disclosed behavior largely restates the schema description for the 'use' parameter.

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 short sentences, front-loaded with the main purpose and then an important optional behavior. There is no wasted wording, though the brevity borders on under-specification for a five-parameter tool.

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 five parameters, no annotations, no output schema, and low schema description coverage, the description is far too sparse. It does not cover error handling, default behaviors, permissions, or the roles of charset/collation/ifNotExists. An agent lacks enough context to invoke the tool correctly in edge cases.

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 only 20%, so the description should compensate for undocumented parameters. Instead, it only mentions the optional selection behavior corresponding to the 'use' parameter, which the schema already documents, and says nothing about name, charset, collation, or ifNotExists. It adds no meaningful semantic detail 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 states a specific verb and resource: 'Crea una base de datos' (Creates a database). It also mentions the optional side effect of selecting the new database as current, which helps distinguish it from a pure creation tool. However, it does not explicitly name or contrast with siblings like drop_database or use_database.

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. It does not mention prerequisites, permissions, or conditions such as whether the database already exists. It only implies usage by stating the action.

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?

With no annotations, the description carries the full behavioral burden but only states that a table is created from a structured definition. It omits required permissions, behavior when the table already exists, the effect of the schema's default ifNotExists=true, and whether the operation is transactional or irreversible.

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 front-loaded sentence with no filler. It is concise, though its brevity contributes to the broader completeness gaps rather than being a structural flaw.

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 DDL tool with 8 parameters, low schema description coverage, no annotations, and no output schema, the description is too thin. It covers the high-level concept but leaves operational, permission, and idempotency details unaddressed.

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 low (25%) and there are 8 parameters. The description names columns, indexes, and foreign keys, which maps to three parameter groups, but it does not explain table name, engine, database, primaryKey, or ifNotExists semantics.

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 and resource ('Crea una tabla') and adds the source domain ('a partir de una definición estructurada de columnas, índices y claves foráneas'). It does not differentiate from siblings like execute_sql or run_query that could also create tables, but the purpose is clear.

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 explicit when-to-use or when-not-to-use guidance, and no prerequisites or alternatives are mentioned. Usage is only implied by the verb 'Crea' and the required structured definition.

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?

readOnlyHint=true already tells the agent this is a safe read, so the annotation carries the safety profile. The description adds that the read-only property reported pertains to the connection itself, not the tool, which is a useful disambiguation. It does not describe error behavior when no connection is active, which is the main remaining gap.

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 that names the three things returned. No filler, no restatement of the tool name, no redundancy.

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 input parameters and no output schema, the description is the sole source of return-value information, and it does enumerate three returned items (connection, current database, read-only flag). It could go slightly further (e.g., behavior when no connection is active), but it is adequate for a trivial zero-arg read tool.

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 there is nothing for the description to disambiguate. The baseline of 4 applies; the sentence correctly implies no input is needed.

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 set: it shows the active connection, its current database, and its read-only status. That is clear and non-tautological. It does not, however, distinguish itself from the sibling list_connections, leaving the agent to infer the distinction between 'current' and 'all' connections.

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 explicit when-to-use guidance and no mention of alternatives such as list_connections or select_connection. The agent can infer that this applies to the already-selected connection, but nothing in the text confirms it or states when this tool should be preferred.

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 destructiveHint=true, so the safety profile is covered structurally. The description adds the non-empty `where` guard rail, which is real behavioral context, but omits irreversibility, affected-row reporting, and permission requirements.

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 with no filler; the mandatory-parameter constraint is placed where it matters most. It is efficient, though extremely terse for a destructive 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 destructive, non-transactional DB mutation with no output schema, the description says nothing about irreversibility, returned affected-row count, or error conditions. The annotations cover only the destructive flag, leaving a meaningful gap for an agent deciding whether to invoke this.

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%: `where` and `database` are well documented in the schema, `table` is not. The description reinforces that `where` is required and cannot be empty, adding a constraint not stated in the schema, which justifies the baseline 3 rather than lower.

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?

Names a specific verb (borra) and resource (registros) and adds the discriminating condition that the `where` clause is mandatory. It is clearly distinct from select_records/update_records in intent, though it does not explicitly name siblings.

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 note that `where` is obligatory and non-empty is a safety-oriented usage constraint that steers the agent away from unscoped deletion. However, there is no when-to-use/when-not guidance relative to update_records or execute_sql, and no mention of prerequisites or transaction handling.

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, covering the safety profile. The description adds useful behavioral context by specifying the returned content (columns, indexes, CREATE TABLE), but omits error handling, permission requirements, and output format.

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 with no filler. Every word contributes directly to communicating what the tool returns.

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?

No output schema exists, so the description must convey return values; it does so adequately (columns, indexes, CREATE TABLE). However, it omits table identifier format and error behavior, leaving gaps for a database introspection tool.

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 50%: the optional 'database' parameter has a description, but the required 'table' parameter has none. The description adds no parameter-level meaning (e.g., table name format) and therefore does not compensate for the undocumented required parameter.

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 ('Muestra') and resource ('tabla'), and enumerates the returned content (columnas, índices, CREATE TABLE). This distinguishes it from siblings like list_tables, but it does not explicitly name alternatives or differentiate in words.

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 when-to-use guidance, no alternatives named, and no prerequisites stated. The description only declares what the tool does, leaving the agent to infer usage 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?

Although annotations already mark destructiveHint=true, the description adds irreversibility, the mandatory confirm=true requirement, and a user-confirmation workflow. These are meaningful behavioral details beyond the annotation and there is no 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?

Two short, front-loaded clauses convey the core action, irreversibility, and confirmation prerequisite without wasted words. Structure is efficient and appropriate for a simple destructive tool.

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 two-parameter destructive operation with a destructiveHint annotation and no output schema, the description covers the key safety information: irreversibility and required confirmation. It does not explicitly document the name parameter or required privileges, which is a minor 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 coverage is 50%. The confirm parameter is already documented in the schema as 'Debe ser true', so the description's 'requiere confirm=true' is largely redundant. The name parameter is undocumented in both schema and description, and the description does not add meaning about what 'name' identifies.

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 ('ELIMINA') and resource ('una base de datos completa'), clearly distinguishing this from sibling operations like drop_table or delete_records by its database-wide scope. An agent can identify the action 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?

Provides critical usage context: the operation is irreversible, requires confirm=true, and should be preceded by asking the user for confirmation. It does not explicitly name alternative tools or when-not conditions, but the preconditions for safe use are 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 already flag destructiveHint=true, so the safety profile is partly covered, but the description adds valuable non-annotation context: irreversibility, the required confirm flag, and a user-confirmation protocol. It stops short of describing side effects on dependent objects (views, FKs).

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 compact sentences, front-loading the destructive nature and the confirm requirement before the user-confirmation instruction. No wasted words; every clause carries operational weight.

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 destructive tool with no output schema, the description supplies the essential safety contract (irreversible, confirm=true, prompt user), which is enough to call it correctly. It omits details on cascading effects or permission requirements, which would strengthen it further.

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% and the schema already documents confirm ('Debe ser true') and database (default connection DB). The description restates the confirm requirement rather than adding syntax or format details for the table or database parameters, so it only marginally exceeds the schema baseline.

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+resource (delete a table and its data), which cleanly distinguishes it from delete_records (rows), drop_database (whole DB), and create_table among siblings. An agent can identify the operation 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?

Gives clear preconditions: irreversible, requires confirm=true, and instructs to ask the user for confirmation first. It does not, however, contrast itself with delete_records or drop_database, leaving the agent to infer the level of destructive scope.

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 only supply destructiveHint=true; the description adds real value beyond that by disclosing the single-statement constraint, the confirm requirement for DROP/TRUNCATE, and the readOnly-connection limitation. It does not describe transaction semantics, whether multiple statements are rejected, or what is returned, but the safety-relevant context is well covered.

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?

Three short sentences with the core operation front-loaded, then the two safety conditions. No filler, every sentence 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?

For a mutation tool with no output schema and only destructiveHint in annotations, the description covers the essential risks (confirmation, readOnly exclusion, single statement). Missing transaction/return behavior details keep it from being fully complete, but an agent has enough to invoke it safely.

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 50%: confirm and database are documented in the schema, while sql and params are bare. The description reinforces the confirm semantics for DROP/TRUNCATE but says nothing about the params array binding or when to pass database, so it only partially compensates for the gap.

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 (Ejecuta) and resource (sentencia SQL única) and scopes it to statements that modify data or schema, with examples (ALTER, UPDATE, CREATE INDEX). It implicitly separates itself from read-oriented siblings like run_query/select_records, but never names an alternative, so differentiation is inferred rather than explicit.

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?

Gives concrete usage conditions: DROP/TRUNCATE require confirm=true, and the tool is unavailable on readOnly connections. It stops short of explicitly naming run_query/select_records as the alternative for non-mutating statements, so the routing guidance is clear but not complete.

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?

No annotations are provided, so the description carries the full burden. It discloses one useful trait — the insert uses a parameterized query — but says nothing about the 1000-row cap, duplicate handling, transaction/partial-failure behavior, or what happens on a constraint violation.

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, front-loaded with the core action and followed by the record shape. No filler, though the parenthetical about parameterized queries is more behavioral than definitional and could have been expanded instead.

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 mutation tool with no annotations and no output schema, the description is minimally adequate: it conveys the write action and the shape of input rows, but omits return/affected-rows behavior and error semantics for a batch insert.

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 50% (database and ignoreDuplicates are documented in the schema, table and records are not). The description explains that each record is a column->value object, which partially compensates for records, but 'table' remains undocumented in both places.

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 and resource ('Inserta uno o varios registros en una tabla') and clarifies the mechanism (parameterized query, column->value objects). It is clearly distinguishable from siblings like update_records, delete_records and select_records, though it never contrasts itself with the more general run_query/execute_sql.

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 prefer this tool over update_records, run_query or execute_sql, nor any prerequisites (e.g. table must exist, column names must match the schema). Usage must be entirely inferred from the 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=true, so the safe read-only nature is covered. The description adds that it returns configured connections plus the active one, which is useful context, but it discloses no further behavioral traits like error conditions or auth requirements. With annotations carrying the safety profile, a 3 is appropriate.

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, well-formed sentence that front-loads the resource and adds the active-connection detail without any filler. Nothing can be trimmed without losing 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 no-parameter, read-only listing tool, the description covers what is listed and mentions the active connection. It is nearly complete; only minor details (e.g., exact per-connection fields or ordering) are absent, and no output schema exists to cover them.

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 there is no per-parameter semantics to document. Per the rubric, zero parameters establishes a baseline of 4, and schema coverage is 100% with an empty property set.

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 ('Lista') and resource ('conexiones MySQL configuradas') plus what else is returned ('cuál está activa'). This is clear and specific, but it does not explicitly differentiate itself from the overlapping sibling 'current_connection', leaving some potential 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?

Provides no when-to-use guidance, no prerequisites, and no comparison to alternatives such as 'current_connection' or 'select_connection'. The intended usage is inferable from the purpose, but nothing in the text helps an agent choose between these closely related tools.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read. The description adds the meaningful constraint that results are bound to the active connection's server, but says nothing about result size, ordering, or behavior when no connection is selected.

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 with no filler, leading with the verb and immediately qualifying the scope. Nothing is redundant or padded.

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 listing tool with annotation coverage and no output schema, the description is nearly sufficient. The only gap is that it doesn't hint at the shape of returned database entries or what happens with no active connection.

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 correctly implies no arguments are needed and instead frames the behavior as depending on ambient connection state.

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 (Lista) and resource (bases de datos) and scopes it to the active connection's server, which separates it from list_connections and list_tables. It doesn't name a sibling explicitly, so it stops short of a 5.

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 scope: an agent can infer this enumerates databases reachable through the current connection. However, there is no statement of when to prefer it over alternatives such as use_database, describe_table, or re-selecting a connection.

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?

readOnlyHint=true already declares this as a safe read. The description adds no further behavioral context beyond restating the default (current database), which the schema description already covers; nothing is said about scope of results (tables only vs views), ordering, or volume.

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?

One short sentence, front-loaded with the action and resource, with zero filler. Nothing redundant or padded.

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?

A simple read-only list tool with one optional, fully documented parameter, so little is required. However, with no output schema, the description could clarify what is returned (table names, including views/schemas?) and is silent on that.

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 single optional `database` parameter is already fully documented, including its default. The description's '(o de `database`)' merely echoes that and adds no new syntax or semantics.

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 and resource ('Lista las tablas') and scopes it to the current database or an explicit `database`. It is distinguishable from list_databases and describe_table by resource, but it never names those siblings to reinforce the distinction.

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 parenthetical hints that a database can be supplied, but there is no when-to-use guidance, no mention of when to prefer list_databases or describe_table, and no prerequisites. Usage must be inferred entirely.

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 destructiveHint annotation already flags the write/delete nature, so the bar is lower; the description adds real context beyond it by scoping the removal to connections 'registered in this session' and disclosing the precondition that the active connection is protected. It stops short of describing failure behavior or any persistence effects.

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 with no filler; the constraint is placed inline where it matters. It is arguably too terse, but nothing in it is wasted.

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 destructive, single-parameter tool with no output schema and only a destructiveHint annotation, the description covers the essential guard but omits error conditions and any statement of what state remains afterward. Adequate but with clear gaps.

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?

There is one required parameter ('name') with 0% schema description coverage, and the description never mentions how the connection is identified or what form the name takes. The noun 'conexión' loosely implies the target, but the parameter itself is left entirely unexplained.

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 ('Elimina') and resource ('una conexión registrada en esta sesión'), which clearly separates it from add_connection, list_connections and select_connection by action. It does not name a sibling explicitly, but the operation is unambiguous.

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?

It supplies a genuine exclusion — the connection cannot be the active one — which tells the agent when this tool will fail. However, it never says when to use this versus select_connection or add_connection, so routing guidance is only implied.

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 only declare readOnlyHint=true, and the description is consistent with that while adding real behavioral context: the query runs inside a READ ONLY transaction and results are capped at 1000 rows. It stops short of describing error handling or what happens on a rejected statement type.

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?

Three short sentences, each carrying a distinct constraint: allowed statements, transaction/row-limit behavior, and parameter binding. The most decision-relevant fact (read-only) is front-loaded with no filler.

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 output schema, the description usefully discloses the 1000-row cap and the read-only transaction guarantee, which is what an agent most needs. Gaps remain around failure modes (what error a disallowed statement produces) and connection scoping, but the core call contract is covered.

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 only 33% (only `database` is documented), so the description must compensate, and it does for `params` by stating the `?` placeholder convention for binding values. The `sql` parameter's meaning is conveyed only indirectly via the statement whitelist, so it is not fully covered.

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 (Ejecuta) plus resource (consulta SQL) and pins the scope with an explicit statement whitelist (SELECT/SHOW/DESCRIBE/EXPLAIN/WITH) executed in a READ ONLY transaction. This immediately separates it from write-oriented siblings like execute_sql, insert_records, or update_records even without naming them.

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 read-only framing implies when the tool applies, and the allowed-statement list effectively excludes writes. However, it never states the alternative explicitly (e.g., 'use execute_sql for writes') or any prerequisite such as which connection must be active, leaving routing to inference.

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?

With no annotations, the description carries the full burden, and it does disclose two real behaviors: it mutates global state affecting every other tool, and it validates connectivity by checking the server responds. It omits what happens on an unknown connection name, whether the choice persists across sessions, and what is returned.

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?

Three short sentences, the core action front-loaded, and every sentence adds a distinct fact (what changes, why it matters, what it verifies). No filler.

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 one-parameter tool with no output schema or annotations, the description covers purpose, global side effect, and connectivity validation, which is enough to call it correctly. Return value shape and error behavior on an invalid name are the only notable gaps.

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% and the single parameter is documented there with a pointer to list_connections. The description adds only illustrative example values ('dev', 'test'), which is marginal value over the schema — the baseline 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?

States a specific verb and resource ("Cambia la conexión activa") with a concrete example ('dev' o 'test'), so the agent knows exactly what changes. It implicitly distinguishes itself from siblings like list_connections and current_connection by acting on the active connection, but never names an alternative explicitly.

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?

"Todas las demás herramientas usan la conexión activa" supplies the context that makes this tool relevant, which is a useful usage cue. However there is no explicit when-to-use/when-not-to-use statement and no mention of the alternatives (list_connections, add_connection) that would frame the decision.

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, so the safety profile is covered. The description adds genuinely useful behavioral scope by enumerating the supported filter operators (equality/IN/IS NULL), implicitly ruling out range/LIKE comparisons. However, it says nothing about row-limit behavior, defaults, or result shape, so it adds only modest 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?

Two short sentences, capability statement front-loaded and the routing instruction second. No filler, no repetition of the tool name.

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 7-parameter tool with a nested where/orderBy structure and no output schema, the description covers the query surface adequately but omits anything about result format, default/total row behavior, or how errors surface. It is functional but leaves the agent guessing on non-happy-path details.

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 only 43%, leaving limit, offset, table and orderBy undocumented in the schema. The description partially compensates by naming ordering and pagination as supported capabilities and by clarifying filter semantics (equality/IN/IS NULL), but it gives no syntax or boundary hints for the 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?

States a specific verb and resource ('Consulta registros de una tabla') and immediately narrows the capability set to simple filters, ordering and pagination. It also names the sibling it is not for joins/aggregations, so an agent can distinguish it from run_query without opening either 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 the agent to run_query when joins or aggregations are needed, which is a clear when-to-use-this-vs-alternative statement. It does not address the read-only nature relative to insert/update/delete siblings, but the intent is unambiguous.

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?

With no annotations at all, the description carries the full burden, and it discloses very little: it is a mutation tool but says nothing about reversibility, affected-row counts, transaction behavior, or permissions. The one useful disclosure is that `where` is required and non-empty, implying an update without a filter is blocked — a meaningful safety guard for a bulk-update tool, but thin overall.

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 that states the action and the key constraint with no wasted words. It is efficient, though its brevity contributes to the thinness noted elsewhere.

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 destructive bulk-mutation tool with no annotations, no output schema, nested objects, and 4 parameters, the description is far too sparse. An agent lacks the behavioral context needed to invoke this safely or predict its effect.

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 only 50%, and `set` and `table` are undocumented in both schema and description. The description only reinforces the `where` requirement ('obligatorio y no vacío'), which partially extends the schema but does not compensate for the 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?

States a specific verb (Actualiza) and resource (registros), which cleanly distinguishes it from insert_records and delete_records among the siblings. It is a clear purpose statement, though it offers no additional differentiation beyond the verb+resource.

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 on when to use this versus delete_records, insert_records, or execute_sql. It notes that `where` is obligatory, which is a hint, but there are no usage conditions, prerequisites, or alternatives named.

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?

No annotations are provided, so the description carries the full behavioral burden. It doesn't disclose that this mutates session/connection state, what happens if the named database doesn't exist, whether it requires an existing connection, or whether the change persists — all important for a state-changing operation with zero annotation coverage.

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 short sentence with no waste, but its brevity is under-specification rather than efficiency — nothing is front-loaded beyond a vague purpose.

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 annotations, no output schema, and one required parameter undocumented, the description should do substantially more. An agent cannot tell whether this switches databases, errors on missing names, or persists across calls.

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 0% and the sole required parameter ('name') is never mentioned in the description. The phrase 'de la conexión activa' implies the target is implicit, but the description adds no meaning about what the name refers to or its format, so it fails to compensate for the coverage gap.

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 verb+resource ('Selecciona la base de datos') scoped to the active connection, which separates it loosely from select_connection. However, 'selecciona la base de datos actual' is ambiguous — it could read as reading the current DB rather than switching to a named one, and no sibling is named to disambiguate from list_databases or current_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?

No when-to-use, when-not, or prerequisite guidance. Given the dense sibling set (select_connection, current_connection, add_connection, create_database), the description never tells the agent when this tool is the right one.

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