Reference

Connect an AI assistant

TimerOS runs a hosted MCP (Model Context Protocol) server at https://api.timeros.ai/mcp, so an AI assistant you already use can read your work and, if you allow it, make a bounded set of changes. There is nothing to install. The assistant acts as you: every request runs through the same routes, guards and permissions your own sign-in has, so it can never see more than you can. It is available on every plan — Freelancer, Startup and Enterprise — at no extra cost, and it is tested with Claude: claude.ai on the web, the Claude desktop app and Claude Code.

How to connect

  1. 1In TimerOS, open Settings → Connections (desktop or web app) and copy the connector URL — or use https://api.timeros.ai/mcp directly.
  2. 2In Claude, open Settings → Connectors → Add custom connector and paste the URL.
  3. 3A TimerOS sign-in page opens. Sign in with your TimerOS email and password, then your 2FA code if your account has two-factor enabled. A workspace that requires 2FA refuses accounts that have not enrolled yet.
  4. 4On the consent page, check the assistant’s name, your workspace name and the access it asked for — read, or read and write — next to the fixed list of things it can never do. Incidents and change requests are a separate box there, ticked by default — untick it to connect without them. Click Allow access to approve, or Cancel to refuse.
  5. 5Expect an email confirming the new connection. It names the assistant and the scope, and tells you where to disconnect it.

What it can do

With read access, the assistant can summarise a project, find tasks, and look up teams, people, goals, clients, invoices, expenses and the profit report — reading never changes anything. With read and write, it can also add and update tasks and subtasks, change task status, add notes, record operating expenses, create projects with phases, and attribute your own unassigned tracked hours to your tasks.

Small changes — a status, a note, a new task — are written in one call. The bigger ones (creating a project, adding a phase, creating a batch of subtasks, attributing hours) go through a plan first, then apply step: the assistant receives a plan it shows you, then applies it in a separate call that hands the plan’s acknowledgement text back verbatim. A plan expires after 10 minutes and applies exactly once. Attributing hours is the only time-related write there is: it assigns minutes you have already tracked but not yet allocated to your own tasks. It never creates time, never moves time between tasks and never edits a day’s totals.

What it can never do

These are not permissions you grant or withhold — the tools simply do not exist. The one exception is incidents and change requests, which you decide when you connect.

  • Change milestone status (which can mint a client invoice), log or edit time beyond the attribution above, assign people to projects or tasks, set budgets or rates, create or send invoices, edit clients or employees, write goals, record transactions or vendor bills, or delete anything.
  • See pay, salaries, tax IDs, dates of birth, home addresses or emergency contacts — those fields are stripped from every response.
  • Read your client chat — there is no tool for it, on any access level. Incidents and change requests are the one thing you decide: the assistant can read them only if you leave the incidents-and-changes box ticked when you connect, and anything a client wrote in them is handed to it marked as data, never as instructions. Client names, descriptions and invoice notes are treated the same way.
  • Bypass your permissions or reach another workspace.

Managing connections

Settings → Connections lists every assistant connected to your account: its name, its access — read, read-and-write, and, if you left it ticked, incidents and change requests — when it was connected, when it was last used and how many changes it has written. Expand a connection for its Activity list — every change the assistant made, each with the call that undoes it. Disconnect is one click, and access stops on the assistant’s very next request.

  • Access tokens last 15 minutes; refresh tokens last 30 days and rotate on every use. A replayed refresh token disconnects that one connection.
  • Your assistant traffic has its own limit of 100 requests per 60 seconds — shared by every assistant connected to your account, and separate from your own use of the app.
  • If your workspace’s subscription lapses, you can still disconnect assistants; the tools themselves refuse until the subscription is active again.

Incidents and change requests

Incidents and change requests carry text your clients wrote — titles, descriptions and comments raised from the portal. That is a different kind of content from the rest of your workspace, so it sits behind its own consent box on the approval page, separate from read and read-and-write. The box is ticked by default: leave it ticked to let the assistant work on incidents and change requests, or untick it to connect without them and keep everything else. Unticking only narrows what you grant — nothing can add access the assistant did not ask for. Reading tickets needs this box; changing one needs it together with read-and-write, so a read-only connection can read tickets but change nothing. A connection you made before this existed does not have it: disconnect it in Settings → Connections and connect again to get the box.

The assistant only works on tickets assigned to you. Adding a note, starting work, resolving an incident and completing a change all refuse on someone else’s ticket. When that happens the assistant asks you first and assigns it only once you agree — never silently.

  • Assigning and routing — hand a ticket to yourself or to a colleague you name. You can also ask the assistant who should take it: it reads teams, job titles, seniority, skills, languages and how many tickets each person already has open, proposes one owner with a one-line reason, and assigns only after you agree. On the Freelancer plan there are no teams, so it routes on people alone.
  • Who is told — assigning a change request notifies the new implementer, the previous one and every active member of the assigned team, in the app and by email. Assigning an incident notifies only the new assignee, whose name the client can see on the portal.
  • Starting work — the assistant can move an incident, or a change that has already been approved, into progress. On a client ticket the client is told that work has begun — for an incident, the first time it is picked up. A change still in draft or waiting for approval cannot be started.
  • Notes stay internal — a note the assistant adds to a ticket is an internal note. The client never sees it.

Resolving an incident or completing a change happens only through a plan you approve. The plan spells out what will be written, what the client will see, what will be emailed and whether it can be undone; the assistant applies it in a separate call, after you say yes. Resolving publishes your resolution notes and root cause to the client’s portal and sends them a branded email asking them to confirm or reopen the incident — reopening undoes it. Completing a change publishes your implementation notes and sends a “completed” email; that one the assistant cannot cleanly reverse.

What this does to your billing
Neither action invoices anything. Resolving an incident is not a billing event at all — the plan only tells you whether that incident joins the unbilled support queue for someone to invoice later. Completing a change on a client ticket records the hours a later support invoice would use: the hours you give it, or the time elapsed since the change was started. Nothing is billed by the action itself and no amount is calculated — the assistant cannot read your rates.

For owners and admins: the workspace switch

A workspace owner or admin can turn Allow AI assistant connections off for the whole workspace from Settings → Connections (desktop app from 1.19.1, web app from 1.4.1). Turning it off disconnects every live connection in the workspace immediately, blocks new sign-ins on the connector, and emails the people affected; members see a notice that it was turned off by an administrator. The switch is on by default and is workspace-wide, not per person.

Other MCP clients
The connector is tested with Claude. Another MCP client needs Streamable HTTP and OAuth 2.1 with PKCE and client ID metadata documents. TimerOS does not support dynamic client registration, so a client that only knows that older method will not connect yet.

Looking for a developer API, personal access tokens or webhooks? Those are still on the roadmap — see the API reference for where things stand.