Gitfence
Start free

AI agents and MCP

Give Claude Code, Codex or Cursor an agent token and connect the MCP server. Scopes, tools, run_tests availability and the guide in every clone.

Short answer: Each AI agent gets its own token and belongs to a person. Its clone and its MCP calls carry only that person's access, or less. The agent can inspect its fence, ask for access, follow and review pull requests and, where Fenced CI runs, run the real tests.

Steps

  1. Create the agent token. On the member's Gitfence home, choose Connect an AI agent, pick the AI tool (Claude Code, Codex or Cursor), optionally set Limit this agent, then choose Connect Claude Code, Connect Codex or Connect Cursor. The token is shown once.
  2. Limit it if needed. Limit this agent can choose a Repository, the paths It may edit, whether Everything else is Read-only or Hidden, and when It stops working: When its pull request is merged or closed or After the expiry date. A limit only narrows the person's access.
  3. Connect MCP. Export the token as GITFENCE_TOKEN and use https://gitfence.dev/mcp:
claude mcp add --transport http gitfence https://gitfence.dev/mcp \
  --header "Authorization: Bearer $GITFENCE_TOKEN"

Codex uses url = "https://gitfence.dev/mcp" and bearer_token_env_var = "GITFENCE_TOKEN" in ~/.codex/config.toml. Cursor uses the same URL and an Authorization header in ~/.cursor/mcp.json or .cursor/mcp.json.

  1. Or skip the hand wiring. The one-paste setup on the member home gives one prompt or command that clones, configures git and connects MCP. Its link works once and expires after 15 minutes; redemption creates the token for that setup, such as a 30-day agent token.

Tools

list_repos, fence_status, check_paths, request_access, my_access_requests, run_tests, test_status, my_pull_requests, pull_request_status, pull_request_diff, pull_request_file_lines, comment_on_line, submit_review, reply_to_review, resolve_thread, react, apply_suggestion, set_labels, set_assignees, list_issues, get_issue, comment_on_issue, create_issue and whoami.

  • update_pull_request edits the title or description, or changes the draft state.
  • close_pull_request closes or reopens your own pull request.
  • delete_branch deletes your own branch.
  • translate_commit translates a commit id between your clone and GitHub.

See Working on pull requests for branch names, push options, review updates and commit ids.

The guide Gitfence writes into AGENTS.md and CLAUDE.md in every clone explains the fence: do not recreate or stub hidden code, ask for access instead, and push to a branch. The MCP server is Streamable HTTP, POST only, with no sessions or SSE.

Reviewing pull requests

Agents can read a pull request diff from their own filtered copy and review it through REST or MCP. Hidden files stay hidden, and types-only files show their generated declarations or stubs. The review rules are the same as in the contractor guide.

For REST, send the token as Authorization: Bearer <token>:

GET /api/collab/repos/<owner>/<repo>/pulls
GET /api/collab/repos/<owner>/<repo>/pulls/<n>/files
GET /api/collab/repos/<owner>/<repo>/pulls/<n>/files?format=patch
GET /api/collab/repos/<owner>/<repo>/pulls/<n>/files?path=<file>
GET /api/collab/repos/<owner>/<repo>/pulls/<n>/lines?path=<file>&side=RIGHT|LEFT&from=1&to=50
POST /api/collab/repos/<owner>/<repo>/pulls/<n>/comments
POST /api/collab/repos/<owner>/<repo>/pulls/<n>/reviews

The first endpoint returns your own pullRequests and a reviewing list. files returns JSON files with hunks and an outside count. format=patch returns plain unified diff text, and path=<file> loads one file in full. lines returns lines of the file from your copy.

Post line comments with {"path","line","side","body"}. Post reviews with {"event":"comment"|"approve"|"request_changes","body"}.

For MCP, my_pull_requests also lists reviewing. The review tools are:

  • pull_request_status.
  • pull_request_diff with repo, number, optional path, and optional format set to "patch" or "json".
  • pull_request_file_lines with repo, number, path, side, from and to.
  • comment_on_line with repo, number, path, line, side and body.
  • submit_review with repo, number, event and body.
  • reply_to_review.
  • resolve_thread with repo, number, comment_id and optional resolved, which defaults to true.
  • react with repo, number, comment_id, content and optional kind set to "issue" or "review".
  • apply_suggestion with repo, number and comment_id.
  • set_labels with repo, number and labels.
  • set_assignees with repo, number and assignees.

Tests in the fence

run_tests runs the repository's test command on the full code in a sandbox with no network, and returns the verdict (or redacted output, if the repository allows it). It works today on self-hosted Gitfence. On our hosted service it is not self-serve yet: we set it up with you, so contact us.

Where it is not set up, fence_status says tests in the fence are not available on this server, and run_tests answers unavailable. The guide then tells the agent to push its branch and say in the pull request that the full tests were not run. Saving a test command under Tests does not switch it on.

Gotchas

  • A folder marked No AI agents is hidden from every agent, whatever its scope says.
  • Git and MCP tokens keep working when Require SSO is on, but the token must not be expired or revoked.
  • Revoke a token under Your passwords and agents on the member home. A revoked token stops working at once.
  • MCP does not see prompts. It records the calls it receives.

Next: code review and access levels.

Related guides