MCP server

Projectrr runs a remote Model Context Protocol server at:

https://projectrr.work/mcp

Connect an assistant to it and it can read and write your boards — issues, projects, statuses, workflow rules, epics and their journals — acting as you, with your permissions. There is no API key to paste: the connection is authorised with OAuth in your browser.

Registering the server

Claude Code

claude mcp add --transport http projectrr https://projectrr.work/mcp

Run it once, then approve the sign-in when your browser opens. Add --scope user to make it available in every project rather than just the current one.

Claude Desktop, Cursor, and other mcp.json clients

Add the server to your client’s MCP config:

{
	"mcpServers": {
		"projectrr": {
			"type": "http",
			"url": "https://projectrr.work/mcp"
		}
	}
}

Restart the client, then approve the sign-in when it opens your browser.

Clients with a “custom connector” UI

Claude Desktop and Claude on the web can add a remote server from settings. Choose Add custom connector, paste https://projectrr.work/mcp, and finish the browser sign-in.

Checking it worked

Ask your assistant:

List my Projectrr organizations.

If it comes back with your organizations, the connection is live. You can also find these instructions, pre-filled for the server you’re signed in to, on your profile page.

How authorisation works

The server implements OAuth 2.1. When your client first connects:

1. It discovers the authorisation server from /.well-known/oauth-authorization-server.
2. It registers itself and sends you to Projectrr to sign in.
3. You approve the connection on a consent screen that names the client.
4. The client receives a token and uses it on every request.

The token is tied to your user account, so the assistant sees exactly the organizations you’re a member of and nothing more. Every action it takes goes through the same permission checks as the web app, and shows up in the activity log attributed to you.

To disconnect, remove the server from your client (claude mcp remove projectrr, or delete it from the client’s MCP config). Revoking a token from Projectrr’s side isn’t built yet — until it is, disconnecting the client is how you end the connection. Tokens are per user, so nothing an assistant holds outlives your own access to an organization.

What the assistant can do

Around 90 tools, mirroring the CLI:

Group	Tools
Orgs	org_list, org_members, org_invite, org_assignees, …
Products	product_list, product_create, product_update, …
Projects	project_list, project_overview, project_create, …
Issues	issue_list, my_issues, issue_view, issue_create, issue_update, issue_spec_get, issue_watch, …
Comments	comment_list, comment_create, comment_resolve, comment_reopen, comment_update, comment_delete
Epics	epic_view, epic_list, epic_create, epic_add_issues, epic_note_add, epic_note_resolve, …
Statuses	status_list, status_create, status_template, status_reorder, …
Rules	rule_list, rule_create, rule_update, rule_toggle, rule_log, …
Integrations	repo_link, release_sync, trello_connect, trello_import, …
Reading	attention, search, activity, report, report_completed

Start with org_list to discover slugs, then product_list and project_list. Issues are addressed either by UUID or by number plus productSlug and projectSlug. org_list also reports your role in each organization, so an assistant can tell before it tries whether a write is one you’re allowed to make.

Things worth knowing before an assistant starts calling them:

• org is optional. Slug-addressed tools take an org argument, needed only when the same product or project slug exists in more than one of your organizations — the API refuses to guess and asks to be told which.
• Finished work is hidden by default. issue_list and my_issues leave out anything in a done or closed status unless you pass includeClosed, which is why an assistant’s counts can differ from a board that is showing its finished columns. issue_list also takes assigneeId and createdById filters — who is doing the work, and who raised it. Those are different people, and both differ from the owner, the accountable lead. See Core concepts.
• my_issues is how “what’s assigned to me” gets answered. No other tool knows which user the token belongs to. Its relation argument picks which sense of “mine”: assigned (the default), created for what you raised, or either.
• rule_update replaces, it doesn’t merge. The actions and conditions you send become the rule’s whole set, so read it with rule_list first and re-send everything you want to keep. Same shape as rule_create.
• comment_create writes a comment a person will see. It lands in the thread on the issue page in the web app, subscribes the author, emails the issue’s watchers, and posts a copy to the issue’s linked Trello card if it has one. comment_update checks permission but not authorship, so an assistant acting as a developer or member can edit anyone’s comment; comment_delete needs owner or admin. See Core concepts.
• A comment has a kind, and blocker is how an agent says it is stuck. comment_create takes the same kinds an epic note does — comment (the default), update, decision, blocker, context, risk — and parentCommentId to reply to an existing one. A blocker or risk stays open until comment_resolve closes it, which is what puts the issue on the organization dashboard’s Needs attention panel next to blocked epics. comment_list takes kind and openOnly to read only what’s outstanding, and reports openBlockers and openRisks for the whole issue whatever the filter.
• blockedBy records what a blocker is waiting on. comment_create, comment_update, epic_note_add and epic_note_update take a blockedBy array; each entry sets exactly one of issueId, epicId or url (with an optional label). They come back on reads already resolved to the target’s title and current status, so an assistant can tell whether the thing in the way has since been finished. The array replaces the note’s existing list, so send every link you want to keep, and referenced issues and epics must be in the same organization. See Epics.
• attention answers “what is stuck”. One call, naming an org, returns every epic and issue in that organization carrying an unresolved blocker or risk — the same list as the dashboard panel, so an assistant can read it instead of walking every project. Rows come back worst first (most open blockers, then most open risks) and each one says what it is, which product and project it’s in, and how many blockers and risks are open, so the follow-up is an issue_view or epic_view. Each row also carries blockers — what its open items are waiting on, already resolved to titles and statuses, deduped and capped at four with the remainder in moreBlockers — so “what is holding this up” is answerable without a second call. It counts only unresolved, root-level blockers and risks, and leaves out finished work — done or cancelled epics, and issues in a done or closed status. limit caps the list (1–50, default 10), so treat a full page as “the worst ten”, not “all of them”.

Working with epics

This is the part worth setting up deliberately. Projectrr tells connected assistants to:

• Call epic_view before working on anything that belongs to an epic, so they start from the decisions already made instead of re-deriving them
• Call epic_note_add afterwards to record what they did or decided, so the next session — yours or theirs — picks up the same context
• Resolve blockers with epic_note_resolve and a body explaining how, rather than editing or deleting the original note

The result is a project journal that survives across sessions and across the line between you and your agents. See Epics.

The same applies one level down: comment_create with kind: "blocker" is how an agent records that a single issue is stuck, and comment_resolve with a body is how it comes back off the dashboard. The resolution is appended to the thread as a reply, so the original still reads as what it was at the time.

attention is the other end of that loop: what agents record as blocked is what comes back when you ask one “show me everything blocked in Greengage”.

Troubleshooting

The browser never opens, or sign-in loops. Check that your client supports remote HTTP MCP servers with OAuth. Older clients that only speak stdio need a bridge.

Tools are listed but every call fails with 401. The token expired or was revoked. Remove and re-add the server to trigger a fresh sign-in.

The assistant can’t see an organization. MCP identity is per user — you only see what your own account can see. Check your membership in the web app.

Scripting instead

If you want automation rather than a conversation, use the CLI. In CI, set PRR_API_KEY and skip signing in altogether.