Integration

Buddy integration

Buddy is a CI/CD and DevOps platform. With this API an agent reads workspaces and projects, browses each project's Git repository (branches, commits, comparisons, files, tags, pull requests), creates and deletes branches and tags, opens, updates and merges pull requests, lists pipelines and their actions, runs pipelines for real (cancel, retry, approve), reads execution and action logs, and reads unit test results. Left to the Buddy dashboard on purpose: committing files, creating pipelines or editing their actions, triggers, variables and YAML definitions (pipelines execute that code with the workspace's variables), and the variable, environment, target, integration, webhook, sandbox, domain, distribution, artifact, member, group, permission, SSO, tunnel, personal token and OAuth client families. Run-time variables cannot be passed to a run, and runs waiting for variables are answered in the dashboard (variables are environment input to the pipeline's code). Variable values, target and proxy credentials, custom repository credentials, webhook trigger whitelists and unit test suite tokens are not returned as fields; action logs come back as Buddy prints them, which masks encrypted variables, so a plain variable a script prints appears in the log. Pipeline runs use the workspace's compute usage (pay as you go on paid plans; the Free plan includes $1 a month of usage credit, per the pricing page). Rate limits apply per resource and are reported in the X-Rate-Limit headers. The Developer API must first be enabled in the workspace settings. Authentication is a Buddy personal access token sent as a Bearer token, to the API host of your region (US, EU or Asia).

Ask it in chat

Say what should happen.
The workflow builds itself.

When this happens, do that in Buddy.Built from the 49 Buddy tools below, on the connection you add once.

What you can do with Buddy

Each of these is one operation on one endpoint, available both as a workflow step and as a tool an AI agent can call on its own. Nothing bundles several operations into one action, so what a run did stays readable afterwards.

Most endpoints run on the free plan. A few, mainly the ones that publish on your behalf, need a paid plan.

Project, 5 operations

  • create_projectCreate projectPOSTCreates a project for real: a Buddy-hosted Git repository, a project with no repository, or one synced from GitHub, GitLab or Bitbucket through an existing integration. Returns the project.
  • delete_projectDelete projectDELETEDeletes a project for real. Returns nothing.
  • get_projectGet projectGETReads one project: display name, status, access, default branch, clone URLs (HTTP and SSH), creator, creation date and submodule and pull request settings.
  • list_projectsList projectsGETLists the projects in a workspace, page by page (page, per_page), optionally only ACTIVE or CLOSED ones, sorted by name, create_date or repository_size. Pass a project's name as project_name to other tools.
  • update_projectUpdate projectPATCHChanges a project's settings for real; only the fields you send change. Rename it (name, display_name), close or reopen it (status), or change submodule and pull request settings. Leave a field out to keep it.

Branch, 4 operations

  • create_branchCreate branchPOSTCreates a branch for real in the project's repository, starting from a commit you name. Returns the branch with its latest commit.
  • delete_branchDelete branchDELETEDeletes a branch for real from the project's repository. Returns nothing.
  • get_branchGet branchGETReads one branch: name, whether it is the default branch, description and its latest commit (revision, message, author, dates).
  • list_branchesList branchesGETLists the branches of a project's repository: name and whether it is the default branch. Pass a branch name to get_branch, list_commits or run_pipeline.

Execution, 4 operations

  • get_executionGet executionGETReads one pipeline run: status, trigger, revisions, branch, environment and each action execution with its status, error message and times. Use it to follow a run started with run_pipeline.
  • list_executionsList executionsGETLists the runs (executions) of a pipeline, page by page (page, per_page): status, trigger, branch or tag, revisions, creator, start and finish times. Pass an id to get_execution.
  • run_pipelineRun pipelinePOSTRuns a pipeline for real (builds, tests, deploys, whatever its actions do) with the workspace's variables, and returns the new run with its id and status; follow it with get_execution. Uses compute usage.
  • update_executionUpdate executionPATCHActs on a pipeline run for real: CANCEL it, RETRY a failed one, APPLY (approve) a run waiting for approval, RUN_DELAYED to start a delayed run now, APPROVE_VT (approve visual test changes).

Pipeline, 4 operations

  • delete_pipelineDelete pipelineDELETEDeletes a pipeline for real. Returns nothing.
  • get_pipelineGet pipelineGETReads one pipeline: settings, trigger events and conditions, refs, environments, variable names (values are not returned) and its list of actions.
  • list_pipelinesList pipelinesGETLists the pipelines of a project, page by page (page, per_page), sorted by name or id: name, triggers, refs, status of the last run, priority, paused or disabled. Pass an id to get_pipeline or run_pipeline.
  • update_pipelineUpdate pipelinePATCHChanges a pipeline's settings for real; only the fields you send change: name, folder, priority, pause or disable it, queue and concurrency rules, cache clearing, notes. Leave a field out to keep it.

Pull, 4 operations

  • create_pull_requestCreate pull requestPOSTOpens a pull request for real from a head branch into a base branch; collaborators see it. Returns the pull request.
  • get_pull_requestGet pull requestGETReads one pull request: state, title, description, base and head branches, head revision, draft, mergeable status, dates, labels, assignees and reviewers.
  • list_pull_requestsList pull requestsGETLists the pull requests of the repository: number, state (OPEN, CLOSED, MERGED), title, base and head branches, draft, mergeable, ahead/behind counts, labels, assignees and reviewers.
  • update_pull_requestUpdate pull requestPATCHChanges a pull request for real; only the fields you send change: title, description, draft, labels, or state (OPEN, CLOSED or MERGED). Leave a field out to keep it.

Tag, 4 operations

  • create_tagCreate tagPOSTCreates a tag for real on a commit of the repository. Returns the tag.
  • delete_tagDelete tagDELETEDeletes a tag for real from the repository. Returns nothing.
  • get_tagGet tagGETReads one tag: name, message and the commit it points to.
  • list_tagsList tagsGETLists the tags of the repository by name. Pass a name to get_tag for its commit and message.

Case, 3 operations

  • get_unit_test_caseGet unit test caseGETReads one test case: name, test group, class, status, time and its data.
  • list_session_test_casesList session test casesGETLists the test cases of a session, page by page (page, per_page), optionally by status: name, test group, class, status and time; view FULL also returns each case's data.
  • list_unit_test_casesList unit test casesGETLists the test cases of one test group, page by page (page, per_page).

Commit, 3 operations

  • get_commitGet commitGETReads one commit: revision, message, author and committer, dates, parents, stats, and per-file changes with additions, deletions and the patch.
  • list_commitsList commitsGETLists commits of the repository, page by page (page, per_page). Filter by branch, file path, author name or email, or a since/until date range; revision picks the starting point.
  • list_pull_request_commitsList pull request commitsGETLists the commits of one pull request.

Content, 2 operations

  • get_repository_pathGet repository pathGETReads a file (its content with its encoding and size) or lists a folder at a path in the repository, for a revision (default: the HEAD of the default branch).
  • list_repository_rootList repository rootGETLists the files and folders at the root of the repository for a revision (default: the HEAD of the default branch). Pass a path to get_repository_path to go deeper.

Session, 2 operations

  • get_unit_test_sessionGet unit test sessionGETReads one test session: status, ref, revision, linked execution, test, failed, skipped and error counts, duration and dates.
  • list_unit_test_sessionsList unit test sessionsGETLists the test sessions (one per test run) of a suite, page by page (page, per_page), optionally for one branch: status, ref, revision, test, failed, skipped and error counts, duration.

Suite, 2 operations

  • get_unit_test_suiteGet unit test suiteGETReads one unit test suite: name, identifier, timeout, error pattern, slow threshold and whether it sends commit statuses. The suite token is not returned.
  • list_unit_test_suitesList unit test suitesGETLists the unit test suites of a project: id, name and identifier. Pass an id to list_unit_test_sessions.

Test group, 2 operations

  • get_unit_test_groupGet unit test groupGETReads one test group of a session: name, status, time and test, failed, skipped and error counts.
  • list_unit_test_groupsList unit test groupsGETLists the test groups of a session, page by page (page, per_page), with their status, time and test, failed, skipped and error counts.

Workspace, 2 operations

  • get_workspaceGet workspaceGETReads one workspace by its domain: id, name, owner id, creation date, whether it is frozen, SSO status and the default pipeline resource.
  • list_workspacesList workspacesGETLists the workspaces your token can reach (limited by the token's workspace restrictions): id, name and domain. Pass a workspace's domain as workspace_domain to every other tool.

Action, 1 operation

  • list_pipeline_actionsList pipeline actionsGETLists the actions of a pipeline: id, name, type, when each runs (trigger_time), what follows it, timeout, retries and last status. Variable values are not returned. Pass ids to run_pipeline's actions_to_run.

Action execution, 1 operation

  • get_action_executionGet action executionGETReads one action's execution inside a run: status, progress, error message, times, who approved or stopped it, variable names it passed or output, and its log lines.

Comparison, 1 operation

  • compare_revisionsCompare revisionsGETCompares two revisions like git log base...head: the commits between them and the changed files with additions, deletions and patches.

File, 1 operation

  • list_pull_request_filesList pull request filesGETLists the files a pull request changes, with additions, deletions and patches.

Identifier, 1 operation

  • resolve_identifiersResolve identifiersGETResolves human-readable IDs to numeric IDs in one call: pass project (and pipeline, environment, artifact, unit_test_suite) by name to get project_id, pipeline_id and the others. The human-readable ID is tried first.

Log, 1 operation

  • get_action_execution_logsGet action execution logsGETReads the console log of one action execution, by line range: offset (0-based, default 0) and limit (default 100, max 1000). Returns the lines and the total line count.

Merge, 1 operation

  • merge_pull_requestMerge pull requestPUTMerges a pull request into its base branch for real. Optional squash, delete_branch (deletes the head branch after the merge) and commit_message.

Update branch, 1 operation

  • update_pull_request_branchUpdate pull request branchPUTUpdates a pull request's head branch for real with the changes from its base branch.

Use Buddy from Claude Code, Cursor or Codex

Connect Buddy in LiveContext, create an API key in Settings, then add the LiveContext MCP server to your client. Its Buddy operations become tools the client can call, next to every other integration you connected.

Claude Code
claude mcp add --transport http livecontext https://livecontext.ai/mcp --header "X-API-Key: YOUR_API_KEY"
Codex (~/.codex/config.toml)
[mcp_servers.livecontext]
url = "https://livecontext.ai/mcp"

[mcp_servers.livecontext.http_headers]
"X-API-Key" = "YOUR_API_KEY"
Cursor, Claude Desktop and other JSON configs
{
  "mcpServers": {
    "livecontext": {
      "type": "http",
      "url": "https://livecontext.ai/mcp",
      "headers": {
        "X-API-Key": "YOUR_API_KEY"
      }
    }
  }
}

Set up the MCP server step by step

How to connect Buddy

  1. Create your workspace

    Sign up free. Nothing to install.

  2. Connect Buddy once

    Add your Buddy connection in Settings. Every tool from this integration reuses it, and secrets are encrypted at rest and visible only to you.

  3. Describe the job in chat

    The workflow builds itself in front of you and picks the endpoints it needs. Drag the steps yourself on the canvas whenever you would rather be explicit.

Buddy integration FAQ

What can you do with the Buddy integration?

LiveContext exposes 49 operations on Buddy, covering project, branch, execution and pipeline.

Popular integrations

Browse the whole catalog