Guide

Connect CI build artifacts into the core automatically

Use a service token to connect build outputs into a connect0 project, so a teammate's agent can inspect them without a manual handoff.

5/18/2026 · connect0 · 4 min

Connect your CI pipeline straight into the core so every build's artifacts are waiting for the next agent — no manual handoff.

You've just merged to main. CI built a binary, generated a coverage report, ran a benchmark. The next person who opens an agent against that project should see those artifacts already in /workspace. Don't make them drag-drop.

The plan

  1. CI obtains a connect0 service token with mcp:write scope.
  2. CI calls upload.create_link against the project.
  3. CI PUTs the artifact at the returned URL.
  4. The next agent session finds the file under /workspace/....

Today's status

This requires a service token — an API-token style credential that authenticates the MCP request without a user session. That credential surface is on the roadmap (it's the API token table that already exists in the schema, just not wired through the MCP transport yet). Until it lands, you have two options:

Option A — use a user's session. Get the user's __session cookie value, send it as a Cookie header on the MCP HTTP request. Brittle (sessions expire, the user can rotate them) — fine for a personal-machine cron, not for shared CI.

Option B — wait for service tokens. Recommended.

What the token-based flow will look like

# .github/workflows/upload-build.yml
- name: Mint pre-signed upload URL
  id: link
  run: |
    set -euo pipefail
    RESP=$(curl -sS https://mcp.connect0.ai/mcp \
      -H "Authorization: Bearer $CONNECT0_TOKEN" \
      -H "content-type: application/json" \
      -d '{
        "method": "tools/call",
        "params": {
          "name": "upload.create_link",
          "arguments": {
            "account_slug": "acme",
            "project_slug": "demo",
            "target_path": "builds/main-${{ github.sha }}.tar.gz",
            "content_type": "application/x-gzip",
            "content_length": ${{ steps.size.outputs.bytes }}
          }
        }
      }')
    echo "upload_url=$(echo "$RESP" | jq -r '.result.content[0].text | fromjson | .upload_url')" >> $GITHUB_OUTPUT

- name: Upload
  run: |
    curl --upload-file ./build.tar.gz \
         -H 'content-type: application/x-gzip' \
         '${{ steps.link.outputs.upload_url }}'

The token in $CONNECT0_TOKEN would have mcp:write scope and be account- or project-scoped (the schema already supports both).

Audit

Every upload via CI lands in upload_link with the client_id field populated (whatever OAuth client the token belongs to). The dashboard's "Recent uploads" column shows the source so you can distinguish CI uploads from human ones.

Failure modes

  • Token revoked. Mid-pipeline 401. Re-mint, re-run.
  • Project slug renamed. project_not_found. Update the workflow.
  • Size mismatch. Same trap as everywhere — the byte count is signed in. Recompute wc -c after every build.

Next steps

Where this fits

This is the Connect everything pillar of connect0 — the core that connects everything your company runs on. A service token lets CI connect build outputs into the core automatically, making your pipeline just another source that feeds the agents downstream. Start building → · All guides →