Jenkins CI/CDサーバーと連携するためのツールを提供するモデルコンテキストプロトコル（MCP）サーバー。このサーバーにより、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 watchMCP サーバーは 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
