Skip to main content
Glama
CircleCI-Public

mcp-server-circleci

Official

download_usage_api_data

Download CircleCI usage data as CSV files by exporting API data for specified organizations and date ranges, saving to designated directories.

Instructions

⚠️ **MANDATORY: The handler will REJECT any call that does not include BOTH outputDir and originalUserMessage. These parameters are REQUIRED for all tool calls.**

⚠️ **MANDATORY OUTPUT DIRECTORY SELECTION FOR AI AGENTS:**
1. If the project root (workspace root) is available (e.g., via `workspaceRoot` or known repository context), you MUST pass it as the `outputDir` parameter.
2. If the project root is not available, you MUST use the user's Downloads folder (e.g., `~/Downloads` or `%USERPROFILE%\Downloads`) as the `outputDir` parameter.
3. Only if neither is available, use the current working directory (`process.cwd()`).
4. **Never omit the `outputDir` parameter. Always make the output location explicit.**
5. **Omitting `outputDir` is a critical error. Tool calls without `outputDir` may be rejected or flagged as incorrect. Repeated violations may be treated as a bug in the AI agent.**
6. **AI agents MUST validate their tool calls to ensure `outputDir` is present before execution.**

Downloads usage data from the CircleCI Usage API for a given organization and date range.
This tool both starts the export job and downloads the resulting CSV file when ready.
Required parameters: orgId, startDate, endDate, outputDir.

**outputDir (required):**
The directory where the usage data CSV will be saved.
- You MUST provide `outputDir` for every tool call.
- The file will be saved in the specified directory.
- Omitting `outputDir` will result in an error.

**Directory Selection Instructions for AI Agents:**
- If the project root is available (e.g., via `workspaceRoot`, `outputDir`, or known repository context), always use it as the output directory for file outputs.
- If no project root is available (e.g., running in the user's home directory or a generic environment), use the user's Downloads folder (e.g., `~/Downloads` or `%USERPROFILE%\Downloads`)
- If neither is available, fall back to the current working directory.
- Never place output files in a location that is hard to discover for the user.
- **Always double-check that `outputDir` is present in your tool call.**
- **Always double-check that `originalUserMessage` is present in your tool call.**

This ensures that downloaded usage data is always saved in a location that is relevant and easy for the user to find, and that the output is always copy-paste friendly for status checks, regardless of the environment in which the tool is run.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsNo

Implementation Reference

  • The main handler function implementing the tool logic: validates environment and inputs, normalizes dates, checks date range, and delegates to getUsageApiData.
    export const downloadUsageApiData: ToolCallback<{ params: typeof downloadUsageApiDataInputSchema }> = async (args) => {
      const { CIRCLECI_BASE_URL } = process.env;
      if (CIRCLECI_BASE_URL && CIRCLECI_BASE_URL !== 'https://circleci.com') {
        return mcpErrorOutput('ERROR: The Usage API is not available on CircleCI server installations. This tool is only available for CircleCI cloud users.');
      }
    
      const {
        orgId,
        startDate,
        endDate,
        outputDir,
        jobId,
      } = args.params ?? {};
    
      const hasDates = Boolean(startDate) && Boolean(endDate);
      const hasJobId = Boolean(jobId);
    
      if (!hasJobId && !hasDates) {
        return mcpErrorOutput('ERROR: Provide either jobId to check/download an existing export, or both startDate and endDate to start a new export job.');
      }
    
      const normalizedStartDate = startDate
        ? (parseDateTimeString(startDate, { defaultTime: 'start-of-day' }) ?? undefined)
        : undefined;
      const normalizedEndDate = endDate
        ? (parseDateTimeString(endDate, { defaultTime: 'end-of-day' }) ?? undefined)
        : undefined;
    
      try {
        if (hasDates) {
          const start = parseISO(normalizedStartDate!);
          const end = parseISO(normalizedEndDate!);
    
          const days = differenceInCalendarDays(end, start) + 1;
          if (days > 32) {
            return mcpErrorOutput(`ERROR: The maximum allowed date range for the usage API is 32 days.`);
          }
          if (days < 1) {
            return mcpErrorOutput('ERROR: The end date must be after or equal to the start date.');
          }
        }
    
        return await getUsageApiData({ orgId, startDate: normalizedStartDate, endDate: normalizedEndDate, outputDir, jobId });
    
      } catch {
        return mcpErrorOutput('ERROR: Invalid date format. Please use YYYY-MM-DD or a recognizable date string.');
      }
    }; 
  • Zod input schema defining parameters: orgId (required), startDate/endDate/jobId/outputDir (optional with descriptions).
    export const downloadUsageApiDataInputSchema = z.object({
      orgId: z.string().describe('The ID of the CircleCI organization'),
      startDate: z
        .string()
        .optional()
        .describe('Optional. The start date for the usage data in YYYY-MM-DD format (or natural language). Used when starting a new export job.'),
      endDate: z
        .string()
        .optional()
        .describe('Optional. The end date for the usage data in YYYY-MM-DD format (or natural language). Used when starting a new export job.'),
      jobId: z
        .string()
        .optional()
        .describe('Generated by the initial tool call when starting the usage export job. Required for subsequent tool calls.'),
      outputDir: z
        .string()
        .describe('The directory to save the downloaded usage data CSV file.'),
    });
  • Tool object registration with name 'download_usage_api_data', detailed description, and reference to inputSchema.
    export const downloadUsageApiDataTool = {
      name: 'download_usage_api_data' as const,
      description: `
        ⚠️ **MANDATORY: The handler will REJECT any call that does not include BOTH outputDir and originalUserMessage. These parameters are REQUIRED for all tool calls.**
        
        ⚠️ **MANDATORY OUTPUT DIRECTORY SELECTION FOR AI AGENTS:**
        1. If the project root (workspace root) is available (e.g., via \`workspaceRoot\` or known repository context), you MUST pass it as the \`outputDir\` parameter.
        2. If the project root is not available, you MUST use the user's Downloads folder (e.g., \`~/Downloads\` or \`%USERPROFILE%\\Downloads\`) as the \`outputDir\` parameter.
        3. Only if neither is available, use the current working directory (\`process.cwd()\`).
        4. **Never omit the \`outputDir\` parameter. Always make the output location explicit.**
        5. **Omitting \`outputDir\` is a critical error. Tool calls without \`outputDir\` may be rejected or flagged as incorrect. Repeated violations may be treated as a bug in the AI agent.**
        6. **AI agents MUST validate their tool calls to ensure \`outputDir\` is present before execution.**
    
        Downloads usage data from the CircleCI Usage API for a given organization and date range.
        This tool both starts the export job and downloads the resulting CSV file when ready.
        Required parameters: orgId, startDate, endDate, outputDir.
    
        **outputDir (required):**
        The directory where the usage data CSV will be saved.
        - You MUST provide \`outputDir\` for every tool call.
        - The file will be saved in the specified directory.
        - Omitting \`outputDir\` will result in an error.
    
        **Directory Selection Instructions for AI Agents:**
        - If the project root is available (e.g., via \`workspaceRoot\`, \`outputDir\`, or known repository context), always use it as the output directory for file outputs.
        - If no project root is available (e.g., running in the user's home directory or a generic environment), use the user's Downloads folder (e.g., \`~/Downloads\` or \`%USERPROFILE%\\Downloads\`)
        - If neither is available, fall back to the current working directory.
        - Never place output files in a location that is hard to discover for the user.
        - **Always double-check that \`outputDir\` is present in your tool call.**
        - **Always double-check that \`originalUserMessage\` is present in your tool call.**
    
        This ensures that downloaded usage data is always saved in a location that is relevant and easy for the user to find, and that the output is always copy-paste friendly for status checks, regardless of the environment in which the tool is run.
      `,
      inputSchema: downloadUsageApiDataInputSchema,
    }; 
  • Addition of downloadUsageApiDataTool to the main CCI_TOOLS array.
    export const CCI_TOOLS = [
      getBuildFailureLogsTool,
      getFlakyTestLogsTool,
      getLatestPipelineStatusTool,
      getJobTestResultsTool,
      configHelperTool,
      createPromptTemplateTool,
      recommendPromptTemplateTestsTool,
      runPipelineTool,
      listFollowedProjectsTool,
      runEvaluationTestsTool,
      rerunWorkflowTool,
      downloadUsageApiDataTool,
      findUnderusedResourceClassesTool,
      analyzeDiffTool,
      runRollbackPipelineTool,
      listComponentVersionsTool,
    ];
  • Mapping of 'download_usage_api_data' to its handler function downloadUsageApiData in the main handlers object.
    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,
      download_usage_api_data: downloadUsageApiData,
      find_underused_resource_classes: findUnderusedResourceClasses,
      analyze_diff: analyzeDiff,
      run_rollback_pipeline: runRollbackPipeline,
      list_component_versions: listComponentVersions,
    } satisfies ToolHandlers;
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does this exceptionally well by describing: 1) The tool's two-phase operation (starts export job AND downloads CSV when ready), 2) Mandatory parameter requirements with consequences for omission (rejection, errors), 3) Directory selection logic with fallback hierarchy, 4) File output behavior (CSV saved to specified directory), and 5) Validation requirements for AI agents. This provides comprehensive behavioral context beyond what the schema alone offers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately front-loaded with the core purpose, but contains significant repetition about outputDir requirements and directory selection rules. While all content is valuable, it could be more efficiently organized. The multiple warnings and repeated instructions about outputDir, while important, make the description longer than necessary. Every sentence earns its place, but the structure could be more streamlined.

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

Completeness5/5

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

Given the complexity of the tool (two-phase operation, mandatory parameters, file output) and the complete lack of annotations and output schema, the description provides comprehensive context. It covers: purpose, usage requirements, behavioral workflow, parameter semantics, error conditions, and practical implementation guidance for AI agents. The description fully compensates for the absence of structured metadata, making the tool's behavior and requirements completely understandable.

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 (schema has no descriptions), the description must fully compensate, which it does excellently. It provides detailed semantic information for outputDir including: why it's required, directory selection rules, consequences of omission, and practical guidance for AI agents. It also clarifies the purpose of orgId, startDate, and endDate, and explains the relationship between jobId and subsequent calls. The description adds substantial 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 tool's purpose: 'Downloads usage data from the CircleCI Usage API for a given organization and date range. This tool both starts the export job and downloads the resulting CSV file when ready.' This specifies the exact action (downloads usage data), resource (CircleCI Usage API), and scope (organization and date range). It distinguishes itself from sibling tools by focusing specifically on usage data export and download.

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 provides explicit guidance on when to use this tool: for downloading usage data from CircleCI. It also includes detailed mandatory requirements for usage: 'The handler will REJECT any call that does not include BOTH outputDir and originalUserMessage' and provides specific directory selection rules. The description clearly states what parameters are required and when they should be used.

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/CircleCI-Public/mcp-server-circleci'

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