Baron MCP server

Baron

Let your coding agent write to your work tracker — and keep the same flow when you change trackers.

Baron is an open-source layer that turns issues, branches, PRs, CI runs, and deployments into one

normalized contract, so your agent never learns a vendor's API, states, or column names.

Docs and site: baron.zanaat.dev

The problem

AI coding agents bake one vendor's API and one team's process into prompts. The moment your issues live in Azure DevOps but your code is on GitHub, or your board columns aren't literally "To Do / Done", or you switch trackers next quarter — the prompts break, and the agent falls back to raw, vendor-specific tools. You've hardcoded vendor lock-in into the way you work.

What Baron does

Plenty of tools let an agent read your tracker. Baron is about the other direction: writing — creating work items, moving them, cutting branches, opening and merging PRs — which is where an agent does damage when it guesses a vendor's state machine wrong.

The agent speaks one abstract vocabulary in terms of roles (backlog → ready → inprogress → inreview → done; blocking is an orthogonal flag, so a blocked item keeps the role the work is actually in), and Baron translates to each provider's real API, states, and quirks. You confirm that mapping once, at baron init, and it is committed to your repo as configuration — not re-guessed by the model on every call.

Each port binds to a provider independently, so issues on Azure DevOps, scm on GitHub, and notify on Slack is a normal setup rather than a special case.

What it looks like

You:  Start work on STORE-142.

Baron  ▸ runs the task-start recipe as a single call:
  ✓ Loaded STORE-142 "Add rate limiting to the login endpoint"  (type role: task)
  ✓ Checked it: not done, has a canonical branch, not assigned to someone else
  ✓ Branched feature/STORE-142 from the repo's default branch
  ✓ Moved STORE-142 → in_progress, assigned to you
  ✓ Commented on the item: "Started work — on branch feature/STORE-142."

That same prompt on Azure DevOps sets the work item state to Active; on GitHub it applies an in-progress label — because inprogress is a role*, not a vendor state.

The checks matter as much as the actions: if the item is already done, belongs to someone else, or is a container that should never be branched, the run stops before anything is created. The branch name is derived by Baron from the item's type role, so every agent and every recipe derives the same name for the same item instead of inventing one.

Why it's different

a provider independently — so a consumer mixes providers rather than betting on one vendor spanning everything.

• Capability ports, not "a tracker." issues / scm / ci / deploy / notify, each bound to

labeled provider-native escape hatch is the explicit last resort, never the default path.

• Normalize, don't raw-proxy. New capabilities become first-class normalized ports; a clearly

Baron either emulates it (e.g. labels), degrades with a warning, or errors loudly — decided by policy, never swallowed.

• Capability gaps are never silent. When a provider lacks something (say, native issue hierarchy),

ship) are declarative YAML executed as a single call, with guards that stop a run before it mutates anything. The order lives in the recipe rather than being improvised per run.

• Workflows are recipes, not prompts. Multi-step flows (task-start, task-finish, task-land,

Shortened. The full README is on GitHub.