MCP server

Remote HTTP transport, so a URL and a token is the whole setup — no local process, no npm install, and it works the same in a desktop client as in a terminal.

Generate the token under Organisation settings → API and pick the Coding agent preset: read and write, no deletes, and no access to budgets, quotes or statements. For a connection the whole team relies on, make it an organisation token — a personal one is deleted with its owner’s account.

The REST API has an endpoint per resource, because that is what a REST API is for. Mapping those one-to-one onto MCP tools is the standard way to build an MCP server badly — every tool definition is spent from the model’s context before it has read a word of your actual work, and a long list of near-identical options is exactly how a model picks the wrong one.

So these are shaped around what somebody asks for, not around the data model. Anything rarer stays behind the REST API, which is still there and still complete.

• list_projects

  The projects you can reach. Start here.

• get_project

  One project's whole plan — phases in order, tasks under each.

• next_tasks

  What to pick up: started work first, then priority, skipping anything blocked.

• get_task

  One task in full, with its specification, test plan and comments.

• search

  Find anything by name or phrase when you don't have a reference.

• update_task_status

  Move a task to in progress, review or done.

• comment_on_task

  Record a decision, a blocker, something worth knowing later.

• log_time

  Log effort — "1h 30m", "45m", "1d 2h".

• create_task

  Add work that genuinely wasn't in the plan.

• update_task

  Correct a task in place — its specification, estimate, or which phase it sits in.

• create_phase

  Add a stage of work for tasks that have nowhere sensible to go.

Every tool goes through the same service classes the web app does. A status change writes the same audit row, notifies the same watchers, and appears in the same Activity tab as one made by hand — there is no second path with its own rules.

Token abilities apply here as they do over REST, with one wrinkle worth knowing: MCP is JSON-RPC over POST, so reading a project and closing a task are the same HTTP verb to the same URL. The ability required is decided by the tool being called, never the method.

The server also tells the model, up front, which three things are the human’s call: don’t mark work done that isn’t finished, don’t restructure a plan without agreement, and don’t invent an estimate.

MCP is for when a person is talking to an AI assistant and wants it to know about their work. If something needs to run a command — CI, a git hook, an agent without MCP support — the CLI fits better. If you’re building software against Waymarq, or need clients, quotes and statements, use the API. And if you’d rather the tracker just kept itself current with no cooperation at all, connect a repository and let your commits do it.

They compose — all four go through the same services, so they agree with each other.