Clientell MCP documentation

Three parts, and they behave differently.

An MCP server is a service that gives an AI client a fixed set of tools it can call on your behalf. Ours runs on Clientell’s infrastructure, not your machine: nothing is downloaded, no process runs locally, and removing it is one command. Almost every question about the product resolves to which of these three parts you are talking about.

Connector tools are reachable directly over MCP. For Salesforce and Slack, your client invokes them as ordinary MCP tools — there is no separate agent-only surface you have to go through to reach them.

What this does, and what it does not do.

The right-hand column is not a list of missing features. Each line is a deliberate design decision, and several of them are the reason the left-hand column can be trusted.

Map, not mirror.

The Context Graph is an index of your org’s structure: which components exist and which reference which. It is what lets a client name the flows that would break before you make a change, rather than guessing your schema.

Objects, fields, flows, Apex, validation rules, profiles and permission sets, plus the references between them. Structural questions — which flow writes to a field, which profiles can edit it, what breaks if it is deleted — are answered from this index alone, without reading a single record.

They do not, from our side. A tool drafts a change plan and checks it against the graph’s dependencies. You run the resulting sf commands yourself, on your machine, under your own credentials and your own permissions.

Refreshed on demand, not continuously.

This determines how much you should trust an answer about something that changed this morning, so it is stated on its own rather than folded into a footnote.

Graph content is refreshed on demand, not through continuous background ingestion. Between refreshes, it can lag behind the connected source systems. Salesforce live-record lookups are separate from the metadata index — they run on demand through your own authenticated Salesforce CLI session, and that live record data is not copied or stored by Clientell.

Where the boundary actually is.

Read this section before you connect a production org. The isolation guarantee and its limit are stated together because either one on its own is misleading.

Private, org, and shared graph scopes use separate graph destinations. Workspace-level isolation prevents access across workspaces. Within a workspace, anyone with workspace access can query the shared graph. These queries do not enforce each person’s individual Salesforce record-level or field-level permissions. Treat information in the shared graph as accessible to everyone with workspace access, and include only information appropriate for that audience.

Slack includes write-capable tools. A direct MCP invocation can execute a write action immediately, without a separate human-approval step enforced by the MCP layer. Any confirmation behavior comes from your MCP client’s own tool-approval settings (check Claude Code, Cursor, or your client’s docs), not from a Clientell-side guarantee. Salesforce record changes follow a different workflow: the agent drafts a change plan, and you run the sf CLI commands yourself under your own Salesforce credentials.

Stored credentials are encrypted using AES-256-GCM, with a fresh nonce for each storage write. Salesforce record access is not among them — records are read and changed through your own CLI session on your own machine, which Clientell never sees. What is held on the Salesforce side is the token for the metadata-indexing connection, scoped narrowly: it cannot read your customer records.

One verified, the rest compatible.

This is a standard Streamable HTTP MCP server exposing tools and instructions, with bearer auth. That is the surface every major MCP client implements, so it should register the same way using their own add-server syntax.

Clients not named here are not excluded. Any client implementing Streamable HTTP MCP with bearer auth can connect; this list is what we have looked at, not an allowlist.

Three stages.

Setup is self-serve. You connect your systems in the Clientell app, the first index is built, and then you register the server with your MCP client.

1. 01

   Connect

   Sign in and authorise the connectors you want through OAuth. Salesforce is the one that matters first.

2. 02

   Build the graph

   The first index of your org is built. This is the slow one, and it runs once before anything can be queried.

3. 03

   Query

   Register the server in your MCP client and ask a question in plain language. The client picks the tools.

claude --version

sf --version

sf org list

claude mcp add-json clientell '{
  "type": "http",
  "url": "https://mcp.clientell.ai/mcp",
  "headers": { "Authorization": "Bearer <YOUR_TOKEN>" },
  "timeout": 180000
}' --scope user

claude mcp add --transport http clientell https://mcp.clientell.ai/mcp \
  --header "Authorization: Bearer <YOUR_TOKEN>" \
  --scope user

The same server entry, in each client’s own configuration format. We have not run these installs ourselves — see Supported clients. If one of them needs a different shape than what is below, that is worth telling us about.

{
  "mcpServers": {
    "clientell": {
      "type": "http",
      "url": "https://mcp.clientell.ai/mcp",
      "headers": { "Authorization": "Bearer <YOUR_TOKEN>" }
    }
  }
}

[mcp_servers.clientell]
url = "https://mcp.clientell.ai/mcp"
http_headers = { Authorization = "Bearer <YOUR_TOKEN>" }

{
  "mcpServers": {
    "clientell": {
      "url": "https://mcp.clientell.ai/mcp",
      "headers": { "Authorization": "Bearer <YOUR_TOKEN>" }
    }
  }
}

{
  "servers": {
    "clientell": {
      "type": "http",
      "url": "https://mcp.clientell.ai/mcp",
      "headers": { "Authorization": "Bearer <YOUR_TOKEN>" }
    }
  }
}

"Added" and "working" are two different things.

Registering the server saved a configuration file. This is where the token gets used and the hostname gets resolved for the first time.

The fast check

Looks at one server, so it returns quickly.

claude mcp get clientell

The full check

Health-checks every MCP server you have configured, so it can take 30–60 seconds — longer if one of your other servers is hung.

claude mcp list

Every status this can report

On older Windows consoles the marks render as √ and × instead of ✔ and ✘. Same meanings.

Inside a session

Start Claude Code and type /mcp. You will see clientell listed with its tools.

Ask it something you would otherwise open six tabs for.

Open your client in any directory and ask a question the way you would ask a colleague. You do not call the tools by name; the client picks them.

• What writes to Opportunity.Amount?Flows, Apex, validation rules and processes that touch one field — the question that usually means reading four setup screens.
• What breaks if I delete Account.Custom_Segment__c?Every reference to a field, before you find them one deploy error at a time.
• Show me every flow on Case that fires after save.Ordering and overlap on one object, in one list.
• Which profiles can edit Contact.Email?Field-level security resolved across profiles and permission sets.

A first question against a cold graph can take a while. If it runs past about two minutes, Claude Code moves it to a background task and tells you so — it has not hung. If an answer comes back marked as truncated, it is incomplete; narrow the question and ask again rather than trusting the count.

The failure that returns an answer instead of an error.

Most admins are authenticated to more than one org. If the client answers about the wrong one, nothing errors — you just get a confident answer about your sandbox.

What is connected, and how current it is.

A connector is a source system the graph indexes. Each one below carries its real status. Anything under Planned has no ingestion pipeline, so this page publishes no access level and no capability for it.

Connector tools are invoked directly over MCP. For Salesforce and Slack, your client calls them as ordinary MCP tools with no separate agent surface in between.

Seven tools do the Salesforce work.

These are the context and planning tools for Salesforce work: they answer questions about the org and draft change plans, and you run the resulting sf commands yourself. Running /mcp in your client will show more than these — setup and account plumbing, listed underneath, plus the connector tools described in Connectors.

• search_salesforce_metadataAnswers structural questions about the org — objects, fields, flows, rules, what depends on what, and who can edit it. Curated audit sections come back from here too.
• get_salesforce_best_practicesFetches the vetted guidance for an admin task — building a Flow, writing a validation rule, loading data — before you do it.
• build_or_fix_salesforce_flowDrafts a new Flow from a plain-language description, or diagnoses one that errors at runtime and proposes a fix. It never deploys — you get a plan, and you run it.
• search_salesforce_docsLooks something up in Salesforce's own published documentation, and cites the guide it came from.
• generate_salesforce_org_reportRenders an impact, audit or access report and hands back the document itself.
• search_work_contextFinds the email, Slack or Jira thread a change was asked for in — the context that lives outside Salesforce.
• merge_duplicate_recordsFinds duplicate Accounts, Contacts or Leads and builds a merge plan, checking every Id against the org's own answer first. It plans and it refuses — it never merges. You run the merge.

Registered and visible in /mcp, but they do not answer questions about your org. Listed here so an unfamiliar name in that panel is not a surprise.

• clientell_onboarding_statusReports where your workspace is in setup — what is connected and whether an index has been built.
• clientell_set_active_orgSets which Salesforce org the session is working against. See Picking the right org.
• clientell_billing_statusReports the billing state of your workspace.
• clientell_delete_my_dataDeletes the data held for you. See Uninstall and data deletion.
• record_work_contextWrites an entry to memory. This is the explicit write described in Memory — nothing is stored without a call like this one.

One person, several identifiers.

The same person is a User record in Salesforce, a member ID in Slack and an account ID in Jira. Clientell can associate identities belonging to the same person across connected systems.

What it remembers, and for how long.

Memory is a set of entries that persist between conversations. An entry is stored only when you or the model explicitly writes one, through record_work_context.

1. 01

   Written

   A fact enters memory only when you or the model explicitly writes it. Nothing is inferred from your activity and stored on its own.

2. 02

   Corrected

   Writing a correction supersedes the earlier value. The earlier version is retained as a version rather than overwritten in place.

3. 03

   Versioned

   Each write is a version, so what the model believed at a point in time stays inspectable rather than being flattened into the latest value.

4. 04

   Expired

   Entries carry a time-based expiry. Once past it, an entry stops being returned to the model.

Find what you are seeing, not what is wrong.

Before anything else, ask the network a direct question. This tells you whether the address is reachable at all, which splits the problem in half.

Two separate things.

Removing the server from your client and deleting the data held for you are different actions. Doing the first does not do the second.

claude mcp remove clientell -s user

Ask your client to call clientell_delete_my_data. This is the tool that deletes the data held for you, and it is separate from removing the server — a client with the server removed still has a workspace behind it.

Short answers to the questions this page gets asked.

Each answer matches the section that owns the subject. Where a section states a limit, the answer here restates the limit.

Where to go next.

• Clientell MCPThe product page: what the Context Graph is, the benchmark, and how it compares to other hosted Salesforce MCP servers.
• AI Context LayerThe layer underneath this server. The same graph, with three other ways into it.
• Compared to Salesforce's hosted MCPWhere the two servers differ, and why you can run both at once.
• Contact usFor anything this page does not answer, including deployment-side failures marked as ours to fix.

Changes to this document.

Material changes to what this page claims. Wording fixes and typography are not listed.

• 21 Sep 2026

  First published. Absorbs the install documentation, which now redirects here. Adds the connector reference, the security and isolation model, identity resolution, memory, and the boundary ledger.

Where this page states a capability, it describes what the software does. It makes no claims about time saved, teams using it, or results you should expect. Connectors without a shipped ingestion pipeline are listed as planned and carry no capability claim.