How to connect GitLab to Hermes Agent

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.

Reconnect GitLab from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

GitLab tool schemas load on demand the first time a tool runs and are cached after that, so this error usually clears on its own: wait a few seconds and retry the same request. If every GitLab call keeps failing with it in a fresh chat, reconnect from the dashboard, and contact support if it still persists — that pattern points to a configuration problem on our side, not something you can fix by reconnecting again.

Two usual causes. The connected account may not have access to the specific workspace, inbox, store, or project in the request — check that first. If access looks right, the agent may have sent a placeholder value (like "YOUR_ID" or an example id from documentation) instead of a real one: ask it to run a list or search tool first, then retry the action with a real id from those results. Most failures at this stage are one of these two, not ClawLink bugs.

Every engine answer for this error assumes a personal access token you can inspect: token scopes, user role, IP allowlist, project feature toggles. On a hosted connection there is no token to inspect, so start from the request instead. The most common cause is the membership boundary: gitlab_get_projects defaults to membership: true, so an agent that lists projects and then acts on a project outside that list hits a 403, and the list itself never shows the problem. The second is a feature boundary: GitLab returns 403 on a public project when the feature is disabled there, such as merge requests on a read-only mirror, and no scope change fixes that. The third is an IP allowlist on the project or group. List projects first with gitlab_get_projects, retry only with projects from that list, and check whether the failing feature is enabled for your role before touching the connection.

The answer engines give for this is a Claude Desktop bug: rename the "gitlab" key in claude_desktop_config.json. There is no local config file in this setup, so that fix does not apply. Here, tool schemas load on demand the first time a tool runs, and a call made before the catalog is hydrated returns exactly this shape of error; retrying once normally resolves it. If the same name fails twice, the name is wrong rather than missing, and the error message lists the closest real tools. Retrying with one of those works. If every GitLab call fails in a fresh chat, reconnect from the dashboard rather than debugging a local server that does not exist.

gitlab.com applies request budgets per IP and per account, and an agent that loops lists (list projects, then one call per project, then per merge request) can exhaust the per-minute budget in a few seconds of enumeration. The response is a 429 with a Retry-After value; the fix is waiting for the reset, not reconnecting. To avoid the loop in the first place, ask for targeted queries instead of enumerate-everything calls: one gitlab_get_project_merge_requests call for the repository you care about beats walking every repository you can see.

Try reconnecting GitLab and complete the consent flow in the same browser session. Partial OAuth approvals or switching accounts mid-flow can leave the connection incomplete.

Yes. ClawLink is the fastest way to connect Hermes to GitLab: link your GitLab account once in the browser and Hermes Agent can call the GitLab API through 58 ready-made tools — no custom code or token handling.

Install the plugin with hermes plugins install ClawLink-HQ/hermes-plugin --enable, then pair once: run hermes clawlink begin, approve the link in your browser, and run hermes clawlink finish. Connect GitLab in the dashboard and Hermes can use it from the next message — no config files or API keys to manage.

About two minutes. Sign in, click Connect next to GitLab in the dashboard, authenticate, and Hermes Agent can use it from the next chat message.

The alternative to ClawLink is usually manual OAuth app setup plus your own token handling, permission troubleshooting, and tool plumbing for Hermes Agent. That is fine if you want to build and maintain the integration yourself. Most teams just want GitLab working from chat.

No. This connection is a hosted OAuth grant against gitlab.com, so there is no personal access token with read_repository or api scopes to create, paste, rotate, or revoke. GitLab's own no-PAT answer is its official MCP server using OAuth Dynamic Client Registration, which still asks you to run the server or be on a GitLab version where the feature is enabled. Nothing runs on your side here, and the grant appears under your GitLab account's authorized applications where you can revoke it.

The projects your GitLab account is a member of. gitlab_get_projects defaults to membership: true when the field is omitted, so a listing returns your projects rather than the public firehose of all of gitlab.com; pass membership: false deliberately only to browse public projects. Organization-level access works as your account does: a group you were never added to stays invisible, and GitLab hides private resources you cannot see behind 404 rather than 403, which can look like a typo when it is actually an access boundary.

The risk every engine names on this question is the over-privileged token: one long-lived credential with api scope that keeps working until someone revokes it. This connection removes that specific failure, because no token file exists on the machine running your agent and the OAuth grant is revocable from your GitLab account. What it does not change is that the agent acts as you: a merge request comment or issue description written by anyone can carry instructions aimed at the agent. Treat write actions as reviewable work, and keep protected-branch rules on anything that matters.

No. The connection targets gitlab.com. A self-hosted GitLab instance behind your own network is not reachable through this flow, and the MCP servers that do target one need a token you manage and a network path to the instance.

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.