The agent layer

What the MCP server exposes, what the skill asks an agent to do with it, and why the instructions are shaped the way they are.

Two halves

The MCP server is the capability: an authenticated endpoint with a set of tools for reading and writing a project. Any MCP client can use it, and the tool descriptions carry enough guidance to be useful on their own.

The skill is the judgement: when to read, when to write, what belongs where, and what to do when the agent is guessing. It is a document the agent loads at the start of a session. You can work without it — the page will just be less consistent.

Connecting

One paste. Create a token under Agents & MCP and you get a sentence to hand to the agent already working in your repository:

Set this project up on Ticulate: read https://ticulate.com/start/xk4m2p and follow what it says.

The agent fetches that URL and the reply carries the token, the calls it needs, and the workflow. Nothing to install and nothing to restart — which is the point. Registering an MCP server writes config, and a session that is already running does not see the new server until it starts again, so the old two-step flow handed an agent tools it could not actually reach.

The code in that link is not the token. URLs get handled far more carelessly than anAuthorization header — access logs, shell history, fetch caches — so it is a stand-in that is exchanged once for the real credential and expires after thirty minutes. The token behind it is stored encrypted and the link is kept out of robots.txt.

Connecting over MCP

Optional, and worth it for repeat sessions: tools rather than curl. It takes effect the next time the session starts.

claude mcp add --transport http ticulate https://ticulate.com/api/mcp \
  --header "Authorization: Bearer tic_your_token"

The token decides everything either way. It resolves to exactly one workspace, and every call is scoped to that workspace — an agent cannot address a project it was not issued a token for, whatever it sends. Read-only tokens are refused on every write with an error saying so.

What the skill asks an agent to do

Resume before writing. Every session.

The first call is project_resume, which returns the entire project document — purpose, architecture, features, roadmap, tasks, activity, decisions, feedback, people — in one response, along with the page's URL and an inbox of questions answered while the agent was away. That is deliberate: an agent returning after a week rebuilds context in a single round trip rather than ten.

Then task_list and feedback_list, because the resume does not carry the full work list and because reading what people asked for before planning is the entire point of collecting it.

Write back before finishing

The most common failure is doing the work, reporting it in chat, and letting the page go stale — which defeats the purpose, since the next session and every stakeholder read the page, not your chat. The skill makes this an explicit checklist rather than a suggestion: any session that changed the project ends with a write.

Never invent

No service, path, feature or date the agent has not actually seen. An invented entry point is worse than an empty section, because the next agent will believe it.

Ask instead of guessing

Both feature_upsert and task_upsert take a question. Setting one flags the item as needing a decision: the question appears on the thing it is about, banners on the overview until someone answers, and the answer comes back in the next project_resume.

This is better than asking in chat, which is lost when the session ends, and much better than picking silently and being wrong. Only the workspace can answer — see stakeholder feedback for why.

Answers usually arrive between sessions, so the resume collects them: inbox.answered holds every question that has been answered since it was asked, newest first, and inbox.waiting the ones still open. An agent that has to scan every feature and task to notice an answer will not, so they are gathered at the top of the document instead.

Set a project up in two calls, not thirty

A first import writes a purpose, an architecture, a dozen features, a work list and a year of history. project_ensure then project_import does all of it in two round trips, and each row is validated exactly as its individual tool would validate it — a bad row comes back in refused while the rest lands.

Backfilled history takes happenedAt per entry. Without it every decision an agent writes up carries the timestamp of the import, and a timeline where a year of work happened in one minute is worse than no timeline.

Ask for review after shipping

review_open puts a specific question about a shipped feature to the people closest to it, rather than the agent declaring itself done. Answers come back as works for me or a reported problem.

If you cannot speak MCP

Every capability is also on a plain REST API with the same token — one GET for the document and one PATCH that dispatches any tool by name. It answers application/json with no event-stream framing to strip, which makes it the simpler path for anything driving Ticulate from a script or a language without an MCP client.

It is a supported route, not a workaround: MCP and REST are thin wrappers over the same functions, so the two cannot drift.

Voice

The page is read by stakeholders who were not in the room, so the skill is specific about tone: plain, declarative, a fact then its consequence. Sentence case. No exclamation marks, no emoji, numerals from zero.

Good. The rehearsal passed. Legal sign-off is the only thing left, so the 14 August date is a plan, not a promise.

Bad. Great progress on the migration! 🎉

Everything is attributed and revertable

Every read and write is logged against the token that made it and shown in Agents & MCP. Every write snapshots what the section held beforehand and bumps a revision counter, so an agent's change can be undone. Provenance on the architecture section — verified by, and when — is stamped from the token, so it cannot be spoofed by the caller.

Agents correct themselves

Agents mis-file build work as features often enough that they need a way to fix it without a human: feature_to_task moves it across, losing nothing. task_delete exists for duplicates. And anything an agent writes, you can edit or delete by hand in the workspace.

Next

• Tool reference — every tool, its arguments, and when to use it
• Several agents at once — attribution and stale-write protection