Asks

An ask is anything you are waiting on Scope3 for: help with something broken, a product capability, supply you want to buy, an integration, or a commercial question. Every ask has one type:

​

One tool to file or answer an ask

Agents on /mcp/v3 use save_ask for every type. A new ask carries a short title; support adds detail, supply adds subject and channel, and integration adds subject. If the type is unclear, omit it rather than delaying the request — Interchange routes it. save_ask returns an opaque askId when the ask can be addressed later. Pass that id back with requesterState to record your answer:

• confirmed_resolved — the requested outcome happened.
• accepted — you acknowledge an answer that closed the ask without a change.
• still_blocked — the release or answer did not unblock you.
• withdrawn — you no longer want the ask pursued.

Your answer does not overwrite Scope3’s status. The two remain side by side, so “we marked it resolved” and “you are still blocked” can both be true.

​

Read your asks

Use search({ kind: "ask" }) from either a buyer or seller account. You can narrow by type or open/closed state. Use the returned opaque id with get({ kind: "ask", id }) for one ask. The REST read remains available at GET /api/v2/asks. All reads are scoped to the authenticated account; another account’s id looks the same as a missing id.

​

When an ask is delivered

Closing an internal issue or merging a pull request does not close your ask. When work explicitly linked to your ask is verified as live in production, Interchange sends an update to your notifications feed and shows the same resolution in Your requests, the REST API, and MCP search and get. The ask remains in your recent history for 90 days. It appears as Done when Scope3 shipped a change, or Closed when Scope3 recorded an explicit no-change outcome. The resolution includes:

• the release version and date;
• what changed, or why no change was made;
• anything you should do next; and
• whether the update was delivered.

Delivery completes Scope3’s track; it does not answer for you. Tell Murph what happened, or pass the ask id and requesterState to save_ask. Use confirmed_resolved when the requested outcome happened, accepted to acknowledge a no-change answer, or still_blocked when you still need help. A disputed answer keeps the release history and your previous notes.

​

Confirmation and compatibility

Inside Murph, a customer-authored filing is staged for confirmation before it creates team-visible work. A direct authenticated /mcp/v3 save_ask call is the execution action itself; it does not create a separate Murph confirmation card. Both paths apply the same validation, redaction, authorization, routing, and account-scoping checks. list_my_requests remains as a deprecated alias through the API release that contains this change. It may be removed no earlier than the following API release, after usage review; new agents should use search and get now. The retired writers are report_issue, report_integration_need, track_my_product_ask, create_supply_request, and remove_supply_request. New Murph turns no longer receive the first three tools. POST /api/v2/supply-requests and POST /api/v2/supply-requests/remove keep working through this API release and route through save_ask. They may be removed no earlier than the following API release, after usage review; builders should replace them now.