MCP Server for AI Agent Coordination in AuricIDE

Two coding agents work in the same repository. One finishes an implementation, sees its check pass, and marks the ticket done. The other reads the requirements, finds a test case nobody wrote, and starts the same work from another angle. Neither made a mistake. Each acted on the state it could see, and neither could see the other.

Adding the second agent broke the model you built around the first. Nobody designs this problem in. You find it after it has already cost you a morning.

One agent is a tool, several agents are a system

With one agent, you handle the coordination. You read what it did, you pick the next step, and you keep the context in your head. That works. It is why a single-agent workflow feels so good at first.

A second agent creates questions that neither agent can answer alone. Has someone already picked up this ticket? Did the last run change the requirements? Is the thing I am about to build already half done in a branch another agent opened twenty minutes ago?

You can keep answering those yourself. Once the runs overlap, you are writing software and running a standup for processes at the same time.

A shared record takes that job over. Ownership, status and changed requirements become things an agent looks up, instead of facts you rebuild from separate sessions.

Two kinds of context, and why the handoff only covers one

The simplest way to orchestrate agents is to pass output forward. Step one runs. Step two gets what step one printed. The chain continues.

The approach is useful and cheap to build. But each handoff contains only what the previous process printed. A chain can move work forward without any agent getting the same view of the project.

Terminal output tells you what happened inside one process. It is a transcript. It cannot tell you what is currently true about the project, because most of that was never printed there.

A requirement got dropped last week. A ticket is blocked, and the reason sits somewhere else. Somebody agreed on Tuesday to write a test case. None of it shows up in the output of the run you just finished.

So there are two kinds of context:

• What just happened. Short-lived, tied to one process, useful to the very next step. Passing it forward is cheap and worth doing.
• What is true about the project. Goals, tickets, requirements, test cases, dependencies, decisions. This outlives every run and matters to every agent, not just the next one.

The handoff covers the first kind for free. For the second kind, somebody has to write it down where every agent can read it. Otherwise it stays in whichever session produced it and goes away when that session ends.

Why the shared record needs a standard door

Once the project has a record like that, every agent needs a way in. You could hand each one a file to read. That holds until two of them write at the same time. It also holds only until you switch agent CLI and find out your invented convention did not come along.

The Model Context Protocol fills that gap. MCP gives a tool one standard way to expose what it can do to any agent that speaks the protocol. No agent needs its own custom integration.

An MCP server for AI agents is a process that offers those capabilities. Here is what you can read. Here is what you can change.

For coordination the useful part is simple: every compatible agent reaches the same record. You can swap the CLI that runs the work without moving that record anywhere.

What this looks like in practice

AuricIDE ships an MCP server called auric-pm that does this job. It exposes the project's goals, tickets, tasks, requirements, test cases, dependencies and history as tools any connected agent can call.

That moves where an agent goes to find out what is true. It reads the shared record instead of guessing from clues another process left in its output. An agent lists the open tickets, does the work, updates the ticket. The next agent, maybe a different CLI entirely, reads that same ticket.

AuricIDE's setup makes two wider coordination choices visible:

• Where does coordination run? auric-pm runs as a local child process. No account, no hosted service, no network hop. The project state stays next to the code, and the trade-off is that one checkout owns the record.
• What gets passed between steps? Chained steps still hand forward the previous step's cleaned terminal output. The shared record holds the project context that has to survive past one run.

The part nobody puts in the demo

Shared state only works if agents actually write to it. That turns out to be the hard part.

An agent can do excellent work and record none of it. To the rest of the fleet, it did nothing. The next agent sees an untouched ticket and a stale requirement, and believes both. You now have a coordination system that is confidently wrong. That is worse than having none, because you trusted it.

The writes cost something too. One shared record means writes have to be serialised, so you want agents updating the state at points that matter, when a step actually finishes. If they log every small action instead, the decisions and the handoffs get buried in noise.

None of this is a flaw in the tooling. A demo shows you agents reading the same state. Running them for a while shows you whether that state is still complete and current after several agents have been changing it.

What to look for in agent tooling

Once several agents share a repository, picking the model answers only part of the problem. You still need to know who owns what, what changed, and which state the next agent should trust.

• Is there a record of the project that lasts, and can every agent reach it? If the only coordination is in chat history, each later agent depends on being handed the right transcript.
• Does the tooling assume one vendor? Agent CLIs are moving fast. A coordinator tied to one of them turns a later switch into a migration of your project state.
• Can you tell which agent needs you? Run several agents and some of them are fine while one is stuck. You want to find that one, not scroll through a wall of panes.
• Where is the coordination state stored, and who can read it? Requirements, decisions and project history can be as sensitive as the code they describe.

One agent gets better when you write better prompts. Several agents need something duller than that: a record of what has been claimed, changed, blocked and finished that everyone can trust. So far that is the part that holds up.