Week of August 24, 2026
Capability changes you can review and undo
Capability editing gained a more complete review path this week: preview a proposal, decide whether to apply it, and restore a deleted Capability with Undo. The MCP work covered tool naming, access renewal and a broader set of planning tools. Some of that tool expansion is still limited to staging or disabled by default.
In this edition
Review a Capability change before applying it
Capability proposals now have a native preview and review flow. Validation and conflict handling follow consistent rules, while the graph and proposal tools retain their app-owned contracts and human approval requirements.
Read moreRead less
- Preview proposals, then approve or reject them in Outcomet.
- Restore retired Capabilities with Delete Undo.
- Get accurate feedback when a map link or proposal action fails.
- Preserve sibling order when reparenting without an explicit position.
- Start graph-based Capability changes as proposals that require approval.
Finish the MCP naming transition
Legacy names remained as compatibility aliases during the week's overlap window. The duplicate legacy names were then removed in favor of the canonical resource-first catalog. Contact and Company tool discovery was also aligned with the deployed write surface.
Read moreRead less
- Canonical MCP names replace duplicate legacy aliases after the compatibility overlap.
- Contact and Company write discovery matches the deployed surface.
- Contact updates use the payload key
id.
Bring Delivery and planning tools into staging
Connected-agent tooling now covers more Work Item and Story operations, alongside a proposal path into human review. This part of the work remains limited: production enablement is still gated.
Read moreRead less
- Added
work_item_searchandwork_item_get, disabled by default and verified against linked staging. - Added Story search, detail and source tools.
- Added five typed planning proposal tools and an app-owned human review inbox in linked staging.
Production remains untouched for this tool expansion.
Keep MCP access working through restarts
Signed OAuth access tokens now survive server restarts and deployments. Refresh handling also has clearer bounds when a response is lost or several requests overlap.
Read moreRead less
- A 60-second replay grace window supports up to five concurrent replays; capacity resets for later windows.
- A lost refresh response can be recovered within that window, using one replay slot. Identical token re-serving is not promised.
- Access-token signing requires its dedicated secret; the app handoff secret can no longer mint or verify these tokens.
- Streamable HTTP uses
POST /mcp, while legacy SSE stays onGET /sse. - By default,
GET /mcpreturns 405 withAllow: POST, DELETE;DELETE /mcpreturns a stateless 204 acknowledgement.
What this means for you this week
- Inspect a Capability proposal before deciding to apply it, and use Undo to restore a deleted Capability.
- Keep existing sibling order during reparenting and get useful feedback when a linking or proposal action fails.
- Use canonical MCP tool names as the legacy duplicates are retired.
- Keep signed MCP access tokens through server restarts, with bounded recovery for lost refresh responses.
The new Work Item, Story and planning tools remain subject to their staging and default-off limits.