模型上下文协议 (MCP) 服务器提供与 Jenkins CI/CD 服务器交互的工具。该服务器使 AI 助手能够通过标准化接口检查构建状态、触发构建以及检索构建日志。
克隆此存储库：
git clone https://github.com/yourusername/jenkins-server-mcp.git
cd jenkins-server-mcp安装依赖项：
npm install构建项目：
npm run buildRelated MCP server: Jenkins MCP Server
服务器需要以下环境变量：
JENKINS_URL ：你的 Jenkins 服务器的 URL（默认为“ http://sohoci.rd.tp-link.net/jenkins ”）
JENKINS_USER ：用于身份验证的 Jenkins 用户名
JENKINS_TOKEN ：用于身份验证的 Jenkins API 令牌
在您的 MCP 设置文件中配置这些：
MacOS： ~/Library/Application Support/Claude/claude_desktop_config.json Windows： %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"jenkins-server": {
"command": "node",
"args": ["/path/to/jenkins-server-mcp/build/index.js"],
"env": {
"JENKINS_URL": "https://your-jenkins-server.com",
"JENKINS_USER": "your-username",
"JENKINS_TOKEN": "your-api-token"
}
}
}
}获取 Jenkins 构建的状态：
// Example usage
const result = await mcpClient.useTool("jenkins-server", "get_build_status", {
jobPath: "view/xxx_debug",
buildNumber: "lastBuild" // Optional, defaults to lastBuild
});输入模式：
{
"jobPath": "string", // Path to Jenkins job
"buildNumber": "string" // Optional, build number or "lastBuild"
}使用参数触发新的 Jenkins 构建：
// Example usage
const result = await mcpClient.useTool("jenkins-server", "trigger_build", {
jobPath: "view/xxx_debug",
parameters: {
BRANCH: "main",
BUILD_TYPE: "debug"
}
});输入模式：
{
"jobPath": "string", // Path to Jenkins job
"parameters": {
// Build parameters as key-value pairs
}
}检索 Jenkins 构建的控制台输出：
// Example usage
const result = await mcpClient.useTool("jenkins-server", "get_build_log", {
jobPath: "view/xxx_debug",
buildNumber: "lastBuild"
});输入模式：
{
"jobPath": "string", // Path to Jenkins job
"buildNumber": "string" // Build number or "lastBuild"
}对于使用自动重建的开发：
npm run watch由于 MCP 服务器通过 stdio 进行通信，因此您可以使用 MCP Inspector 进行调试：
npm run inspector这将提供一个 URL 来访问浏览器中的调试工具。
该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅LICENSE文件。
Get the console output of a Jenkins build
| Name | Required | Description | Default |
|---|---|---|---|
| buildNumber | Yes | Build number (use "lastBuild" for most recent) | |
| jobPath | Yes | Path to the Jenkins job |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It states 'Get' implying a read operation, but does not mention authentication, error states, or output characteristics. Missing details like whether it supports partial output or handles large logs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the primary action. Slightly more structure (e.g., listing parameters) could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, no output schema), the description is minimally adequate. However, it lacks information about the return format (e.g., plain text, truncated, streaming) and any limitations. A bit more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no extra semantics beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'console output of a Jenkins build'. It is specific and distinct from sibling tools like get_build_status, though it could note that it retrieves full output versus status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_failed_build_log for failed builds). The description simply states the function without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status of a Jenkins build
| Name | Required | Description | Default |
|---|---|---|---|
| buildNumber | No | Build number (use "lastBuild" for most recent) | |
| jobPath | Yes | Path to the Jenkins job (e.g., "view/xxx_debug") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'Get the status' without explaining what status information is returned, whether it is read-only, or any side effects. This is insufficient for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it is arguably too minimal, lacking details that could be added without much verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not mention what the status response looks like (e.g., fields, format). For a tool returning build status, this is a significant gap that leaves agents uninformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because both parameters have descriptions. The description adds no additional meaning beyond the schema, so it meets the baseline of 3 but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'status of a Jenkins build', making the purpose explicit. It distinguishes from sibling tools like get_build_log and trigger_build by focusing on status retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives such as get_build_log or get_failed_build_log. The usage context is only implied through the tool's name and siblings, not stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger a new Jenkins build
| Name | Required | Description | Default |
|---|---|---|---|
| jobPath | Yes | Path to the Jenkins job | |
| parameters | Yes | Build parameters (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states it triggers a build, but lacks details on idempotency, blocking, returned output, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy. It is concise, but could add more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and two parameters (including a nested object), the description is too minimal. It fails to explain return values, authentication, or build lifecycle behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover both parameters (jobPath, parameters). The description adds no extra meaning beyond 'trigger a build', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Trigger') and resource ('Jenkins build'), clearly differentiating it from sibling tools that retrieve or manage builds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_build_status, list_all_jobs). No context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_build_logget_build_statustrigger_buildScored across 3 tools
Each tool has a clearly distinct purpose: get_build_log retrieves console output, get_build_status checks build status, and trigger_build initiates new builds. There is no overlap or ambiguity between these functions.
All tools follow a consistent verb_noun pattern (get_build_log, get_build_status, trigger_build) with clear, descriptive names. The naming convention is uniform and predictable throughout the set.
With only 3 tools, the server feels thin for a Jenkins integration, which typically involves more operations like managing jobs, viewing queue status, or canceling builds. While the tools cover basic build interactions, the scope is limited.
The toolset is severely incomplete for Jenkins functionality. It lacks core operations such as listing jobs, viewing build history, managing job configurations, or handling Jenkins system information. Agents will face significant gaps in performing typical Jenkins tasks.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The Buildkite MCP server exposes Buildkite product data (pipelines, builds, jobs, and test data) to AI tools, editors, and agents through the Model Context Protocol. It provides capabilities including pipeline creation and management, build monitoring with specialized tools like 'wait_for_build', efficient log querying using Apache Parquet conversion and caching, and OAuth-based authentication for both read-write and read-only access to Buildkite's REST API.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
A Model Context Protocol server for Wix AI tools
