An agent works your helpdesk under a person's permissions
Certainty HelpDesk ships its own MCP server, so the assistant your team already uses can file an issue, move a status, assign work by name and track the time it spent. A token carries one person's role and memberships, and every write is attributed to them.
Most of what you would otherwise do by clicking
An agent can run a search, list your work and your notifications, walk organisations, projects and the items inside a project, read an issue, a feature or change request or a task, create issues, feature and change requests, client requests and tasks, update them, re-sort one filed as the wrong kind, change a status, assign an item, comment, delete a task, manage its own user's personal tasks and notes, start, stop, log and summarise time, read the project tracker and post a weekly update, read and fill in the custom sheets on the Projects page, and list the credentials about to expire or record a new one in a project's secrets register.
Assignment works in plain language. Asking it to assign something to a colleague by name resolves the name, so nobody hands an agent a user ID. If the name is ambiguous it says so rather than guessing.
- A failed call comes back as a readable result, so an agent can explain itself
- Titles and descriptions written over MCP land in the same edit history as the browser
- A timer an agent starts closes itself after two hours and waits for a person to confirm it
A token is a person, not a service account
An agent holds exactly the permissions of the user whose token it carries: the same role, the same organisation and project membership, nothing more. It cannot open a project that person is not a member of, and it cannot read an internal record they could not read.
The role behind the token is the control. Narrow the person's role in the role editor, or take them off a project, and the agent is narrowed on its next call. Permissions are re-read on every request, so nothing has to be signed out and back in.
- The role needs team workspace access, so a client role can never use MCP at all
- File attachments are not supported over MCP and still go through the web app
- A revoked token, a deleted user and a suspended account all fail as the same plain response
Acting as Abdullah · Senior SWE
Minted once, listed in one place, revoked in one click
Each person generates their own tokens in the team workspace settings, names them, and copies the value out of a dialog that shows it exactly once. Only a hash is stored, so a lost token is replaced rather than recovered. There is no admin screen listing everyone's tokens and no way to mint one on somebody's behalf, because a token is a personal credential rather than a shared key.
The card lists every token you hold with its name, its hint, when it was created and when it was last used. Revoking cuts access immediately and leaves the row marked revoked, so the history stays readable. A sign-in and consent flow from a hosted client lands in the very same list, named after the client that asked.
- A connection guide with the exact snippet for Claude Code, Claude Desktop, Cursor or anything else
- The endpoint is filled in for you, so you are copying a value rather than looking one up
- Any client that speaks Streamable HTTP can connect
Your MCP tokens
- Attaching files over MCP: uploads still go through the web app.
The things teams ask about this
Which assistants can connect to it?
Anything that speaks the Model Context Protocol over Streamable HTTP. The connection card carries ready-made instructions and a copyable snippet for Claude Code, Claude Desktop and Cursor, and an Other tab with the endpoint for everything else. Hosted clients that use a sign-in and consent flow instead of a pasted token land in the same token list afterwards.
How do we stop an agent reaching something it should not?
By narrowing the person, not the agent. A token inherits its user's role, organisation membership and project membership, and permissions are re-read on every request, so editing the role or removing them from a project takes effect on the agent's next call. There is no separate agent permission model to keep in step.
Can we tell afterwards which changes an agent made?
Yes. Every write is attributed to the user whose token was used, and the activity trail records the source as web or MCP on each change, so a status flip made by an assistant reads differently from one made in a browser. Title and description edits over MCP are snapshotted into the same version history as any other edit.
Can an agent upload a screenshot or a document?
No. File attachments are not supported over MCP and still go through the web app. It is the one everyday thing an agent cannot do for you, and worth knowing before you build a workflow that assumes otherwise.
Where this connects to the rest of it
See it against your own work
Thirty minutes on a call, one of your real client projects on the screen, and an honest answer about whether this part of the product earns its place in how you work.
partnerships@dhcertainty.com