@cocaxcode/database-mcp

by cocaxcode

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.4
Disambiguation4/5
Most tools map clearly to distinct resources (connections, groups, queries, rollbacks, history, config, dumps), and descriptions handle edge cases such as conn_switch vs conn_set_default. The main ambiguity is conn_set being a generic field updater that overlaps with conn_rename, conn_set_default, and conn_set_group; conn_list/conn_get and conn_group_list/conn_project_list are also somewhat similar.
Naming Consistency3/5
The set uses snake_case throughout and is generally readable, but it mixes object-first names like conn_create, rollback_list, and db_dump with verb-first names like execute_query, search_schema, and inspect_last_query. The conn_set/conn_set_default/conn_set_group trio also blurs the verb/noun boundary.
Tool Count2/5
34 tools is a large surface, especially for a server whose connection-management subset is fragmented across create, set, rename, duplicate, switch, set_default, set_group, export, and import. While the domain is broad, many of these could be consolidated, making the set feel heavier than necessary.
Completeness4/5
The core workflow is well covered: connection lifecycle, query execution, mutations with rollback, history, config, and dump/restore all have corresponding tools. Minor gaps exist, such as no rollback cleanup command and no explicit transaction control, but agents can work around them.
Average 3.8/5 across 30 of 34 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 states that an association is removed, but does not disclose whether the connection itself is affected, whether the action is reversible, or what the outcome/return value is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and it is front-loaded with the core action. However, it is so terse that it omits context that would help an agent understand side effects and usage boundaries.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation-like tool with no annotations and no output schema, the description should provide more context about side effects, reversibility, and expected response. The simple parameter set reduces the need for detail, but the missing behavioral information leaves the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the only parameter 'project' is already described as 'Ruta del proyecto'. The tool description adds no additional parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Elimina la asociacion de conexion') and the target resource ('de un proyecto'), making it distinct from sibling tools like conn_delete, conn_set, and conn_switch. It conveys a specific unlink operation rather than a general delete or create action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 conn_delete or conn_set. The description implies the use case but does not state exclusions, prerequisites, or when another sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Al modificar el grupo de una conexión, es una operación mutadora. No se indican permisos requeridos, reversibilidad, ni qué ocurre si el grupo no existe. La descripción es demasiado escueta y las anotaciones ausentes no compensan la falta de contexto.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Una sola oración compacta y directa que comunica el propósito central. Sin relleno ni repeticiones innecesarias.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Herramienta simple con dos parámetros documentados y sin esquema de salida. El significado de grupo no se contextualiza con respecto a los comandos conn_group_*, y no se informa si devuelve algo o cómo se reportan errores.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
El esquema cubre el 100% de los parámetros con descripciones breves que repiten el nombre, aunque añaden el detalle de que 'connection' y 'group' son nombres. No aporta reglas de formato, valores permitidos ni relaciones entre parámetros más allá del tipo string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
La descripción 'Asigna o cambia el grupo de una conexión existente' tiene un verbo específico y un recurso claro (grupo de una conexión), y se distingue de la herramienta conn_group_create al centrarse en conexiones existentes, aunque no nombra alternativas explícitas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indica el efecto pero no ofrece orientación sobre cuándo usar esta herramienta en lugar de conn_group_create, conn_set_default u otras herramientas hermanas. No se mencionan exclusiones ni casos límite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full transparency burden. It only mentions the absence of ANALYZE by default, but doesn't clarify that the tool is read-only, doesn't modify data, or any other side effects. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally brief and to the point, using only two sentences without redundancy. It conveys the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is minimal and doesn't cover what the output format looks like or any limitations (e.g., that EXPLAIN doesn't execute the query). This leaves gaps in what an agent can anticipate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all 7 parameters, covering each field. The tool description adds no additional context or explanation about how parameters like 'verbosity' or 'max_rows_in_response' relate to the EXPLAIN plan, so it adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows the execution plan of a query via EXPLAIN, distinguishing it from execute_query which actually runs the query. It also notes the default behavior (without ANALYZE), adding specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 like execute_query or search_schema. It fails to mention scenarios such as query performance analysis or debugging execution plans.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description does not mention side effects, reversibility, or whether renaming a connection could affect dependent objects or active sessions. While it is clear that the operation renames, the lack of any additional behavioral context is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core action without unnecessary words. It is effectively concise, though it provides no additional structural elements like examples or headings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter rename operation, the description is adequate but sparse. It does not address potential edge cases like renaming a connection that does not exist or is currently in use, and it does not describe any return value (though no output schema exists). The high schema coverage partially compensates, but the lack of annotations and behavioral details leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since both parameters have descriptions. The tool's description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool renames an existing connection, using a specific verb and resource. It is distinct from sibling tools like conn_create or conn_delete, which imply different operations. The purpose is immediately clear without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no mention of prerequisites, and no exclusions (e.g., cannot rename a connection in use). The description only states the action, leaving the agent without context on its proper usage relative to other connection tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention whether the operation is read-only, performance implications, or what 'current project' means. The one-line description offers only the basic purpose, not the behavioral traits an agent would need to invoke safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. Every word earns its place, conveying the essential action without redundancy. Ideal for a simple listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description does not explain what constitutes a 'dump', whether it lists all dumps or filters them, or what the response contains. Since there is no output schema, the description could have elaborated on the return format or scope, making it only minimally complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is trivially complete. Per the baseline for tools with no parameters, a score of 4 is appropriate since there is no additional parameter meaning to convey; the description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing available dumps in the current project. It uses a specific verb and resource ('list dumps') and the context ('current project') adds clarity. It is easily distinguished from sibling tools like db_dump (create) and db_restore (restore), though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or any prerequisites (e.g., whether a project must be selected). It only states what it does, leaving the agent to infer usage from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description states it lists history and is filterable, but it does not disclose important behaviors such as whether results are sorted (e.g., chronological), how pagination works beyond the limit, what constitutes 'success' status, or whether the tool is read-only. Since there are no annotations, this is a notable gap for a tool that could have side effects (though listing is generally safe). The description does not mention any side effects or read-only guarantee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Spanish, followed by a short clause about filtering. It is front-loaded with the core purpose ('Lista el historial') and includes the key filtering attribute. No fluff or redundant information. It could be slightly more structured with separate sentences for purpose and filters, but it's efficient and within reasonable length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple list operation with 4 optional filters and no output schema, the description provides the essential purpose and filter categories. However, it lacks context on the ordering of results, interpretation of 'estado' (success boolean), and any interaction with other tools like history_clear (e.g., whether this tool only lists in-memory history). Without annotations, some behavioral info would improve completeness. But for a straightforward list tool, it's adequate, scoring a 3.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with each parameter having a brief description: 'type' filters by type, 'limit' caps results, 'success' filters by outcome, and 'connection' filters by connection name. The tool description adds only high-level filter categories ('tipo, conexion y estado') which maps to type, connection, and success, but it doesn't add detail beyond the schema. The schema already documents the parameters, so the description provides a baseline 3, but it doesn't clarify value formats (e.g., allowed types for 'type' field) beyond what the schema lists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Lista el historial de consultas ejecutadas' (Lists the history of executed queries), which clearly identifies the verb (list) and resource (query history). It also mentions filterability by type, connection, and status, providing a clear purpose. However, it doesn't explicitly distinguish from sibling tools like history_clear or inspect_last_query, though the resource is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reviewing executed queries, and the filter hints indicate typical use cases. However, it does not provide explicit guidance on when to use this tool vs alternatives like history_clear or inspect_last_query, nor does it mention any exclusions or prerequisites. Since it's a history listing tool, the context is somewhat clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The verb 'Lista' implies a read-only operation, but the description does not state what output format to expect, whether any filtering applies, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the essential purpose immediately and avoids redundant or empty phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—no parameters and no output schema—the description provides enough context for a basic listing operation. It could be slightly more explicit about what 'conexiones especificas asignadas' means or what fields are returned, but for a zero-parameter list tool it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%, so the schema already fully documents the absence of inputs. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lista') and the resource ('todos los proyectos con conexiones especificas asignadas'), making the core purpose understandable. It does not explicitly distinguish it from sibling tools like conn_list or conn_get, but the focus on projects with assigned connections provides reasonable specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There are no stated exclusions, prerequisites, or references to sibling tools such as conn_project_clear or conn_list, leaving the decision context entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the load. It discloses the conversational/interactive behavior (asking questions) and the options for scope and content, which is useful. However, it does not describe the output file location, potential side effects, or whether it creates a file in the working directory, which would be expected for a dump operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, and front-loaded with the main action. The conversational flow is clearly stated without unnecessary detail. It earns a 4 because it's efficient, though it could be more structured with explicit sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 4 parameters, all with high schema coverage, and no output schema, the description is decent but not complete. It covers the parameter semantics via schema and the conversational behavior, but lacks details on return value (file path, success/error messages) and safety aspects. For a tool that writes to disk, more transparency would be better.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description adds the key behavioral note that if parameters are not passed, the tool will prompt, which supplements the schema. This adds value beyond the schema's static descriptions, hence a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Exporta la base de datos a un archivo SQL' (exports the database to an SQL file). It distinguishes from sibling tools like db_restore and db_dump_list, though it doesn't explicitly mention those. The conversation flow detail adds context about the interactive nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a conversational flow (asking about scope and content) but does not provide explicit guidance on when to use this tool versus alternatives like execute_query or db_restore. It doesn't state exclusions or prerequisites, leaving the agent without clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that changes are saved permanently, which is a meaningful behavioral trait. However, with no annotations present, the description must carry the full burden; it does not mention potential side effects, permissions required, or the impact on running server operations. The statement about permanence is useful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that clearly state the purpose and the key persistence characteristic. There is no superfluous content, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 optional parameters and no output schema, the description provides the essential purpose and a critical persistency detail. The schema covers parameter constraints. However, it does not mention what happens if called with no parameters (likely a no-op) or any other contextual side effects, but overall it is reasonably complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any parameter-specific details, but the input schema already provides comprehensive documentation (max_history and max_rollbacks with ranges and defaults). Since schema description coverage is 100%, the baseline of 3 applies; the description adds no extra value beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool modifies server configuration and that changes are permanent. It uses a specific action verb ('Modifica') and a resource ('configuracion del servidor'), which distinguishes it from getter tools like config_get. However, it lacks explicit detail on what configuration aspects are affected (e.g., history/rollback limits), since those appear only in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that config_get should be used for reading current settings, nor does it describe any preconditions or scenarios where this tool is appropriate. This leaves the agent without explicit usage criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no runtime annotations to indicate safety or side effects. The description says 'Quita un directorio' implying destructive removal from the group, but it does not disclose whether the directory is deleted from the underlying data model, whether cascading effects occur, whether confirmation is required, or what happens if the scope is not currently assigned to the group.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence in Spanish that directly states the operation and condition. No filler or redundant repetition, and the key behavioral detail (current-directory default) is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is concise but for a mutating operation with no annotations and no output schema, it does not explain behavioral impact (e.g., does removal break group attrs? What if scope doesn't exist?), nor cover consequences, errors, or return states. There is no characterization of the group object being modified or the optionality of the scope beyond default. Missing context about precise meaning of 'directorio'. For a parameter set of 2, this is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters (group name and scope path) with high coverage. The description adds a useful behavioral note: if scope is omitted, the current directory is used. This adds understanding beyond the dry schema, though no additional edge constraints, defaults, or value formats are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Quita' - removes) and the target resource (a directory/scope from a group), and the tool name distinguishes this from sibling tools like conn_group_delete (which removes the entire group).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what it does but provides no explicit guidance on when to use this tool versus alternatives (e.g., conn_group_delete for deleting whole groups, conn_group_add_scope for adding scopes). No edge cases, exclusions, or alternative conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the basic action without detailing side effects, prerequisites (e.g., the source connection must exist), constraints (e.g., name uniqueness), or what happens on error. For a mutating operation, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clean sentence with no redundant wording. It front-loads the action and target, effectively communicating the tool's purpose with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of a duplicate operation and full parameter documentation, the description is adequate for a basic tool. However, it lacks details about error cases (e.g., missing source, duplicate new name) or any additional context (like whether it overwrites or returns anything), which would make it more complete for an agent to reason about edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters 'name' and 'new_name' described. The description adds minimal extra meaning by clarifying that 'new_name' is for the copy, which is already implicit in the schema. This meets the baseline for high coverage but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Duplica una conexion existente con un nuevo nombre' clearly states the action (duplicate), the resource (connection), and the result (with a new name). It distinguishes from sibling tools like conn_create (creates new from scratch) and conn_rename (renames existing) by indicating it duplicates an existing connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you want to copy an existing connection with a new name, but it does not explicitly state when to use it versus alternatives like conn_create or conn_rename. There is no 'when not to use' or alternative mention, so it falls into implied usage without clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add value by noting that the password is shown masked, which is a non-obvious behavioral detail. However, it does not explicitly state whether the operation is read-only, nor does it mention any side effects, permissions, or error behavior. The masking note is a positive but insufficient disclosure for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary purpose and a key behavioral note. There is zero wasted wording, and the structure is efficient for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (one parameter, no output schema, no annotations), the description is acceptable but minimal. It states the purpose and one notable behavior (password masking), but does not elaborate on what 'detalles' includes or any prerequisites. This is adequate for a basic get tool but leaves room for more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single 'name' parameter, with 100% coverage, so the description does not need to add extra detail. The description's phrase 'de una conexion' aligns with the parameter, but it adds no new semantic information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves connection details, with a specific verb (obtiene) and resource (detalles de una conexion). It distinguishes itself from sibling tools like conn_list (which likely lists all connections) by focusing on a single connection's details, though it doesn't explicitly mention the 'name' parameter in the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like conn_list or conn_get. It does not mention any prerequisites, exclusions, or specific contexts where this tool is preferred, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description does not disclose behavioral details such as idempotency, overwriting behavior, validation, or error handling. It only states the basic update action, leaving significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and clearly states the purpose. It is appropriately sized for the simple operation it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of parameter descriptions, the description is adequate but lacks context on failure modes, return values, or side effects. It does not mention whether the transaction is persistent or if reconnection is needed, which might be important in a database context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for all parameters (key, name, value), including valid values for key. The tool description adds little beyond the schema, merely restating that a field is updated. It does not enrich the meaning of parameters further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: updating a field of an existing connection. It distinguishes itself from sibling tools like conn_create, conn_rename, etc., by focusing on field updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for updating existing connections, but it does not explicitly mention when to use it over alternatives. No guidance is provided on scenarios like batch updates or when to prefer another tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions a specific behavior: it always asks the user which group the connection belongs to (SIEMPRE pregunta al usuario a que grupo pertenece). However, it does not disclose other side effects such as persistence, credential storage, error handling, or whether it overwrites existing connections. With no annotations provided, this partial transparency is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys the tool's purpose and a key behavior without unnecessary verbosity. It is well-structured and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context about return values, error cases, or prerequisites (beyond the group question). Given the tool's complexity (many parameters, multiple database types), the description is minimal. It does not explain what happens on success or failure, nor does it mention authentication or security considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any information about the parameters. The input schema already provides descriptions for each property (e.g., dsn, host, mode), covering 100% of the parameters. Since schema coverage is high, the baseline score is 3; the description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a new database connection (Crea una nueva conexion) and specifies supported types (PostgreSQL, MySQL o SQLite). This distinguishes it from sibling tools like conn_set or conn_switch, which imply modification or switching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating new connections via the verb 'crea', but it does not explicitly contrast with alternatives like conn_set or provide context on when to choose this tool over others. No exclusions or specific scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it requests confirmation and creates a snapshot for rollback. It also mentions default result compression. These are important side effects that might not be obvious, and no annotations are present to cover them. However, it does not explicitly mention irreversibility (except via rollback) or potential locking, but the core behaviors are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. It conveys the essential purpose and a key usage hint without any extraneous information. The structure is clear and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain what the tool returns. It mentions result compression but not the structure or content of the response (e.g., affected rows, result set, error handling). Given that there is no output schema, the description should clarify the return value. This omission makes the tool's context incomplete for a caller.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides detailed descriptions for all parameters (100% coverage). The tool description adds a specific note about using verbosity=minimal for mutations, which is useful, but it does not add significant semantic value beyond what the schema already offers. According to the baseline for high schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool executes mutations (INSERT, UPDATE, DELETE, DDL), which unambiguously specifies its purpose and distinguishes it from query-only tools like execute_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance (e.g., using verbosity=minimal for mutations when only affectedRows matter), but it does not explicitly advise when to use this tool versus alternatives like execute_query or explain_query. The distinction is implicit from the term 'mutacion' but not directly contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation through 'Lista' and 'Muestra', but does not explicitly state that it is non-destructive, nor does it mention any side effects, permissions, or pagination behavior. It adds minimal context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action, and contains no unnecessary words. Every sentence contributes to the purpose, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters and no output schema, the description conveys the purpose and scope well. It could mention what fields are returned (e.g., snapshot IDs), but it is complete enough given the low complexity and lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes both parameters (limit, connection) fully (100% coverage), so the description adds no additional meaning. Since the schema already handles the semantics, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Lista' (lists) and identifies the resource 'rollback snapshots disponibles' (available rollback snapshots), explicitly stating it shows recent mutations that can be reverted. This clearly distinguishes it from sibling tools like rollback_apply and history_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to see available rollback operations before applying one, but it does not explicitly state when to use this tool versus alternatives like rollback_apply or history_list. No exclusions or comparisons are given, so 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.
Behavior3/5
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 that the group's connections become accessible from the added directory, which is a key behavioral outcome. However, it omits prerequisites (e.g., group must exist, directory path validity), potential errors, reversibility, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and action, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple additive operation with complete schema coverage, the description is mostly adequate. However, without annotations or an output schema, it lacks details on error conditions, return values, or side effects. It covers the core purpose but leaves room for more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds minimal semantic value beyond the schema, mainly rephrasing 'directorio' as 'scope' and reinforcing the default behavior of omitting scope. Baseline of 3 is appropriate since schema already fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: adds a directory (scope) to a group, and explains the functional consequence (connections become accessible from that directory). It distinguishes from the sibling conn_group_remove_scope by its additive nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need to add a scope to a group. It does not explicitly mention alternatives or exclusions, but the purpose is straightforward and the sibling existence is implicit. Lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool executes a SELECT 1 and measures latency, which is good, but doesn't detail error behavior, timeouts, or whether it modifies state. For a simple read operation, this may be sufficient, but some behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, with no waste. It front-loads the action and includes the operational detail of executing SELECT 1 and measuring latency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is mostly complete. However, it doesn't mention what output to expect (e.g., latency value, success/failure) or edge cases. Given the simplicity and schema coverage, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already defines the parameter 'name' as the connection name. The description adds the action (test connection) but doesn't add extra parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: testing a database connection by executing SELECT 1 and measuring latency. This is specific and distinguishes it from siblings like conn_create, conn_set, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to verify connectivity and performance. However, it doesn't explicitly mention alternatives or when not to use it. Given the sibling list, there are no similar testing tools, so it's clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of conveying safety. 'Muestra' implies a read-only operation, but it does not explicitly state that no modifications are made or whether sensitive configuration is exposed. It adds useful context about the content (rollback and history limits) but lacks deeper 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the tool's purpose and scope with minimal verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description adequately explains what the tool returns (server configuration with emphasis on rollback and history limits). It does not mention the response format, but given the tool's simplicity, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty. The description does not need to explain parameter meaning. Baseline 4 is appropriate since there are no parameters and the description's mention of config scope adds minor value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Muestra' (shows) and identifies the resource as 'configuracion actual del servidor' (current server configuration), explicitly naming rollback and history limits. This clearly distinguishes it from related tools like config_set (which changes config) and rollback_list/history_list (which list events rather than configuration).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for reading current configuration, but it does not explicitly state when to use it over alternatives or mention exclusions. There is no 'when to use' guidance, but the verb 'Muestra' and the resource scope make the usage context reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the destructive nature ('Elimina') and, more importantly, mandates user confirmation before setting confirm=true. It does not mention permanence or cascading effects, but the key safety behavior is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one short declarative sentence plus a focused safety warning. Every word earns its place and the critical instruction is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter deletion tool with no output schema and no annotations, the description plus schema cover purpose, parameters, and the essential confirmation gate. It lacks some side-effect detail but is otherwise complete enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully explains both 'name' and 'confirm'. The description mostly reinforces the confirm requirement already present in the schema without adding substantial new parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Elimina una conexion' clearly states the tool's verb and resource: deleting a connection. This is unambiguous and distinguishes it from sibling tools like conn_create, conn_set, or conn_rename.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'IMPORTANTE: pide confirmacion al usuario antes de llamar esta tool con confirm=true' provides a critical precondition for safe invocation. However, it does not explicitly discuss when to prefer this tool over alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosing behavioral traits. It discloses that passwords are masked by default and that include_secrets=true will unmask them, which is a key behavioral aspect. However, it does not mention the response format or any side effects, but for a simple export tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, direct and efficiently worded, with no unnecessary verbiage. It front-loads the main purpose and then adds the critical secret-handling detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (two optional parameters, no output schema), the description covers the essential aspects: what it does (exports to JSON) and the key behavioral option (masking). It does not elaborate on the return structure, but that may not be necessary here. It is complete enough for an agent to understand the tool's function and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides thorough descriptions for both parameters (name and include_secrets), and the description adds minimal extra context, such as the JSON export format and the default masking behavior. Since schema coverage is 100%, the baseline is 3, and the description aligns with the schema without contradicting it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Exporta conexiones a JSON' (exports connections to JSON), specifying the verb 'export', the resource 'connections', and the output format 'JSON'. This distinguishes it from sibling tools like conn_list or conn_get, which are likely for reading or retrieving data, whereas this tool specifically exports to JSON.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical guidance on the default masking behavior and how to include secrets via include_secrets=true. It does not explicitly contrast with alternative tools, but it establishes clear context for when to use this export tool, especially regarding secrets handling. It could be improved by noting when to prefer this over conn_list, but it's acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the creation action and a follow-up step, but does not explain side effects, permissions, uniqueness requirements, or what happens on failure. This is adequate for a simple create operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, focused sentences that immediately state the action and the next logical step. There is no repetition or extraneous information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter creation tool without an output schema, the description covers the essential purpose and workflow (create then add scopes). It does not address potential edge cases like duplicate group names or idempotency, but for this level of complexity it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full parameter documentation (100% coverage) for the single 'name' parameter with examples ('cocaxcode', 'optimizatusol'). The description does not contribute additional parameter details, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary function: 'Crea un nuevo grupo de conexiones' (Creates a new connection group). The verb 'crea' and resource 'grupo de conexiones' are specific, and the follow-up mention of 'conn_group_add_scope' distinguishes it from sibling group-related tools by indicating a workflow step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage guidance by instructing the user to 'Luego añade scopes (directorios) con conn_group_add_scope' (Then add scopes with conn_group_add_scope). This clarifies a typical sequence of operations but does not explicitly state when to use this tool versus alternatives like conn_create or conn_group_delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 a crucial side effect: the group's connections are not deleted but become orphaned. This is a valuable behavioral note beyond the basic action, though it doesn't cover other aspects like error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and then the critical side effect. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description is largely complete: it states the action and the key behavioral consequence. It could mention error handling or prerequisites, but these are not essential for a minimal viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'name' is fully described in the schema ('Nombre del grupo a eliminar'), and the description does not add additional parameter semantics. Since schema coverage is 100%, the baseline is 3; the description adds no extra parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes a group ('Elimina un grupo'), with a specific verb and resource. It distinguishes from sibling tools like conn_delete (which deletes a connection) and conn_group_create (which creates a group).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the tool name and description, but there is no explicit guidance on when to use this over alternatives or prerequisites. It does not mention exclusions or context beyond the deletion action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 states the tool lists connections and indicates the active one, which implies a read-only operation, but it does not explicitly disclose side effects, permissions, or any other behavioral traits. The behavior is straightforward but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It is well-structured and front-loaded, making it easily scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description provides adequate information about the primary function (listing connections and indicating the active one). However, it lacks details about the return format (e.g., whether it returns IDs, names, or other metadata), and there is no output schema to compensate. Still, it is sufficiently complete for a straightforward listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. Per the baseline for 0 params, a score of 4 is appropriate since there are no parameter semantics to explain beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's function with a specific verb ('Lista' = lists) and resource ('conexiones disponibles'), and adds a unique outcome ('indica cual esta activa'). This effectively distinguishes it from sibling tools like conn_get, conn_create, or conn_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (to see all connections and identify the active one) but does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool references are provided, so it falls into 'implied usage' rather than clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the key behavior: the default activates automatically when entering the project. However, it does not mention potential side effects (e.g., overwriting an existing default), required permissions, or reversibility, which leaves gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences in Spanish, front-loaded with the action and then the behavioral effect. Every word adds value, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a small tool with one parameter, no output schema, and no annotations, the description adequately explains the purpose and key behavior. It could elaborate on what constitutes a group or what happens on failure, but it is not severely incomplete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because the 'name' parameter has a description matching the tool's purpose. The description does not add additional meaning beyond the schema, such as format or constraints, so it sits at the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Marca una conexion como el default de su grupo' (Marks a connection as the default of its group). It distinguishes from siblings like conn_set_group (which sets group membership) and conn_switch (which switches active connection), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining that the default activates automatically when entering the project, which implies when this tool is useful. However, it does not explicitly mention when not to use it or compare with alternatives like conn_set or conn_switch, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It clearly indicates the tool deletes history (mutating/destructive), but does not mention irreversibility, permission requirements, or side effects on other data. While not misleading, it only partially carries the transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences with zero filler. It front-loads the primary action and clearly mentions the optional filtering. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is nearly complete. It states the action, the optional condition, and the parameter's meaning. It does not describe the return value (e.g., success message or count), but that may be unnecessary given the tool's simplicity and lack of output schema. Slightly more context (like a note that the action is permanent) would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full description for the only parameter 'before' (100% coverage), so the baseline is 3. The description adds the phrase 'solo las anteriores a una fecha' which reinforces the parameter's purpose, but this is largely redundant with the schema's description. No additional semantics like format examples or constraints are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Limpia el historial de consultas' (clears the query history), with an optional date filter. This distinguishes it from sibling tools like history_list (which lists history) and other mutating tools. The verb-resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool to clear history, optionally filtered by date. However, it does not explicitly state when NOT to use it or mention alternatives (e.g., 'use history_list to view, use history_clear to delete'). The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It reveals the tool reverses a mutation and requires user confirmation before execution, which is important. However, it does not explicitly state that the operation is destructive, permanent, or irreversible, nor does it mention any prerequisites or side effects beyond the confirmation requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise – two sentences. The first sentence states the purpose, and the second highlights a critical safety note. No redundant or filler content; every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, no output schema, no annotations), the description covers the core action and the key prerequisite (user confirmation). It does not explain return values or error scenarios, but for a simple mutation tool with a well-covered schema, it is adequate. A more detailed note on permanent effects would push it to a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage). The description reinforces the confirm parameter's requirement ('confirma con el usuario antes de ejecutar con confirm=true'), but this essentially repeats the schema's existing description ('Debe ser true para confirmar. Pregunta al usuario antes.'). It adds minimal new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Revierte una mutacion usando un rollback snapshot' – a specific verb (revert) and resource (mutation using a rollback snapshot). This distinguishes it from sibling tools like rollback_list, which lists snapshots, and history_clear, which clears history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a critical safety instruction: 'confirma con el usuario antes de ejecutar con confirm=true.' It provides clear context on when to use the tool (when a rollback snapshot exists) but does not explicitly state when not to use it or mention alternatives. The guidance is helpful but lacks direct comparison to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral transparency burden. It does disclose that this is a read-only listing and what is included, but it offers no caveats about return format, ordering, authentication, or failure behavior. This is adequate for a trivial list tool but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states exactly what the tool returns with no filler or repetition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and a simple listing purpose, the description is nearly complete: it names the entity and the key fields returned. It could add a note about output format or empty results, but for this complexity level it is quite sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers parameter semantics. The description correctly focuses on the output rather than inputs, and no additional parameter guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lista') and identifies the exact resource ('grupos') plus the associated data returned (scopes, default, conexiones). This clearly distinguishes it from siblings like conn_list, conn_group_create, and conn_group_add_scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Lista todos los grupos' provides clear context for when to use this tool: whenever you need an unfiltered view of all groups and their links. It does not explicitly name alternatives, but no other sibling is a group-list tool, so the context is sufficient and there are no exclusions to state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It communicates that the change is session-scoped and not permanent, which is useful context. However, it does not disclose validation behavior, effects of switching, or error conditions, leaving some uncertainty about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the first states the core operation and scope, the second provides the key alternative. There is no filler, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple connection-switching tool with two well-schema-documented parameters, the description is largely complete: it explains the action, the session scope, and the related default-setting tool. It omits return/error details, but given the simplicity and lack of output schema, this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters ('name' and 'project'), and the description adds no parameter-specific meaning beyond that. The baseline of 3 applies because the schema already documents the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and object: 'Cambia la conexion activa (de sesion)' clearly states it switches the active session connection. It also distinguishes itself from conn_set_default, so the agent knows exactly what this tool does versus related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance by saying 'Para cambiar el default permanente usa conn_set_default,' naming a specific alternative for the permanent-default case. This tells the agent when not to use this tool and where to route that request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly states that existing connections are skipped by default and that overwrite=true replaces them, which is meaningful disclosure for an import/mutation tool. It does not cover broader side effects or return behavior, but for a straightforward import it is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary purpose and followed by the key behavioral caveat. Every sentence contributes value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two simple parameters, full schema coverage, and no output schema, so the description doesn't need extensive return-value details. It covers the import source, duplicate policy, and overwrite behavior, making the tool reasonably complete for its complexity. Minor gaps exist around errors or partial import behavior, but they are not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the consequence of overwrite=false (skipping existing connections) and explicitly pointing to overwrite=true for replacement, which the schema does not fully convey. It also references the JSON format from conn_export, reinforcing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Importa conexiones desde un JSON exportado' (imports connections from an exported JSON). It clearly distinguishes the tool from siblings like conn_export and conn_create, and adds duplicate-handling detail that sharpens the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the intended use: importing connections from a conn_export-generated JSON, rather than creating them one by one with conn_create. It also gives concrete guidance on when to set overwrite=true. However, it does not explicitly name alternative tools or state when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the destructive behavior (DROP TABLE + CREATE TABLE) and the requirement for user confirmation, which are the most critical side effects and preconditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loads the primary action, and then emphasizes the critical destructive warning, making it well-structured and easy to follow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the core action, destructive nature, and confirmation requirement, but does not mention return values or post-restore behavior. Given no output schema, a brief note on expected success/failure would improve completeness, but it is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (confirm and filename), so the tool description adds no additional semantic value beyond what is already documented. Schema coverage is 100%, keeping the baseline at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Restaura un dump SQL') and the resource ('en la base de datos activa'), making it unambiguous and distinct from sibling tools like db_dump or rollback_apply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to ask the user for confirmation before executing (with confirm=true), providing a clear when-to-use condition. It does not mention alternatives, but the destructive nature implicitly cautions against casual use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses automatic LIMIT injection, result compression behavior (verbosity levels, cell truncation), and the ability to recover full results via inspect_last_query. This is rich behavioral context beyond the schema, though it doesn't mention side effects or error handling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Both the description and the verbosity parameter explanation are well-structured and front-loaded. The description is concise in the main description field, and the verbose parameter details are placed in the parameter descriptions where they belong, not bloating the top-level description. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (8 params, multiple verbosity levels) and has no output schema, but the description compensates well by explaining the return behavior (compression, truncation markers, recovery path). It could mention what the result contains when compressed (e.g., return keys) but the verbosity parameter description already covers that. Missing explicit mention of error behavior or side effects, but for a read tool it's largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in the schema. The description adds value by explaining the verbosity levels' use cases and the compress-then-recover workflow, which goes beyond the schema's flat parameter descriptions. However, it doesn't reiterate every parameter since the schema already covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Ejecuta una consulta de lectura (SELECT, SHOW, etc.)' with a specific verb and resource type. It distinguishes from sibling execute_mutation by explicitly limiting to read operations, and mentions automatic LIMIT injection as a key behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (read queries) and when to use inspect_last_query for full results without re-execution. However, it doesn't explicitly exclude write queries or name execute_mutation as the alternative for mutations, though the read-only framing implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states that it does not re-execute SQL, returns full results without truncation or row caps, and handles missing call_id by returning the most recent. It also implies a warning behavior via the parameter description. This is excellent behavioral disclosure beyond what the schema offers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main purpose and key behavioral notes. Every sentence adds value with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 parameter, no output schema), the description is sufficiently complete. It covers purpose, usage, and key behavioral notes. It could benefit from a brief note on the return format, but since it's about retrieving a stored result, the expectation is clear. The low complexity does not demand more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the call_id parameter with a description, but the tool description adds essential context: that the call_id comes from a compressed response, and the behavior when omitted. This goes beyond the schema's description and clarifies the purpose of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the complete result of a previous execute_query, execute_mutation, or explain_query, with explicit mention that it does not re-execute SQL. This clearly distinguishes it from sibling execution tools like execute_query, execute_mutation, and explain_query, which actually execute queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: use the call_id from the compressed response, and if omitted it returns the most recent query. It also warns about multiple queries in the last 5 seconds. However, it does not explicitly state when not to use this tool or mention alternative tools (e.g., for re-executing), but 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses behavior by explaining what each detail level returns (names, names+columns, full with FK and indices), which is additional context beyond the schema enum labels. It does not explicitly state read-only behavior, but the search semantics are inherently non-destructive and clearly implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that front-load the purpose and then clarify the available detail levels. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity search tool with all optional parameters, the description sufficiently covers the core purpose and output granularity. The absence of an output schema is partially addressed by describing what each detail level includes. It could mention the result format or read-only nature, but the information provided is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics for the 'detail_level' parameter by expanding on what 'names', 'summary', and 'full' actually return, which the schema enum descriptions do not fully convey. This justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Busca' (searches) and the resource 'tablas/vistas en el schema de la base de datos' (tables/views in the database schema). It distinguishes the tool from sibling tools focused on connection management or query execution by specifying its schema-discovery role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when exploring the schema for tables/views. It also explains the three detail levels, guiding the agent on output granularity. However, it does not explicitly mention alternative tools or when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![database-mcp MCP server](https://glama.ai/mcp/servers/cocaxcode/database-mcp/badges/card.svg)](https://glama.ai/mcp/servers/cocaxcode/database-mcp)

Score Badge

Copy to your README.md:

[![database-mcp MCP server](https://glama.ai/mcp/servers/cocaxcode/database-mcp/badges/score.svg)](https://glama.ai/mcp/servers/cocaxcode/database-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cocaxcode/database-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server