Skip to main content
Glama
ampcome-mcps

CircleCI MCP Server

by ampcome-mcps

analyze_diff

Analyzes git diffs against IDE rules to identify violations, with options for speed mode and filtering by violation type or compliance status.

Instructions

This tool is used to analyze a git diff (unstaged, staged, or all changes) against IDE rules to identify rule violations. By default, the tool will use the staged changes, unless the user explicitly asks for unstaged or all changes.

Parameters:

  • params: An object containing:

    • speedMode: boolean - A mode that can be enabled to speed up the analysis. Default value is false.

    • filterBy: enum - "Violations" | "Compliants" | "Human Review Required" | "None" - A filter that can be applied to set the focus of the analysis. Default is None.

    • diff: string - A git diff string.

    • rules: string - Rules to use for analysis, found in the rules subdirectory of the IDE workspace settings. Combine all rules from multiple files by separating them with ---

Returns:

  • A list of rule violations found in the git diff.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsNo

Implementation Reference

  • Main handler function implementing the analyze_diff tool logic: analyzes git diff against cursor rules using CircletClient and returns violations or compliance status.
    export const analyzeDiff: ToolCallback<{
      params: typeof analyzeDiffInputSchema;
    }> = async (args) => {
      const { diff, rules, speedMode, filterBy } = args.params;
      const circlet = new CircletClient();
      if (!diff) {
        return {
          content: [
            {
              type: 'text',
              text: 'No diff found. Please provide a diff to analyze.',
            },
          ],
        };
      }
    
      if (!rules) {
        return {
          content: [
            {
              type: 'text',
              text: 'No rules found. Please add rules to your repository.',
            },
          ],
        };
      }
    
      const response = await circlet.circlet.ruleReview({
        diff,
        rules,
        filterBy,
        speedMode,
      });
    
      if (!response.isRuleCompliant) {
        return {
          content: [
            {
              type: 'text',
              text: response.relatedRules.violations
                .map((violation) => {
                  return `Rule: ${violation.rule}\nReason: ${violation.reason}\nConfidence Score: ${violation.confidenceScore}`;
                })
                .join('\n\n'),
            },
          ],
        };
      }
    
      return {
        content: [
          {
            type: 'text',
            text: `All rules are compliant.`,
          },
        ],
      };
    };
  • Zod input schema defining parameters for analyze_diff: speedMode, filterBy, diff, rules.
    export const analyzeDiffInputSchema = z.object({
      speedMode: z
        .boolean()
        .default(false)
        .describe('The status of speed mode. Defaults to false.'),
      filterBy: z
        .nativeEnum(FilterBy)
        .default(FilterBy.none)
        .describe(`Analysis filter. Defaults to ${FilterBy.none}`),
      diff: z
        .string()
        .describe(
          'Git diff content to analyze. Defaults to staged changes, unless the user explicitly asks for unstaged changes or all changes.',
        ),
      rules: z
        .string()
        .describe(
          'Rules to use for analysis, found in the rules subdirectory of the IDE workspace settings. Combine all rules from multiple files by separating them with ---',
        ),
    });
  • Tool registration object defining name 'analyze_diff', description, and inputSchema.
    export const analyzeDiffTool = {
      name: 'analyze_diff' as const,
      description: `
      This tool is used to analyze a git diff (unstaged, staged, or all changes) against IDE rules to identify rule violations.
      By default, the tool will use the staged changes, unless the user explicitly asks for unstaged or all changes.
    
      Parameters:
      - params: An object containing:
        - speedMode: boolean - A mode that can be enabled to speed up the analysis. Default value is false.
        - filterBy: enum - "${FilterBy.violations}" | "${FilterBy.compliants}" | "${FilterBy.humanReviewRequired}" | "${FilterBy.none}" - A filter that can be applied to set the focus of the analysis. Default is ${FilterBy.none}.
        - diff: string - A git diff string.
        - rules: string - Rules to use for analysis, found in the rules subdirectory of the IDE workspace settings. Combine all rules from multiple files by separating them with ---
    
      Returns:
      - A list of rule violations found in the git diff.
      `,
      inputSchema: analyzeDiffInputSchema,
    };
  • Registration of analyzeDiffTool in CCI_TOOLS array and analyzeDiff handler in CCI_HANDLERS object.
    import { analyzeDiffTool } from './tools/analyzeDiff/tool.js';
    import { analyzeDiff } from './tools/analyzeDiff/handler.js';
    import { runRollbackPipelineTool } from './tools/runRollbackPipeline/tool.js';
    import { runRollbackPipeline } from './tools/runRollbackPipeline/handler.js';
    
    // Define the tools with their configurations
    export const CCI_TOOLS = [
      getBuildFailureLogsTool,
      getFlakyTestLogsTool,
      getLatestPipelineStatusTool,
      getJobTestResultsTool,
      configHelperTool,
      createPromptTemplateTool,
      recommendPromptTemplateTestsTool,
      runPipelineTool,
      listFollowedProjectsTool,
      runEvaluationTestsTool,
      rerunWorkflowTool,
      analyzeDiffTool,
      runRollbackPipelineTool,
    ];
    
    // Extract the tool names as a union type
    type CCIToolName = (typeof CCI_TOOLS)[number]['name'];
    
    export type ToolHandler<T extends CCIToolName> = ToolCallback<{
      params: Extract<(typeof CCI_TOOLS)[number], { name: T }>['inputSchema'];
    }>;
    
    // Create a type for the tool handlers that directly maps each tool to its appropriate input schema
    type ToolHandlers = {
      [K in CCIToolName]: ToolHandler<K>;
    };
    
    export const CCI_HANDLERS = {
      get_build_failure_logs: getBuildFailureLogs,
      find_flaky_tests: getFlakyTestLogs,
      get_latest_pipeline_status: getLatestPipelineStatus,
      get_job_test_results: getJobTestResults,
      config_helper: configHelper,
      create_prompt_template: createPromptTemplate,
      recommend_prompt_template_tests: recommendPromptTemplateTests,
      run_pipeline: runPipeline,
      list_followed_projects: listFollowedProjects,
      run_evaluation_tests: runEvaluationTests,
      rerun_workflow: rerunWorkflow,
      analyze_diff: analyzeDiff,
      run_rollback_pipeline: runRollbackPipeline,
    } satisfies ToolHandlers;
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 describes the analysis process and default behavior, but lacks critical behavioral details: it doesn't specify if this is a read-only or mutating operation, what permissions or prerequisites are needed, how errors are handled, or any rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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 appropriately sized and front-loaded: it starts with the core purpose, then details parameters and returns. Every sentence adds value, such as explaining defaults and parameter semantics. It could be slightly more concise by integrating the returns section more seamlessly, but overall it's efficient and 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?

Given the tool's complexity (analyzing diffs with rules) and lack of annotations and output schema, the description is moderately complete. It covers the purpose, parameters, and returns, but misses behavioral aspects like error handling or side effects. Without an output schema, it briefly mentions the return type ('list of rule violations'), but more detail on the output structure would help. It's adequate but has clear gaps.

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?

The description adds substantial meaning beyond the input schema. The schema has 0% description coverage for its single parameter ('params'), but the description explains the nested parameters (speedMode, filterBy, diff, rules) in detail, including their purposes, defaults, and usage notes (e.g., diff defaults to staged changes, rules location and combination method). This compensates well for the schema's lack of descriptions.

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's purpose: 'analyze a git diff against IDE rules to identify rule violations.' It specifies the verb ('analyze'), resource ('git diff'), and target ('IDE rules'), distinguishing it from sibling tools focused on pipelines, tests, or configurations. This 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 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 the tool: for analyzing git diffs (unstaged, staged, or all changes) against IDE rules. It mentions the default behavior (staged changes) and user overrides. However, it does not explicitly state when NOT to use it or name alternatives among siblings, though the sibling list suggests no direct alternatives for this function.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/ampcome-mcps/circleci-mcp'

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