Jenkins CI/CD 서버와 상호 작용하기 위한 도구를 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버를 통해 AI 어시스턴트는 표준화된 인터페이스를 통해 빌드 상태를 확인하고, 빌드를 트리거하고, 빌드 로그를 검색할 수 있습니다.
이 저장소를 복제하세요:
지엑스피1
종속성 설치:
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 watchMCP 서버는 stdio를 통해 통신하므로 MCP Inspector를 사용하여 디버깅할 수 있습니다.
npm run inspector이렇게 하면 브라우저에서 디버깅 도구에 액세스할 수 있는 URL이 제공됩니다.
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
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
