Workspace MCP tools

Read surface#

• Business profile, operational readiness and runtime state.
• Follow-ups and central business memory.
• Business-bound searches for people, companies, leads, prospects, opportunities, conversations, calls, cases, onboarding and Knowledge.
• The sheet and business for domain searches are fixed server-side; neither is an arbitrary caller-controlled query target.

Write surface#

• Update supported Business Setup profile fields.
• Set Email, Phone, SMS or WhatsApp requirement state.
• Assign supported business channel endpoints.
• Set autonomy policy within the workspace ceiling.
• Start or pause runtime only when Owner/workspace-admin authorization permits it.
• Add or archive central business memory.

Authorization chain#

OAuth user
  -> live workspace role
  -> selected business
  -> OAuth scope
  -> active business check
  -> canonical domain service
  -> audit/result

Protected calls re-check business availability at execution time. A stale token cannot make an inactive or inaccessible business reachable.

Customer operations without an authority shortcut#

The marketplace write set covers ordinary relationship work rather than third-party communication: create or match a new person when the identity is safe for this business, schedule or close a follow-up, open or resolve a support case, open or move an unpriced opportunity, and ask to advance a relationship stage. These calls run through data_workspace and its owning services with the actor marked as Connect. The actor choice is load-bearing: a model call is not re-labelled as a human click merely because the OAuth user is an administrator.

That means existing sales and lifecycle approval rules still decide consequential transitions. A requested stage can return held rather than moved. A deal can be opened without a model inventing its price or probability. Completing a follow-up records that the obligation is done; it does not pretend an email was sent or a phone call occurred. The result returned by the tool is the record state Connect actually stored.

Identity and sibling-business protection#

A workspace can contain several businesses and can also know one human across more than one of them. The normal product has human workflows that can deliberately share or adopt that relationship. A single-business MCP grant is narrower. If a supplied email or phone already resolves to a Person outside the authorized business, the create-person tool refuses instead of attaching that Person to the current business. A legacy email Contact outside the business is refused for the same reason.

What success evidence looks like#

Configuration writes already use a persist, read-back, compare sequence and return audit evidence. Customer-operation writes return the row after the canonical Data Workspace has re-read it inside the same business reach. A client should report a held, refused, conflict or verification failure exactly as returned. Retrying a failed state transition as though transport had failed can turn an explicit safety decision into repeated pressure on the same boundary.

• Use read tools first when the requested write depends on current state.
• Use the smallest matching tool instead of reconstructing a generic data editor.
• Keep the business implicit in authorization; never ask a model to copy an internal id between businesses.
• Treat missing records as absent within this business, not as evidence that they do not exist anywhere in the workspace.

Questions#

Related#

• Authenticating to the MCP server
• The Connect MCP server
• What Connect may do
• Security and isolation