Server Quality Checklist

Tool Scores

• jenkins_get_coverage_reportC
  2.6/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. It states it's a read operation ('obtener'), but doesn't describe what format the coverage report returns, whether it includes summary vs detailed data, if it requires specific permissions, or any rate limits. For a tool with 5 parameters and no output schema, this leaves significant behavioral gaps.

  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, efficient Spanish sentence that gets straight to the point. It's appropriately sized for a tool with clear parameters in the schema. While it could be more informative, it doesn't waste words or include unnecessary elaboration.

  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 tool with 5 parameters, no annotations, no output schema, and multiple similar siblings, the description is insufficient. It doesn't explain what type of coverage data is returned, how it differs from other coverage tools, or provide context about the Jenkins coverage reporting system. The agent would struggle to understand when and how to use this tool effectively.

  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 all parameters are documented in the schema. The description adds no additional parameter semantics beyond implying this tool retrieves coverage reports for builds. It doesn't explain relationships between parameters (e.g., how packageName and className refine the report) or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

  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 description 'Obtener reporte de cobertura de código de un build' clearly states the action (obtener/get) and resource (reporte de cobertura de código/coverage report), but it's vague about scope and doesn't differentiate from siblings like jenkins_get_coverage_lines or jenkins_get_coverage_paths. It specifies 'de un build' which helps somewhat, but doesn't clarify what type of coverage report this returns versus other coverage-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 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. With multiple coverage-related siblings (jenkins_get_coverage_lines, jenkins_get_coverage_paths), there's no indication of what distinguishes this general 'reporte' from those more specific tools. No prerequisites, exclusions, or comparison context is provided.

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

• jenkins_get_build_stepsC
  2.9/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. It states it retrieves status but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what 'estado' entails (e.g., success/failure, duration). This is a significant gap for a tool with no annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every word earning its place.

  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?

  Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'estado' includes (e.g., step names, outcomes, logs) or address complexity like handling multiple builds. For a tool with 3 parameters and no structured output, more context is needed.

  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%, so the schema already documents all three parameters (app, buildNumber, branch). The description adds no additional meaning beyond what the schema provides, such as clarifying how 'app' relates to Jenkins jobs or the format of 'estado'. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 'Obtener el estado de los steps de un build específico' clearly states the action (obtener/retrieve) and resource (steps de un build específico). It distinguishes from siblings like 'jenkins_get_job_status' by focusing on build steps rather than job status, though it doesn't explicitly contrast with them.

  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 doesn't mention prerequisites, when not to use it, or refer to sibling tools like 'jenkins_get_job_status' for broader job information.

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

• jenkins_get_coverage_linesC
  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 full burden but only states what the tool does, not how it behaves. It lacks details on permissions, rate limits, error handling, or output format, which are critical for a tool with 4 parameters and no output schema.

  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 in Spanish that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded.

  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?

  Given the tool's complexity (4 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what 'coverage lines' means, the format of the output, or behavioral aspects like authentication or errors, leaving significant gaps for the agent.

  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 documents all parameters. The description adds no additional meaning beyond implying the 'path' parameter targets a specific file, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

  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 'Obtener líneas de cobertura de un archivo específico' clearly states the action (obtener/get) and resource (líneas de cobertura/coverage lines) with specificity about targeting a file. It distinguishes from siblings like jenkins_get_coverage_paths (which gets paths) and jenkins_get_coverage_report (which gets a report), but doesn't explicitly contrast them.

  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, context, or exclusions, leaving the agent to infer usage from the tool name and parameters alone.

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

• jenkins_get_coverage_pathsC
  2.9/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. It states it's a read operation ('obtener'), implying it's non-destructive, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what the output format looks like (e.g., list of paths). This is a significant gap for a tool with no annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.

  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?

  Given the complexity of a Jenkins coverage tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects, usage context, and output format, which are crucial for an AI agent to invoke it correctly. The description should compensate for the missing structured data but doesn't.

  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 documents all three parameters (app, buildNumber, branch) with descriptions. The description doesn't add any meaning beyond what the schema provides, such as explaining how these parameters interact or affect the results. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 ('obtener todos los paths de archivos') and the resource ('con cobertura'), which translates to 'get all file paths with coverage'. It specifies the verb and resource, but doesn't differentiate from sibling tools like 'jenkins_get_coverage_lines' or 'jenkins_get_coverage_report', which also deal with coverage 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 sibling tools or contexts where this specific tool is appropriate, such as distinguishing it from 'jenkins_get_coverage_lines' for line-level details or 'jenkins_get_coverage_report' for summary reports.

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

• jenkins_get_git_branchesC
  2.9/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 states the tool retrieves Git branches for a job, implying a read-only operation, but doesn't specify whether it requires authentication, rate limits, error handling, or the format of the returned data. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.

  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 in Spanish: 'Obtener las ramas de Git disponibles para un job'. It is front-loaded with the core purpose, has no redundant information, and efficiently communicates the tool's function without unnecessary elaboration.

  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?

  Given the tool's complexity (retrieving Git branches from Jenkins), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what data is returned, potential errors, or dependencies on Jenkins job configurations. For a tool interacting with version control in a CI/CD system, more context is needed to ensure proper usage by an AI agent.

  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% description coverage, with one parameter 'app' documented as 'Nombre de la aplicación' (Name of the application). The description adds no additional semantic details beyond what the schema provides, such as clarifying what 'app' refers to in the Jenkins context or how it relates to the job. Baseline score of 3 is appropriate since the schema handles parameter documentation adequately.

  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: 'Obtener las ramas de Git disponibles para un job' (Get the available Git branches for a job). It specifies the verb 'obtener' (get) and the resource 'ramas de Git' (Git branches) with the context 'para un job' (for a job). However, it doesn't explicitly differentiate from sibling tools like 'jenkins_get_job_status' or 'jenkins_get_build_steps', which focus on different aspects of Jenkins jobs.

  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 doesn't mention prerequisites, such as needing a specific Jenkins job configuration, or compare it to sibling tools like 'jenkins_get_job_status' for job details or 'jenkins_start_job' for job execution. Usage is implied by the purpose but lacks explicit context or exclusions.

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

• jenkins_get_job_statusC
  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 full burden for behavioral disclosure. It states this is a read operation ('Obtener' - Get), but provides no information about authentication requirements, rate limits, error conditions, or what the status output might include. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

  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 Spanish sentence that directly states the tool's purpose. There's no wasted language, repetition, or unnecessary elaboration. It's appropriately sized for a simple status-checking tool.

  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?

  Given no annotations, no output schema, and a read operation that likely returns structured status information, the description is insufficient. It doesn't explain what 'estado' (status) includes, whether it returns simple status strings or complex job metadata, or any error handling. For a tool that presumably returns job status details, more context is needed.

  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%, with both parameters clearly documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in description.

  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 ('Obtener el estado' - Get status) and target resource ('un job específico de Jenkins' - a specific Jenkins job). It distinguishes from siblings like jenkins_get_node_status (node vs job) and jenkins_get_build_steps (steps vs status), but doesn't explicitly differentiate from all siblings. The purpose is specific and understandable.

  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 doesn't mention when this tool is appropriate versus jenkins_get_node_status or jenkins_get_build_steps, nor does it provide any context about prerequisites or typical use cases. The agent must infer usage from the tool name alone.

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

• jenkins_get_node_statusC
  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. While 'Obtener el estado' implies a read-only operation, the description doesn't address authentication requirements, rate limits, error conditions, or what the status response might contain. For a tool that presumably interacts with a CI/CD system, this lack of behavioral context is a significant gap.

  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 Spanish sentence that states the core purpose without unnecessary words. It's appropriately sized for a straightforward status-checking tool and gets directly to the point with no wasted verbiage.

  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 tool with 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what kind of status information is returned, what format it might be in, or how to interpret the results. Given the complexity of Jenkins build systems and the lack of structured metadata, the description should provide more operational 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 description mentions 'un nodo específico de un build' which relates to the 'nodeId' and 'buildNumber' parameters, but doesn't add meaningful context beyond what the 100% schema coverage already provides. The schema descriptions clearly explain each parameter's purpose, so the description adds minimal value here. This meets the baseline for high 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 verb ('Obtener el estado' - Get status) and resource ('de un nodo específico de un build' - of a specific node of a build), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'jenkins_get_job_status' or 'jenkins_get_build_steps', which would require more specific language about what distinguishes node status from other status checks.

  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. There's no mention of prerequisites, when this tool is appropriate versus other Jenkins status tools, or what context would require checking node status specifically rather than job or build status. The agent receives no usage context beyond the basic purpose.

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

• jenkins_get_pending_actionsC
  2.9/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 states the tool retrieves pending input actions, implying a read-only operation, but doesn't clarify aspects like authentication needs, rate limits, error handling, or what 'pending input actions' entail (e.g., user prompts, approvals). This leaves significant gaps in understanding the tool's behavior and constraints.

  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 in Spanish that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly. This conciseness is effective for a straightforward retrieval tool.

  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?

  Given the complexity of a Jenkins tool with no annotations and no output schema, the description is insufficient. It lacks details on what the tool returns (e.g., format of pending actions), error conditions, or how it integrates with sibling tools. For a tool that likely interacts with build processes, more context is needed to ensure proper usage and understanding of results.

  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% description coverage, with clear parameter definitions: 'app' (application name), 'buildNumber' (build number), and 'branch' (Git branch, defaulting to 'main'). The description doesn't add any semantic details beyond this, such as examples or usage context. Since the schema is comprehensive, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

  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 'Obtener las acciones pendientes de input de un build' clearly states the purpose: to retrieve pending input actions for a build. It uses a specific verb ('Obtener') and resource ('acciones pendientes de input de un build'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'jenkins_get_build_steps' or 'jenkins_submit_input_action', which could handle related actions.

  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 doesn't mention prerequisites, context, or exclusions, such as when to choose this over 'jenkins_get_build_steps' or how it relates to 'jenkins_submit_input_action'. Without such information, users must infer usage from the tool name and parameters alone.

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

• jenkins_start_jobC
  2.9/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 full burden. 'Iniciar' implies a write/mutation operation that triggers a Jenkins job, but it doesn't disclose behavioral traits like whether this is asynchronous/synchronous, what permissions are required, potential side effects (e.g., resource consumption), or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap.

  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 in Spanish that directly states the tool's purpose. It's front-loaded with the core action and includes the key constraint. There's no wasted verbiage or unnecessary elaboration.

  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 tool (starting a Jenkins job) with no annotations and no output schema, the description is incomplete. It doesn't cover what happens after invocation (e.g., returns a build ID, triggers async execution), error handling, or integration with sibling tools. Given the complexity and lack of structured data, more context is needed.

  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%, with both parameters ('app' and 'branch') clearly documented in the schema. The description adds minimal value beyond the schema by implying these parameters are used to start a job, but doesn't provide additional context like parameter relationships or examples. Baseline 3 is appropriate when schema does the heavy lifting.

  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 ('Iniciar' - start) and resource ('job de Jenkins') with a specific constraint ('con una rama específica' - with a specific branch). It distinguishes from siblings like jenkins_stop_job (stop vs start) and jenkins_get_job_status (get vs start), though it doesn't explicitly mention these distinctions. The purpose is specific and actionable.

  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 doesn't mention prerequisites (e.g., job must exist), when not to use it (e.g., if job is already running), or refer to sibling tools like jenkins_get_job_status to check status first. Usage is implied but not explicitly stated.

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

• jenkins_stop_jobC
  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 full burden for behavioral disclosure. While 'Detener' implies a destructive action, it doesn't specify whether this requires special permissions, if the stop is immediate or graceful, what happens to queued builds, or what the response looks like. For a mutation tool with zero annotation coverage, 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 a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a tool with a clear, singular purpose.

  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 destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after stopping a job, what permissions are required, potential side effects, or what the tool returns. The combination of mutation nature and lack of structured documentation creates significant 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%, so the schema already documents all three parameters with clear descriptions. The description adds no additional parameter semantics beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.

  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 ('Detener' - stop) and resource ('un job de Jenkins en ejecución' - a running Jenkins job), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'jenkins_get_job_status' or 'jenkins_start_job' beyond the obvious action difference.

  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 doesn't mention prerequisites (e.g., the job must be running), when not to use it, or how it relates to sibling tools like 'jenkins_start_job' or 'jenkins_get_job_status'.

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

• jenkins_submit_input_actionC
  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 full burden for behavioral disclosure. It states the tool sends an input action but doesn't describe side effects (e.g., whether this modifies build state, requires authentication, or has rate limits), return values, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap in 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, efficient sentence in Spanish that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes essential information.

  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?

  Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits, return values, error handling, and integration with sibling tools (e.g., relationship to 'jenkins_get_pending_actions'). For a tool that modifies Jenkins state, more context is needed to ensure safe and correct 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?

  Schema description coverage is 100%, with the single parameter 'decisionUrl' documented as 'URL de la decisión (proceedUrl o abortUrl)'. The description adds no additional parameter semantics beyond what the schema provides, such as how to obtain this URL or format details. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 ('Enviar una acción de input') and the target resource ('a Jenkins'), with specific verbs 'aprobar/rechazar' indicating approval/rejection. It distinguishes from siblings like 'jenkins_start_job' or 'jenkins_stop_job' by focusing on input actions rather than job control or status retrieval. However, it doesn't explicitly mention that this is for pending actions, which could be inferred from sibling 'jenkins_get_pending_actions' but isn't stated.

  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 on when to use this tool versus alternatives is provided. The description implies usage for Jenkins input actions but doesn't specify prerequisites (e.g., needing a pending action from 'jenkins_get_pending_actions'), exclusions, or comparisons to other tools. This leaves the agent to infer context without clear direction.

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