Server Quality Checklist

Tool Scores

• db_schema_listC
  2.9/5.0
  Behavior2/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 states the tool lists saved snapshots without full schema bodies, which hints at a read-only operation, but doesn't clarify permissions, rate limits, pagination (implied by 'limit' parameter), or what 'instantáneas' entails. This leaves significant gaps in understanding the tool's behavior.

  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, efficient sentence that front-loads the core purpose. It wastes no words and directly communicates the tool's function, making it easy to parse quickly.

  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 has an output schema (which should cover return values) and no annotations, the description is minimally adequate for a listing tool. However, with 3 parameters at 0% schema coverage and no behavioral details, it lacks completeness for effective use, especially compared to siblings like db_schema_get. The presence of an output schema slightly mitigates the need to describe returns.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'instantáneas guardadas' but doesn't explain parameters like workspace_id, connection_name, or limit. The description adds minimal semantic value beyond the schema, failing to clarify what these inputs mean or how they affect the listing.

  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 action ('Lista') and resource ('instantáneas guardadas'), specifying it lists saved snapshots without full schema bodies. It distinguishes from siblings like db_schema_get (which likely retrieves full schema) by noting the exclusion of complete schema content. However, it doesn't explicitly name alternatives, keeping it from a perfect score.

  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 db_schema_get or db_schema_save. The description implies it's for listing snapshots, but it doesn't specify contexts, prerequisites, or exclusions, leaving the agent to infer usage from sibling names alone.

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

• db_schema_deleteB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but provides minimal behavioral insight. It implies a destructive operation ('Elimina'), but doesn't disclose critical details like whether deletion is permanent, requires specific permissions, has side effects on related data, or what happens on success/failure. This is inadequate 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, direct sentence with zero wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration.

  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 destructive nature, lack of annotations, and presence of an output schema (which might cover return values), the description is minimally complete but lacks depth. It states what the tool does but omits important behavioral and usage context needed for safe operation.

  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 description adds meaningful context for the single parameter by specifying that 'snapshot_id' refers to a snapshot to be deleted. With 0% schema description coverage and only one parameter, this adequately compensates, though it could elaborate on ID format or sourcing.

  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 action ('Elimina' - deletes/destroys) and the resource ('una instantánea' - a snapshot) by ID, making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like db_schema_update or db_schema_save, which might also modify schema-related data.

  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. The description doesn't mention prerequisites, such as needing an existing snapshot ID, or contrast it with siblings like db_schema_list for viewing snapshots or db_schema_save for creating them.

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

• db_schema_getB
  3.3/5.0
  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 mentions that it returns the most recent schema when snapshot_id is None, which adds some context. However, it lacks details on permissions, error handling, rate limits, or what the output contains (though an output schema exists). For a tool with no annotations, 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 concise and front-loaded: it states the main purpose in the first phrase, followed by a conditional behavior. Both sentences earn their place by providing essential information without 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 tool's complexity (3 parameters, no annotations, but with an output schema), the description is minimally adequate. It explains the core functionality and one parameter's behavior, but lacks details on permissions, errors, or full parameter semantics. The output schema reduces the need to describe return values, but more context is still needed for a higher score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains the behavior of snapshot_id (if None, returns the most recent), which adds meaning for one parameter. However, it doesn't clarify workspace_id or connection_name, leaving two parameters undocumented. This partial coverage is inadequate given the low schema coverage.

  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: 'Obtiene un esquema guardado' (Gets a saved schema). It specifies the verb (obtiene/gets) and resource (esquema guardado/saved schema), making the action clear. However, it doesn't explicitly differentiate from siblings like db_schema_list or db_schema_update, which would require a 5.

  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 on when to use it: 'Si `snapshot_id` es None, devuelve el más reciente para workspace_id + connection_name' (If snapshot_id is None, returns the most recent for workspace_id + connection_name). This gives guidance on parameter behavior but doesn't explicitly mention when to use this tool versus alternatives like db_schema_list or db_schema_update, which would be needed for a 5.

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

• db_schema_saveA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. While it indicates this is a save/persist operation, it doesn't describe important behavioral traits like whether this creates new records or overwrites existing ones, authentication requirements, error conditions, or rate limits. The description provides basic functional context but lacks critical operational details.

  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 appropriately sized and well-structured with a clear purpose statement followed by parameter explanations. The Args section is organized, though the Spanish/English mix slightly affects coherence. Every sentence adds value with no redundant information.

  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 complexity (6 parameters, mutation operation) and the presence of an output schema (which handles return values), the description provides good contextual coverage. It explains all parameters meaningfully and states the tool's core purpose. The main gap is lack of behavioral transparency details that would be important for a write operation.

  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?

  With 0% schema description coverage, the description provides substantial semantic value for all 6 parameters. It explains workspace_id as 'proyecto o carpeta (p. ej. nombre del repo)', connection_name as 'nombre lógico de la BD', schema structure expectations, dialect options, and label/summary purposes. This compensates well for the schema's lack of descriptions.

  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 with specific verb ('Guarda una instantánea') and resource ('esquema de una base de datos'), distinguishing it from siblings like delete, get, list, and update. It precisely communicates this is a save/persist operation for database schema snapshots.

  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 through the parameter explanations (e.g., workspace_id as 'proyecto o carpeta', connection_name as 'nombre lógico de la BD'), but doesn't explicitly state when to use this tool versus alternatives like db_schema_update or db_schema_delete. No explicit when-not-to-use guidance is provided.

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

• db_schema_updateA
  4/5.0
  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 discloses important behavioral traits: the update requires matching workspace_id and connection_name for verification, optional parameters only apply changes if sent, schema replaces the entire JSON, empty strings become NULL in the database, new_workspace_id/new_connection_name rename the snapshot, and bump_captured_at updates the row date by default. This covers mutation effects, data handling, and default behavior.

  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 appropriately sized and front-loaded with the core purpose. Each sentence adds value: verification requirements, optional parameter behavior, renaming functionality, and date update default. While slightly dense, there's minimal waste, and the structure guides the reader through key aspects efficiently.

  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 complexity (10 parameters, mutation tool, no annotations) and the presence of an output schema (which handles return values), the description is largely complete. It explains verification needs, parameter behaviors, renaming, and date updates. The main gap is lack of explicit error cases or permissions, but it covers most operational context well for an update tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description compensates excellently by explaining the semantics of most parameters: workspace_id and connection_name serve as verification, schema replaces the entire JSON, dialect/label/summary only write if passed, new_workspace_id/new_connection_name rename the snapshot, and bump_captured_at updates the date. It adds crucial meaning beyond the bare schema, covering 9 of 10 parameters effectively.

  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 'Actualiza una instantánea existente' (Updates an existing snapshot), providing a specific verb (update) and resource (snapshot). It distinguishes from sibling tools like db_schema_delete, db_schema_get, db_schema_list, and db_schema_save by focusing on modification rather than creation, retrieval, listing, or deletion.

  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 updating an existing snapshot, mentioning that workspace_id and connection_name serve as verification. However, it doesn't explicitly state when to use this tool versus alternatives like db_schema_save (for creation) or provide clear exclusions. The guidance is contextual but not comprehensive.

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