How AI assistants work with Drum
An AI assistant connected to Drum is another way for a person to use Drum. It does not get its own view of the data or its own rules. Most of how it behaves follows from that.
The assistant acts as you
Drum’s MCP server has no separate identity for AI. Each connection, whether made with Sign in with Drum or with an API token, belongs to one Drum user in one account. Every tool call runs as that user.
This keeps the question of what an assistant may do in one place: your role. A firm already decides who can see budgets, approve costs or edit other people’s time. The assistant inherits those answers, so nobody has to set up a second permission model for AI and keep it in step with the first.
It also makes the assistant’s work traceable. A time entry the assistant logs is your time entry, recorded under your name, exactly as if you had typed it. If a firm wants an assistant with narrower access than a person, it gives that assistant its own Drum user with a narrower role.
Sign in with Drum adds one more limit on top. A hosted client asks for read access, write access, or both, and a client with read access only cannot call a tool that changes data, whatever the role allows.
Toolsets keep the assistant focused
Drum has many tools, from logging time to rebuilding a proposal template. An AI model chooses a tool by reading every tool’s description on each turn. The more tools it holds, the more often it picks the wrong one, and the more of its working memory the list uses up. Hosted clients such as claude.ai and ChatGPT feel this most.
Toolsets solve this by grouping the tools by kind of work. A project manager who logs time and records costs needs My work. A sales lead adds Sales and Clients. Each connection holds only the toolsets its person chose, and the screens show how many tools each one adds, with a warning above 30.
Toolsets are about focus, not security. Leaving a toolset out does not take a permission away from you, and adding one does not grant one. When an assistant needs a tool from a toolset you did not select, Drum tells it which toolset to ask you to add, rather than pretending the tool does not exist.
The assistant sees only what your role permits
Drum checks your role before it lists a tool, and again on every call. A tool your role cannot use is left out of the list. Within a tool, the same record rules apply as in the browser: a project you cannot see is not found, and a budget figure you may not see is left out of the result.
Answering “not found” for a hidden record is deliberate. An assistant that was told “you may not read project 20488” would learn that the project exists. Treating hidden and missing records the same way gives nothing away.
When the assistant is refused because your role does not allow something, the error says so and tells it not to retry. A role change in Drum is the only fix, and that is a decision for a person.
The same operations as the REST API and the screens
The MCP tools are not a separate copy of Drum’s logic. When an assistant logs time, records a cost or converts an opportunity, it calls the same operation that the Drum screen and the REST API call for that job. The same validation runs, the same timesheet locks hold, the same approval workflow starts and the same webhook events fire.
This is why the three surfaces agree. An error from a tool carries the same reason code that the REST API returns. Money is integer cents and tax exclusive in both. Retries are safe in the same way: a create that times out can be sent again with the same idempotency key, and Drum returns the first result instead of making a second record.
The difference is the shape of the conversation. The REST API serves programs that know exactly what to ask for. The MCP server serves a model that has to find its way. So the tools add things a model needs: one search_records tool that turns a name into an id, short results with a has_more flag instead of long lists, and messages that say what to try next.
Some actions need a person
Some tools send email, delete records or replace data, such as sending a proposal or merging companies. Drum marks these tools as destructive, and its instructions tell the assistant to ask you before it calls one. Read the assistant’s plan before you agree, as you would check a colleague’s work before it goes to a client.
For more on the risks and how Drum limits them, see Keeping AI access safe.