Skip to main content
Glama
vlhommeau

travis-mcp

by vlhommeau
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

travis-mcp

MCP server for Travis CI, over the Travis API v3. Lets AI coding agents check build status, find the failing job and read its log — read-only by default, with opt-in build restart/cancel. Also ships a standalone usage metrics script (build minutes, concurrency peaks, reliability) for an entire Travis account.

Why access control lives in the server

Travis API tokens have no scopes: the API docs state a token can be used "to do anything that you can do using the web interface" (restart/cancel/trigger builds, edit settings and env vars). Access therefore cannot be narrowed through the token and is enforced here:

  • the HTTP client reads with GET, and its only write method refuses any path other than /build/{id}/restart and /build/{id}/cancel before sending anything (covered by tests, including path-traversal attempts);

  • the write tools are not even registered unless TRAVIS_ALLOW_WRITE lists them;

  • nothing ever triggers a build with custom config, reads or edits env vars, settings or caches.

Related MCP server: DevOps MCP Server

Tools

Tool

Travis endpoint

Purpose

get_build

GET /build/{id}

State, branch/PR, commit, timing, job IDs, web URL

get_build_jobs

GET /build/{id}/jobs

Per-job state and stage, to spot the failing job

list_builds

GET /repo/{slug}/builds

Recent builds, filtered by branch, event type, state or PR number

get_job_log

GET /job/{id}/log.txt

Job log, ANSI and travis_time/travis_fold markers stripped, tail (default 200 lines) or grep with context

restart_build

POST /build/{id}/restart

Opt-in (TRAVIS_ALLOW_WRITE=restart). Restarts all jobs of a finished build — replaces the previous run's logs and result

cancel_build

POST /build/{id}/cancel

Opt-in (TRAVIS_ALLOW_WRITE=cancel). Cancels a created or running build

The write tools are annotated destructiveHint: true, so MCP clients that honor annotations ask for confirmation. Their descriptions tell the model to call them only on an explicit human instruction naming the build; they return the build's state before the action and whether Travis accepted it (@type: pending).

A job may have no stored log (Travis then returns a literal null body, e.g. a log not yet archived or removed); get_job_log reports it as unavailable rather than returning null.

The API has no pull request filter, so list_builds with pull_request pages through the last 500 PR builds and filters client side.

Configuration

Variable

Required

Default

TRAVIS_API_TOKEN

yes

—

TRAVIS_DEFAULT_REPO

no

— (owner/name used when list_builds gets no repo)

TRAVIS_ALLOW_WRITE

no

empty = read-only. Comma list of restart, cancel; any other value fails at startup

TRAVIS_API_URL

no

https://api.travis-ci.com

TRAVIS_WEB_URL

no

https://app.travis-ci.com

Get the token from https://app.travis-ci.com/account/preferences → API authentication (works for accounts that sign in with GitHub), or with the Travis CLI: travis login --pro && travis token --pro. The Assets and RSS tokens on the same page do not give access to builds or logs.

Keep the token out of tracked files: store it in the OS keychain or a secrets manager and export it into the environment the MCP client is launched from.

Usage

Claude Code .mcp.json, pinned to a full commit SHA — not a tag or branch, which can be moved to point at different code (the matching tag is listed in the release):

{
  "mcpServers": {
    "travis": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "github:vlhommeau/travis-mcp#<commit-sha>"],
      "env": {
        "TRAVIS_API_TOKEN": "${TRAVIS_API_TOKEN}",
        "TRAVIS_DEFAULT_REPO": "owner/name",
        "TRAVIS_ALLOW_WRITE": "restart,cancel"
      }
    }
  }
}

No build step: the server is plain ESM JavaScript, runnable straight from a git checkout (Node.js 20+). Dependencies are pinned to exact versions and the whole tree is locked by npm-shrinkwrap.json — unlike package-lock.json, npm honors it when the package is installed as a dependency (including through npx github:...), so every install resolves the same transitive versions.

Usage metrics script

scripts/travis_metrics.py extracts account-wide usage over a period — the numbers Travis Insights doesn't show (concurrency) or can't export. Python 3.11+, standard library only, GET requests only.

export TRAVIS_API_TOKEN=...
python3 scripts/travis_metrics.py --owner my-org --out ./travis-metrics            # last 3 months
python3 scripts/travis_metrics.py --owner my-org --since 2026-06-01 --until 2026-09-01 --limit 10
python3 scripts/travis_metrics.py --from-cache ./travis-metrics/raw.json --limit 5  # re-analyze, no API calls

Option

Default

--owner

—

Organization or user login; every repository under it is scanned

--months / --since, --until

3 months up to yesterday

--until is exclusive

--tz

Europe/Paris

Timezone for calendar days

--limit

10

Plan concurrency limit, for saturation detection

--repo

all

Restrict to a slug (repeatable)

--min-interval

0.25 s

Throttle between requests (Travis publishes no rate-limit headers; 429/5xx are retried with backoff, honoring Retry-After)

Outputs, in --out:

  • daily.csv — per day: builds, jobs, build minutes, peak concurrent jobs, peak demand (running + waiting — running jobs can never exceed the plan's cap, so demand is what shows how far above it the need went), minutes at or above the limit, peak waiting jobs and waiting job-minutes while at the limit, jobs that waited over 1 minute, passed/failed/errored/canceled counts, errored and failed rates;

  • saturated_days.csv — the days whose peak reached the limit;

  • summary.json — totals and mean/median/p90: minutes per month, builds per day, build duration (wall clock and billed), concurrency and peak demand, queue wait percentiles and histogram (with the "waited" threshold stated explicitly), state split, active repositories, and the caveats below;

  • raw.json — the fetched builds and jobs, for --from-cache re-analysis.

How it works:

  • Repositories come from GET /owner/{login}/repos (skipping those with no build ever); builds from GET /repo/{id}/builds?include=build.jobs&sort_by=id:desc, which embeds each job's created_at/started_at/finished_at/restarted_at, so one request covers 100 builds; GET /job/{id} is only a fallback. Paging stops once a whole page predates the period.

  • Concurrency: one sweep over every job's [started_at, finished_at] across all repositories (the plan's limit is account-wide), split at local midnight.

  • Queue wait: from when a job became runnable — restarted_at, else created_at, or the end of the previous stage for multi-stage builds — to started_at (or to its cancellation if it never started). The "waiting at limit" figures only count waiting while running jobs are at or above --limit, i.e. queueing attributable to the cap.

Caveats (also written to summary.json): a restarted job only keeps its latest run's timestamps, so minutes and peaks are lower bounds; queue wait includes VM boot time, hence the 1-minute threshold; waits over 6 hours are treated as data artifacts and excluded.

Development

npm install
npm test
python3 -m unittest discover -s test -p 'test_*.py'
TRAVIS_API_TOKEN=... npx @modelcontextprotocol/inspector node src/index.js

Available Tools

4 tools
get_buildGet buildB
Read-only

State, branch/PR, commit, timing and job IDs of one Travis build.

ParametersJSON Schema
NameRequiredDescriptionDefault
build_idYesTravis build ID, the number in .../builds/<id> URLs

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds no extra behavioral context such as authentication needs, rate limits, or response detail, but for a simple read-only get tool this is a minor gap.

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

Conciseness5/5

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

The description is a single concise sentence that front-loads the key returned data fields and the resource scope. There is no filler or repetition, and every word contributes to understanding what the tool does.

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 single-parameter read-only tool with annotations and a fully documented schema, this description is mostly complete: it states the exact resource and the fields returned. It does not describe the response shape or error behaviors, but the absence of an output schema is partially compensated by the explicit field list.

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

Parameters3/5

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

The schema fully describes build_id with a clear pattern and example URL context, and schema coverage is 100%. The description does not add parameter-specific meaning beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource ('one Travis build') and lists the fields returned: state, branch/PR, commit, timing, and job IDs. This clearly distinguishes it from list_builds (multiple builds) and get_job_log (a log), though it has some overlap in scope with get_build_jobs since it also mentions job IDs.

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

Usage Guidelines2/5

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

There is no guidance about when to use this tool versus its siblings, such as get_build_jobs or list_builds. The description implies a use case (retrieving details of a single build) but does not state exclusions, prerequisites, or when another tool 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.

get_build_jobsGet build jobsA
Read-only

Jobs of one Travis build with their state and stage, to find which job failed.

ParametersJSON Schema
NameRequiredDescriptionDefault
build_idYesTravis build ID, the number in .../builds/<id> URLs

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the purpose and scope (jobs of one build) but does not disclose additional behavioral details like return format, pagination, or rate limits. With annotations covering the safety aspect, a 3 is appropriate – the description adds some value but not rich behavioral context.

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

Conciseness5/5

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

The description is a single sentence that conveys purpose, scope, and intended use without any redundant words. It is front-loaded with the key information (jobs of one Travis build) and includes the practical use case.

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?

For a simple read-only tool with one well-documented parameter, the description is complete. Annotations cover the safety profile, the schema covers parameter semantics, and the description states the purpose and use case. No critical information is missing for an agent to invoke it correctly.

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

Parameters3/5

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

The input schema covers 100% of the parameter (build_id) with a clear description of its format and meaning. The tool description does not add any additional parameter information beyond what the schema already provides. Baseline 3 is correct when schema does the heavy lifting.

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 function: retrieving jobs of a single Travis build, including their state and stage, with the explicit purpose of finding which job failed. It distinguishes from siblings like get_build (build details), list_builds (build list), and get_job_log (job log) by focusing on job-level status for a specific build.

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 a clear use case ('to find which job failed') and implicitly indicates when to use it: when you need job states and stages for a specific build. It doesn't explicitly state when not to use it or mention alternatives, but the context is sufficient given the sibling tools.

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

get_job_logGet job logA
Read-only

Plain-text log of one Travis job, ANSI codes stripped. Returns the last lines by default; use grep to extract matching lines with context instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
grepNoCase-insensitive regex; returns matching lines with 3 lines of context
job_idYesTravis job ID, from get_build_jobs
tail_linesNoNumber of trailing lines to return

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context: output is plain text, ANSI codes are stripped, only trailing lines are returned by default, and grep returns matching lines with context.

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

Conciseness5/5

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

The description is two sentences with no waste, and the primary return format is stated immediately. The grep guidance follows naturally and every clause earns its place.

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?

For a simple read-only log retrieval tool with fully documented parameters, the description covers the output format, the default tail behavior, and how to use grep. Nothing essential is missing for an agent to call the tool correctly.

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?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that grep extracts matching lines with context and that the default behavior is to return trailing lines, both of which go beyond the raw schema definitions.

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 states a specific verb and resource: retrieving the plain-text log of one Travis job. It also adds meaningful detail by noting ANSI codes are strippedhe, and the singular job scope distinguishes it from build-level siblings like list_builds and get_build_jobs.

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 clearly indicates how to use the tool: it returns the last lines by default highlights the grep parameter for extracting matching lines with context. It does not explicitly address when to choose this tool over sibling tools, but the 'one Travis job' scoping makes the primary use case clear.

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

list_buildsList buildsA
Read-only

Most recent builds of a repository, newest first. Filter by branch, event type, state or pull request number.

ParametersJSON Schema
NameRequiredDescriptionDefault
repoNoRepository slug "owner/name"
limitNo
stateNo
branchNoBranch name (for PR builds: the target branch)
event_typeNo
pull_requestNoOnly builds of this pull request number (implies event_type=pull_request)

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful ordering behavior ('newest first') and filter dimensions, but it does not disclose the return shape, pagination behavior, or how filters combine.

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

Conciseness5/5

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

A single, tight sentence that front-loads the core behavior ('Most recent builds of a repository, newest first') before listing filters. There is no filler or redundant restatement of the title.

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?

For a six-parameter list tool with no output schema, the description covers the main intent and filter options but omits the result format and pagination details. It is adequate for basic invocation, but an agent would still rely on inference about what the returned build objects look like.

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

Parameters3/5

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

The description adds meaning by naming branch, event type, state, and pull request number as filter dimensions, which is helpful because state and event_type have no textual schema descriptions. It does not mention limit explicitly, and repo semantics are already covered by the schema, so the description only partially compensates for the 50% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: list the most recent builds of a repository, sorted newest first, and names the supported filter dimensions. It does not explicitly distinguish itself from siblings such as get_build, though the plural 'builds' and 'most recent' imply a list operation.

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

Usage Guidelines3/5

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

The description implies when to use the tool: when you need recent repository builds, possibly filtered by branch, event type, state, or pull request number. However, it gives no explicit guidance about when to prefer get_build, get_build_jobs, or get_job_log instead.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.1
    • First observedget_build
    • First observedget_build_jobs
    • First observedget_job_log
    • First observedlist_builds
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a distinct layer of the CI data model: build, jobs of a build, build list, and job log. There is no overlap or ambiguity in purpose.

Naming Consistency5/5

All names follow a clean snake_case verb_noun pattern. The use of list_ for the plural build listing and get_ for singular resources is a standard and predictable convention.

Tool Count5/5

Four tools form a well-scoped, focused surface for read-only Travis CI build inspection. Each tool clearly earns its place without unnecessary redundancy.

Completeness4/5

The set covers the complete inspection workflow: discover builds, view build details, drill into jobs, and fetch job logs. Missing write operations like restart or cancel are likely out of scope but could be considered minor gaps.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • DevOps MCP Server

    huangjien
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables read-only integration with GitHub, Jenkins, and Artifactory for DevOps monitoring, analysis, and troubleshooting. Provides repository inspection, build log retrieval, and artifact management through natural language.
    MIT

  • Jenkins MCP Server

    ooooshino
    A
    license
    Not graded
    quality
    D
    maintenance
    Read-only MCP server for Jenkins CI, enabling AI agents to securely query job/build status, logs, artifacts, and generate verification reports for loop workflows.
    17 npm
    ISC