Provides tools for reviewing CircleCI configurations, including retrieving actual configs, validating YAML, analyzing bottlenecks, workflow health, and dependency graphs.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@advanced-circleci-mcp-server Show bottlenecks for gh/myorg/myrepo"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
CircleCI config review に特化した MCP サーバー。 既存の circleci-mcp-server が持たない Insights（性能・クレジット） と 実 config 取得 を中心に、config review に必要な5次元のデータを束ねたツールを提供する。
ツール | 問い | 内部 API |
| 何をレビューするか（実 config の取得） |
|
| 変更案は妥当か（compile & validate） |
|
| どこが遅い・高い（job 別 p95・クレジット集中） | Insights: workflows + jobs |
| workflow の健全性（duration/flaky/test metrics） | Insights: summary + test-metrics + flaky-tests |
| 依存関係と実 resource_class（DAG 分析） | Pipeline/Workflow/Job + job detail |
最新 pipeline の config（source YAML と orb 展開後の compiled YAML）を取得。
{ "project_slug": "gh/org/repo" }
{ "pipeline_id": "uuid", "branch": "main" }任意の YAML を CircleCI に送って検証・展開。変更案を提案する前に必ず通す。
{ "config_yaml": "version: 2.1\n...", "owner_id": "org-uuid" }全 workflow × 全 job の Insights を取得し、クレジット消費順にソートして返す。
{ "project_slug": "gh/org/repo", "reporting_window": "last-30-days" }
{ "project_slug": "gh/org/repo", "reporting_window": "last-7-days", "all_branches": true }workflow サマリ＋テストメトリクス（slowest/most-failed）＋flaky test を束ねて返す。
total_test_runs: 0 の場合は store_test_results 未設定を意味する。
{ "project_slug": "gh/org/repo", "workflow_name": "build-and-test" }pipeline または workflow の job 依存グラフ（requires/dependencies）と実 resource_class を返す。
{ "pipeline_id": "uuid" }
{ "pipeline_id": "uuid", "include_resource_class": false }
{ "workflow_id": "uuid" }Related MCP server: greybeard
次元 | 既存 circleci-mcp-server | このサーバー |
A Config |
|
|
B Discovery |
|
|
C Insights（性能） | なし |
|
D テスト健全性 |
|
|
E Usage（コスト） |
| 実装しない |
CIRCLE_TOKEN=<Personal Access Token>npm install
npm run build{
"mcpServers": {
"advanced-circleci": {
"command": "/path/to/advanced-circleci/build/index.js",
"env": { "CIRCLE_TOKEN": "your-token" }
}
}
}npm run inspector集計ウィンドウ: 最大90日。既定はデフォルトブランチのみ（all_branches: true で全ブランチ）。
on-hold / tag トリガーの実行は集計対象外。
データは日次更新。直近24時間は反映されないことがある。
クレジットは概算。正確な課金額は Plan Overview で確認。
job 別メトリクスは必ず workflow 名が要る（プロジェクト横断の一括 job エンドポイントは存在しない）。
Identify the slowest and most credit-intensive jobs across all workflows in a project. Fetches Insights data for every workflow, then for every job within each workflow, and returns results sorted by total_credits_used. Use this to find resource_class over-provisioning, unnecessary serialisation, and credit hot-spots.
| Name | Required | Description | Default |
|---|---|---|---|
| branch | No | Filter to a specific branch. Defaults to the default branch. | |
| all_branches | No | Set true to aggregate across all branches. | |
| project_slug | Yes | Project slug (e.g. gh/org/repo or circleci/orgID/projectID). | |
| reporting_window | No | Time window for Insights aggregation. | last-30-days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behaviors: it fetches Insights data per workflow and per job, and sorts by total_credits_used. This adds valuable context beyond a mere operation, though it lacks mentions of rate limits or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the core purpose in the first sentence and providing usage context in the second, with no wasted words.
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?
While lacking an output schema, the description explains the sorted result based on total_credits_used, which is sufficient for an agent to understand the tool's return. It could specify output structure but remains adequate.
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 description coverage is 100%, so the schema already documents each parameter. The description adds high-level purpose but does not elaborate on parameter semantics beyond what the schema provides, meeting the baseline.
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 starts with a specific verb-resource pair ('Identify the slowest and most credit-intensive jobs') and clearly distinguishes this tool from siblings like get_config, get_dag, etc., which cover other aspects of a project.
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 states concrete use cases ('find resource_class over-provisioning, unnecessary serialisation, and credit hot-spots'), providing clear guidance on when to employ the tool, though it omits explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the CircleCI config for a project's latest pipeline (or a specific pipeline). Returns source YAML (as written) and compiled YAML (after orb expansion). Use this as the starting point for any config review.
| Name | Required | Description | Default |
|---|---|---|---|
| branch | No | Branch to filter when resolving the latest pipeline. Ignored if pipeline_id is set. | |
| pipeline_id | No | Specific pipeline UUID. If omitted, fetches the latest pipeline for project_slug. | |
| project_slug | No | Project slug (e.g. gh/org/repo or circleci/orgID/projectID). Required if pipeline_id is not provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes a non-destructive fetch operation (reads config, returns YAML) and implies no side effects. It does not mention authentication or rate limits, but the read-only nature is clear from 'Fetch' and the return description.
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 three sentences, each concise and impactful. The first sentence states the action and scope, the second explains the return format, and the third gives a usage tip. No fluff.
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?
Despite lacking an output schema, the description adequately explains the return format (source and compiled YAML). It covers the main use case and provides a starting point for review. Minor gaps like error handling or edge cases are not critical for this fetch tool.
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?
The input schema has 100% description coverage, so the baseline is 3. The description adds no new meaning beyond what the schema already provides for branch, pipeline_id, and project_slug; it merely restates the schema's logic.
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 'Fetch the CircleCI config for a project's latest pipeline (or a specific pipeline)' with specific verb and resource. It distinguishes from siblings like get_dag or validate_config by positioning itself as the starting point for config review.
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 includes the directive 'Use this as the starting point for any config review,' providing clear context on when to use the tool. However, it does not explicitly exclude alternative tools or mention cases where siblings would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the job dependency graph (DAG) for a pipeline or workflow. Includes job requires/dependencies lists and (when include_resource_class is true) the actual resource_class that was assigned. Use this to identify unnecessary serialization, missing requires, and executor sizing.
| Name | Required | Description | Default |
|---|---|---|---|
| pipeline_id | No | Pipeline UUID. Fetches all workflows in the pipeline. Required if workflow_id is not provided. | |
| workflow_id | No | Workflow UUID. Fetches jobs for this single workflow. If pipeline_id is also set, pipeline_id takes precedence. | |
| include_resource_class | No | Fetch actual resource_class from job detail endpoint (N API calls, one per job). Set false to skip for large pipelines. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions the optional include_resource_class parameter affects performance (N API calls), but does not disclose other behavioral traits like authentication needs 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?
Two sentences: first states purpose, second gives usage guidance. No wasted words; each sentence earns its place.
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?
For a tool with 3 parameters and no output schema, the description covers key behavioral aspects. It could mention the return format (e.g., graph structure), but current level is sufficient.
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%, and the description adds meaning by explaining what the tool returns when include_resource_class is true (actual resource_class). This goes beyond the schema's parameter descriptions.
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 tool returns the job dependency graph (DAG) for a pipeline or workflow, which distinguishes it from sibling tools like get_bottlenecks or get_config.
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 provides specific use cases: 'identify unnecessary serialization, missing requires, and executor sizing.' It does not explicitly list when not to use or alternative tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a combined health report for a specific workflow: duration/success/MTTR metrics, slowest and most-failed tests, and flaky tests. Use this to evaluate test splitting opportunities, flakiness, and overall reliability.
| Name | Required | Description | Default |
|---|---|---|---|
| branch | No | Filter to a specific branch. Defaults to the default branch. | |
| all_branches | No | Set true to aggregate across all branches. | |
| project_slug | Yes | Project slug (e.g. gh/org/repo or circleci/orgID/projectID). | |
| workflow_name | Yes | Exact workflow name as it appears in the config. | |
| reporting_window | No | Time window for Insights aggregation. | last-30-days |
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. It describes what the tool returns but fails to state whether it is read-only, destructive, or any side effects. No mention of auth requirements, rate limits, or data freshness.
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 two sentences: the first lists contents, the second provides use cases. No redundant or extraneous information. Efficient and well-structured.
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, the description partially compensates by listing metric categories, but it does not describe the structure or format of the report (e.g., JSON fields). Adequate but could be more explicit about the output.
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 description coverage is 100%, so the schema already documents all parameters. The description lists metrics but does not add parameter-specific details beyond what the schema provides. Baseline of 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 precisely states the tool returns a combined health report for a specific workflow, listing concrete metrics (duration, success, MTTR, slowest/failed tests, flaky tests). It clearly distinguishes from siblings (get_bottlenecks, get_config, etc.) which focus on other aspects.
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 explicitly advises when to use the tool: 'Use this to evaluate test splitting opportunities, flakiness, and overall reliability.' It provides clear context but does not mention when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate and compile a CircleCI config YAML string. Returns whether the config is valid, any errors, and the fully-expanded output YAML (with orbs resolved). Use this to verify a proposed config change before recommending it.
| Name | Required | Description | Default |
|---|---|---|---|
| owner_id | No | Organization UUID (required to resolve private orbs). Find it via GET /me/collaborations. | |
| config_yaml | Yes | Full CircleCI config YAML string to validate. | |
| pipeline_parameters | No | Pipeline parameter values to use during compilation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return of validity, errors, and fully-expanded YAML (with orbs resolved), which is comprehensive. It does not mention that the tool has no side effects, but that is implied.
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?
Two sentences, front-loaded with purpose. Each sentence adds value without waste.
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 or annotations, the description explains return values (validity, errors, expanded YAML) and the purpose clearly. It could mention output format but is still fairly complete.
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%, so baseline is 3. The description adds minimal context beyond schema, e.g., owner_id resolves private orbs. Overall, the schema already documents parameters adequately.
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 tool validates and compiles a CircleCI config YAML string, specifying the verb (validate/compile), resource (config YAML), and output (validity, errors, expanded YAML). It distinguishes from sibling tools like get_config which likely retrieves config.
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 explicitly recommends using this tool to verify a proposed config change before recommending it, providing clear context. It does not explicitly list when not to use or alternatives, but the recommendation is specific enough.
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. Dates show when Glama detected each change.
v0.1.0get_bottlenecksget_configget_dagget_workflow_healthvalidate_configEach tool has a clearly distinct purpose: bottlenecks, config retrieval, DAG, workflow health, and validation. No overlap in functionality.
Four of five tools follow the 'get_' prefix pattern (get_bottlenecks, get_config, get_dag, get_workflow_health), but validate_config uses a different verb, creating a minor inconsistency.
With 5 tools, the set is compact and well-scoped for an advanced CircleCI analysis server, covering essential diagnostic and validation operations without unnecessary bloat.
The tools cover core analytical tasks (config, bottlenecks, DAG, health) and validation, but may lack operational tools like triggering pipelines or managing contexts, which is acceptable for the stated focus.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Appcircle mobile CI/CD platform.
The MCP server that vets MCP servers: identity, risk grade and per-tool risk before you install.
Conformance checker for MCP servers. Free, no key, verdicts recomputable and re-measured daily.
Monitor MCP servers, API contracts and AI outputs for schema drift. Alerts on breaking changes.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hidetaka-cci/advanced-circleci-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
