Docs
Using your workspace

Settings

Everything that configures a workspace lives under Settings, grouped into Workspace, Data, People & Access, and Developer. Here's what each page does and where there's an equivalent over the REST API. Settings is a console/admin surface, not an agent one — managing a workspace is a human task, so there is no Settings tool over MCP. (The one piece an agent touches, your shared Context, has its own context tool — see below.)

Workspace

  • General — the workspace name and avatar. Admin only. API: PATCH /workspaces/:id (the workspaces.update operation).
  • Apps — which top-level surfaces this workspace has (Home, Data, Knowledge Base, Needs review). A tenant-level on/off, distinct from per-member access. Saved via the self-config PATCH; no MCP equivalent (a tenant-wide entitlement, not an agent action).
  • Context— the workspace’s long-term memory: audience, positioning, competitive intel, goals. Amdahl reads and writes it as it learns. This is the one settings page an agent reaches, and it has its own dedicated tool rather than a general settings one. API + MCP: the context tool / context.entries_* operations (list / get / create / update / delete), plus context.summary for the company profile.

Data

  • Data Filters — rules that exclude noise (internal domains, test records) before normalization. API: /api/platform/v1/console/data-filters.
  • CRM Mappings— map your CRM’s deal stages onto a standard funnel so pipeline questions work across tools. API: /api/platform/v1/console/crm-mappings.
  • Data Access — per-member and per-role data-scoperules (company / source / record-type / time): “this person sees only these accounts.” Enforced on every surface — app, API, and MCP — because every read routes through the same operations. API: the console grants + roles endpoints.

People & Access

  • People— the member roster (add / remove / role) plus the workspace domains & self-join card. See Manage settings for the full walkthrough.
  • Roles & Access — named roles with a per-surface Hidden / Read / Writegrant (“which consoles can you open”), and a per-member override. Admin only. API: the console roles + grants endpoints. Not on MCP — access management is a console/admin task, not an agent action.

Developer

Mint and revoke API keys, and connect a client over MCP or the REST API. See Using the API and Using MCP.

Danger

Leave a workspace, transfer ownership, or delete a workspace. These map to the workspaces.leave / transfer_ownership / delete operations (owner-gated where it matters). They are deliberately NOT on the MCP surface — tenant lifecycle over an agent tool would be a confused-deputy risk.

One access model, everywhere

The point of Data Access + Roles is that the rules you set here apply on everysurface. An agent connected over MCP, a script using the REST API, and a teammate in the app all see exactly the data their grants allow — there is no separate “API bypass.” Default is full access until you set a policy.