mcp-jenkins

Server Quality Checklist

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

Latest release: v3.5.0
Disambiguation4/5
Most tools are clearly separated by resource area (queue, view, build, node, plugin) and follow get_all_X/get_X pairs. Some ambiguity remains between the generic item tools and job-related operations, and the plugin update/backup/problem variants could be confused, but the descriptions mostly clarify the boundaries.
Naming Consistency5/5
Tool names consistently use snake_case verb_noun patterns, with get_all_<resource>/get_<resource> pairs and set_<resource>_config throughout. Minor deviations like query_items or run_groovy_script still fit the verb-first convention and do not break the overall predictability.
Tool Count2/5
At 35 tools, this is well above the 25-tool threshold and feels heavy for an agent to navigate. Many near-duplicate accessor pairs and plugin variants inflate the surface without adding proportionally distinct functionality.
Completeness3/5
The operational coverage is strong: builds, artifacts, console output, test reports, queue management, nodes, plugins, and pending-input handling are all represented. However, lifecycle operations are incomplete—there is no explicit create/delete for jobs, nodes, or plugins, and no plugin install/update—so administrative workflows hit dead ends unless falling back to run_groovy_script.
Average 3.7/5 across 35 of 35 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 6 of 8 community issues answered or closed in the last 6 months
- No commit activity data available
- Last stable release on August 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks any behavioral disclosure beyond 'Get' and 'Returns: The item'. It does not mention read-only nature (no annotations provided), authentication requirements, error handling, or side effects. An agent cannot infer safety or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and uses a clear Args/Returns format, but it is not front-loaded with essential context. Every sentence is present, but the overall brevity sacrifices necessary detail.
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 presence of many sibling tools and an output schema, the description does not explain how return values map to item types or provide context about error behavior. It fails to help an agent understand when this tool is the correct choice.
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?
The input schema has no description and the description only restates 'The fullname of the item', adding minimal value. With 0% schema description coverage, the description should clarify the parameter format (e.g., full path pattern) but fails 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 description states 'Get specific item from Jenkins' which provides a verb and resource, distinguishing it from list-oriented siblings like get_all_items. However, the term 'item' is ambiguous given many get_* tools (e.g., get_build, get_view) and the description does not clarify what constitutes an item.
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 offers no guidance on when to use this tool versus alternatives such as get_all_items or query_items. It implies usage when you have a fullname, but does not explain prerequisites or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose side effects, permissions, or idempotency, but it only implies a write operation with no further details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it redundantly restates parameter definitions already present in the schema, wasting space that could provide additional context.
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, output schema, or parameter details, the description fails to convey error handling, XML validation expectations, or consequences of setting config incorrectly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description merely echoes parameter names ('fullname', 'config_xml') without adding type constraints, format requirements, or any meaningful semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set specific item config' and identifies the resource as a Jenkins item, differentiating from sibling tools like get_item_config.
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 set_node_config, nor are there any prerequisites or typical scenarios mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits like authentication requirements, side effects (e.g., overwriting config), or what happens on failure. Only the verb 'set' implies mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant 'Args:' section that echoes the schema. It could be more concise by omitting the repeated parameter definitions.
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 with no output schema and no annotations, the description lacks explanation of the operation's effects, success/error responses, and prerequisites. It is insufficient for an agent to understand the tool fully.
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?
With 0% schema description coverage, the description minimally clarifies parameters (e.g., 'The name of the node' and 'The config XML of the node'), but adds no details on format, constraints, or valid values.
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 ('Set specific node config') and the resource ('in Jenkins'), distinguishing it from siblings like get_node_config and set_item_config.
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 on when to use this tool versus alternatives such as get_node_config or set_item_config. The description lacks context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits like side effects, required permissions, or what happens upon stopping (e.g., graceful vs. forceful stop). The description merely states the action without depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a brief sentence and an Args section. It is front-loaded and avoids unnecessary words. However, the Arg descriptions are missing, which slightly reduces structure clarity.
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 tool has no output schema and no annotations. The description fails to explain return values, success/failure behavior, or error conditions. For a stop action, it leaves the agent uninformed about consequences.
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%. The description only lists parameter names ('fullname' and 'number') without any additional meaning, such as format, constraints, or examples. It adds no value beyond the schema itself.
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 'stop' and the resource 'specific build in Jenkins'. It distinguishes from siblings like 'cancel_queue_item' which targets queue items, not builds. However, it does not explicitly contrast with 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?
No guidance is provided on when to use this tool versus alternatives, such as 'cancel_queue_item' or conditions for stopping a build. The description lacks context on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits, but it only states the action. It does not disclose side effects, required permissions, error conditions, or whether the cancellation is reversible.
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 short for a simple tool, but it could be more concise by removing the docstring-style argument list and integrating the parameter into the main 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?
Given the lack of output schema, annotations, and the simplicity of the tool, the description fails to provide essential context about what happens on success or failure, or any prerequisites.
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 coverage is 0%, yet the description adds no meaning beyond the schema. The parameter 'id' is simply restated as 'The id of the queue item', which is redundant.
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 (cancel), the resource (queue item), and the method (by id). It distinguishes well from siblings like get_queue_item (retrieve) and build_item (create).
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 such as stop_build for running builds, nor are there any prerequisites or conditions for cancellation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must stand alone. It indicates a read operation (getting config) but does not disclose the return format or any side effects. Minimal but adequate behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the Args/Returns formatting is somewhat redundant. Still, it conveys the core information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. However, it lacks context about what a node config entails (e.g., XML, JSON). Adequate but not comprehensive.
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 add value. It merely restates the parameter name as 'The name of the node,' adding no semantic detail beyond the schema itself.
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 gets node config from Jenkins using a specific verb and resource. It distinguishes from siblings like set_node_config and get_node, though does not explicitly differentiate.
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 on when to use this tool versus alternatives like get_node or set_node_config. The description lacks context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states that it returns a list of items, with no mention of side effects, performance, or return structure beyond what is implied by the name. This is minimal disclosure.
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 very concise at two lines, but the second line appears to be a redundant documentation header ('Returns: A list of items') that adds little value. Still, it is front-loaded and compact.
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 no parameters and an output schema exists, the description is minimally adequate. However, it does not clarify what constitutes an 'item' or mention pagination, leaving gaps for an agent unfamiliar with Jenkins.
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?
There are no parameters, so schema coverage is 100%. The baseline for zero parameters is 4, and the description adds no additional semantic information beyond the schema.
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 'Get all items from Jenkins', specifying the action and resource. However, it lacks differentiation from sibling tools like 'get_item' or 'query_items', which could cause confusion for an AI agent.
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 usage guidelines are provided. The description does not indicate when to use this tool versus siblings such as 'get_item' (for a single item) or 'query_items' (for filtered results).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavioral traits such as whether authentication is required, rate limits, or side effects. Merely states it returns a list.
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?
Extremely concise: two short sentences with no extraneous information. Front-loaded with the primary action.
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 low complexity (no parameters, simple retrieval) and presence of output schema (documenting return type), the description is adequately complete. Could optionally mention that output is a list of queue items, but not necessary.
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?
Zero parameters, so baseline per rules is 4. Description adds no parameter details, but none are needed as schema covers everything.
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?
Tool description states verb 'Get' and resource 'all items in Jenkins queue', clearly distinguishing from sibling 'get_queue_item' which retrieves a single item. However, no explicit differentiation from other list 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?
No guidance on when to use this tool versus alternatives like 'get_queue_item' or 'cancel_queue_item'. The description lacks context about appropriate use cases, prerequisites, or when to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially indicates that the response includes executor info, but lacks details on permissions, error handling, or read-only nature. The output schema likely covers return structure, but behavioral traits are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. However, the 'Args' section is redundant as it simply restates the parameter name without new info.
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 a simple tool with one parameter and an output schema, the description covers the basic purpose. It lacks usage guidance and does not clarify when to use this versus get_all_nodes or get_node_config, leaving gaps for an agent.
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?
The only parameter 'name' has 0% schema description coverage. The description merely repeats 'The name of the node', adding no additional context like format, constraints, or examples.
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 'Get a specific node from Jenkins' and notes that it contains executor info about the node, distinguishing it from sibling tools like get_all_nodes and get_node_config.
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 on when to use this tool versus alternatives like get_all_nodes or get_node_config, nor any conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation ('Get'), but does not explicitly declare read-only or destructive behavior. With no annotations, the description carries the full burden. It lacks details on side effects, permission requirements, or rate limits, but the operation is simple and the output schema provides some clarity.
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 short and to the point, with the main purpose stated at the beginning. It includes an Args and Returns section. However, it could benefit from a slightly more structured explanation of the depth parameter's effect.
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?
While the output schema exists and covers return values, the description does not differentiate this tool from siblings like get_plugins_with_backup or get_plugins_with_problems. The parameter explanation is vague, and the tool's place in the broader set of plugin-related tools is unclear.
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 0% description coverage. The description adds a brief explanation for the 'depth' parameter ('The depth of the information to retrieve'), which is minimal and vague. It adds some value beyond the schema but does not fully compensate for the lack of parameter documentation.
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 gets plugins that have available updates. This verb+resource pair is specific and distinguishes it from siblings like get_all_plugins (all plugins) and get_plugins_with_problems (plugins with problems). The purpose is unambiguous.
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 such as get_plugin, get_all_plugins, or get_plugins_with_problems. The description does not mention any filters, prerequisites, or context-specific usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the return value (a URL) and does not mention any side effects, permissions, or rate limits. For a read operation, this is minimally acceptable but lacks detail on whether it triggers a build or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear heading, bullet-like parameter explanations, and a returns line. It is front-loaded with purpose. One could argue that the parameter descriptions could be integrated more succinctly, but overall it's well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (context signal shows 'Has output schema: true'), the description handles the return value adequately. The tool has simple parameters and low complexity, so the description is sufficiently complete. It could mention that the URL is direct and accessible, but that's minor.
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 descriptions for all three parameters: fullname, relative_path, and number. Given 0% schema description coverage, this is crucial and well done. The descriptions are clear and functional, though not extremely detailed.
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 'Get the direct URL of an artifact from a specific build in Jenkins' which is a specific verb+resource. It distinguishes from sibling tools like get_build_artifact (which likely returns the artifact itself) by focusing on the URL. However, it does not explicitly differentiate itself among the many sibling tools, so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit guidance on the 'number' parameter ('if None, get the last build'), but does not explicitly state when to use this tool versus alternatives like get_build_artifact or get_all_build_artifacts. There is no mention of prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Returns: A list of all nodes'. It does not disclose behavioral traits such as authentication needs, rate limits, or effects of the operation.
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?
Extremely concise with two sentences. Every word is necessary, and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. However, the description is minimal and doesn't clarify behavior in edge cases (e.g., no nodes). For a simple list operation, it's adequate but not thorough.
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?
There are no parameters, so the schema provides full coverage. The description adds no parameter information, but none is needed given zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all nodes from Jenkins', specifying the verb (get) and resource (all nodes). It distinguishes from siblings like get_node by implying a bulk retrieval.
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 on when to use this tool versus alternatives like get_node. The description does not mention prerequisites, context, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It only states 'Get...config' without confirming it is a read-only operation or discussing auth requirements. Given the absence of annotations, more detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a clear docstring format (Args/Returns). Every sentence provides essential information, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the existence of an output schema, the description is largely complete. It covers the input and high-level output, though it could be more explicit about the output format.
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?
The single parameter 'fullname' is described only as 'The fullname of the item', adding minimal value beyond the schema. No explanation of format, examples, or how to find the fullname. With 0% schema description coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the config of a specific Jenkins item, distinguishing it from siblings like get_item (likely returns metadata) and get_item_parameters (returns parameters). The verb 'Get' and resource 'specific item config' are precise.
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 explains that fullname is required, but lacks explicit guidance on when to use this tool versus alternatives such as get_item or get_item_parameters. It is adequate but could be improved with context on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the minimal description fails to disclose behavioral traits beyond the basic function. No mention of read-only nature, scope (all Jenkins vs folder-level), or any constraints. The description adds no value over the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences. It front-loads the core purpose and is free of wasted words. Every sentence serves a clear function.
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 presence of an output schema (reducing burden to explain returns), the description is adequate but minimal. It covers the basic purpose but lacks any additional context about the tool's behavior within the Jenkins ecosystem, such as what qualifies as 'running' or performance considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters (100% coverage), so the description has no burden to explain parameters. Baseline for 0 parameters is 4, and the description adds no additional meaning, which is acceptable as there are no parameters to clarify.
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 'Get all running builds from Jenkins' with a specific verb and resource. It distinguishes from sibling tools like 'get_build' (specific build) and 'get_all_queue_items' (queue items), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_build, get_all_queue_items). The description lacks any usage context, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states it 'returns' plugins with backupVersion. It omits any behavioral traits like authentication needs, side effects, or rate limits. Read-only operation is implied but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short sections: purpose, parameter, return. Every sentence is necessary and front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with one optional parameter and an output schema, the description covers the essentials. However, it could briefly mention that results are a subset of all plugins.
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 has 0% coverage for the depth parameter. The description adds a brief explanation: 'The depth of the information to retrieve.' This adds some meaning but remains vague about what depth entails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves plugins with a backupVersion for downgrade, using specific verb and resource. It distinguishes from siblings like get_all_plugins or get_plugins_with_updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for downgrade scenarios but does not explicitly state when to use or provide alternatives. No 'when-not' or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states it's a read operation and returns a queue item, but lacks detail on error handling (e.g., if id not found), permissions, or rate limits. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Relatively concise but includes redundant 'Args' and 'Returns' sections that repeat the main description. Front-loaded well, but returns line is vague.
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 presence of an output schema and the simplicity of the tool (one parameter), the description covers the essential purpose and parameter meaning. Adequate for a straightforward get 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 context for the 'id' parameter beyond the schema (which only specifies type integer) by stating 'The id of the queue item'. Since schema description coverage is 0%, this is helpful.
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?
Clear verb 'get' and resource 'queue item', method 'by id'. Differentiates from sibling 'get_all_queue_items' which gets all items.
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 on when to use this tool vs alternatives. Missing context for when a specific item is needed versus listing all items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states execution and return, but fails to disclose that running arbitrary Groovy scripts can be destructive, requires permissions, or runs on the Jenkins master. This is a significant gap for a tool with such power.
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 includes useful examples but is slightly verbose. The main point is clear and front-loaded. Could be more concise by reducing example redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one required parameter and an output schema (not shown). The description explains the return value. However, it misses critical context such as safety warnings, risk of destructive actions, and permission requirements, making it incomplete for such a powerful 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 input schema has 0% description coverage (just types). The description adds that 'script' is the Groovy code to execute, which is minimal but clarifies the parameter's role. Baseline is 3 due to low coverage, and the description adds some value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Execute') and resource ('arbitrary Groovy script on Jenkins'), and clearly distinguishes from sibling tools which are mostly read-only or specific operations.
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 states the tool provides access to internal features not available via REST API, implying when to use it, and includes examples. However, it does not explicitly mention when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It mentions the return structure but does not disclose whether the operation is read-only, what happens on missing items, or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences plus structured Args/Returns. Every part is necessary and no fluff, fitting the format perfectly.
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 simplicity (1 param, output schema exists), the description covers the basic purpose and return structure. However, it could include error handling or prerequisites, like needing the job to exist.
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 meaning to the single parameter 'fullname' by specifying it is the fullname of the item, which is not present in the schema (just 'string'). This provides necessary context 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?
Description clearly states it gets parameter definitions of a Jenkins job, with specific verb and resource. Among siblings like get_item and get_item_config, this tool is uniquely for parameter definitions, so it distinguishes well.
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 does not explicitly state when to use this tool versus alternatives. It implies usage when parameter definitions are needed, but no exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It implies a read operation ('get') but does not explicitly state safety, idempotency, side effects, or performance impact. The depth parameter's effect on dependencies is noted, but overall transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured with separate sections for Args and Returns. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter) and the existence of an output schema, the description covers the core purpose and parameter. It lacks usage guidelines but is otherwise adequate for a basic list-retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the purpose of the 'depth' parameter and its default value, including that it includes dependencies. Since schema description coverage is 0%, this adds valuable meaning beyond the schema's type and default.
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 ('Get all installed plugins') and the resource ('from Jenkins'). It is distinct from sibling tools like get_plugin (single plugin) or get_plugins_with_updates (filtered list).
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 (e.g., get_plugins_with_problems, get_plugin_dependency_graph). The description does not mention any conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the return format (list of views with name and URL) but does not mention performance, rate limits, or safety implications beyond the implied read operation. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and contains zero wasted words. Every sentence adds value.
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 no parameters and an existing output schema, the description is complete enough for a simple list tool. It specifies 'top-level' views, confirming scope. It could optionally mention typical usage contexts, but this is not a critical 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?
No parameters exist, so schema coverage is 100%. The description adds no parameter information beyond the schema, which is sufficient. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get', the resource 'all top-level views', and specifies the source 'from Jenkins'. This effectively distinguishes it from sibling tool 'get_view' which retrieves a single view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all top-level views but provides no explicit guidance on when to use this tool versus alternatives like 'get_view' or other sibling tools. No when-not or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states it retrieves build info but does not explicitly confirm the operation is read-only, mention any side effects, or discuss prerequisites like authentication. The output schema exists but the description should add context about system impact.
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?
Three sentences: purpose, parameter descriptions in Args, and return indication. It is front-loaded with the verb and resource, and every sentence is necessary, with no filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with an output schema, the description covers the essential purpose and parameter behaviors. However, in the context of many similar get_* siblings, it could improve by specifying that it returns metadata (not logs or artifacts) and mentioning that the job must exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must clarify meaning. It explains 'fullname' as the job's full name and 'number' as the build number with a conditional default ('if None, get the last build'). This adds significant semantic value beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with 'specific build info from Jenkins', clearly distinguishing it from sibling tools that retrieve artifacts, console output, or build parameters. It immediately communicates the resource and action.
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 explains the fallback behavior for the 'number' parameter (if None, get the last build), but does not explicitly state when to use this tool versus alternatives like get_build_artifact or get_build_console_output. The usage context is implied but not contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It implies a read-only operation via 'Get', but does not explicitly state safety, error conditions (e.g., build not found), or output format beyond 'console output'. Filtering behavior is described, but full transparency is lacking.
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 standard docstring with a one-line purpose followed by parameter explanations. It is front-loaded and contains no fluff, though it could be slightly more concise without losing information.
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 presence of an output schema (relieving need to describe return type), the description covers parameters and basic behavior. However, it lacks usage examples, error handling notes, and context about when to apply filters. For a tool with 5 parameters and filtering logic, it is adequate but not comprehensive.
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 compensates well. Each parameter (fullname, number, pattern, offset, limit) is explained with semantics like 'regex pattern to filter lines' and 'if None, get the last build'. The order of operations (filtering then offset/limit) is clarified.
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 'Get the console output of a specific build in Jenkins', using a specific verb and resource. It differentiates from siblings like get_build, get_build_artifact, and get_build_test_report by specifying 'console output'.
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?
No explicit guidance on when to use this tool vs alternatives. While the purpose is clear, with 32 sibling tools, the description does not provide context such as 'use this for raw console logs' or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It implies a read operation but does not explicitly state that it is safe or non-destructive. It adds the detail that specifying None for number fetches the last build, which is useful, but lacks disclosure on permissions, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence for purpose, followed by structured Args and Returns sections. Every sentence earns its place with no redundancy. The key information is front-loaded.
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 no annotations and a moderate complexity (2 parameters, output schema exists), the description explains the core functionality and parameter behavior. However, it lacks context about what constitutes a 'script' in Jenkins, error scenarios, and whether the operation is safe. The output schema presumably details return structure, so that gap is acceptable.
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?
Schema description coverage is 0%, so the description is responsible for explaining parameters. It clearly defines 'fullname' as the Jenkins job fullname and 'number' as build number with the behavior of getting the last build when null. This adds full meaning beyond the schema's type-only definition.
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 gets scripts used in a specific Jenkins build, with a specific verb and resource. It distinguishes itself from siblings like get_build (build info) and get_build_artifact (artifacts) by focusing on scripts.
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 like get_build or get_build_console_output. There is no mention of prerequisites, such as needing the job name or build number beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that for depth >= 2, dependencies are included, and it returns None if not found. However, with no annotations provided, the description bears the full burden. It does not mention potential errors, data source, or caching behavior. The depth feature is a positive, but overall transparency is adequate but not comprehensive.
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 (three sections: purpose, args, returns) with no wasted words. It is well-structured and front-loaded with the core purpose. Every sentence provides essential 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 has only two parameters and no enums, the description covers the core functionality well. It explains the depth dependency and return value. However, it lacks prerequisites or use case context. With an output schema present (not shown), the return description is sufficient, but missing a comparison with siblings slightly reduces completeness.
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 significant meaning beyond the input schema. It explains that 'short_name' is the plugin's short name and 'depth' controls information depth (default 2 includes dependencies). Since schema coverage is 0%, this explicit documentation is valuable and clarifies parameter behavior.
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 'Get a specific plugin from Jenkins', providing a specific verb and resource. It distinguishes itself from siblings like 'get_all_plugins' (which retrieves all) and 'get_plugin_dependency_graph' (which focuses on dependencies) by specifying it retrieves a single plugin with optional dependency detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or compare with siblings like 'get_all_plugins' or 'get_plugin_dependency_graph'. The only implicit hint is the depth parameter for dependencies, but no direct usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the return value (queue item number) and the conditional behavior of build_type. However, it does not disclose potential side effects (e.g., queuing a build), failure scenarios, or permission requirements. It adequately covers the basic behavior but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured. It uses a clean list format for args and returns, with no unnecessary words. Every sentence serves a purpose.
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?
Given that an output schema exists (as per context signals), the description need not detail return values beyond mentioning the queue item number. It covers all parameters and their roles, and the return type. The description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaningful context: fullname is 'The fullname of the item', data is 'parameters to trigger the build', and build_type is explained with a condition. This provides essential semantics beyond the schema's enum and type definitions. It could be more precise about the format of fullname.
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 'Build an item in Jenkins', indicating a specific action (build) on a resource (item). It distinguishes from sibling tools by focusing on building rather than retrieving or configuring items. However, the term 'item' is slightly vague; Jenkins typically uses 'job', but context clarifies.
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 guidance on when to use 'buildWithParameters' and when the 'data' parameter is required. It implicitly tells the agent to use this tool for building items, and no sibling tool offers the same function, so no explicit when-not is needed. The guidance is clear but could be more explicit about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the output (list of problematic plugins) but not behavioral aspects like read-only nature, performance, or permissions.
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 minimal and front-loaded with the purpose, using two sentences plus a return line. No superfluous 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?
Given zero parameters and an output schema, the description covers the purpose and output adequately. Lacks extra context like prerequisites, but is sufficient for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per scoring rules. The description does not need to add parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all plugins with problems from Jenkins, listing example issues like missing dependencies and incompatible versions, distinguishing it from sibling tools like get_all_plugins or get_plugin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving problematic plugins, but does not explicitly differentiate from alternatives like get_plugins_with_updates or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It explains that if 'number' is None, the last build is used, which adds value. However, it does not disclose whether the operation is read-only, authentication needs, error handling (e.g., if no build exists), or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single sentence for purpose followed by clearly labeled Args and Returns sections. No redundant words or information, and the structure is easy to parse.
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 presence of an output schema, the description effectively covers purpose, parameters with defaults, and return value. However, it lacks context about potential errors (e.g., build not found), prerequisites, and relationship with other sibling tools. It is nearly complete for a simple getter 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?
Schema coverage is 0% (no descriptions in input schema), but the description fully documents both parameters: 'fullname' as the job fullname and 'number' as the build number (defaulting to last build). This compensates completely for the missing 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 clearly states 'Get the test report of a specific build in Jenkins', specifying the verb 'Get' and the resource 'test report of a specific build'. This distinguishes it from sibling tools like 'get_build' (which gets build metadata) and 'get_build_console_output' (which gets console logs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving test reports from builds but does not provide explicit guidance on when to use this tool versus alternatives (e.g., using 'get_build' for build details) or when not to use it. No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'Recursively analyzes dependencies down to leaf nodes', which is a key behavioral trait. Additionally, specifies return format with nodes and edges. Could mention read-only nature, but sufficient.
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?
Description is clear and front-loaded with the primary action. Includes Args and Returns sections. Slightly verbose but no wasted sentences.
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 one parameter and an output schema (not shown), the description covers the essential aspects: input, recursion behavior, and output format. Could mention error cases or limitations, but sufficient for basic use.
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 0%, but the description adds meaning for the only parameter 'short_name' by explaining it is 'The short name of the plugin to analyze'. This provides context beyond the schema's type constraint.
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?
Clearly states 'Get dependency graph for a specific plugin in Graphviz format', distinguishing it from sibling tools like get_plugin or get_all_plugins. The verb 'Get' and resource 'dependency graph' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for analyzing plugin dependencies but does not explicitly state when to use it, when not to, or mention alternatives. No guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions querying and traversal depth but does not explicitly state that it is read-only, safe to call repeatedly, or what happens if patterns match nothing. It lacks explicit safety or idempotency claims.
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 short: one-line purpose, then clear bullet-style Args, then Returns. Every sentence is informative and there is no fluff. Front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (present but not shown) and 4 optional parameters. The description covers what the tool does and each parameter. It could mention that patterns are combined and optional, but it's sufficiently complete given the output schema handles return details.
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?
Schema description coverage is 0%, but the description fully explains each parameter: class_pattern is 'The pattern of the _class', etc., and folder_depth is 'The maximum depth of folders to traverse. If None, traverses all levels.' This adds significant meaning beyond the raw 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 'Query items from Jenkins' with specific filter parameters (class, fullname, color patterns, folder depth). This distinguishes it from sibling tools like get_all_items (unfiltered) and get_item (single item).
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 filtering use via patterns but does not explicitly state when to use this tool over get_all_items or other query tools. No 'use this when' or 'consider alternatives' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a list of artifact metadata dicts with specific fields (fileName, relativePath, displayPath). However, it doesn't discuss potential errors or side effects, though it's a read-only operation. The return format adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: purpose sentence followed by Args and Returns sections. It is front-loaded with the main purpose. However, the Args section is slightly redundant with the schema but still helpful.
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?
Given the tool's simplicity (listing artifacts with two parameters) and the presence of an output schema, the description is complete. It explains the return format and parameter behavior, covering all needed 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?
Schema coverage is 0%, so the description must compensate. It adds meaning to both parameters: 'fullname: The fullname of the job' and 'number: The number of the build, if None, get the last build'. This explains the default behavior and provides context that the schema lacks.
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 'List the artifacts of a specific build in Jenkins', using a specific verb and resource. It distinguishes from siblings like 'get_build_artifact' by focusing on listing all artifacts of a build.
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 explains the arguments and default behavior (if number is None, get last build). It implies when to use this tool (to list all artifacts of a build) but does not explicitly state when not to use it or mention alternatives, though it's clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns a dictionary and that omitting number fetches the last build. However, it fails to mention error handling (e.g., if build doesn't exist) or whether the operation is read-only. The behavioral details are adequate but not comprehensive.
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 with one introductory sentence followed by structured Args and Returns sections. Every line adds value without redundancy. The structure is front-loaded and easy to parse.
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?
Given the simple signature (2 parameters) and the presence of an output schema (implied by context signals), the description explains what the tool does, how parameters affect behavior, and what is returned. No gaps remain for an agent to infer basic usage.
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?
Schema description coverage is 0%, but the description adds clear meaning: fullname is 'The fullname of the job' and number is 'The number of the build, if None, get the last build'. This provides essential context beyond the schema types and defaults, fully compensating for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves parameters of a specific build in Jenkins, using the verb 'Get' and resource 'build parameters'. It distinguishes from siblings like get_item_parameters (which gets item parameters) and get_build (which gets build details) by specifying 'parameters of a build'.
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 explains when to provide the build number and defaults to the last build if omitted. It does not explicitly contrast with alternative tools, but the context of 'build parameters' implies a focused use case. A higher score would require mentioning when not to use this tool or suggesting alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral details such as base64 encoding for binary files and plain text for text files, and the return format. However, without annotations, some side effects or permissions are not mentioned.
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?
Concise and well-structured with clear sections for purpose, arguments, and returns. Every sentence is essential and front-loaded with the main action.
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?
Given the tool's complexity and presence of an output schema, the description adequately covers parameters, behavior, and return format. No gaps identified.
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 fully explains each parameter: fullname as job fullname, relative_path with an example, and number as build number with default null. Adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Download an artifact from a specific build in Jenkins', distinguishing it from sibling tools like get_all_build_artifacts and get_build_artifact_url which perform different actions.
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?
Indicates when to use the number parameter ('if None, get the last build'), but does not explicitly mention when not to use this tool or point to alternatives. Still provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers behaviors like nesting, automatic handling of special characters, and response structure. However, it omits error handling, permissions, or rate limits.
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-structured with paragraphs, Args, and Returns sections. Every sentence adds value, and it is appropriately concise for the content.
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?
Given the presence of an output schema, the description adequately covers parameters, path syntax, and response structure. It is sufficient for an AI agent to understand and invoke the tool correctly.
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 fully compensates by providing examples for view_path, explaining path separators, and specifying the default for depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a Jenkins view by path, returning jobs and/or nested sub-views. It distinguishes from sibling tools like 'get_all_views' which lists all views, and 'get_item' for jobs.
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 clear guidance on navigating nested views using '/' in the path, and explains the depth parameter. While it doesn't explicitly state when not to use this tool, it implies its specific use case for drilling into views.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that only the given build is inspected, explains the number=None last-build behavior, and highlights the pitfall where a paused build that is not the latest will not be found. This is meaningful behavioral context beyond a simple 'get' statement, though it does not explicitly assert read-only/no-side-effect 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 well-structured with a clear opening statement, a usage context paragraph, and an Args/Returns breakdown. Every sentence earns its place, including the edge-case explanation about stale builds, and the most important usage guidance appears before the parameter details.
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?
Given moderate complexity, two parameters, and an existing output schema, the description covers the call flow, the relationship to submit_input, the edge case with last-build resolution, and what the return value contains. Nothing essential for selecting or invoking this tool is missing.
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 0%, so the description must compensate. It defines fullname as the job full name and number with the key behavior 'if None, check the last build,' which adds meaning beyond the raw schema. It could include a path format example for fullname, but the provided semantics are sufficient for correct invocation.
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-resource pair: 'Get the pending input steps of a specific build in Jenkins.' It clearly states the purpose and differentiates from sibling tools by explaining it is the precursor to submit_input and that it inspects only one build rather than finding builds generally.
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 when-to-use guidance: call it when a pipeline shows 'Paused for Input' and before submit_input. It also explains when not to rely on the default last-build behavior and directs the user to get_running_builds to find a paused build that is no longer recent, which is clear exclusion and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses critical behaviors: omission of declared parameters settles with null (no fallback to defaults), timeout ambiguity, and the fact that a settled input rejects second submissions. These go beyond typical expectations and fully inform the agent of risks.
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-organized with Warnings, Args, and Returns sections. It front-loads the purpose and then provides necessary warnings. Though a bit verbose, every sentence carries value for a complex tool; the structure aids readability.
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?
Given the tool's complexity (Jenkins input handling, edge cases), the description covers everything: parameter semantics, return format, error scenarios, and fallback behavior. It explicitly describes the return dict structure and explains the action values. Nothing essential is missing.
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?
Despite 0% schema description coverage, the description explains each parameter in the Args section: fullname, number, input_id (with auto-resolution), parameters (with example), and action (with allowed values). This adds meaning well beyond the raw schema, making the tool callable correctly.
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 states 'Respond to a pipeline input step of a build that is paused for input in Jenkins' — a specific verb, resource, and context. It clearly distinguishes itself from siblings like get_pending_inputs (which only retrieves) and stop_build, leaving no ambiguity about what this tool does.
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?
Explicitly directs usage: 'use get_pending_inputs to confirm its pending input' and 'get_running_builds to locate a paused build that is not the job's last one'. It also warns against retrying after timeout and advises re-checking. This provides clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lanbaoshen/mcp-jenkins'

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