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 before normalization, so the data your team and agents see stays clean. Admins manage them under Settings, Data, Data Filters (or via the API). What you can filter on:

  • Time keep only the last N months, or only interactions on or after a date.
  • CRM match drop records not tied to a CRM account.
  • Sender domain drop everything from a domain (e.g. internal or no-reply domains).
  • Specific email addresses drop individual people without excluding their whole domain, e.g. a few contacts at an investor or partner domain you do not want in your data.
  • Call length / purpose drop calls under a set length, or keep only certain conversation purposes.

  Add a rule with "Add rule," pick the type, fill in the values (domains and emails are entered as removable chips), and save. Rules apply going forward and re-clean existing data on the next sync. Data Filters are a console/admin task, so there is no Data Filters tool on MCP. 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-scope rules (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 / Write grant ("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 every surface. 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.