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.
Subscribe for updates
Get an email whenever we publish new guides and blog posts. Unsubscribe anytime.
By subscribing you agree we may email you about Velocity and related Level Up Labs updates. We store your address in the same lead sheet as our contact form.