Confirmations and follow-up questions

​

Overview

Atlas can ask for a small decision before your assistant continues. These requests make answers more trustworthy, prevent accidental workspace changes, and keep sensitive account actions on Atlas-owned browser pages. You may see a follow-up question when Atlas needs to:

• Clarify an ambiguous search, place, issue area, guided starter, or research run.
• Confirm a workspace action such as saving actors, creating a coverage target, watching a resource, or spending a research run.
• Ask consent before opening Atlas account settings in your browser.

If your MCP client does not support a particular interaction, Atlas falls back to the safest available behavior. Read-only requests continue when they can. Budgeted or workspace-writing actions do not proceed without confirmation.

​

In-client questions

Some follow-up questions appear inside your MCP client. Atlas uses them for non-sensitive choices such as: Atlas treats decline and cancel as normal outcomes. Declining or canceling a workspace action means nothing is created. Declining optional research context keeps the request usable with the information already provided.

​

Browser handoffs

Some actions happen outside the MCP client on an Atlas-owned web page. The shipped browser handoffs open Atlas account settings for billing and API key management. Your client should show the Atlas URL and ask before opening it. The URL contains an opaque mcpElicitationId; it does not contain payment data, credentials, user identity, workspace identity, or submitted form content. Some API-key setup requests are blocking: Atlas tells the MCP client that a browser handoff is required before the agent can continue. After you complete the account-page handoff, the agent can retry the request. Atlas does not ask for API keys, passwords, access tokens, payment details, or other credentials through MCP forms. Those actions stay on Atlas-owned browser pages. After you open Atlas in the browser, Atlas verifies that the signed-in browser session matches the MCP user and workspace that started the request. If the identity does not match, the completion is rejected.

​

What gets logged

Atlas records privacy-safe lifecycle events so clients and operators can understand what happened:

• requested
• accepted
• declined
• canceled
• unsupported client fallback
• completed URL flow
• expired browser handoff
• browser sign-in mismatch
• unavailable completion notification

These logs are meant to be useful for support and client troubleshooting. They can show that a request was shown, accepted, declined, canceled, unsupported, or completed, and they can explain why a browser handoff did not finish. They do not include submitted form content, raw prompts, private notes, credentials, payment data, browser session contents, or session replay. Workspace admins can also see aggregate integration activity. That activity shows whether the workspace is using API or MCP access, not the private content of the session. See Workspace integration activity.

​

Troubleshooting

The client did not show a form.
Your client may not support in-client follow-up questions. Atlas will keep read-only requests on the safest normal path and will stop state-changing actions that need confirmation. The client did not open a browser.
Make sure the client supports URL-mode elicitation and can open HTTPS URLs in your default browser. You can always open Atlas directly and manage billing from account settings. A workspace action did not happen.
Check whether the confirmation was declined, canceled, or unsupported. Atlas does not infer consent for saved lists, coverage targets, watches, or research runs. A URL flow did not complete.
Sign in to Atlas with the same account and workspace that started the MCP request. Atlas rejects unknown, expired, already completed, or identity-mismatched request IDs.

​

Related