Server Quality Checklist

Tool Scores

• siigo_describe_functionB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=true, so the read-only nature is clear. The description adds context about the output content (parameters, order, defaults, example), which is useful given no output schema, but it does not disclose other behavioral details such as error handling or prerequisites.

  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 compact noun phrase that conveys the essential content without wasted words. It is appropriately sized, though it lacks a verb and could be slightly more explicit, so it does not earn a perfect 5.

  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 parameter, read-only annotation, and no output schema, the description adequately explains what the tool returns. It is missing usage context, but the information provided is sufficient for a straightforward meta-function description tool.

  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 parameter 'funcion' with an example, so coverage is 100%. The tool description does not add any additional parameter-level meaning beyond that, 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.

  Purpose4/5

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

  The description lists what the tool provides (parameters, positional order, default values, and a manual example), making the purpose clear. The title 'Describir una funcion de ExcelSIIGO' adds the verb and resource, distinguishing it from sibling tools that perform actual operations.

  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 explicit guidance is given on when to use this tool versus alternatives like siigo_list_functions. The implication is that it is for looking up function details, but there is no direct statement of use cases or exclusions.

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

• siigo_set_company_aliasA
  3.6/5.0
  Behavior3/5

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

  The annotations (readOnlyHint: false, destructiveHint: false) already indicate this is a non-read-only, non-destructive operation. The description adds modest context by explaining that the tool assigns a readable name, but it does not disclose additional behavioral traits such as persistence, overwrite behavior, or permissions. With annotations covering the safety profile, a score of 3 is appropriate.

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

  Conciseness5/5

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

  The description is a single, concise sentence that is front-loaded with the action and resource. Every word contributes to meaning, with no redundancy or filler.

  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 (2 required parameters, no output schema, no nested objects) and the presence of annotations and full schema coverage, the description is sufficiently complete. It provides the core purpose and the schema handles parameter details, making it adequate for an agent to select and invoke the tool correctly.

  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 has 100% coverage: both 'empresa' and 'alias' have descriptive examples ('Ruta de la empresa' and 'Nombre legible'). The description adds a little context by explaining the rationale (refer by name instead of path), but it does not add parameter-level details beyond the schema. Baseline 3 is correct.

  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 'Da' (gives) and the resource 'un nombre legible a una empresa' (a readable name to a company), making the purpose specific. It also explains the benefit of referring to a company by name instead of path. However, it does not explicitly distinguish this tool from sibling tools, so it misses the top score.

  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 usage context: you use this tool when you want a readable alias for a company. It does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. This is implied usage rather than explicit guidelines.

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

• siigo_list_installationsA
  3.7/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description discloses the exact search sources (Windows registry, server configuration, drive scanning) and detection criterion (folders containing EXCELSIIGO.exe). This adds valuable context about the tool's behavior and what to expect in terms of scope and method.

  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 and immediately front-loads the main purpose. Every sentence contributes: the first defines what the tool returns (installations), the second explains how they are found. No fluff or repetition.

  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 zero-parameter, read-only list tool with no output schema, the description is largely sufficient. It explains the object (installations), the detection method, and the search areas. However, it could be slightly more explicit about the returned data format (e.g., folder paths, installation names), which is not specified but is reasonably inferred.

  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 description does not need to explain any. Per the rubric, a baseline of 4 is appropriate when there are no parameters, and the schema coverage is trivially complete. The description adds no parameter-related details because none exist.

  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 resource (SIIGO Pyme installations) and the action (detected on the computer), and the title explicitly says 'Listar'. It distinguishes from siblings like siigo_list_companies by specifying it scans for folders with EXCELSIIGO.exe. The verb is slightly implicit in the description ('detectadas') but the title and context make it clear.

  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. It does not mention exclusions or prerequisites, relying entirely on the user to infer that it is for listing installations. Given the sibling tools list existing, a brief note on when to choose this over, say, siigo_list_companies or siigo_add_installation would be helpful.

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

• siigo_get_configA
  4/5.0
  Behavior4/5

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

  The annotation readOnlyHint=true already communicates the read-only nature, but the description adds valuable context beyond this: 'Las claves aparecen enmascaradas' (keys appear masked) discloses a specific behavioral trait—that secrets are not shown in plaintext. This is useful for an agent to set expectations about the response. No contradiction with annotations.

  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, with the main action first ('Muestra la configuracion actual') and a key detail second. Every word earns its place; there is no fluff or 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 simplicity (no parameters, no output schema, basic read operation), the description provides sufficient context: it names what is shown and the masking behavior. However, it does not describe the structure or format of the configuration returned, which could be helpful but is not critical for a config viewer. The presence of readOnlyHint annotation compensates for some missing context.

  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, so there is nothing to add semantically. Per the rubric, 0 params defaults to a baseline of 4. The description does not need to elaborate on parameters since none exist.

  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 with a specific verb ('Muestra' = shows) and resource ('la configuracion actual' = current configuration). It is distinct from sibling tools, which focus on specific data entities like companies, functions, or financial records, making this the obvious tool for viewing server configuration.

  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, nor any exclusions or prerequisites. The purpose is self-evident (view config), but there is no explicit statement of context, such as 'use this to inspect current settings before making changes.' This is similar to the MID example (update_drive) which scored 2 for lacking usage guidance.

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

• siigo_list_companiesA
  4.1/5.0
  Behavior4/5

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

  Annotations already flag readOnlyHint=true, and the description adds meaningful procedural details: reading filepath.txt, exploring SIIWI00..SIIWI99 folders, discarding non-SIIGO data, and checking credentials. This goes beyond the structured hint without contradicting it, providing context on what the tool inspects.

  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 only two sentences and states the core behavior efficiently. However, the first sentence 'Empresas SIIWInn visibles' is a fragment and slightly cryptic, though the second sentence clarifies the process.

  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 description explains what the tool does, how it filters installations, and the output concept (credential status). Since there is no output schema, it would benefit from a more explicit output shape, but the simplicity of the tool (no inputs) and the clear process make it sufficiently 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?

  With zero parameters, the schema carries no parameter meaning, and the description doesn't need to explain any inputs. The 100% schema coverage and absence of parameters justify the baseline 4 per the rubric.

  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 lists visible SIIGO companies ('Empresas SIIWInn visibles') and details the process of reading filepath.txt and scanning SIIWI folders, distinguishing it from list-installation and data-fetching siblings. 'Indica si cada empresa ya tiene credenciales configuradas' specifies the credential-status check, making the purpose concrete.

  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 for discovering SIIGO companies and their credential status, but it does not explicitly state when to choose this over sibling tools like siigo_list_installations or siigo_get_config. Since the context is clear but no alternatives or exclusions are mentioned, it earns a 3.

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

• siigo_add_installationA
  4.2/5.0
  Behavior3/5

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

  Annotations are neutral (readOnlyHint=false, destructiveHint=false). The description adds a useful precondition: 'Debe contener EXCELSIIGO.exe' (must contain EXCELSIIGO.exe). However, it does not disclose what happens if the file is missing, error behavior, or side effects, so transparency is limited beyond the annotation baseline.

  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, with the action verb first, a clear condition, and a key requirement. No filler words or 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 single parameter and no output schema, the description adequately covers the essential purpose, trigger condition, and validation requirement. It could mention the outcome or error handling, but for this simple add operation, it is sufficiently 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%: the 'carpeta' parameter is documented with an example. The description adds the EXCELSIIGO.exe requirement, which is not in the schema, thus enriching parameter semantics and justifying a score above the baseline.

  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: 'Agrega manualmente una carpeta de instalacion' (manually adds an installation folder). It specifies the verb, resource, and the manual/auto-discovery distinction, which differentiates it from sibling tools like siigo_list_installations.

  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 context: 'cuando el autodescubrimiento no la encuentra' (when autodiscovery doesn't find it). This clearly implies this is a manual fallback, but it does not name alternative tools or explicitly state when not to use it, preventing a perfect score.

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

• siigo_read_xlsxA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description adds the pagination behavior and the SIIGO file requirement, which is valuable context beyond the simple read-only hint. It does not detail error handling or return structure, but with annotations covering safety, 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?

  Two sentences, front-loaded with the primary action, then the use case. No fluff 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?

  Given the tool's simplicity and the comprehensive schema, the description covers the main use case and the pagination concept well. The absence of an output schema makes a note about return format slightly desirable, but the description is complete enough for an agent to invoke correctly.

  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 provides 100% coverage with detailed descriptions for all 5 parameters, so the description does not need to add parameter-level detail. The baseline of 3 applies; the description contributes no additional parameter 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 reads any .xlsx generated by SIIGO in a paginated manner ('Lee de forma paginada cualquier .xlsx generado por SIIGO'). This specific verb+resource combination distinguishes it from sibling tools that manage installations or execute functions.

  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?

  Provides explicit usage context: use after an export function returns only the first page of a large result ('despues de que una funcion de exportacion devolviera solo la primera pagina'). It clearly indicates when to use, though it does not explicitly name alternatives or exclusions.

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

• siigo_set_credentialsA
  4.2/5.0
  Behavior4/5

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

  The description adds a valuable security guarantee that the password is never returned in any response, which goes beyond the minimal annotations. It also clarifies the scoping behavior for default vs. company-specific credentials. However, it does not mention whether existing credentials are overwritten.

  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 three sentences long, front-loaded with the main action, and every sentence provides useful context. There is no redundant or filler content.

  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 credential-setting tool, the description covers the core purpose, scoping options, and an important security property. It could mention whether it overwrites existing credentials or returns confirmation, but these are minor omissions for the tool's 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 input schema already provides 100% coverage with clear descriptions for all parameters, including the default behavior for 'empresa'. The description mainly rephrases this and adds a convenience note, offering marginal additional 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 the tool saves a user and password in the server configuration using a specific verb and resource. It also distinguishes between the default and company-specific scenarios, making the tool's behavior clear and distinct from siblings.

  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 explicitly explains when to omit or include the 'empresa' parameter, providing clear usage context for both default and per-company credential saving. It does not explicitly name alternatives, but the tool's unique purpose among siblings makes the usage context clear.

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

• siigo_doctorA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this by stating it does not execute EXCELSIIGO.exe or affect accounting. It adds context about the environment components checked (Windows, Excel, desktop session, credentials, companies, path length limits), which goes beyond the structured annotations.

  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 long, front-loads the main purpose, and packs essential information without fluff. Every clause adds value: the list of checks, the explicit non-actions, and the just-in-time usage instruction.

  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 moderate complexity and the absence of an output schema, the description is complete enough to guide an agent: it explains what is checked, what is not touched, and when to invoke it. It does not describe the return format, but for a diagnostic tool with one optional parameter this is a minor 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 coverage is 100% for the single optional parameter, which already has a clear description ('Descubrir las empresas, que implica escanear discos y tarda mas'). The tool description does not add any further meaning about parameters, but this is unnecessary given the schema fully documents 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 uses a specific verb ('Comprueba') and names the resource ('este equipo pueda ejecutar SIIGO') while enumerating the exact checks performed. It also distinguishes itself by explicitly stating what it does NOT do ('No ejecuta EXCELSIIGO.exe ni toca la contabilidad'), setting it apart from sibling tools that run or modify SIIGO.

  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?

  Provides explicit when-to-use guidance: 'Ejecutela primero cuando una funcion falle sin una explicacion clara.' It also clarifies the tool's safe, non-invasive nature through exclusions, effectively telling the agent when not to worry about side effects and when to choose this diagnostic tool over others.

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

• siigo_list_functionsA
  4.5/5.0
  Behavior4/5

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

  The readOnlyHint annotation already marks this as safe/read-only. The description adds context by stating the exact count (47 functions) and that it maps CLI functions to MCP tool names, which is useful beyond the annotation. It does not mention filtering behavior, but the simple nature of the tool and annotation coverage make this 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 two sentences, front-loaded with the core purpose, and includes a cross-reference to a sibling tool. No wasted words.

  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?

  For a simple list tool with one optional filter and no output schema, the description adequately conveys what the tool returns (catalog of functions with MCP names) and points to describe_function for deeper detail. It is self-contained for the tool's 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% for the single optional parameter 'grupo', which is documented with examples in the schema. The description adds no extra detail about the parameter, so it relies on the schema. 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 this tool lists a catalog of the 47 CLI functions with their equivalent MCP tool names, using a specific verb ('Catalogo') and resource. It distinguishes itself from siblings like siigo_list_companies and explicitly references siigo_describe_function for parameter details.

  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 directs users to siigo_describe_function for viewing parameters of a specific function, indicating when to use this tool (to browse the catalog) versus when to use an alternative. This is clear when/when-not guidance.

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

• siigo_run_functionA
  4.6/5.0
  Behavior5/5

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

  The description discloses that export functions generate an .xlsx and return its first rows, while PUSH* functions import and require confirmation. It also warns that a malformed parameter causes the CLI to return code 081 and still exit with code 0, making errors look like successes. This goes well beyond the annotations, which only indicate destructiveness.

  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, using three sentences to convey the core action, behavior differences, and a critical error-handling tip. The warning about the 081 code is front-loaded and every clause carries meaning, so it earns a high score.

  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 tool with 10 parameters and no output schema, the description covers the essential context: what the tool does, the difference between export and import functions, and the critical error mode. It doesn't detail the exact return structure, but it mentions that export functions return the first rows, which is the key behavior. The reference to describe_function fills the gap for parameter specifics.

  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 provides detailed descriptions for all 10 parameters, so the baseline is 3. The description adds value by warning about malformed parameters and referencing siigo_describe_function for parameter formats, which helps with the nested 'params' object. It also highlights that confirmarEscritura is mandatory for PUSH*, reinforcing 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 executes any of the 47 SIIGO Pyme functions by name, specifying export vs import behaviors. It distinguishes from siblings like siigo_describe_function (which describes functions) and siigo_read_xlsx (which reads files). The verb 'Ejecuta' and resource 'funciones de SIIGO Pyme' make the purpose specific.

  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 tells the user to call siigo_describe_function first to understand the required parameters, which is an explicit usage prerequisite. It also clarifies that PUSH* functions require confirmarEscritura=true, guiding correct operation. However, it doesn't explicitly state when to use sibling tools instead (e.g., siigo_list_functions), so it's clear but not fully exclusionary.

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

• siigo_start_hereA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with these. It adds useful behavioral context beyond the annotations: the tool reveals a 'trampa' that produces wrong data and which functions cannot be undone, and asserts it is the 'unico canal que llega siempre'. This provides meaningful transparency about its role and reliability.

  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 compact: three sentences that state the return value, the usage rule, and the rationale. It is front-loaded with the main function and every sentence adds value. No fluff or repetition.

  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?

  With no parameters, a simple read-only annotation, and no output schema, the description covers all necessary context for an agent to use this tool correctly. It explains what it returns, when to call it, and why it exists, making it complete for its onboarding purpose.

  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 baseline is 4 per the rubric. The description does not need to add parameter semantics, and it correctly focuses on what the tool returns rather than on inputs.

  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: 'Devuelve el protocolo de uso de este servidor' (returns the usage protocol for this server). It specifies the content of the protocol (starting point, the trap that causes wrong data, and irreversible functions) and distinguishes itself from sibling tools by being a mandatory first step before all other siigo_* 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 gives explicit usage instruction: 'Llamela antes de cualquier otra herramienta siigo_* en esta conversacion' (call it before any other siigo_* tool). It also explains why this is necessary, because MCP clients may discard server-sent instructions, making this tool the only reliable channel.

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