Skip to main content
Glama
ampcome-mcps

CircleCI MCP Server

by ampcome-mcps

rerun_workflow

Rerun a CircleCI workflow from the beginning or restart from a failed job to address pipeline issues and complete builds.

Instructions

This tool is used to rerun a workflow from start or from the failed job.

Common use cases:

  • Rerun a workflow from a failed job

  • Rerun a workflow from start

Input options (EXACTLY ONE of these TWO options must be used):

Option 1 - Workflow ID:

  • workflowId: The ID of the workflow to rerun

  • fromFailed: true to rerun from failed, false to rerun from start. If omitted, behavior is based on workflow status. (optional)

Option 2 - Workflow URL:

  • workflowURL: The URL of the workflow to rerun

    • Workflow URL: https://app.circleci.com/pipelines/:vcsType/:orgName/:projectName/:pipelineNumber/workflows/:workflowId

    • Workflow Job URL: https://app.circleci.com/pipelines/:vcsType/:orgName/:projectName/:pipelineNumber/workflows/:workflowId/jobs/:buildNumber

  • fromFailed: true to rerun from failed, false to rerun from start. If omitted, behavior is based on workflow status. (optional)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsNo

Implementation Reference

  • The main asynchronous handler function for the 'rerun_workflow' tool. It resolves the workflow ID from URL if provided, fetches the workflow status, validates conditions, and calls the CircleCI client to rerun the workflow, returning a message with the new workflow ID and URL.
    export const rerunWorkflow: ToolCallback<{
      params: typeof rerunWorkflowInputSchema;
    }> = async (args) => {
      let { workflowId } = args.params;
      const { fromFailed, workflowURL } = args.params;
      const baseURL = getAppURL();
      const circleci = getCircleCIClient();
    
      if (workflowURL) {
        workflowId = getWorkflowIdFromURL(workflowURL);
      }
    
      if (!workflowId) {
        return mcpErrorOutput(
          'workflowId is required and could not be determined from workflowURL.',
        );
      }
    
      const workflow = await circleci.workflows.getWorkflow({
        workflowId,
      });
    
      if (!workflow) {
        return mcpErrorOutput('Workflow not found');
      }
    
      const workflowFailed = workflow?.status?.toLowerCase() === 'failed';
    
      if (fromFailed && !workflowFailed) {
        return mcpErrorOutput('Workflow is not failed, cannot rerun from failed');
      }
    
      const newWorkflow = await circleci.workflows.rerunWorkflow({
        workflowId,
        fromFailed: fromFailed !== undefined ? fromFailed : workflowFailed,
      });
    
      const workflowUrl = `${baseURL}/pipelines/workflows/${newWorkflow.workflow_id}`;
      return {
        content: [
          {
            type: 'text',
            text: `New workflowId is ${newWorkflow.workflow_id} and [View Workflow in CircleCI](${workflowUrl})`,
          },
        ],
      };
    };
  • Zod schema defining the input parameters for the rerun_workflow tool: optional workflowId (UUID string), optional fromFailed (boolean), optional workflowURL (string).
    export const rerunWorkflowInputSchema = z.object({
      workflowId: z
        .string()
        .describe(
          'This should be the workflowId of the workflow that need rerun. The workflowId is an UUID. An example workflowId is a12145c5-90f8-4cc9-98f2-36cb85db9e4b',
        )
        .optional(),
      fromFailed: z
        .boolean()
        .describe(
          'If true, reruns the workflow from failed. If false, reruns the workflow from the start. If omitted, the rerun behavior is based on the workflow status.',
        )
        .optional(),
      workflowURL: z.string().describe(workflowUrlDescription).optional(),
    });
  • MCP tool object registration exporting the tool definition with name 'rerun_workflow', detailed description of usage, and reference to the input schema.
    export const rerunWorkflowTool = {
      name: 'rerun_workflow' as const,
      description: `
      This tool is used to rerun a workflow from start or from the failed job.
    
      Common use cases:
      - Rerun a workflow from a failed job
      - Rerun a workflow from start
    
    Input options (EXACTLY ONE of these TWO options must be used):
    
    Option 1 - Workflow ID:
    - workflowId: The ID of the workflow to rerun
    - fromFailed: true to rerun from failed, false to rerun from start. If omitted, behavior is based on workflow status. (optional)
    
    Option 2 - Workflow URL:
    - workflowURL: The URL of the workflow to rerun
      * Workflow URL: https://app.circleci.com/pipelines/:vcsType/:orgName/:projectName/:pipelineNumber/workflows/:workflowId
      * Workflow Job URL: https://app.circleci.com/pipelines/:vcsType/:orgName/:projectName/:pipelineNumber/workflows/:workflowId/jobs/:buildNumber
    - fromFailed: true to rerun from failed, false to rerun from start. If omitted, behavior is based on workflow status. (optional)
      `,
      inputSchema: rerunWorkflowInputSchema,
    };
  • Collection of all CircleCI tools including rerunWorkflowTool in CCI_TOOLS array (line 41) and handler mapping rerun_workflow: rerunWorkflow in CCI_HANDLERS object (line 69). This aggregates tools for MCP server registration.
    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;
Behavior3/5

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 explains the optional 'fromFailed' parameter's default behavior ('If omitted, behavior is based on workflow status'), which is valuable context. However, it doesn't mention authentication requirements, rate limits, side effects, or what happens to the original workflow instance, leaving gaps for a mutation tool.

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 well-structured with clear sections (purpose, use cases, input options) and uses bullet points effectively. While slightly verbose, every sentence serves a purpose - the URL format examples are particularly helpful. The information is front-loaded with the core purpose stated first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, the description does a good job covering the essential aspects: purpose, usage scenarios, parameter semantics, and input constraints. The main gaps are the lack of information about authentication, side effects, and return values, but given the comprehensive parameter coverage and clear usage guidance, it's mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage (the schema has descriptions but context signals indicate 0% coverage), the description provides comprehensive parameter information. It explains the two input options, clarifies the exclusive choice requirement, documents the optional 'fromFailed' parameter with its default behavior, and provides URL format examples with placeholders, adding significant value beyond the bare schema.

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 specific action ('rerun a workflow') and specifies the scope ('from start or from the failed job'). It distinguishes this from sibling tools like 'run_pipeline' or 'run_rollback_pipeline' by focusing specifically on re-executing existing workflows rather than initiating new ones.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides usage guidance through 'Common use cases' listing both scenarios (rerun from failed job or from start). It also provides clear parameter selection rules ('EXACTLY ONE of these TWO options must be used'), which helps the agent choose between workflowId and workflowURL approaches.

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