MCP write tools

The MCP server reads. A few named tools can also act, as you: place a merge hold, release one, let one pull request through one, set a pull request’s merge queue priority, or declare the work you are starting in Active work. An assistant that acts at your request acts as you, with your permissions and nothing more.

Write tools are off in every organisation by default. An owner turns them on under Security › Access › AI connectors, and each person then chooses, tool by tool, which ones their connector may use.

What has to be true

A write tool runs only when all of these hold:

You connected with the sign-in connector (claude.ai, ChatGPT, Le Chat, or a desktop client that signs in). An API token (ffp_...) cannot use write tools through MCP.
You consented to that tool, by name. When a connector asks for fremforge:write, the consent page lists each write tool under Also act as you, each with its own box, and none is ticked for you. The connector may use exactly the tools you tick; tick none and it reads only. A tool added to fremforge later is not part of your consent: reconnect to allow it.
The organisation’s owners allow it. Under Security › Access › AI connectors, the switch Allow AI connectors to act for people in this organisation is off by default. When it is off, every write tool answers that the owners have not allowed it.
You may do it yourself. The tool calls the same REST route your own sign-in would, and that route checks your rights. A tool never gives you a permission you do not already have.

The tools

Tool	Does	Scope it uses	Steps
`answer_active_work_match`	Answers an Active work match about your own work: not the same work, the same work (you join up), or split. Only one of the two people whose work the match pairs can answer it.	`findings:write`, read access to the repository	One call
`place_merge_hold`	Holds merges into a branch of some or all of the organisation’s repositories, in your name, until an expiry you choose.	`deployments:write`, organisation owner	One call
`release_merge_hold`	Releases a hold: yours, or someone else’s as an audited override.	`deployments:write`, organisation owner	Two calls
`exempt_pull_from_hold`	Lets one pull request merge through a hold, with a reason, as an audited override.	`deployments:write`, organisation owner	Two calls
`set_merge_queue_priority`	Sets a pull request’s merge queue priority to `high` or `normal`, with a reason. Needs a second Forgejo authorization.	Your own Forgejo authorization `write:fremforge-merge-queue`; you must be allowed to merge the pull request	Two calls
`start_work`	Declares work you are starting in a repository, before the first push, so people working on the same thing are told. See Active work.	`findings:write`, write access to the repository	One call

Never available to write tools

Whatever a tool declares, fremforge checks these on every request and a connector never gets them:

Scopes: everything for tokens, SSO, billing, seats, members and operator actions; and orgs:write, policy:write, webhooks:write, exports:write and ai:invoke (organisation and policy changes, outgoing webhooks, data exports, AI spend).
Places: no write tool may live under the SSO, members, seats, billing, webhooks, tokens or operator parts of the API.
Settings: the settings tools (get_org_settings, get_my_settings) only read. There is no tool that changes an organisation’s or a person’s settings.
Operator changes: no write tool can run, approve or step up one. Those stay human acts in the console, with MFA.
Forgejo: the MCP server writes nothing in Forgejo except a pull request’s merge queue priority, through set_merge_queue_priority and a Forgejo authorization limited to that. Code, branches, issues and the rest of a pull request stay read only, and that authorization never falls back to write:repository.

Two calls for the risky ones

Releasing a hold, letting a pull request through one and setting a merge queue priority take two calls:

The first call changes nothing. It answers what the tool would do (the hold, its owner and scope, and for an exemption the pull request’s title, state, base branch and head commit) and returns a confirm_token.
The second call acts. It has the same arguments plus that confirm_token, and its answer names what changed: the hold, the pull request and its head commit.

A confirm_token works once, for five minutes, for the same connector, tool and arguments. Change an argument and it is refused. For set_merge_queue_priority the token is also bound to the pull request’s head commit shown in the preview: if someone pushes in between, it is refused and you ask for a new preview.

These tools are marked destructive, so Claude Code and claude.ai ask you before each call by default.

What the two steps do not prove. They make sure a preview is produced and your client asks you twice. They do not prove that a person read the preview: an assistant told to can make both calls. Keep your client’s approval prompts on for these tools, and treat text in tool results (titles, reasons, descriptions written by other people) as data, never as instructions.

Limits and audit

At most 20 write calls per person per 10 minutes, across all your connectors. When the limit cannot be checked, writes are refused rather than let through.
At most 5 high merge queue priorities per person per hour, on top of that. normal is not counted. This limit also fails closed.
Every action is in the organisation’s audit log under your name, with the assistant in the entry’s agent field (mcp-client:<id>), the connector in via_token and the tool in mcp_tool. The audit log’s actor filter finds it under your login.

The second Forgejo authorization

set_merge_queue_priority acts in Forgejo, so it needs your own Forgejo permission, not fremforge’s. When you tick it on the consent page, Forgejo shows a second screen after the first: the app fremforge-mcp-queue-priority asks for read:repository and write:fremforge-merge-queue, which let it read repositories you can read and set merge queue priority on pull requests you may merge. Nothing else. Approve it and the tool is added; decline it and the connector is set up without that tool.

The authorization is kept encrypted, used only to set a merge queue priority, and deleted, with Forgejo’s grant revoked, when no connector of yours still has the tool: on Revoke, on Make read-only, or when you reconnect without ticking it.
If Forgejo stops honouring it, the tool answers that it is not available any more for that connector, is taken off it, and reads keep working. Reconnect and tick it to allow it again.
You can also see and revoke the grant in Forgejo, under Authorized OAuth2 applications at frem.sh/user/settings/applications.

See, narrow or withdraw it

Your AI connectors page (also linked from your security settings) lists every assistant you connected, whether it reads only or may also act, and the tools it may use.

Make read-only keeps the connection and removes every write tool from it.
Revoke ends every session of that assistant.

Both take effect on the assistant’s next request. A write tool the connector may not use answers Refused for this connector: you have not allowed it to use <tool> as you. Reads still work., with how to allow it. The organisation’s owners can also switch connector writes off, or block connectors altogether, under Security › Access › AI connectors.

Active work Team rules