Claude Code and MCP, on the record.

If your engineers use Claude Code, turn on the Ticinuum MCP server and an engineer's own session can read the ticket, work it as that engineer, and have its token spend attributed to the ticket, in the same ledger as the autonomous runs. Metadata only: prompt content stays on the laptop. Both halves ship off until the platform operator turns them on.

Early access ↓

Claude Code & MCP · opt-in

Your engineers' sessions join the record.

Turn on the Ticinuum MCP server and an engineer's own Claude Code session can read the ticket, its plan, the repo profile and the run history, annotate the work as that engineer, and have its token spend attributed to the ticket — in the same ledger the autonomous runs use.

Connect by URL, or tici claude TIC-827 — add your Ticinuum MCP address to Claude Code, Claude Desktop, or claude.ai and sign in through the browser (OAuth 2.1) — or sign the tici launcher in once with tici login, and tici claude TIC-827 activates the ticket, resolving its initiative and project and opening a session, then launches an unmodified Claude Code. No fork, no wrapper; any MCP client works. Every connection is listed, and revocable, under Settings → Connections.
Read and write as the engineer, never as the platform — more than 200 tools — read the ticket, its plan and changes, runs and run logs, findings and spend; file, comment, attach, label, link and hold; put a question to a colleague — each bounded by the engineer's live role in one org: a viewer's client is read-only, and removing a member revokes their connections. Calls go through the same services as the UI, so the injection quarantine applies, and every write is audited with the credential that made it.
Spend attributed, prompts never captured — the laptop reports what it used — tokens, model, latency — and the control plane decides what it belongs to from the activated ticket, pricing it at API list rates. Metadata and counters only; prompt content is never ingested. Every cost figure is labelled autonomous, workstation, or total, and an OrgAdmin can see workstation spend per engineer.
Spending is a separate grant — the tools whose purpose is starting or resuming paid agent work — run, groom, retry, approve, answer, merge, and filing a ticket with run set — need a permission the engineer grants explicitly when connecting, and tici login does not ask for it. No tool completes a ticket, and none accepts an org id. A ticket filed over MCP joins the same lifecycle as one filed in the UI: it is groomed if it needs it, then waits for a person's Run, gated exactly the same way, and the merge waits for a person unless your org lets the agent merge.

Honesty note: both halves — the MCP server and workstation metering — ship off until the platform operator turns them on, and connecting by URL also needs the operator to publish the server's address. Every workstation request is priced at API list rates, even on a Claude subscription seat, because how to value a subscription is still undecided; the combined autonomous-plus-workstation dashboard is not built.

workstation · illustrative

$ tici login   # once — approve in your browser
  $ tici claude TIC-827
  activated TIC-827 · initiative + project resolved
  session open · attribution set
  launching claude…

  › mcp__ticinuum__get_ticket_plan
  › mcp__ticinuum__get_repo_profile
  › mcp__ticinuum__add_comment

Tokens land in the same usage ledger as autonomous runs, labelled workstation. Prompt content stays on the laptop.

Roadmap fence

Claude Code & MCP: what's opt‑in, and what isn't built.

What's built but off until you turn it on, and what isn't built yet. Open any row for the whole sentence, or read the whole fence.

On the roadmap Not built yet, or built but not yet validated in use. Don't rely on these. 2 items

CostThe combined autonomous + workstation cost dashboard — waits on a decision about how to value subscription-funded sessions — today every workstation request is priced at API list rates
IntegrationsMCP parity, finished — an engineer's everyday verbs are tools today; many admin and settings operations are not yet

Built · opt-in · off by default Shipped, but off until someone turns it on, usually your org admin, on the record. 2 items

CostWorkstation session metering — an engineer's Claude Code spend attributed to the ticket in the same ledger as autonomous runs, priced at API list rates, with per-engineer spend for an OrgAdmin; metadata and counters only, prompt content never captured
IntegrationsTicinuum MCP server — Claude Code, Claude Desktop, claude.ai or any MCP client works the ticket as the signed-in engineer: more than 200 tools, each bounded by that engineer's live org role. Connect by URL (OAuth 2.1), or sign the tici launcher in with tici login and launch with tici claude; review or revoke every connection in Settings → Connections. The tools whose purpose is starting paid agent work need a grant the engineer gives explicitly, and no tool completes a ticket (a ticket filed over MCP is groomed like any other, then waits for a person's Run)

FAQ

Questions, answered plainly.

Can our engineers use Claude Code with it?

Yes, once the platform operator turns on the MCP server — it ships off. An engineer connects Claude Code, Claude Desktop, or claude.ai by URL and signs in through the browser — or signs the tici launcher in once with tici login, after which tici claude TIC-827 activates the ticket and launches an unmodified Claude Code. More than 200 tools — read the plan, the changes, the repo profile, the run history; file, comment, attach, label, link, and put a ticket on hold so nothing auto-acts on it — act as that engineer, bounded by their live role in one org, through the same injection quarantine and audit trail as the UI. The tools whose purpose is starting or resuming agent work that spends your budget (run, groom, retry, approve, merge) need a separate permission the engineer grants explicitly when connecting, and tici login doesn't ask for it; no tool completes a ticket. Every connection shows up in Settings → Connections, where it can be revoked. A ticket filed over MCP is groomed like any other, then waits for a person's Run; the merge waits for a person unless your org lets the agent merge. Connect a client →

Do you see our prompts?

No. Workstation metering (also opt-in) ingests metadata and counters only — tokens, model, latency, timestamps — and attributes them to the activated ticket server-side. Prompt content is never captured; an opt-in content path is an undecided governance question, not a feature. The autonomous agent's own rendered prompts are stored as artifacts by default, and that family can be turned off or kept in your bucket like any other.

The rest of the deep dive

Every other guardrail, on its own page.

Put your backlog on the continuum.

From intent to PR to review — one durable, auditable continuum of work. Early access opens soon.

coming soon

Early access opens once the waitlist terms and privacy notice are final. Nothing to sign up for yet — this page collects no email.