Jenkins MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools are clearly distinct, targeting specific resource-action pairs (jobs, builds, nodes, views, credentials, plugins, queue). A few could cause minor confusion, such as jenkins_get_queue vs jenkins_get_queue_item, or jenkins_get_job vs jenkins_get_job_config, but the descriptions differentiate them well. The session management tools are also well-separated.
Naming Consistency4/5
The uniform 'jenkins_' prefix and verb_noun pattern (get_job, create_job, delete_job, enable_job) are highly consistent throughout. Minor deviations exist like jenkins_system_info vs the expected jenkins_get_system, and jenkins_run_groovy_script doesn't follow verb_noun for a specific resource, but the pattern is otherwise strong.
Tool Count2/5
At 53 tools, this is substantial for a CI/CD server. While Jenkins is a large domain covering jobs, builds, nodes, views, credentials, plugins, queue, and system operations, the volume is heavy and could overwhelm an agent. Some tools like jenkins_get_last_build, jenkins_get_last_successful_build, and jenkins_get_last_failed_build could arguably be consolidated, but the breadth generally tracks the genuine complexity of Jenkins.
Completeness5/5
Coverage is exceptionally comprehensive. The tool set spans job lifecycle (create/get/update/delete/copy/rename/enable/disable), build operations (build/info/log/stop/delete/last variants), node management, views, credentials, plugins, the build queue, and system administration. The only minor gaps are niche operations like credential updates or job-level artifact downloads, but nothing that would create dead ends in core workflows.
Average 3.2/5 across 53 of 53 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't describe what information is returned (beyond 'information'), whether the read is safe, whether it throws on missing builds, or what the response structure looks like. Given there's an output schema, some weight is offset, but the description itself is thin on behavioral context.
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 brief and direct, with no fluff. However, it reads more like a docstring skeleton than a purpose-crafted tool description—the Args section is auto-generated style rather than front-loaded value. It's concise but doesn't use the space to add differentiating or behavioral detail.
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?
For a relatively simple get operation with an output schema and a defaulted parameter, the description covers the basic purpose. However, with 0% schema coverage and no annotations, key context is missing: what fields the build info returns, whether 'last build' means most recent by number regardless of status, and how this relates to the two sibling 'last successful/failed build' tools. It's minimally viable but not complete for an agent to select this over closely-related siblings.
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 description coverage is 0%. The description lists 'job_name' and 'session_name' as parameters with a one-word gloss each ('Full job name', 'Jenkins session to use'), which essentially restates the schema properties without adding meaningful semantics. No format, naming conventions, defaults behavior, or constraints are explained beyond what the schema already shows.
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 states the tool gets information about the last build of a job, with a clear verb (get) and resource (last build of a job). This is reasonably distinguishable from siblings like jenkins_get_last_successful_build and jenkins_get_last_failed_build, though it doesn't explicitly differentiate which 'last build' (successful/failed/all) it retrieves. This could be confusing given those siblings exist.
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 vs alternatives. With siblings like jenkins_get_last_successful_build, jenkins_get_last_failed_build, and jenkins_get_build_info, it would be valuable to clarify whether this returns the most recent build regardless of status. No exclusions or when-not-to-use 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 carries the full burden of behavioral disclosure. It's a mutating operation (adding a job to a view), but the description doesn't state whether a valid Jenkins connection is required, whether the job must already exist in Jenkins, whether the operation can overwrite/duplicate, or what the return value indicates. This mutation tool with zero annotation coverage needs more behavioral context.
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 at one sentence plus a compact parameter list. It front-loads the core purpose. However, the parameter descriptors add marginal value since they duplicate the schema titles.
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 mutating tool with no annotations and 0% schema coverage, this is under-specified. There's an output schema noted, which could convey return format, but the description doesn't explain what success/failure looks like, whether the connection needs establishing first, or any prerequisites. Among ~50 Jenkins sibling tools, this one's relationship to jenkins_connect, jenkins_get_view, and job management tools is not clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description does restate each parameter's purpose ('View name', 'Job name to add to the view', 'Jenkins session to use'), but these merely mirror the schema titles. Session_name is noted as a session identifier, but there's no guidance on what format/values are valid or how session_name relates to jenkins_connect sessions.
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 states a clear verb+object ('Add a job to an existing view'), which clearly communicates what the tool does. It distinguishes from siblings like jenkins_create_view and jenkins_get_view since the focus is on adding jobs to views, not managing views themselves. The purpose is clear though the description doesn't explicitly contrast with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explain when to use this tool vs alternatives. It doesn't mention that the view must already exist (evidenced by 'existing view'), require prior connection via jenkins_connect, or note error handling if the job/view doesn't exist. No alternatives or exclusions 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 carries the full burden of behavioral disclosure. It doesn't state whether cancellation is destructive/irreversible, whether it requires specific permissions, what happens if the item already started building, or what the response/error behavior is. For a cancel/delete-type mutation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficient, using a terse one-line summary followed by a parametrized arg list. Every sentence serves a purpose, though the arg descriptions add marginal value. Slightly thin but appropriately sized.
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?
Despite having an output schema, this is a mutation tool with no annotations and only a minimal description. For a cancel operation, the agent needs to understand side effects, reversibility, and error conditions (e.g., canceling a non-existent or already-started item). The description is incomplete for guiding an agent through the full interaction lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameters. The description mentions 'queue_id: Queue item ID to cancel' and 'session_name: Jenkins session to use', but these add little beyond the schema field names themselves. It doesn't clarify where to find a queue_id (e.g., from jenkins_get_queue), what a session_name is, or any format/semantic details beyond what the schema already shows.
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 ('Cancel/remove') and resource ('item from the build queue'), which is precise and unambiguous. It distinguishes this from sibling tools like jenkins_get_queue_item or jenkins_get_queue, and from build-control tools like jenkins_stop_build, though it doesn't explicitly name alternatives.
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 jenkins_stop_build or jenkins_delete_build. It doesn't explain the relationship between the queue, builds, or when canceling a queue item is appropriate. The distinction between canceling a queued item and stopping a running build is critical context absent here.
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 the full burden of behavioral disclosure. It doesn't state whether an active connection/session is required, what happens on name conflicts, whether this is a mutating operation, or what the return value/output schema contains. For a creation tool with zero annotations, this is a notable gap.
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 compact and organized with an Args section listing parameters in a scannable format. It front-loads the core purpose efficiently with no wasted words, though the Args block is marginal value since it mirrors the schema.
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?
With an output schema present but no annotations, and 4 parameters with 0% schema coverage, the description should do more. It doesn't address session requirements, error conditions, naming conventions, or how folder creation relates to the job creation workflow. The description is minimally sufficient for the simple purpose but lacks depth for a tool with no annotation support.
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%, meaning the description must compensate, but it only echoes the parameter names (folder_name, parent_folder, description, session_name) without adding meaning. It clarifies that parent_folder empty means root level, which adds slight value, but doesn't explain formats, session requirements, or constraints on any parameter.
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 'Create a new folder in Jenkins' with a specific verb and resource. It distinguishes from siblings like jenkins_create_job and jenkins_create_view by specifying 'folder' as the resource type, though it doesn't explicitly contrast itself from those siblings.
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 guidance on when to use this tool versus alternatives like jenkins_create_job or jenkins_list_folder_jobs. The description does not mention prerequisites (e.g., needing an active session) or exclusions.
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 bears the full burden of behavioral disclosure. The description implies this is a state-changing operation (bringing a node online), but doesn't disclose what happens to a node that's already online (idempotency), what state transitions occur, whether authorization/permissions are needed, or the effect of the session_name parameter. Minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact — a one-line purpose statement plus two terse parameter lines. It's appropriately sized with minimal waste, though the parameter restatements add little value.
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 2-parameter state-changing mutation tool with no annotations, the description is thin. It doesn't describe return/output behavior despite an output schema existing, doesn't contrast with sibling jenkins_disable_node or address idempotency, and doesn't note node prerequisites. A boolean success/failure output likely exists but isn't characterized.
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 must compensate, but it only restates the parameter names ('Node name to enable', 'Jenkins session to use') without adding format, validation, or behavioral detail. session_name is arguably clarified by its default value in the schema, but the description adds no meaning beyond a literal restatement of the names.
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 (bring back online) and resource (Jenkins node/agent), making the purpose unambiguous. It distinguishes from sibling jenkins_disable_node (the opposite operation) without explicitly naming it, though the inverse action is directly referenced by the phrase 'back online'.
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 given on WHEN to use this tool vs alternatives. While the counter-operation is jenkins_disable_node, the description doesn't mention it, nor does it note prerequisites (e.g., node must be in an offline/disconnected state to enable, or that a disconnected node vs a disabled node are different states). The sibling jenkins_get_node_info could check node state, but this isn't suggested.
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 the full behavioral disclosure burden. It doesn't state what 'information' is returned, whether the build must exist (behavior when no failed build exists - e.g., error or empty response), or any session/authentication requirements. The output schema exists but the description adds no behavioral expectations beyond the literal terse statement.
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 efficient - one opening sentence plus a compact Args block. Every sentence serves a purpose and there is no filler. However, it could add useful behavioral context within the same space.
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?
Despite having an output schema, the description is thin for a build-status tool. It doesn't address: what happens if there's no failed build, what fields the returned info contains, or whether this respects job filters. The bare Args block plus a single sentence is minimal for the informational value an agent would need to correctly invoke this among many jenkins_* siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for both parameters. The description lists 'job_name: Full job name' and 'session_name: Jenkins session to use' in an Args block, which provides minimal meaning. 'Full job name' is somewhat helpful (indicating possibly nested paths), but 'session to use' is vague - doesn't explain what a session is or how to specify or set it up.
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 states 'Get information about the last failed build of a job' which is a specific verb+resource+condition. It distinguishes from sibling tools like jenkins_get_last_build and jenkins_get_last_successful_build by specifying 'failed' builds. However, it doesn't explicitly contrast with these close siblings.
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 when-to-use or when-not-to-use guidance is provided. There's no mention of alternatives or exclusions. The tool just states what it does without contextual usage guidance. Sibling tools like jenkins_get_build_info and jenkins_get_last_successful_build exist but no comparison is made.
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, so the description carries full burden of behavioral disclosure. The description reveals nothing beyond the literal action: no mention of what the log contains, how recent it is, whether it requires an active agent, rate limits, truncation behavior, or format of the output. For a read tool this is a significant gap since the agent can't anticipate what kind of content or volume to expect.
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 compact and gets to the point quickly with a clear one-line purpose statement followed by a minimal Args list. There is no wasted prose. However, the Args section largely duplicates what the input schema already provides, so those lines add limited value.
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?
There is an output schema which helps somewhat with return value expectations. But the tool is a node-log retrieval operation with no annotations and minimal description. Given the sibling ecosystem (many get_* tools with similar shape), the description does not explain what distinguishes a node log from a build log, whether the log covers the full node lifecycle, or how output is structured. For an agent to invoke this correctly and interpret results, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists both parameters (node_name and session_name) with brief one-word labels, but adds essentially no meaning beyond the schema's own names and types. The parameter names are fairly self-explanatory given the tool's purpose, so some credit is earned, but the description provides no format constraints, defaults rationale, or behavioral nuance.
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 log output from a Jenkins node/agent' with a specific verb (get) and resource (log from a node). It distinguishes reasonably from sibling tools like jenkins_get_build_log by targeting nodes rather than builds. However, it doesn't strongly differentiate from sibling tools like jenkins_get_node_info or jenkins_list_nodes in terms of scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't explain the relationship to jenkins_get_build_log (build log vs node log), when node logs are useful (e.g., build log captures the console, node log captures the agent's own output), or any prerequisites like needing a connected session.
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 the full burden of behavioral disclosure. The description only states the action (get details + list jobs) but doesn't disclose whether this is a read-only operation, whether a Jenkins connection is required, what happens if the view doesn't exist, or how many jobs might be returned. For a read-only retrieval tool with zero annotation coverage, this is a notable gap.
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 efficient and front-loaded — the purpose statement comes first, and the Args block is minimal. However, it could be tighter (the Args section adds negligible value since it just repeats parameter names). No waste, but some under-specification.
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?
With zero annotation coverage, 2 parameters at 0% schema description coverage, and an output schema present, the description is too thin. It should explain what 'details' means (build status, health, configuration?), the return format, and the relationship between views and jobs in Jenkins. The presence of an output schema helps but the description doesn't provide enough operational context for a tool that must interact with a live Jenkins server.
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 neither the schema nor the description provides parameter documentation. The description merely repeats the parameter names ('view_name: View name', 'session_name: Jenkins session to use') without adding meaning about formats, constraints, or how they affect behavior. With 2 parameters and zero coverage, the description should compensate but doesn't.
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 states 'Get details about a view and list its jobs' with a specific verb (get) and resource (view). It clearly communicates the tool retrieves view details plus its jobs, which distinguishes it from sibling tools like get_job, list_views, and list_jobs. However, it doesn't explicitly name sibling alternatives, so it loses a point.
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 about when to use this tool versus alternatives like list_views, get_job, or list_jobs. There is no 'when to use' or 'when not to use' context. The implicit context (a view aggregates jobs in Jenkins) would help but is not stated.
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 the full burden of behavioral disclosure. It does not mention whether renaming affects running builds, whether the job must exist, what the response/return value is, or any error conditions. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a docstring-style structure listing parameters. Every sentence earns its place, but it's under-specified rather than bloated. The format is clean and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation (rename) with no annotations and an output schema, but the description provides no behavioral detail. It doesn't explain session requirements, what happens on rename (URL changes, downstream refs), or error handling. For a state-changing operation, this is incomplete.
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 should compensate. It lists the three parameters (job_name, new_name, session_name) with one-line glosses, but adds no semantics beyond the property titles already in the schema. For a session_name parameter, there's no hint about what sessions are or how to choose one.
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 states 'Rename a Jenkins job' with a clear verb+resource. It distinguishes reasonably from sibling tools like jenkins_copy_job and jenkins_create_job, though it doesn't explicitly differentiate. Clear enough for an agent to identify the purpose.
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 like copy_job, create_job, or delete_job. Not stated whether renaming affects builds, downstream consumers, or requires permissions. No exclusions or context for common usage scenarios.
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 the full burden of behavioral disclosure. It fails to state whether the abort is immediate or graceful, whether the build enters an 'aborted' state vs 'failed', whether it requires specific permissions, or what happens if the build is already completed. The behavior of stopping versus aborting is ambiguous.
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 compact and reasonably structured with a clear Args list. No wasted sentences. However, given the behavioral ambiguity noted in transparency, the brevity comes at the cost of completeness.
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?
This is a mutation tool with no annotations and no behavioral detail. It has an output schema, which slightly reduces the need for return-value documentation, and the build_number=0 special value is helpful. However, for a destructive-ish action on a running build, the absence of behavioral context (what state results, what happens to output, error conditions for non-running builds) makes it incomplete.
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%, and the description only lists parameter names without adding meaning. It notes that build_number uses 0 = last build (a useful special value the schema doesn't convey), which is the only added semantics. session_name is unexplained, and job_name format nuance ('Full job name') is mentioned but adds minimal value over the schema's 'Job Name' title.
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 'Abort/stop a running build' uses a specific verb+resource pair. It clearly distinguishes this from sibling tools like jenkins_delete_build (delete) and jenkins_cancel_queue_item (cancel queued item). However, it doesn't explicitly differentiate itself from these related build-management siblings, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't clarify the difference between aborting a running build versus jenkins_delete_build (which deletes a build record) or whether it applies only to running/in-progress builds. No exclusions or alternative-tool references are provided.
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 of behavioral disclosure, but it doesn't state that deletion is a destructive, irreversible mutation, what happens on success/failure, or whether it requires specific permissions. The only behavior it discloses is the arg list, which is already in 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief and the parameter list is argparse-style (unusual for MCP tool descriptions). It's concise and front-loaded with the purpose, but the Args section largely duplicates what the schema already provides, reducing its added value relative to length.
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?
A destructive mutation tool with no annotations, no behavioral context, and 0% schema parameter coverage is underspecified. It doesn't mention irreversible consequences, session requirements, error conditions, or what distinguishes a 'system' store from other stores. For an irreversible operation, this is inadequate even with an output schema present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 4 parameters. It lists each parameter with a brief parenthetical ('_' = global, 'system' = system store), which adds some value over the bare schema defaults. However, these are terse and don't explain the domains/stores concept, valid values for domain (folder paths? 'system' store vs others?), or relationship between these parameters.
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+resource ('Delete a credential from Jenkins'), which accurately distinguishes it from credential creation and listing siblings like jenkins_create_credential and jenkins_list_credentials. It's clear but doesn't go beyond the name to differentiate scope or nuances from other credential-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 on when to use this tool vs alternatives. It doesn't mention prerequisites (e.g., needing jenkins_connect first), mention that credential deletion is irreversible, or contrast with jenkins_create_credential for editing existing credentials (delete + recreate pattern). The description is entirely silent on usage context.
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 the full burden. It states the primary effect (prevents new builds) but doesn't disclose whether existing/running builds are affected, whether disabling is reversible, whether it requires admin permissions, or what the return/response looks like despite having an output schema. The description adds the 'prevents new builds' clarification, which is useful, but leaves many behavioral aspects unaddressed.
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 compact and front-loaded with the core purpose. The Args section is brief. However, it's written in Python docstring format ('Args:') which is wasted structure for a tool description, and the parenthetical could be integrated more cleanly. It's adequately concise but the format isn't optimal.
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 state-changing tool with no annotations and 0% schema coverage but with an output schema present, the description should explain more. It doesn't describe what the response contains, whether disabling affects in-progress builds, how sessions work, or the enable counterpart. A moderately complex tool like this needs a bit more behavioral and session context to be self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should help with parameters. 'job_name' is described as 'Full job name' which adds minor meaning beyond the schema's raw 'Job Name' title. 'session_name' is described as 'Jenkins session to use', which adds context but doesn't explain what sessions are or how they're obtained. The two Args lines offer marginal value over 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 the verb+resource ('Disable a Jenkins job') and provides a helpful parenthetical clarification (prevents new builds from being triggered). It distinguishes from sibling jenkins_enable_job by specifying the 'disable' direction, though it doesn't explicitly name the sibling alternative.
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 guidance on when to use this tool vs alternatives (e.g., when to use jenkins_disable_job vs jenkins_quiet_down, or prerequisites like needing an existing job). The disable/enable relationship with the sibling is implicit but not explicitly articulated.
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 the full burden of behavioral disclosure. It does not state whether enabling requires job ownership/permissions, whether the operation is immediately effective, whether a running build is affected, or what the response looks like. For a mutation tool this is a meaningful gap.
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 brief and front-loaded with a clear purpose statement, which is good. However, the Arg/param listing is terse and repeats names without enriching meaning. It's efficient but under-specified rather than optimally concise.
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 annotations, 0% schema coverage, and 2 params, the description should do more. It doesn't mention permissions, side effects, confirmation/response behavior, or clarify session_name semantics. An output schema exists, so return-format documentation is not required, but behavioral and parameter completeness is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists 'job_name: Full job name' and 'session_name: Jenkins session to use', which adds a minimal gloss but no additional semantics beyond what parameter names imply. The description doesn't clarify job_name format (path syntax?), required status of session_name, or relationship between the two.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: enable a disabled job so it can be built again. It uses a specific verb+resource pairing (enable job) and directly complements its sibling jenkins_disable_job. However, it doesn't explicitly contrast with sibling tools beyond the implicit opposite role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('Enable a disabled Jenkins job') but provides no explicit when-to-use or when-not-to-use guidance. There's no mention of alternatives (e.g., jenkins_disable_job for the reverse, or requiring an existing disabled job). A capable agent could infer usage but there's no explicit guidance.
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 the full burden of behavioral disclosure. It states it returns 'detailed information' but doesn't explain what fields are returned, whether the plugin must be installed (or fails if not), memory/permission requirements, or any other behavioral nuance. The description adds minimal context about edge cases or failure modes.
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?
Concise and efficiently formatted with the Args section clearly mapping to parameters. Two sentences of actual description plus parameter annotations. Minimal waste, though the docstring-style Args formatting is slightly redundant with the schema.
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?
With an output schema present, the return value is documented structurally. The tool is relatively simple (2 params, one required). However, no annotations exist and the description doesn't explain query prerequisites like needing an active Jenkins connection (though jenkins_connect sibling suggests it), or failure behavior for non-installed plugins. Adequate but with gaps for a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain plugin_name with an example ('git', 'pipeline-model-definition') which is genuinely useful, and mentions session_name is the Jenkins session. However, it doesn't explain the relationship between the parameters, whether session_name defaults matter, or what a plugin short name is vs a full name. Partial compensation but incomplete.
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 retrieves detailed information about a specific installed plugin, with an example clarifying the plugin_name format. However, it doesn't explicitly distinguish from the close sibling jenkins_list_plugins, though the verb 'get detailed info about a specific installed plugin' vs 'list plugins' is reasonably self-evident distinction.
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 vs jenkins_list_plugins or jenkins_get_plugin_info alternatives. There's no mention of when this is appropriate, whether it requires an active connection first, or how it differs from list/install plugin operations. The context is implied but no exclusions or alternatives are named.
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 the full burden of behavioral disclosure. It's a read-only operation (safe), which is consistent with sibling naming, but the description doesn't state this explicitly. It also doesn't disclose the return type/format beyond 'console text output,' whether logs are paginated, truncated at any length, or whether start_line enables incremental fetch (implied but not stated as behavior).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with a clear structure: a one-line purpose statement, a return-value line, then an Args section mapping each param. No wasted sentences. It could be slightly tighter but is efficiently organized for an agent to parse.
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?
This is a read-only log tool with 4 params (1 required), 0% schema coverage, and an output schema present. Since the output schema exists, the return format is covered there. However, the description is thin on behavioral details: no mention of progressive/large-log handling implications, no clarity on capacity limits, no note that this is a safe read operation, and session_name is under-explained. The start_line 'bytes' semantics are unusual and would benefit from more explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaning for most params: job_name='Full job name', build_number='0 = last build', start_line='Start offset in bytes for progressive output (default: 0 = from beginning)', session_name='Jenkins session to use'. However, session_name is only described as 'Jenkins session to use' - no explanation of what a session is or when/whether it's needed, which is a gap for a non-obvious parameter. start_line being in 'bytes' is useful though unusual.
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 console output (build log) for a specific build' - a specific verb (get) + resource (build log). It distinguishes from siblings like jenkins_get_node_log (node log vs build log), jenkins_get_build_info (metadata vs console output), and jenkins_get_last_build. The 'Returns the full console text output of the build' line reinforces the purpose. However, it doesn't explicitly contrast with jenkins_get_build_info which would help differentiation.
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 gives no when-to-use guidance, no exclusions, and no mention of alternatives. For a log retrieval tool, it doesn't clarify when to use start_line progressive retrieval vs full fetch, or when a session_name is needed. Context like rate limits or large-log handling would help. While the start_line param hints at progressive use, no explicit usage scenarios are given.
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 the full burden. It says the tool shows busy executors and what they're running, but doesn't mention whether it requires an active connection, the format of the output, whether it fails gracefully on disconnected sessions, or any rate-limit concerns. For a read-only diagnostic tool, the safety profile is implied but not explicitly stated.
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 compact at three lines of substantive content. It front-loads the core purpose ('Show executor status across all nodes') then elaborates with one detail line before the Args. No redundant phrasing or filler. Every sentence earns its place, though the Args section merely restates the parameter.
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 is straightforward (single parameter, no nested objects, has output schema), so the bar for completeness is lower. However, with no annotations and 0% schema coverage, the description alone must convey usage context. It adequately conveys the read-only nature and scope (all nodes), and the output schema exists to explain return values. This is adequate for a simple diagnostic tool but could note the session prerequisite.
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?
With only 1 parameter and 0% schema description coverage, the schema provides nothing beyond the parameter name and default. The description mentions 'session_name: Jenkins session to use' in Args, which adds some semantic meaning (that it's a session selector), but doesn't explain what a session is, how sessions are established, or what happens if the named session doesn't exist. The baseline of 3 applies since the single parameter is fairly self-explanatory.
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 shows executor status across all nodes and details which executors are busy and what they're running. This is a specific verb+resource combination that distinguishes it from siblings like jenkins_get_queue or jenkins_list_nodes, which deal with related but different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It doesn't mention differences from related tools like jenkins_get_node_info or jenkins_get_queue. The usage context is implied by the name and brief description but no exclusions or alternatives are provided.
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 the full burden of behavioral disclosure. Yet it says nothing about what happens if there is no successful build (does it error? return null?), whether authentication is required, or what the response structure looks like. For a read operation this is a moderate gap, particularly the failure-case behavior which is often relevant.
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 brief and front-loaded with the core purpose in the first line. It's compact at roughly three short sentences. One could argue it's slightly under-specified rather than verbose, but for what it does say, it's efficient and waste-free.
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 there is an output schema present (which covers return-value explanation), the tool's key behavioral aspect - what happens when no successful build exists - is entirely undocumented. This is a common and important edge case for 'last successful build' tools. The description also lacks any detail on session handling or error conditions, making it incomplete for a tool with no annotations and 0% schema description coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists both parameters (job_name: 'Full job name', session_name: 'Jenkins session to use') but only with docstring-style notes that add very little meaning beyond the schema itself - job_name being 'Full' and session_name being a 'Jenkins session' are minimal elaborations. No guidance on format, how to obtain the session name, or the default value's significance.
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 states the tool gets information about the last successful build of a job - a clear verb+resource pairing. It distinguishes from siblings like jenkins_get_last_build, jenkins_get_last_failed_build, jenkins_get_build_info through the 'successful' qualifier. While it doesn't explicitly name sibling alternatives, the meaning is 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?
The description implies this is for retrieving the most recent successful build of a job, which gives context for when to use it (when you want the last green build). However, it doesn't explicitly state when not to use it or name alternative tools like jenkins_get_last_failed_build or jenkins_get_build_info. The context is clear enough but no exclusions are given.
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 the full burden of behavioral disclosure. It doesn't state whether the operation is read-only (likely given the name), what the exact return structure is, whether session/auth requirements matter, or any side effects. For an info-query tool the risk is low, but the description adds minimal behavioral context beyond the name.
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 compact with a clean Args section and no wasted words. It's appropriately sized for a two-parameter tool, though it could benefit from a note about what 'detailed information' includes.
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?
Has an output schema, so return values are documented elsewhere. The description covers the essential purpose and the one non-obvious constraint (master node naming). Given there are no annotations and 0% schema description coverage, it does a reasonably adequate job for a low-risk read tool, though it doesn't clarify the exact metadata returned or differentiate from sibling node tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaningful guidance for node_name by noting the master node special values ('(built-in)' or '(master)'), which is genuinely useful. However, session_name receives no explanation beyond its name and default value, and there's no elaboration on how node_name semantics map to the underlying Jenkins API.
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 it gets detailed info about a specific Jenkins node/agent, which is a clear verb+resource. However, it could more strongly distinguish itself from sibling tools like jenkins_list_nodes (list all nodes), jenkins_enable_node/disable_node, and jenkins_get_node_log, since it only vaguely says 'detailed information' without specifying what information is returned.
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 ('get detailed info about a specific node') but provides no explicit guidance on when to use this vs sibling tools like list_nodes or get_node_log. The schema hint about the master node ('(built-in)' or '(master)') is useful but no alternatives or exclusions 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 carries the full burden of behavioral disclosure. It is a read-only operation, but nothing confirms this explicitly (no mention of it being safe or non-destructive, which is important given the large family of mutating sibling tools). It also doesn't describe the return format or what the output contains beyond 'position and why they're waiting'.
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 compact and efficiently written with a clear one-line purpose, followed by brief result context and a single Args section. Every sentence earns its place with no fluff or 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?
This is a simple read-only listing tool with a single parameter and an output schema present. The description fronts the purpose and result summary well. However, given no annotations, it could have mentioned safe/read-only nature, and it could more explicitly distinguish itself from jenkins_get_queue_item for querying individual queue entries. Adequate but with room for improvement.
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?
With schema description coverage at 0%, the description's 'Args: session_name: Jenkins session to use' provides the key semantic for the single parameter. The schema only supplies type ('string') and default ('default'), so the description adds the meaning that session_name identifies which Jenkins session to use — helpful but minimal.
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 'List all items currently in the Jenkins build queue' with a specific verb ('list') and resource ('build queue'). It also adds useful context about what's shown (jobs waiting, position, reason for waiting). It doesn't explicitly distinguish from sibling tools like jenkins_get_queue_item, but the distinction is reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives such as jenkins_get_queue_item, jenkins_status, or jenkins_get_executor_status. There's no 'when to use' or 'when not to use' context provided, and no mention of prerequisites like the session needing to be connected via jenkins_connect.
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 for behavioral disclosure. It reveals this is a read/listing operation focused on the Update Center but does not explain what the result set looks like, whether it requires network access, or any details about pagination/limits. For a read-only search tool with zero annotation coverage, more 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a one-line purpose statement plus an Args list. No wasted words, and the Args section improves scannability. It's appropriately concise for a simple two-parameter tool.
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 is straightforward (list available plugins with optional filter), the description covers the core purpose and both parameters. However, with no annotations and no clarity on the output format or return semantics for a search operation, the completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The Args section explains query (filter, empty=all) and session_name (session to use), adding meaning to both parameters. However, it doesn't clarify the format of the query (fuzzy vs exact, wildcards) or what 'session' means. It provides basic but not rich parameter semantics.
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 searches available plugins for installation from the Jenkins Update Center, distinguishing it from jenkins_list_plugins (which likely lists installed plugins). The verb 'search' plus 'available plugins from Jenkins Update Center' provides good specificity.
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 vs alternatives. While the sibling name jenkins_list_plugins suggests a contrast (installed vs available), the description does not name or clarify this distinction or mention any exclusions. The description implies usage context ('for installation') but doesn't 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 carries full burden for behavioral disclosure. It doesn't mention whether a live session is required, whether it reads from a local cache, how many views might return, pagination, or error behavior. The description is a pure read operation but gives no safety/reliability context.
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 compact (three lines including the Args section) and front-loaded with the actionable sentence 'List all Jenkins views.' Efficient and to the point, though the Args re-statement is arguably redundant with the schema.
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?
This is a simple listing tool with one parameter, so minimal description may suffice. An output schema exists (no specifics needed on return format), and the parameter is trivially documented. However, given zero annotations and the broader Jenkins tool family, a note about session requirements or the difference from jenkins_get_view would strengthen completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter (session_name) at 100% with a default. The description says 'Jenkins session to use,' adding mild meaning beyond the schema's title 'Session Name.' With only one param and full schema coverage, the baseline of 3 is appropriate; the brief description adds minimal but non-zero value.
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 uses a specific verb+resource ('List all Jenkins views') that clearly states what the tool does. It doesn't explicitly distinguish from siblings, but 'list_views' vs 'get_view' and 'create_view'/'delete_view' makes the purpose reasonably clear from context.
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 like jenkins_get_view or jenkins_list_jobs. There is no mention of exclusions, prerequisites (e.g., must be connected first via jenkins_connect), or preferred use cases. While the sibling naming provides some context, the description itself offers no usage direction.
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 the full burden of behavioral disclosure. It says the tool 'shows' information, implying a read-only operation, but doesn't explicitly state it performs no mutations, doesn't describe the output structure beyond listing content categories, and doesn't mention any auth requirements or session prerequisites beyond passing a session_name. For a system diagnostic tool, more behavioral context would be valuable.
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 efficient: three sentences that establish purpose and content categories, plus a minimal Args section. It is front-loaded with the core action and resource. There is little waste, though it could drop the Args block since it adds marginal value over the input schema.
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 and 1 optional parameter, so it's not highly complex. The description covers what the tool retrieves (version, JVM, system properties, environment) but doesn't mention return value structure despite having an output schema — though the output schema itself would provide that. It's adequate for a read-only diagnostic tool but could benefit from noting this is a safe/non-mutating operation and any requirements for it to work (e.g., connected session).
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?
With only 1 parameter (session_name) and 0% schema description coverage, the description mentions 'Session: Jenkins session to use' for the param in the Args section. This adds minimal meaning — it states the parameter selects a session but doesn't explain what a session is, how to create one, or what happens if the default is used. The schema already has the parameter defined with a default, so the description adds only the word 'Jenkins session.' Baseline 3 is roughly appropriate but the description could add more value given low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gathers comprehensive Jenkins system information, listing version, JVM info, system properties, and environment overview. It uses a specific verb ('Get') and specific resource ('Jenkins system info'), and is reasonably distinguishable from other system-level siblings like jenkins_status, though it doesn't explicitly differentiate itself from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like jenkins_status or jenkins_list_nodes. It doesn't state when to prefer system_info over status, nor does it explain what distinguishes system-level information from other info-gathering tools. The context is minimal and no exclusions or alternatives 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 bears full burden. It states the action (create) but doesn't disclose what happens on failure, whether it requires authentication/session established, whether existing job with same name errors, or behavior of the 'folder' parameter when the folder doesn't exist. With zero annotations and a mutation tool, this is a notable gap.
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 reasonably concise with a one-line summary plus an Args block listing all four parameters. The Arg list is somewhat redundant with the schema but does add minor clarity. Could be tightened, but not verbose.
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 annotations and 0% schema coverage, the description should provide more. It doesn't mention the output schema content, error scenarios, whether the job can be overwritten, or how the session/folder interacts. Schema covers param names/types but not semantics. A fully self-describing tool would note overwrite behavior or validation of XML.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The Args section repeats parameter names with brief explanations (job_name, config_xml, folder, session_name), which adds minimal meaning. It clarifies folder means 'root level' when empty and session_name is a session selector, going slightly beyond schema. However, it doesn't explain what format config_xml expects or how folder paths are specified.
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?
Description uses specific verb+resource: 'Create a new Jenkins job from an XML configuration.' It clearly distinguishes from siblings like jenkins_copy_job or jenkins_create_folder by specifying creation from XML config. However, it doesn't explicitly contrast with related job tools (copy_job, update_job_config).
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 purpose implies it's for creating jobs, which is clear context. However, no explicit when/when-not guidance is given, and it doesn't distinguish from jenkins_copy_job or other job-creation-like operations. No prerequisites like needing a prior connection (jenkins_connect) are mentioned.
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 the description carries the full transparency burden. 'Get detailed information' implies a read-only operation, and the tool name itself (get_build_info) makes the non-destructive nature reasonably clear. However, it doesn't disclose any error behaviors (e.g., what happens if the build doesn't exist), auth requirements, or whether session_name matters. Adequate but not rich.
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 well-organized with a clear summary line, a fields line, and an Args block. No filler or repetition. The Args section earns its place since schema coverage is 0%, though the definitions are thin. Reasonably front-loaded with the core purpose stated first.
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?
An output schema exists (per context signals), so the return value explanation is not required. The tool has 3 params and a clear read operation. For a simple informational tool, the description is mostly adequate, but the thin parameter documentation (0% schema coverage) and lack of usage guidance leave modest gaps. Not egregious, but could mention what distinguishes this from build_log or last_build tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The Args section repeats parameter names with terse definitions: 'Full job name', 'Build number to inspect', 'Jenkins session to use'. These add minimal value beyond the schema — job_name being 'full' is mildly useful but build_number and session_name definitions are largely tautological. No format, constraints, or examples are given. The description does not fully compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Get detailed information about a specific build') and lists what the info includes (result, duration, timestamp, changes, artifacts). It distinguishes from siblings like jenkins_get_build_log (which shows logs) and jenkins_get_last_build (last build only). However, it doesn't explicitly differentiate itself from get_last_successful/failed_build variants in the wording.
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 when-to-use guidance, no exclusions, no alternative tools named. The presence of sibling build-related tools (get_last_build, get_build_log, stop_build, delete_build) suggests context where choosing between them matters, but the description provides no guidance on which to pick. The fields listed (result, duration, artifacts) hint that it's the comprehensive inspect tool, but this isn't stated explicitly.
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 provided, the description carries the full burden. It discloses that 'secrets are masked' which is a useful behavioral trait for a credential-returning tool, hinting this is a safe read operation. However, it doesn't mention permissions/authentication requirements, whether the operation fails for non-existent credentials, or the response structure beyond masking. The masking disclosure is the key value-add here.
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 compact and front-loaded with the essential purpose in the first line. The Args block is redundant with the schema and arguably shouldn't be repeated. It doesn't contain egregious waste but the Args listing adds no value beyond what the input schema provides, so it's not fully economical.
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 need not be explained. However, with 0% schema description coverage, no annotations, and 4 parameters, the description should more thoroughly explain the domain/store/session concepts that are Jenkins-specific and would be unclear to an agent. The '(secrets are masked)' note is helpful, but overall the description is thin for a tool that interacts with Jenkins's credential subsystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 4 undocumented parameters. As written, the Args section is a near-verbatim restatement of the schema (credential_id: Credential ID, domain, store, session_name with the same defaults). It adds virtually no meaning beyond what parameter names and defaults convey. It doesn't explain what '_' means as a domain value beyond a parenthetical that's still cryptic, nor does it explain the concept of a credential store or session.
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+resource ('Get details of a specific Jenkins credential') and distinguishes it from siblings like jenkins_list_credentials (list all) and jenkins_save_credentials (create/update). The parenthetical '(secrets are masked)' adds valuable scope clarification. However, it doesn't explicitly differentiate from jenkins_create_credential or jenkins_delete_credential, though the purpose is still distinct enough.
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 through the verb 'Get details of' and the parenthetical about masking, but it doesn't explicitly state when to use this vs alternatives like jenkins_list_credentials. It doesn't give exclusions or alternative tool names. The tool's use case is fairly intuitive given the sibling naming, but there's no explicit guidance.
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 the full burden of behavioral disclosure. It mentions 'recursive' which is a useful behavioral trait, but doesn't explain what happens with empty folders, whether the output includes nested job types beyond build jobs (e.g., pipelines, multi-branch), or what happens if the folder doesn't exist. With an output schema present, some return format is covered structurally, but error/edge-case behavior is undocumented.
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 compact with a helpful one-line purpose statement followed by a tight Args block. Each element earns its place. Could arguably benefit from a sibling distinction line, but it's appropriately concise and 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?
For a relatively simple listing tool with an output schema and only 2 parameters, this is mostly adequate. But given the sibling jenkins_list_jobs exists, a note distinguishing folder-scoped recursive listing from global listing would improve completeness. The description covers core semantics without being exhaustive, which is reasonable for a low-complexity 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?
Schema description coverage is 0%, so the description must compensate, and it does. It provides concrete examples for folder_path ('my-folder' or 'parent/child-folder') which is genuinely helpful, and clarifies that session_name refers to the Jenkins session. However, it doesn't specify whether folder_path is required to be exactly formatted or what happens with root-level listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('List all jobs inside a Jenkins folder') with the key modifier 'recursive', which distinguishes it from jenkins_list_jobs (which lists jobs without a folder scope). The purpose is clear and distinguishable from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs jenkins_list_jobs or other alternatives. The description implies usage (when you need jobs inside a folder) but doesn't explicitly differentiate from the sibling jenkins_list_jobs or clarify when recursive listing is appropriate versus get_job.
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 behavioral burden. It states the copy preserves configuration and requires a session. However, it doesn't disclose what happens if the target name already exists (overwrite/error), what the output/return value is, or whether this requires admin permissions. It's a mutation tool with decent but incomplete 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 compact with a one-line summary followed by an Arg block. Every sentence earns its place. The structure is clean and front-loaded with the core purpose. Slightly more behavioral detail could be added without bloating, but as-is it's efficient.
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 3 parameters, 0% schema coverage, no annotations, and no return-value info, the description is relatively lean. It explains the copy semantics ('identical configuration') which adds real value. However, it doesn't cover edge cases like name conflicts, session requirements, or what the output contains (though an output schema exists). Adequate but with room for more context.
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 schema description coverage is 0%, so the description must compensate. The Args section mirrors parameter titles ('Name of the job to copy', 'Name for the new job', 'Jenkins session to use') but adds little semantic value—these are restatements of the schema titles. It doesn't explain character constraints, naming rules, or the session parameter's default behavior.
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 states a specific verb+resource ('Copy/clone an existing Jenkins job to a new name') with clear scope: the new job will have identical configuration. This distinguishes it from sibling tools like jenkins_rename_job, jenkins_create_job, and jenkins_get_job. Purpose is clear, though it doesn't explicitly contrast with the rename sibling.
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 when to use it (when you want a duplicate of an existing job with a new name) by noting 'identical configuration to the source'. However, it doesn't explicitly state when NOT to use it or mention alternatives like jenkins_rename_job versus copy. The guidance is clear but not explicit about 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 are provided, so the description carries the burden of behavioral disclosure. 'Disconnect' implies a state change to a session, but the description doesn't mention side effects (e.g., whether in-progress operations are affected, whether this is idempotent, whether the session can be reconnected to). The disconnect semantic is fairly intuitive for a paired connect/disconnect tool, but lacks detail on consequences.
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 compact and directly states the purpose first. The Args block is minimal but functional. One minor redundancy: the parameter info is duplicated between the description and the schema, adding little unique value, but the overall structure is clean and 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 a single optional parameter with a default, an output schema, and a fairly self-explanatory purpose, the description covers the core need. However, for a state-changing operation on a session, it would be helpful to mention what 'disconnect' actually does at the Jenkins API level (whether it terminates a connection established via jenkins_connect, whether it's idempotent, etc.). The description is minimally adequate but leaves behavioral questions open.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description names the single parameter (session_name) with its default value, which mirrors the schema's structure (default: 'default'). With schema coverage at 0% for descriptions, the param documentation in the Args section partially compensates, but it adds no new meaning beyond what the schema already shows—it repeats the parameter name and default without enriching semantics (e.g., no format constraints, no examples).
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 uses a specific verb+resource ('Disconnect a specific Jenkins session'), which clearly states what the tool does. It is distinguishable from siblings like jenkins_connect and jenkins_status, though it doesn't explicitly reference these alternatives.
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 vs alternatives. It doesn't clarify what constitutes a session, how it relates to jenkins_connect, whether sessions persist across process restarts, or when disconnection would be appropriate (e.g., cleanup after failed jobs).
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's a read operation (retrieving config), but doesn't explicitly state it's non-destructive or side-effect-free. It also doesn't mention auth requirements, error cases, or what happens if the job doesn't exist. An output schema exists which may convey return format, but behavioral safety isn't disclosed.
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 brief and efficient, with purpose stated up front followed by an args summary. Every sentence earns its place. Slightly padded by the args section that partially overlaps with the schema, but not wasteful.
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?
An output schema exists, so return format burden is reduced. With 2 parameters and a well-defined read operation, the description covers the essentials. However, as a read-only config retrieval tool with no annotations, it could benefit from noting there's no side effect and clarifying how it differs from related sibling tools. Adequate but not exemplary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists both parameters (job_name: full job name, session_name: Jenkins session to use) in the args section, adding 'full' to job_name and clarifying session_name's role. However, 'session_name' being optional with a 'default' default value isn't clarified — no mention it can be omitted safely.
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?
Description clearly states it gets a job's XML configuration (config.xml), with specific verb+resource. It distinguishes from sibling tools like jenkins_update_job_config (which modifies config) and jenkins_get_job (which gets job metadata), though it doesn't explicitly name the distinction.
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?
Description says it's useful for understanding job setup, modifying, or duplicating configurations, which implies when to use it. However, it doesn't explicitly contrast with jenkins_update_job_config or jenkins_get_job, and no exclusions or alternatives are named. The usage context is clear for an experienced user but lacks explicit 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 carries the behavioral disclosure burden. It correctly notes the requirement for the 'Pipeline: REST API plugin' and describes what output the tool shows. However, it doesn't disclose failure behavior (e.g., what happens with non-pipeline jobs), or whether this is a read-only operation, though 'Get' reasonably implies a safe read. The plugin requirement is a useful behavioral note.
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 compact: a short purpose statement, a sentence about output content, a plugin requirement note, and an Args list. It's well-structured and front-loaded with the core purpose. No wasted sentences, though the Args section somewhat duplicates schema 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?
Output schema exists, so return values need no explanation. However, given 0% schema coverage and no annotations, the description must handle parameter semantics and behavioral context. It provides some coverage of both but leaves gaps: no mention of error handling for non-pipeline jobs, no prerequisite about session connectivity, and minimal detail on each parameter's accepted values. It's viable but not comprehensive for a tool with no annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and there are 3 parameters. The description lists each parameter with a brief explanation (job_name, build_number with 0=last build, session_name), which adds meaning to the parameter names. However, the explanations are minimal—especially job_name and session_name which just restate their names. The build_number default-value explanation is the most valuable addition. Given 0% coverage, the description compensates partially but not richly.
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 states 'Get pipeline stage details and status for a pipeline build' with a clear verb (get) and resource (pipeline stages for a build). It also says it shows each stage's name, status, and duration. While it doesn't explicitly distinguish from sibling tools like jenkins_get_build_info, the specific focus on stages is clear and reasonably differentiates it.
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 guidance on when to use this tool versus similar sibling tools like jenkins_get_build_info, jenkins_get_build_log, or jenkins_get_last_build. The build_number=0 default ('last build') implies usage context but there's no explicit when-to-use or when-not-to-use guidance, and no mention of the Pipeline: REST API plugin prerequisite's importance beyond a brief note.
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 the full burden. 'Install' implies a mutating operation, but the description doesn't disclose what happens on failure, whether it overrides existing versions, permissions needed, or the post-install state (requires restart). The 'may need a restart' note is useful but minimal for a destructive/mutating tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences plus an Args block that maps directly to parameters. No wasted prose. Well structured for parsing.
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?
There is an output schema present, which reduces the need to document return values. However, for a plugin-install operation with no annotations and no mention of failure modes, restart requirement beyond a passing note, or how to verify installation, the description is adequate but not complete. It covers the essentials without being exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The Args section explains plugin_name ('short name'), version ('Specific version to install (empty = latest)'), and session_name ('Jenkins session to use'). This adds meaningful semantics beyond parameter names alone, but it is terse and could be richer (e.g., version format, where plugin names come from).
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 ('Install'), the resource ('a Jenkins plugin'), and the mechanism (downloaded and installed). It distinguishes from sibling tools like jenkins_list_plugins and jenkins_get_plugin_info, which read plugin data rather than install. The scope is clear.
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 says 'Jenkins may need a restart to activate it,' which gives some usage context, but it does not explicitly mention when to use this versus alternatives like jenkins_run_groovy_script, mention that the plugin must be available in the update center, or note prerequisites like being connected. Usage guidance is implied rather than explicit.
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's a read-only listing operation, which is inherently low-risk, but the description doesn't disclose what fields are returned, whether the output is complete or paginated, or any session/connection requirements (implied by session_name param). For a benign listing tool, this is adequate but not rich.
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 compact and front-loaded with a clear one-line purpose, followed by a terse parameter list in Args format. It uses an efficient structure with each parameter explained in one line. Minor waste: the Args block largely repeats the schema defaults that are already present in the input schema.
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?
An output schema exists, so return values are covered by structured data. The tool is a simple listing operation with 3 optional parameters. The description covers core meaning and defaults adequately, though it doesn't explain session management or credential output shape in prose. For a low-complexity list tool with an output schema, this is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. The description does add some semantics for 'domain' (with the '_' = global domain note) and 'store' (with 'system' = system store), which helps. However, 'session_name' is only described as 'Jenkins session to use' with no explanation of what a session is or how one is established. Partial compensation, but gaps remain.
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 states clearly it lists all credentials stored in Jenkins, using a specific verb+resource. It distinguishes reasonably from sibling tools like jenkins_get_credential (which retrieves a single credential) and jenkins_save_credentials/create_credential (which write). However, it doesn't explicitly contrast with those siblings, so it's clear but not maximally differentiated.
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 lists parameters but provides no explicit guidance on when to use this tool versus alternatives or exclusions. The 'List all credentials' phrasing implies a listing action distinct from retrieval (get_credential) but doesn't explicitly name alternatives or when-not-to-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, so the description carries full burden of behavioral disclosure. It doesn't state whether a trigger is async (returns quickly and build runs later), whether it requires a valid session/connection, whether it fails for disabled jobs, or any error behavior. For a build-triggering action, knowing async vs sync behavior is critical, yet it's not disclosed.
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 compact and front-loaded with the core purpose first. The Args section is efficient. Minor redundancy: it restates parameter meanings that are already in the schema, but the JSON example earns its place given 0% schema coverage.
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?
There is an output schema (though not shown), which reduces the need to describe return values. However, for a trigger tool with 3 parameters and no annotations, the description is adequate but missing key behavioral context: does the tool block until build completes, return a queue item ID, or fire-and-forget? The description is functional but not rich enough for a mutation operation with zero annotation support.
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 for all parameters. It does explain parameters with a real example (JSON format for parameters), the default empty string for non-parameterized jobs, and the session_name. This adds meaningful value beyond bare parameter names, though session_name could use more clarity on what a 'Jenkins session' means.
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 first line clearly states the tool triggers a Jenkins job build, which is a specific verb+resource. This distinguishes it from siblings like jenkins_get_build_info or jenkins_stop_build, though it doesn't explicitly call out any sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to trigger a build), and notes parameterized vs non-parameterized handling. However, it doesn't explicitly state when NOT to use it or contrast with siblings like jenkins_replay_pipeline or jenkins_get_build_info. Usage context is implied but not reinforced with exclusions.
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 for behavioral disclosure. The description states it's a mutation (takes node offline) but doesn't disclose whether this requires elevated permissions, whether it's reversible (via jenkins_enable_node, which is inferable from siblings but not stated), or what the output/response looks like. The reversible aspect could be mentioned as behavioral context but is absent.
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 compact - a single sentence plus three concise parameter lines. No wasted words. It's appropriately sized for a simple tool. Slight deduction because the parameter list is somewhat redundant with the schema (which lists the same parameter names), though the semantic add-ons do add value.
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 and only 3 params, so it's not complex. The description covers the mutation action, the reason semantics, and session context. However, for a mutating operation with no annotations, it doesn't fully disclose whether there are side effects (e.g., jobs failing, in-flight builds affected) or permissions required. Adequate but with modest gaps for a mutation 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?
Schema description coverage is 0%, so parameters have no schema descriptions. The description compensates reasonably: it defines node_name ('Node to disable'), reason ('Reason for taking offline (displayed in Jenkins UI)'), and session_name ('Jenkins session to use'). Each parameter gets a meaningful one-line explanation that adds value beyond the bare type definitions in 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 the action: 'Take a Jenkins node/agent offline with a reason message.' The verb 'Take offline' combined with the 'node/agent' resource is specific and clear. It distinguishes from sibling tools like jenkins_enable_node and jenkins_get_node_info by focusing on the offline/disabling action, though it doesn't explicitly reference siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (disabling a node with a reason) but provides no explicit guidance on when to use this tool versus alternatives (e.g., jenkins_quiet_down for whole-server shutdown). There's no mention of when NOT to use it or prerequisites like being connected to a Jenkins session. The session_name parameter hints at connection requirements but isn't explained.
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 provided, the description carries the full burden. It clearly indicates this is a read-only operation (safe to call), which is useful. However, it doesn't disclose whether it requires an established session, what happens on connection failure, rate limits, or the output structure beyond naming fields. For a straightforward read-only listing tool, the basic safety transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at roughly three sentences, with zero filler. It states the purpose, lists the returned fields, and documents the one parameter. Every sentence earns its place.
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?
There is an output schema present, so the return format is covered. The tool is a straightforward read-only list operation with a single parameter, so the complexity is low. The description covers what it lists and the parameter. However, it doesn't mention session prerequisites or behavior differences from similar node-listing tools, leaving minor gaps for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description mentions 'session_name: Jenkins session to use' in the Args section, which adds a small amount of context (that a session is needed). However, with only 1 param having a default value of 'default', the schema already conveys most needed info. The description adds minimal value beyond what the parameter name suggests.
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 'List all Jenkins nodes/agents with their status' with a specific verb (List) and resource (Jenkins nodes/agents). It distinguishes from sibling 'jenkins_get_node_info' by explicitly listing 'all' nodes and the fields shown (name, status, executors, labels). However, it doesn't explicitly contrast with the get_node_info sibling.
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 guidance on when to use this tool versus alternatives like jenkins_get_node_info, jenkins_get_executor_status, or jenkins_system_info. The description implies usage context ('list all nodes') but provides no exclusions or alternative pointers, relying on the agent to infer based on tool names.
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 provided, the description carries the full burden of behavioral disclosure. The 'replaces the entire job configuration' warning is valuable and discloses destructive behavior. However, it doesn't mention whether the job must be disabled to update, whether the update invalidates running builds, what happens to unchanged settings, or auth requirements. The key destructive trait is disclosed but other operational behaviors are absent.
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 compact and front-loads the critical warning before the Args list. The warning placement is effective. The Args section adds marginal value since parameter meanings are self-evident from names, but it's not wasteful. One or two sentences could be trimmed without loss.
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 (not shown in full), so return format is partially handled elsewhere. For a destructive mutation tool with zero annotations and 0% schema coverage, the description provides the essential safety warning but lacks operational details like whether the job needs to be disabled, whether this can break a running pipeline, or preconditions. It's minimally adequate but missing deeper behavioral context for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the three args (job_name, config_xml, session_name) with brief one-line meanings, but adds no additional context beyond the schema. Notably, it doesn't explain that config_xml must be valid XML or complete config, nor does it describe what format/source is expected. The parameter names themselves are fairly self-descriptive, but the description adds nothing over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (update), resource (job's XML configuration), and specifically states it 'replaces the entire job configuration', making it distinct from jenkins_get_job_config and other job-manipulation siblings. The full replacement semantics are explicitly called out.
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 includes the critical warning that this replaces the entire config, which is essential usage context. However, it provides no guidance on when to use this rather than jenkins_create_job, jenkins_enable_job, or when a partial update is possible. No exclusions or alternative tool references.
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 the full burden of disclosing behavior. It does flag irreversibility ('This cannot be undone'), which is valuable. However, it doesn't disclose whether the deletion cascades, whether authorization/permissions are needed, or what happens to downstream artifacts/logs associated with the build. For a destructive operation with zero annotations, this is a meaningful gap despite the warning.
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 compact and efficient — a single purpose sentence, a clear irreversibility warning, and terse arg list. The warning is appropriately placed near the top. It could arguably be trimmed, but it wastes no space and is well structured.
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?
For a destructive tool with no annotations and no output schema details covered in the description, the irreversibility warning is essential and present. However, the description could be more complete by noting which sibling tool it pairs with (e.g., jenkins_build / jenkins_get_build_info for verification) and clarifying session_name's default behavior. The output schema exists, so return-value explanation isn't required, but permission/cascade behavior would elevate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description compensates by listing the three args (job_name, build_number, session_name) with terse one-line meanings. However, these mostly restate what the parameter names already convey ('Job name', 'Build number', 'Jenkins session'). The description adds little beyond the schema's field names and does not explain edge cases like whether build_number is required to exist or how session_name interacts with the 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 verb ('Delete'), the resource ('a specific build'), and the scope ('from the build history'). This clearly distinguishes it from sibling tools like jenkins_stop_build (stops but doesn't delete) and jenkins_delete_job (deletes a job, not a build), 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the irreversible nature with the warning 'This cannot be undone,' which implies caution. However, it does not explicitly state when to use this tool versus jenkins_stop_build, which is a natural alternative an agent might confuse it with. The usage context is only implied through the irreversibility warning rather than explicit 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 carries full disclosure burden. It states what the tool returns (configuration, health, last builds, parameters) but doesn't disclose aspects like required permissions, whether the job must exist or error behavior if not found, or whether this is a read-only operation. A read operation implies no side effects but is not explicitly stated.
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 compact at ~50 words, front-loads the main purpose in the first line, and uses a clean Args section. No wasted sentences. It could be slightly more informative without bloating, but as structured it's economical.
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?
There is an output schema, so return format isn't required. However, with no annotations and only 0% param schema coverage, the description is the only disclosure vehicle. For a 'get details' tool about a job, it covers purpose and one param's format well but leaves the second param and behavioral details (auth needs, existence errors) undocumented. Adequate but with notable gaps for a job-inspection 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?
Schema description coverage is 0%, so the description must compensate. The Args section does add value for job_name ('use 'folder/job-name' for jobs in folders'), which is genuinely helpful syntax guidance. However, session_name gets no explanation beyond its name, and the description doesn't clarify formats or constraints. Since there are only 2 params and one gets useful extra semantics, a 3 is fair but the job_name guidance is the only real value-add.
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 uses a clear verb+resource pattern ('Get detailed information about a specific Jenkins job') and enumerates the content ('configuration, health, last builds, parameters, and more'). It distinguishes adequately from siblings like jenkins_get_build_info (which targets builds, not jobs) and jenkins_get_job_config (which is narrower, config-only). However, it doesn't explicitly name sibling differentiators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (read job details) but provides no explicit when-to-use vs when-not-to-use guidance or alternatives. Given the many sibling tools (get_job_config, get_build_info, etc.), explicit guidance on when to choose this over one of those would help. The Args section gives parameter context but no usage constraints.
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 behavioral disclosure burden. It does disclose persistence (persisted to disk) and the security-relevant fact that an API token is stored, which is important context. However, it doesn't mention whether credentials are stored encrypted/plaintext, whether saving overwrites an existing session, or authentication/permission requirements. The persistence disclosure is valuable but security details are missing.
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 in the first sentence. The additional sentences about auto-connect persistence and the per-arg labels are useful. It's efficient without redundancy, though the per-arg list somewhat duplicates schema titles.
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 4 params with 0% schema coverage and no annotations, the description is thin for a tool that stores secrets. There is an output schema available, so return values need no explanation. Missing details: when to use vs jenkins_create_credential, security implications of storing a token to disk, and behavior on overwriting an existing session name. For a security-sensitive persistence operation, this is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all 4 parameters. The description does provide a semantic label for each param (session_name: name to save under; url: Jenkins server URL; username: Jenkins username; api_token: Jenkins API token). However, this largely restates the parameter names/titles. It adds no format requirements, no notes on token vs password ambiguity, and no explanation of the default values' implications.
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 states 'Save Jenkins credentials for a session name (persisted to disk for future use)', which clearly identifies the verb (save), resource (Jenkins credentials), and key behavior (persistence). Among siblings like jenkins_create_credential and jenkins_get_credential, it's distinguishable as the session-saving consumer-type credential tool. However, it could more explicitly contrast with jenkins_create_credential (which likely creates a credential on the Jenkins server rather than locally).
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 states these credentials are 'used for auto-connect and future sessions', implying this is a setup/configuration step to be done once before using the tool suite. However, it does not explicitly name alternative tools or state when NOT to use this (e.g., when you need a server-side credential, use jenkins_create_credential instead). The usage context is clear but exclusions are absent.
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 describes what the tool outputs (active sessions, version, executor info, job counts) which is genuinely helpful. However, it doesn't disclose whether this performs any state-changing effects, whether it requires an active connection, or any side-effects beyond displaying status. Given zero annotations, the description adds moderate value.
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 compact at three sentences plus an Args section. It's front-loaded with the core purpose in the first sentence and the output breakdown follows immediately. YAML-style formatting is consistent. Minor waste in the blank line before Args, but overall efficient.
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 one simple optional parameter, a moderate output schema, and a clear read-only status-reporting purpose. The description covers what's displayed, which is the main concern. It could mention whether an active Jenkins connection is required, but for a status display tool of this simplicity, the coverage is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only one parameter, the description compensates by explaining session_name means 'Session to check (default: default)'. While the schema already declares the default value, the description clarifies the parameter's role as selecting which session to inspect. For a single optional parameter with a default, this is adequate.
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 states 'Show connection status and Jenkins system overview' with specifics on what's displayed (sessions, version, executor info, job counts). This clearly distinguishes it from the many sibling tools like get_executor_status or system_info, though it doesn't explicitly name any differentiating sibling.
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 given on when to use this versus alternatives. There's no mention of what distinguishes it from jenkins_system_info or jenkins_get_executor_status, and no context like 'check after connecting' or 'use for diagnostics'. The purpose implies usage but doesn't state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the functional effect on queued builds, which is useful behavioral context. However, it doesn't mention whether the tool is idempotent, what happens if quiet-down wasn't active, or any failure states.
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 covering purpose and effect, plus a brief Args section. No wasted words, information front-loaded in the first sentence.
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?
There is an output schema available, and the tool is a simple state-change operation with one well-defined parameter. However, for a mutation-style operation with zero annotations, it would benefit from noting prerequisites (e.g., whether a prior quiet-down must exist) and idempotency characteristics.
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 single parameter session_name has 0% schema description coverage, but the description includes an 'Args' section explaining it is the 'Jenkins session to use.' The description meaningfully compensates for the schema gap since there's only one obvious parameter and it's clearly defined.
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?
Clear verb+resource: 'Cancel quiet-down mode and resume normal operations.' It states the action and outcome. Doesn't explicitly distinguish from its sibling jenkins_quiet_down, but the inverse relationship is strongly implied by 'cancel quiet-down.'
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?
Describes the effect ('Queued builds will begin processing again') which gives some context on when this is useful, but doesn't explicitly name the alternative (jenkins_quiet_down) or state when NOT to use it. Usage context is implied rather than explicit.
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 does disclose the view_type options ('list' default or 'my') which is useful behavioral context. However, it doesn't explain what happens for invalid view names, whether creation fails if view already exists, or any permission requirements.
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 efficiently structured with a brief one-line summary followed by a concise Arg list. Three sentences total for three parameters. No wasted words, though view_type could mention that 'my' means 'My View' aliasing is redundant with the parenthetical.
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 is relatively simple with only 3 params and 1 required. It has an output schema so return values need not be described. The view_type options and session usage are covered. Given the low complexity and output schema presence, the description is reasonably complete, though it could note the need for an active session/connection first.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain view_name and view_type reasonably well, including the 'list'/'my' options and default. session_name is described only as 'Jenkins session to use' which adds minimal value over the schema. The param descriptions are adequate but not deep.
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?
Description clearly states 'Create a new Jenkins view' with a specific verb and resource. It distinguishes from siblings like jenkins_list_views and jenkins_delete_view, though it doesn't explicitly name them as alternatives.
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 (creating views) but provides no guidance on when to use this vs alternatives, no prerequisites (like requiring an active session via jenkins_connect), and no exclusions. The session_name parameter hints at the session requirement but isn't explained.
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 burden. It doesn't mention error behavior for invalid queue IDs (e.g., what happens when the item no longer exists or was consumed), rate limits, or whether the item persists after building. For a read-only lookup tool, this is a moderate gap but not severe for a simple fetch operation.
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 compact - two short sentences plus an args list. It's front-loaded with the purpose statement. The args section is slightly redundant given the schema also lists these params, but it adds the provenance note about queue_id which is useful. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and only 2 simple parameters (one required), the description is mostly adequate. The main gap is no guidance on behavior when the queue item is no longer present (already built, cancelled, expired). For a lookup tool with an output schema, this is near-sufficient but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains queue_id ('Queue item ID (from jenkins_get_queue)') adding provenance context beyond the schema type, and session_name ('Jenkins session to use') gives purpose. While an output schema exists, the param explanations add value by linking queue_id to its source tool.
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 states 'Get details of a specific item in the build queue' with a clear verb and resource. It distinguishes from its sibling 'jenkins_get_queue' (which lists the queue) versus getting a specific item. The sibling 'jenkins_cancel_queue_item' is clearly different. Clear enough purpose.
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?
It provides an Args section explaining where queue_id comes from ('from jenkins_get_queue'), which gives some usage context. However, there's no explicit statement of when to use this vs alternatives, and no mention of the relationship to cancel_queue_item or when getting individual item details is needed.
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 behavioral disclosure burden. It does explain that safe mode waits for running builds while immediate restart may abort them, which is important destructive context. However, it doesn't mention whether restart requires admin/authentication permissions, the session constraints, or what happens to the current session connection during restart - gaps given restart is a disruptive action.
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 compact and front-loaded with the core purpose in the first sentence, followed by tight parameter explanations. Each sentence about parameters earns its place, though the Args section format with inline defaults is reasonable. Minor waste: the 'Args:' header and formatting could be trimmed, but otherwise efficient.
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?
For a destructive restart operation with no annotations and 0% schema coverage, the description covers the safe/immediate distinction well but omits important context: restart is disruptive to the server and all sessions, likely requires admin privileges, and the output schema (which exists) is not referenced. Enough for a competent agent to proceed safely, but gaps around permissions and session impact remain.
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 fully document parameters. The description explains the 'safe' parameter's behavioral difference (wait vs immediate) and identifies 'session_name' for session selection. This adds meaningful semantic value beyond the bare schema, though session_name could use slightly more context on how sessions are established/used.
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 'Restart the Jenkins server' with a specific verb and resource. It distinguishes from sibling tools like quiet_down, which is a graceful shutdown, by focusing specifically on restarting the server rather than read/query operations.
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 safe parameter behavior (safe vs immediate restart), which provides context on a key decision. However, it doesn't explicitly state when to prefer restart over quiet_down, disconnect, or other lifecycle tools, nor does it mention prerequisites like requiring an active session.
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 of behavioral disclosure. The description explains what fields map to which credential types (e.g., password holds the private key for 'ssh' type), which is useful behavioral context. However, it does not disclose what happens on duplicate credential_id (overwrite vs error), whether the operation is idempotent, or what the return/response looks like, despite there being an output schema present.
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 efficiently structured with a one-line purpose statement followed by a compact Args list. Every line earns its place by adding param semantics. Not excessively verbose, though the Args block could arguably be trimmed since somewhat redundant with the schema field titles, but it adds type-mapping context that justifies its presence.
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?
With 9 params including compound type-dependent relationships, the description does a solid job covering the essential semantics. The output schema exists, so return-value explanation is not required. The main gap is the absence of error/duplicate-handling behavior and no mention of prerequisites like an active jenkins_connect session. Overall adequate 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 description coverage is 0%, so the description carries the full burden of explaining the 9 parameters. The description adds meaningful semantics by mapping credential_type to specific parameter usage ('userpass' uses username/password, 'ssh' uses password field for private key, 'secret' uses secret). It also explains domain ('_' = global) and store ('system' = system store). This is substantially more than the raw schema provides.
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 'Create a new credential in Jenkins' with a specific verb and resource. It distinguishes from siblings like jenkins_save_credentials, jenkins_get_credential, and jenkins_delete_credential, though it doesn't explicitly contrast with jenkins_save_credentials (which might be a similar operation). Purpose is clear and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys that this is for creating credentials by listing the credential types and their associated parameters. However, it doesn't provide explicit when-to-use guidance, prerequisites (e.g., needing an active Jenkins connection), or when to prefer this over jenkins_save_credentials. The credential_type options ('userpass', 'secret', 'ssh') give some context on appropriate usage scenarios, but exclusions are not stated.
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 full burden. The warning that jobs in the view are NOT deleted is excellent safety transparency for a delete operation. It clarifies the scope of destruction, which is the most critical behavioral trait for a DELETE tool. However, it doesn't mention what happens to the empty view state or any permission requirements.
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 compact with a clear single-sentence purpose, a prominent safety warning, and a brief args list. The warning is appropriately front-loaded. Slightly could be tighter, but there is no wasted content.
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?
For a 2-param delete tool, the description adequately covers the safety-critical behavior (jobs not deleted). However, given there's no annotation coverage and the delete operation has side effects, it could mention prerequisites (e.g., session must be connected) or permission requirements. The args are described but thinly. Adequate but with room for more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists 'view_name' and 'session_name' with brief one-line descriptions in the args block, which is minimal but adequate — the arg descriptions essentially restate the schema property names without adding semantic depth or format/validation details.
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 tool states it deletes a Jenkins view clearly with verb+resource. It distinguishes from delete_job by clarifying the tool targets views specifically, though sibling tools like delete_job vs delete_view could be more explicitly differentiated. The non-destructive clarifier about jobs not being deleted adds purpose scope.
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 implicitly indicates when to use (when you need to remove a view) but provides no explicit when-not-to-use or alternative guidance. No comparison against similar tools like delete_job or list_views. The warning about views not deleting jobs is useful context but isn't usage-guideline 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?
Annotations are not provided, so the description carries the behavioral burden. It's a read-only listing operation (non-destructive), which is evident from 'List all installed plugins'. It doesn't add context about pagination limits, output volume, or whether it requires an active session beyond the session_name parameter. Adequate but not rich.
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 efficient - a single clear sentence defining the action and output fields, followed by a minimal Args section. No wasted words. It's appropriately sized for a simple listing tool.
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 and a single simple parameter. The description covers the core purpose (listing installed plugins with version and status). For a read-only listing operation with an output schema available, the description is reasonably complete. It could mention the installation-path contrast with related tools but isn't critically incomplete.
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 is only one parameter (session_name). While the description doesn't detail session_name beyond 'Jenkins session to use', the schema coverage is 0% meaning the description adds the only semantic hint available. The description does mention session_name in the Args section, providing minimal compensation for zero schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all installed Jenkins plugins with version and status (specific verb 'List all installed Jenkins plugins with version and status'). It distinguishes reasonably from sibling 'jenkins_list_available_plugins' by implying installed plugins specifically. However, it doesn't explicitly call out the contrast with available plugins.
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 implied usage context through the name and described action (list installed plugins). It doesn't explicitly state when to use this vs jenkins_list_available_plugins vs jenkins_get_plugin_info, which are conceptually related siblings. No exclusions or alternative recommendations 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 does disclose the key behavioral trait: running builds continue but no new builds are queued. However, it doesn't mention whether this is reversible, what the response looks like, or whether it's idempotent (recalling when already in quiet-down). For a state-changing server operation, some additional context would help.
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 efficient and well-structured. It opens with the main action, clarifies the key behavioral nuance in one sentence, provides usage context, and documents the single parameter. 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?
For a state-changing server operation with only one optional parameter and no complex schema, the description is reasonably complete. The behavior ('running builds continue, no new builds queued') is clearly stated. The use case ('before maintenance or restart') is given. An output schema exists but the description doesn't need to explain return values per the rubric. Could mention reversibility (via jenkins_cancel_quiet_down) but this is a minor gap.
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%, and the description lists 'session_name: Jenkins session to use' but adds little meaning beyond the schema. The schema already declares session_name as a string with a 'default' value. The description says 'Jenkins session to use' which is only marginally more informative—it doesn't clarify what a session is, how it relates to jenkins_connect/disconnect, or whether it's the session identifier from a prior connection.
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 puts Jenkins into quiet-down mode and explains what that means operationally ('no new builds will be started'). It uses a specific verb+resource construction that is clear. However, it doesn't explicitly distinguish from sibling jenkins_cancel_quiet_down or jenkins_restart, though the meaning is implicit enough given the descriptive text.
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 a clear when-to-use context: 'Useful before maintenance or restart.' This is good usage guidance for selecting this tool. It doesn't explicitly name alternatives or state when NOT to use it, but the maintenance/restart context is clear and differentiates from normal operations.
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?
With no annotations provided, the description carries full behavioral burden. It discloses that existing same-name sessions are disconnected first, that credentials are cached, and gives SSL and timeout defaults. This is good behavioral transparency for a connection-establishing tool.
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 efficiently structured with a concise intro and an Args block. Each sentence earns its place, though the Args block could arguably be trimmed since the schema already carries defaults, but the added semantics (URL example, token generation path) justify the length.
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 connection tool with 6 parameters and an output schema present, the description covers the connection behavior, session management, and parameter semantics well. It doesn't describe the output/return value, but the output schema exists to cover that, and the tool's behavior is fairly straightforward.
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 carry the parameter documentation. It does so well, explaining each parameter including example URL format, where to generate the API token, and SSL self-signed cert behavior — meaningfully beyond the bare 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 the tool connects to a Jenkins server and creates a named session, with specific verb+resource. It distinguishes from siblings like jenkins_disconnect but doesn't explicitly name the alternative, though the purpose is distinct enough given the large sibling set.
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 connection model and credential caching but doesn't explicitly contrast with sibling tools or state when to use this vs. alternatives. It implies this should be used before other operations via the session concept but doesn't say so explicitly.
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?
Despite no annotations, the description explicitly discloses the destructive nature with 'This action cannot be undone. All build history will be lost.' This is a strong behavioral disclosure covering the most critical aspect. It doesn't address permissions/auth requirements, but the 'session_name' parameter hints at session-based auth context. Given no annotations carry any burden, this is solid disclosure of the key irreversible consequence.
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?
Compact and front-loaded with the purpose and the critical warning. The warning is well-placed right after the purpose line. The Args section is minimal and helpful. Slight redundancy between 'cannot be undone' and 'All build history will be lost' but both add distinct 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?
This is a critical destructive action with no annotations, so disclosure of irreversibility is essential and provided. The output schema presence means return-value description is not needed. The main gap is lack of session/auth prerequisites, but for a simple delete operation the description covers the essential risk information adequately.
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 carries the full burden. It does explain job_name format ('use folder/job-name for jobs in folders') which adds real value beyond the bare schema. However, session_name is not explained at all beyond 'Jenkins session to use' - the description mentions it in Args but provides minimal semantics about its meaning or default 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?
Description clearly states it 'Delete a Jenkins job permanently' - specific verb (delete) + resource (Jenkins job) + permanence qualifier. Distinguishes from siblings like jenkins_delete_build, jenkins_delete_view, and jenkins_delete_credential by targeting 'job' specifically.
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 warns this is permanent and irreversible, giving clear context that this is a destructive operation. However, it doesn't explicitly contrast with alternatives (e.g., disable_job as a non-destructive option) or state when to prefer this over 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 are provided, so description carries the full burden. It discloses the key behavioral trait (re-runs a build, script editing doesn't modify the Jenkinsfile) and clarifies that empty script = use original. However, it doesn't mention mutation impact, whether this triggers new runs, permission requirements, or what the return value looks like.
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 compact with a brief intro plus a clean Args block. The key 'without modifying the Jenkinsfile' clarification is valuable. Slightly redundant since Args mostly repeats titles, but overall efficient.
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 mutation action with no annotations and 0% schema coverage, the description covers the tool's purpose, parameters, and the critical distinction (replay vs new build, script editing semantics). Has output schema which relieves need to document return format. Could add prerequisites (requires an existing pipeline build) but is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args section explaining each of the 4 parameters: job_name (pipeline job name), build_number, script (modified script, empty=original), session_name (Jenkins session). This compensates for the schema gap, though it largely paraphrases the parameter titles without adding type or format 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?
Clear verb+resource: 'Replay a pipeline build' with specific capability (optionally with modified Groovy script). Distinguishes from sibling jenkins_build by stating it re-runs an existing build and allows editing the script without modifying the Jenkinsfile.
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 core capability (re-running a build, editing script without touching the Jenkinsfile). However, it doesn't explicitly state when to prefer this over jenkins_build or when not to use it, though the differentiation is fairly clear from the description.
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 the return fields (name, type, color/status, URL) which is genuinely useful, but doesn't mention whether listing requires an active session, what happens on connection failure, or error behavior. For a read-only list operation, this is adequate but not rich.
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?
Compact and front-loaded. The core purpose is stated in the opening sentence, the return fields in one sentence, and parameters in a concise Args block. No wasted words or redundant restatement of the schema defaults.
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?
Has an output schema, so return format is covered elsewhere. For a 2-parameter list tool with no required params, this description covers the essentials: scope, return fields, and parameter semantics. Could mention session requirements or pagination limits, but for a straightforward listing tool this is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly documents both parameters (folder and session_name with defaults). The folder semantics (empty = root) and session_name default are explained directly. This compensates well for the lack of schema descriptions, though it could add format details like whether folder uses forward slashes or dots.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Jenkins jobs, optionally within a specific folder, and shows job name, type, color/status, and URL. This is a specific verb+resource+scope combination that distinguishes it from siblings like jenkins_get_job or jenkins_list_folder_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?
The description clarifies the folder parameter supports scoping to a subfolder (empty = root level), which provides context on when to use folder. It doesn't explicitly name alternatives, but the distinction from jenkins_list_folder_jobs and jenkins_get_job is clear enough from the purpose statement.
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?
With no annotations provided, the description carries the full burden. It explicitly warns that scripts run with full Jenkins access (a critical safety disclosure for a mutation-capable admin tool). It does not mention what happens to output/return value, error handling, or whether the script result is returned to the caller, which would add depth. But the security warning is significant and valuable disclosure 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 reasonably compact with effective front-loading: the core purpose is in the first line, the prominent warning follows immediately, and examples are provided at the end. The examples and Args block are useful, though the Args section slightly duplicates the input schema. Minor redundancy, but overall well-organized and scannable.
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 (though its content isn't shown), the description still gives useful examples of common scripts and a clear warning about power. For a generic execution tool with zero annotation coverage, it covers the essential safety context. It could be improved by noting what the tool returns (script output vs. exit code), but it's reasonably complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the two parameters (script, session_name) with brief explanations, but doesn't elaborate on the 'session' semantics — what a session is, why it defaults to 'default', or when one would use a different session. The script parameter is self-explanatory, but session_name lacks meaningful context about its lifecycle or purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a Groovy script on the Jenkins Script Console, with a specific verb (execute) and resource (Script Console). It distinguishes itself from siblings like jenkins_get_job or jenkins_build by being a general-purpose admin execution tool, and provides concrete example scripts that make 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: it's an admin scripting tool for arbitrary Groovy execution. The warning note ('powerful admin tool') implies it should be used carefully. However, it doesn't explicitly name alternative tools for specific operations (e.g., use jenkins_get_job for reading job details), though the sibling set is large and this tool is clearly the generic escape hatch. The examples help establish appropriate use cases.
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:

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

Score Badge

Copy to your README.md:

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

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/Pawangunjkar/jenkins-mcp'

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