Baron

What the Baron MCP server does

The Baron MCP server lets an agent operate on development work through common capability ports instead of learning each provider's API. Its supported areas include issues, scm, ci, deploy, and notify. GitHub and Azure DevOps provide the broadest set of ports; Jira and Linear provide issues; Slack provides notifications.

Baron focuses on write operations as well as reads. An agent can create or update work items, move an item between normalized roles, create branches, open or merge pull requests, inspect CI runs, read deployments, and send notifications where the configured provider supports those actions. Provider differences remain behind the port interface.

The normalized issue roles are backlog, ready, in_progress, in_review, and done. Blocking is represented separately, so an item can remain in its actual work role while also being marked blocked. Baron records the mapping from these roles to provider-specific states, labels, or transitions in repository configuration.

How it works

Each capability port is bound to a provider independently. A project can use Azure DevOps for issues, GitHub for source control, and Slack for notifications rather than selecting one vendor for every function. When a provider lacks a capability, Baron can emulate it, degrade with a warning, or stop with an error according to policy.

Multi-step workflows are expressed as YAML recipes and executed through one call. Recipes such as task-start, task-finish, task-land, and ship can combine checks and mutations. Guards run before changes are made; for example, a task-start flow can stop if an item is already complete, assigned to another person, or unsuitable for branching. The same recipe also derives a consistent branch name from the item's type role.

The Baron MCP server exposes direct operations including baron_issue_write, baron_scm_write, baron_ci_read, baron_deploy_read, and baron_notify_send. baron_recipe_run runs a complete workflow. A provider-native escape hatch exists for cases that cannot be represented by a normalized operation.

Setup and configuration

Install the published CLI through npm and run initialization from inside the project:

npx -y @zanaat/baron-cli@latest init --provider github
npx -y @zanaat/baron-cli@latest doctor
npx -y @zanaat/baron-cli@latest run --recipe task-start

Initialization can detect the repository owner and name from the Git remote. For GitHub, it offers browser-based authentication or a fine-grained token. Credentials are written to .baron/credentials, while provider bindings and role mappings are stored in .baron/policy.json; the credentials file is intended to be gitignored.

baron doctor checks the policy against the live provider and exits with status 1 when it detects drift. The MCP server can also run in a container, and a Claude Code plugin packages the server with workflow skills.

Tools and capabilities

• Write and update issues through normalized issue operations.
• Create branches and manage pull requests through the scm port.
• Read CI runs and deployment information.
• Send notifications through the notify port.
• Execute YAML workflow recipes as a single MCP call.
• Use GitHub, Azure DevOps, Jira, Linear, and Slack according to their supported ports.

Limitations and notes

Provider coverage is not uniform. Jira and Linear currently expose the issues port, while Slack exposes notifications; the README does not list source-control, CI, or deployment ports for those providers. GitLab is described as roadmap work rather than current support. Provider-specific gaps may produce warnings or errors instead of silently succeeding, depending on policy. Setup also requires provider credentials and a configured policy before write operations can be used safely.