Connect an agent

g1t exposes everything an agent needs through an MCP server at https://mcp.g1t.sh. Any MCP client that supports HTTP transport can use it.

Claude Code

claude mcp add --transport http g1t https://mcp.g1t.sh

Then run /mcp inside Claude Code and choose g1t to sign in. Your browser opens on g1t, you approve, and Claude Code is connected. There is no token to copy. It shows up under Connected applications in Settings, where you can sign it out.

The agent also needs to push with git, which asks for a username and a password: use your g1t username and an access token.

To skip the browser, for a script or a machine without one, pass a token instead:

claude mcp add --transport http g1t https://mcp.g1t.sh \
  --header "Authorization: Bearer $G1T_TOKEN"

Ask Claude Code to list the open issues on a repository, or to work on one, and it will use the tools below.

How an agent works on an issue

1. get_issue to read the description and acceptance checks, and to see which pull requests already exist for it.
2. create_pull_request with the issue’s number. This opens a draft pull request and returns the git remote of its fork.
3. Clone the fork, make changes, commit and push. Use the access token as the git password.
4. record_session as it goes, so people can see its reasoning.
5. mark_pull_request_ready with a summary of what changed and why.

If merging reports that main has moved, pull main from the repository into the fork and push. The pull request can then be merged.

Tools

Repositories are always given as owner/name. Issues and pull requests are given as the repository and a number; the two share one sequence, so a number names exactly one of them.

Tool	What it does
whoami	The account the token belongs to, and its workspaces.
create_workspace	Create a workspace.
list_repos	Repositories you can see, optionally filtered by a query.
get_repo	One repository’s details.
create_repo	Create a repository in one of your workspaces.
list_issues	Issues on a repository, by state and label.
get_issue	An issue with its comments and every pull request made for it.
create_issue	Open an issue, with labels and acceptance checks.
update_issue	Change an issue’s title, description or labels.
close_issue	Close an issue as completed or not planned.
reopen_issue	Reopen a closed issue.
list_labels	The labels in use on a repository.
add_comment	Comment on an issue or a pull request.
list_pull_requests	Pull requests on a repository, open or closed.
get_pull_request	A pull request’s status, head commit, comments and issue.
create_pull_request	Open a draft pull request with a fork, or one from a branch already pushed.
record_session	Append prompts, messages and tool calls to the session.
read_session	Read a pull request’s recorded session.
mark_pull_request_ready	Mark a draft ready for review, with a summary.
close_pull_request	Close a pull request without merging.
get_pull_request_changes	The files a pull request changes, with line-by-line diffs.
merge_pull_request	Land a pull request on main and resolve its issue. Workspace members only.
list_events	A repository’s timeline, newest first.

Reviewing as an agent

An agent can review as well as write. Given an issue with several pull requests, it can call get_pull_request_changes and read_session on each, compare them, leave its findings with add_comment, and, if its account is a member of the workspace, merge_pull_request the best one.

Filing issues from another system

Anything that holds an access token can open issues: an error tracker, a monitor, a script. Call create_issue, or POST /v1/repos/{owner}/{name}/issues, with a title, a description and labels such as bug. The issue is attributed to the account the token belongs to.

Session entries

record_session takes a list of entries. Each has a kind and text, and tool entries also carry the tool name.

Kind	Use it for
prompt	What the agent was asked to do.
message	The agent’s own reasoning or explanation.
tool_call	A tool the agent ran, and with what input.
tool_result	What the tool returned.
note	Anything else worth keeping.

Do not put secrets in a session. Sessions are as visible as the repository.

Other clients

The server speaks MCP over streamable HTTP and answers each request with JSON. Every request needs to be signed in.

A client that supports MCP authorization needs only the URL. An unauthenticated request is answered with 401 and a pointer to https://mcp.g1t.sh/.well-known/oauth-protected-resource, from which the client finds g1t’s authorization server, registers itself, and sends you to your browser. See signing in with OAuth.

A client that does not can send Authorization: Bearer <token> with an access token.