Server Quality Checklist

Tool Scores

• get_database_schemaC
  2.8/5.0
  Behavior2/5

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

  The description states the tool returns a JSON with the complete database structure, which is useful. However, without annotations, the description carries the full burden, and the massive irrelevant sections about React component rules and system details actively misdirect the agent about the tool's behavior. It fails to disclose anything beyond the basic return type, such as read-only nature or performance implications.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness1/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  This description is egregiously overlong, with hundreds of words of unrelated DOSSIN system details and React component instructions preceding the actual tool purpose. It is not front-loaded and violates conciseness by forcing the agent to wade through irrelevant material to find the one relevant sentence.

  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 core information about the schema (tables, columns, data types, relations, indexes, constraints) is present, and it explains return format. However, the description is dominated by irrelevant content, and with no output schema or annotations, the agent cannot easily distinguish which parts apply. The context is muddled, making the description incomplete as a guide for proper usage.

  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 there is no parameter semantics to explain. The baseline of 4 applies because the description cannot add value beyond the schema, and it correctly does not attempt to do so.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose3/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The core statement 'Obtiene el schema completo de la base de datos MySQL incluyendo tablas, columnas, tipos de datos, relaciones (foreign keys), índices y constraints' clearly specifies the tool's verb, resource, and scope, and the usage section differentiates it from execute_query. However, this essential purpose is buried under a lengthy unrelated preamble about the DOSSIN system and React component generation, which significantly obscures and dilutes the tool's actual function.

  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 explicit when-to-use guidance: 'Primera interacción con la base de datos', 'Antes de construir consultas complejas', 'Para entender relaciones entre tablas', and 'Cuando necesites saber nombres exactos de columnas'. It implicitly separates it from execute_query by framing schema retrieval as a prerequisite to building queries, but it does not explicitly state when not to use the tool.

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

• execute_queryA
  4.4/5.0
  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 of behavioral disclosure. It successfully communicates the read-only nature via 'Solo consultas SELECT permitidas' and gives a clear list of available data. It also warns about best practices like limiting results. It could additionally describe return format or error behavior, but the essence of the tool's behavior is well-covered.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized into clear sections (DATOS DISPONIBLES, MEJORES PRÁCTICAS, EJEMPLO). Every sentence provides actionable information: the data list prevents guesswork, the best practices are concise and directly useful, and the example demonstrates usage. No filler or 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 SQL query tool with two parameters and no output schema, the description provides substantial context: available tables, best practices, and an example. The main gap is that it does not describe what the query result object looks like (e.g., array of row objects), but given the simplicity and the example, an agent can likely infer this. It also appropriately points to schema discovery as a prerequisite.

  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% (both query and params are described). The description adds value by reinforcing the parameter usage with an example ('SELECT * FROM turnos WHERE fecha >= CURDATE() LIMIT 10') and by explaining the placeholder mechanism (?) for dynamic values. This goes beyond the schema, which only shows type and example, by giving contextual guidance on their combined use.

  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: 'Ejecuta consultas SQL SELECT en la base de datos de Dossin.' It lists the specific data entities available, which helps an agent understand the scope. The sibling tools (get_database_schema, compile_and_save_component) are clearly different in purpose, so this tool is well-distinguished.

  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 explicit best practices: use parameters (?), fetch schema first, use LIMIT, and use CURDATE(). The 'Solo consultas SELECT permitidas' restriction clarifies when not to use this tool (i.e., for non-SELECT operations). However, it does not explicitly name the alternative tool for schema retrieval, though 'Obtén el schema primero' strongly implies get_database_schema.

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

• compile_and_save_componentA
  4.9/5.0
  Behavior5/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 explicitly states the authentication requirement: '⚠️ ANTES de llamar a esta tool, DEBES preguntar al usuario por su token de autenticación.' It explains the backend compilation process, the generation of a public URL, and the traceability of the user. It also warns about not sending hardcoded artifacts. These are valuable behavioral traits beyond what the schema alone would reveal.

  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 lengthy but well-structured with section headers, bullet points, and bold text. The core purpose is front-loaded in the first sentence. While some content is redundant (e.g., repeated emphasis on authentication token), the detailed transformation instructions and usage rules justify the length for a tool with such specific requirements. It could be tightened slightly, but the structure makes it scannable and useful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is highly complete for a tool with 3 required parameters, no output schema, and no annotations. It covers the tool's purpose, authentication prerequisites, step-by-step user interaction, the distinction between artifacts and Dossin components, the transformation procedure, backend compilation behavior, and the expected result (public URL). There are no critical gaps in context or usage requirements.

  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?

  Though the input schema has 100% coverage with each parameter described, the description significantly enriches the meaning of the parameters. For reactCode, it specifies what a valid Dossin component must include (imports, fetch, states) and explicitly says not to send hardcoded artifacts. For userToken, it details the exact flow for obtaining it from the user and explains it is used for Authorization Bearer and traceability. For componentName, it notes it is used for the HTML title and file name. This goes well beyond the one-line schema 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 opens with a clear, specific statement: 'Envía un COMPONENTE DOSSIN al backend para compilación remota a HTML standalone.' It identifies the verb (send), the resource (COMPONENTE DOSSIN), and the purpose (compilation to standalone HTML). It also distinguishes itself from sibling tools (get_database_schema and execute_query) through the 'CUÁNDO USAR' section, explicitly stating when this tool should be used and when it should not. This makes its purpose unmistakable.

  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 provides explicit usage guidance with a dedicated 'CUÁNDO USAR' section: 'Solo después de transformar ARTEFACTO → COMPONENTE DOSSIN', 'Para generar archivos HTML de producción', and 'Para obtener URL pública del componente'. It also clearly contrasts artifacts (NOT to compile) with Dossin components (to compile), giving detailed transformation steps. This fully addresses when to use the tool and when to avoid it.

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