Dev note ·
New tools for your AI agent, without waiting on a BacklogZero release
Install a Provider on your appliance and the agent sees new tools. Same MCP connection, no core fork, no extra server.
Sprint 103 lets your appliance grow its tool catalog
- MCP
- PROVIDERS
This sprint
If you use BacklogZero with Cursor or Claude Desktop, the AI does not talk to Jira, GitHub, or Ansible Automation Platform through a pile of one-off scripts. It talks through one MCP connection, and that connection exposes a catalog of named tools the agent can call.
Until now, those tools mostly came from what shipped inside BacklogZero itself. This sprint starts to change that: you can install an extension package onto your appliance, and the agent sees new tools, without us merging a PR into core, and without you forking the product.
What moved
A Provider is a named bundle of related agent tools for one area of your stack. Built-ins look like this:
| Provider | What it’s for | Example tools the agent gets |
|---|---|---|
| ITSM | Tickets / backlog | Read and transition Jira or ServiceNow work |
| GitHub | Playbooks in git | Check, save, push playbook content |
| Automation | AAP | Create or resolve job templates; gated job launch |
| Core | Appliance health & RAG | Health, readiness, retrieval rebuild |
Each tool the agent sees in MCP is a capability: a stable name, an input schema, and a risk level. A Provider owns a set of those capabilities. Skills (guided workflows) and Policies (gates like “launch needs confirm”) sit on top of capability ids; they do not hard-code Provider internals.
| Before | After |
|---|---|
| New tools meant a core change or a wait | Install a Provider onto your appliance |
| Skills compose existing capabilities | Still true — they still cannot introduce capabilities |
| Policies gate existing capabilities | Still true — same ids, new Providers included |
When we say “install a Provider,” we mean: add a new group of tools to the same MCP catalog your IDE already uses, not standing up a second MCP server, and not teaching the agent a new protocol.
You describe the Provider in a small manifest.yaml, install it (authenticated) onto the appliance, and those capabilities show up in Configuration → MCP Connect and on HTTP /mcp. Uninstall when you are done (builtins are untouched; install/uninstall is audited).
Still open
On purpose, this slice does not add:
- A public Marketplace to browse other people’s packages
- A polished SDK for authoring integrations
- Slack (or similar) as a first-class product Provider
Org-local install/persist first; share and trust later. A Marketplace before installables is a storefront with an empty warehouse.
For customers
- In the IDE: new tools appear on the same BacklogZero MCP connection: same auth, same Connect panel, same Skill/Policy model once those capabilities exist. You are not juggling another MCP server or another token scheme.
- For operators / integrators: trial or land org-specific capabilities on your deployment without waiting for our release train, and without carrying a private fork of builtins.
- For the product: Skills and Policies keep working the same way. They still bind to capability ids. Extending the platform means adding Providers, not rewriting every workflow.
BacklogZero stays one AI interface; Providers are how that interface grows.
Signed-in tour: UI features (Configuration → MCP Connect). PAT and transport: MCP quickstart.
Try it (about five minutes)
Goal: install a tiny Provider, see its tools in the catalog, call one, then uninstall — without editing BacklogZero core. Sign in; mint a PAT from Configuration → MCP Connect.
1. Install a sample Provider
Post a package description to the authenticated install API (lab fixture sample.echo, or a manifest / source_path on the appliance). Builtins are not modified. Anonymous install returns 401.
2. See it in Connect
Refresh Configuration → MCP Connect. Sample Echo Provider should appear with the new capabilities, beside Core / ITSM / GitHub / Automation.
3. Call a new tool
On the same HTTP /mcp connection (same token), ask the agent to list tools or call sample_echo_ping. It should be on the same BacklogZero MCP connection, not a second server.
4. Uninstall
Uninstall sample.echo. Core / ITSM / GitHub / Automation stay. Install and uninstall are audited.
Available to customers
Included for current subscribers running the latest bundle. After you install a Provider, restart the IDE MCP process so the new tools appear.