
Workspace for Humans + AI
Ambiguous is the workspace for human-AI collaboration. 17 productivity apps rebuilt from scratch to make work flow across Docs, Mail, Chat, Sheets, CRM, Calendar, and more.
Example path →
https://app.ambiguous.ai/mcpAmbiguous Workspace: one MCP server covering a whole workspace — mail, calendar, docs, sheets, slides, tasks, CRM, drive, chat, wiki and admin. Creating or reading a document offers an editable view in hosts that support MCP Apps; resources/read serves that view. The host mounts it separately from the JSON tool result, so JSON alone says nothing about whether the view rendered. Give the document link, and do not claim the view is absent or failed unless the host reports that failure. Every tool is one REST API operation and its name is that operation's operationId (, , ); the input schema flattens the operation's path, query, header and body fields into a single object. The catalog holds hundreds of tools, so call tools/list and search it for the operation you need instead of guessing a name. Use canonical tools for new work; older names may remain callable as compatibility aliases. App-only entries support the embedded editor. initialize and tools/list are public, and so are two kinds of tools/call: creating a doc, spreadsheet, presentation or canvas without an account (, , , ), which returns the new item's link and a one-time claim_key; and reading, commenting on or editing an item whose link lets people who aren't signed in do so. Keep a claim_key and hand it to the person you are working for: after signing in they call with it and the item moves into their workspace with them as owner. Every other tools/call needs a credential, either an Authorization: Bearer ak_... API key or OAuth 2.1, which MCP clients negotiate automatically from the 401 challenge. A signed-in call acts as the authenticated identity inside its own workspace and is bounded by that identity's role and key scopes; a signed-out call gets exactly the role the item's link grants. request_context: Describe why this request is being made and how it supports the user’s overall goal. This explanation is used for analytics to understand how this request is intended to accomplish that goal. Provide 20–30 words in third person, without using “we,” “I,” or “you.” Do not include credentials, secrets, or personal information. Example: “Reviewing upcoming calendar events to identify scheduling conflicts and prepare a weekly availability summary that helps the team coordinate its meetings.” reference_resource_id: If available, provide the ID of the email, chat message, comment, task, document, file, or other accessible Ambiguous resource where the user requested this work. These metadata fields are removed before the operation executes; existing business context fields retain their meaning. Client metadata and context confer no authority. Give feedback through in your own words; no category or outcome report is required. A successful tool call alone does not prove job completion. Prompts, logging and completions are not supported. MCP Events exposes the existing notification event types through events/list and events/subscribe. Events come from the connected identity's inbox, like notifications watch, and do not mark work read. Before acting on an event, call with its notification_id and act only when was_unread is true.
Resource discovery and access: Search and list results include only items you can open. If a search or list is empty, or a resource read returns 404, explain that an empty result or a 404 does not establish whether an item exists; advise asking your manager or the resource owner for access. Your manager's access does not grant you access. Do not send an automatic request to your manager or claim that a hidden item exists.
None in the store listings or on the server