Day 7/15 — Explore Salesforce MCP Tools & sobject-all

Yesterday Neha asked Claude about Acme Global Tech and got a sensible answer. Today her admin, Arjun, asks the question every admin should ask next: what else could Claude have done in that conversation? The connector Neha used has eleven tools, and five of them create, change or delete records. Arjun has never seen their names, and doesn't know which ones Claude runs without asking.

Today we open up the tool list of sobject-all, the Salesforce Headless 360 (now called AIforce) hosted Model Context Protocol (MCP) server you connected on Day 6, read tool definitions the way a model reads them, inspect a server with MCP Inspector, and take a read-only look at the beta Headless 360 MCP Server. By the end you will have a written tool inventory for your org and will have called each read tool once, on purpose, before we build with them on Day 8.

What sobject-all exposes

Salesforce calls platform/sobject-all "the full-capability SObject server": every standard and custom object, through eleven MCP tools. Claude's Configure screen shows display names, not ids, so both are below, with the parameters Salesforce documents.

Tool id	Display name in Claude	What it does	Parameters	Changes data?
getObjectSchema	Get Object Schema (Enhanced)	Schema "optimized for LLM consumption": an index with no parameters, detail for one object	object-name (optional)	No
soqlQuery	Query Records (SOQL)	Runs a SOQL query	query (required)	No
find	Search Across Objects (SOSL)	Runs a SOSL search, up to 2,000 records	search (required)	No
getUserInfo	Get Current User Info	The signed-in user's identity, profile, role and timezone	none	No
listRecentSobjectRecords	Get Recently Viewed Records	Recently viewed records of one type	sobject-name (required)	No
getRelatedRecords	Get Related Records	Follows a relationship from one record, for example Contacts	sobject-name, id, relationship-path (all required)	No
createSobjectRecord	Create Record	Creates a record from field-value pairs	sobject-name, body	Yes
updateSobjectRecord	Update Record	Changes fields on one record	sobject-name, id, body	Yes
updateRelatedRecord	Update Related Record	Updates a record reached through a child-to-parent relationship, up to five levels deep	sobject-name, id, relationship-path, body	Yes
deleteSobjectRecord	Delete Record	Deletes a record into the Recycle Bin	read its schema in Inspector	Yes
deleteRelatedRecord	Delete Related Record	Deletes a record reached through a relationship	read its schema in Inspector	Yes

In a Developer Edition org on 2026-10-04, claude.ai grouped them as Read-only tools (the first six) and Write/delete tools (the last five), and every one defaulted to Needs approval.

The descriptions carry rules aimed at the model. soqlQuery says: "Always include a WHERE clause to filter results and a LIMIT clause to control result size." createSobjectRecord says "Call getObjectSchema first to understand required fields," and updateSobjectRecord says "Only include fields you want to change." The delete tools carry the sharpest wording. deleteSobjectRecord says: "Confirm with the user before deleting. Deleted records go to the Recycle Bin and can be recovered in the Salesforce UI for up to 15 days (no undelete tool is available through MCP)." deleteRelatedRecord warns that "deleting a master record in a master-detail relationship also deletes all of its detail records, including the child record you started from." Read that twice before you leave either tool enabled.

Two details are easy to miss. getObjectSchema "Includes admin-authored guidance about data quality and business definitions alongside the standard schema," so what your admins write there becomes context the model reads. And Salesforce's wiki mentions MCP prompt templates for sobject-all, such as an Account Review Briefing. Don't plan around them: on 2026-10-04 no Salesforce prompt templates appeared anywhere in claude.ai, the + menu included.

The smaller servers

Standard servers' tool sets "cannot be modified." What you can choose is the server, and three smaller SObject servers are subsets of sobject-all:

Server	Tools	What it leaves out
platform/sobject-reads	6: the six read tools	Every write. "No data changes are possible through this server."
platform/sobject-mutations	6: getObjectSchema, soqlQuery, find and the three create/update tools	Deletes, and three read tools
platform/sobject-deletes	5: getObjectSchema, soqlQuery, find and the two delete tools	Creates, updates, and the same three read tools

Salesforce's advice for a first server is "try the platform/sobject-reads server in a sandbox. It's read-only, risk-free, and immediately useful." Match the server to the job: sobject-reads for questions and briefs, sobject-mutations for tasks and field updates (with the confirmation step from Day 9), sobject-deletes only with a person approving every call, and sobject-all for learning in a test org.

Server choice has a limit: "You cannot restrict access to a specific MCP server through the ECA configuration." Choosing sobject-reads limits what one client calls, not what a user could connect elsewhere. The user's permissions limit the damage, and they are the subject of Day 11.

Reading a tool definition

When a client connects, it asks the server for its tools with tools/list and later runs one with tools/call. Each tool definition has a name, a description, an inputSchema and optional annotations (plus an optional title and outputSchema). Claude "calls its tools when the user's request maps to a tool's described capability."

Here is roughly what the model sees for soqlQuery. I rebuilt it from Salesforce's documentation and trimmed the description, so treat it as the shape, not the exact text.

{
  "name": "soqlQuery",
  "description": "… Always include a WHERE clause to filter results and a LIMIT clause to control result size. …",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "A valid SOQL query string" }
    },
    "required": ["query"]
  }
}

The org test found one difference: Claude Code's permission prompt on 2026-10-04 showed the SOQL in an argument named q, not query. Trust the schema your server returns over any article, this one included.

Read a definition in four passes.

1. The name is what you see in every tool-call block. Names are case-sensitive and unique within a server. Clients prefix them: claude.ai showed mcp__Salesforce_sobject-all__find, so the connector's name becomes part of the id.
2. The description decides whether the model picks the tool, and carries Salesforce's usage rules. A query without a LIMIT means the model ignored an instruction.
3. The input schema is JSON Schema: required lists what the model must supply. When a call fails validation, start here.
4. The annotations describe behaviour to the client, not to Salesforce.

Annotations are hints

Salesforce's best-practice guide says MCP tools support "four boolean hints" and that "Platform tools ship with accurate annotation values." The MCP specification defines them: readOnlyHint ("the tool does not modify its environment"), destructiveHint ("the tool may perform destructive updates"), idempotentHint (repeating a call "will have no additional effect") and openWorldHint (it "may interact with an 'open world' of external entities"). When absent, a tool counts as not read-only, possibly destructive, not idempotent and open-world. Claude Code shows them as labels such as "read-only" or "destructive · open-world".

Two sentences keep annotations in their place. Salesforce: "Annotations are hints, not enforcement." The specification: clients "MUST consider tool annotations to be untrusted unless they come from trusted servers." A client can use them to decide when to ask you first, but the user's permissions, field-level security and sharing decide what a call may do. Read the values from your own server and record them in your inventory.

Inspecting the hosted server with MCP Inspector

MCP Inspector shows the raw tool list, every schema, the annotations and the protocol traffic. Salesforce names it in its troubleshooting pages: "Try the same connection/sign-in in Postman or MCP Inspector. If it works there, review your MCP client's authentication setup."

Salesforce documents no Inspector callback, so I tested Inspector 2.9.0 (the version with a Servers list and Add Servers) in a Developer Edition org on 2026-10-04. It sent redirect_uri=http://127.0.0.1:6274/oauth/callback, and Salesforce answered redirect_uri_mismatch. Registering that URI fails too: Salesforce refused to save it ("Cannot be an HTTP URL"), because plain http is allowed only for localhost. The fix is to open the Inspector at http://localhost:6274, so it uses the http://localhost:6274/oauth/callback you registered on Day 5.

Step by step (web client)

1. Check that http://localhost:6274/oauth/callback is on the Callback URL list of your Claude MCP Test app. Keep the scopes at exactly Access Salesforce hosted MCP servers (mcp_api) and Perform requests at any time (refresh_token, offline_access).
2. Run npx -y @modelcontextprotocol/inspector@latest (Node.js 22.19 or later), then open http://localhost:6274 in your browser, not 127.0.0.1.
3. Add a server with the Streamable HTTP transport and paste your sobject-reads Server URL from Setup. Start with the read-only server, not sobject-all.
4. Enter the Claude MCP Test consumer key as the client ID and leave the secret empty. (Labels differ between Inspector versions.)
5. Connect, sign in to your Developer Edition org and allow access on the same screen you saw on Day 6.
6. Open the tools list and click through each one: description, input schema, annotations.

On 2026-10-04 the server card showed Connected (2229 ms), Streamable HTTP and MCP 2025-06-18, the protocol revision it negotiated, and the six read tools with the display names and ids from the first table. Write down the revision your server negotiates; it can change.

Don't copy the access token anywhere. And each Inspector sign-in is another approval on Claude MCP Test: Salesforce allows five per user per app and revokes the oldest on the sixth, as Day 5 and Day 6 explain.

Beta: the Headless 360 MCP Server

Everything so far has been fixed, per-object tools. The Headless 360 MCP Server takes the opposite approach: "Instead of exposing thousands of features as individual tools, the server provides four tools backed by a continuously growing library of Salesforce operations." The reason: "Beyond a few dozen tools, an AI client struggles to select the right one for a given task."

The docs say four tools; Claude Code's /mcp listed five on 2026-10-04. The annotations column is what Claude Code displayed:

Tool	What it does	Parameters (documented)	Annotations shown
discover	"finds the actions your agent can take" with a "Hybrid semantic + keyword search"	query (required); limit 1–50, default 10; optional domain and resultType (endpoint or sor, a Setup Operation Recipe)	read-only
describe	"returns the full specification for an action"	id (required): an operation ID or recipe ID	read-only
dispatch	"runs the chosen action"	url and method (GET, POST, PUT, DELETE or PATCH); optional headers, body, queryParams	destructive · open-world
dispatch_readonly	"runs read-only actions" and "never changes data or configuration"	url and method (GET only); optional headers, queryParams; no body	read-only · open-world
display_widget	not used in the org test	read its schema in /mcp	none shown

Salesforce says: "Use them in this order for the best result." Discover finds a candidate, Describe fetches its contract, and a Dispatch tool runs it.

In the org test, discover returned recipes with named steps, not a flat list of operations: asked about permission sets, it found the "PermSets" recipe, with read steps such as list-permission-sets and list-assignments next to write steps that create, edit, delete, assign and unassign. describe returned a full specification: GET /services/data/v67.0/tooling/query, operationId getServicesDataV670ToolingQuery (shared by about 25 recipes), a required q, a QueryResult output, and the note "tested on a live org". dispatch_readonly then ran SELECT Id, Name, Label, IsCustom, License.Name FROM PermissionSet WHERE IsOwnedByProfile = false ORDER BY Label and got HTTP 200 with 95 permission sets: 17 custom, including Headless Assistant User, and 78 standard.

Now read those definitions the way you read soqlQuery. With sobject-all, the name tells you what a call does. With dispatch, it doesn't: the same tool can list permission sets or change them, depending on its url, method and body, and its annotation says so. Any approval of dispatch has to be based on the arguments. dispatch_readonly limits method to GET, and it is the only dispatch tool I let a model use while exploring.

Salesforce's docs describe "dozens of operations, with most focused on Setup tasks for admins", such as managing users, Apex triggers and named credentials.

The details you need to try it:

• URL: https://api.salesforce.com/platform/mcp/v1/platform/headless-360 (sandbox and scratch orgs use /v1/sandbox/platform/headless-360). Copy the exact URL from Setup.
• Prerequisites: API version 67.0 or later, an External Client App with the mcp_api scope, and an MCP client with OAuth.
• Activation: Setup → Quick Find "MCP Servers" → MCP Servers → Headless360 (H360) MCP Server → Activate. That is the label the Salesforce Servers tab showed on 2026-10-03.
• Guardrails: "If you can't do it in Salesforce, your agent can't do it through the MCP server." Salesforce also asks you to "configure your client to require your approval before it runs a tool that changes org configuration or alters or deletes data."

Hands-on: your org's tool inventory

Today's deliverable: for every tool your clients can reach, whether you want it enabled.

Step 1: see what each client has

• Claude: open the connector and click Configure. You see display names in the two groups described above, each group with its own "Needs approval" dropdown and each tool with three icons: allow, needs approval, block. Note each setting.
• Claude Code: run claude mcp list and check the status reads ✔ Connected, then ask: Using salesforce-sobject-reads, list the exact names of your tools. You should get six, each prefixed with the server name, such as mcp__salesforce-sobject-reads__soqlQuery. Local servers get mcp__<server>__; claude.ai connectors that Claude Code inherits get mcp__claude_ai_<connector>__, such as mcp__claude_ai_Salesforce_sobject-all__find.

The first time Claude Code calls a tool, it asks. On 2026-10-04 the prompt read "Tool use · salesforce-sobject-reads — SoqlQuery Tool: (MCP)", showed the query argument and the tool's description, then:

Do you want to proceed?
1. Yes
2. Yes, and don't ask again for salesforce-sobject-reads — SoqlQuery commands in <project path>
3. No

Option 2 remembers that one tool for this project folder only. The server itself is local too: claude mcp add without a scope flag stores it for the current folder only (in ~/.claude.json), so add -s user if you want it in every project.

Step 2: fill in the inventory

Copy this table into your notes, add one row per tool from the tables above, and fill in the last three columns from what you saw.

Server	Tool	Reads or writes	Client permission	Annotations seen	Keep enabled?
sobject-all	soqlQuery	Reads	Needs approval (default)
sobject-all	deleteSobjectRecord	Deletes	Needs approval (default)
headless-360	dispatch	Anything		destructive · open-world

Add rows for every other server you activated. A missing tool means you are connected to a different server than you think.

Step 3: call each read tool once

Run these in a new chat with only the Salesforce connector enabled. After each answer, expand the tool-call block and note which tool ran.

#	Prompt	Expected tool	What to check
1	Who am I signed in as in Salesforce?	getUserInfo	It is your test user, with the profile and timezone you expect
2	Using only the schema tool, list the objects you can see, then describe the Opportunity object.	getObjectSchema twice (index, then detail)	The second call passes object-name
3	List the open opportunities for Acme Global Tech with amount and close date, biggest first.	soqlQuery	The query has a WHERE and a LIMIT
4	Search Salesforce for "Sync errors" and tell me which records mention it.	find, then possibly soqlQuery	The case "Sync errors after upgrade" comes back, by search or by a fallback query
5	Show me the contacts on the Acme Global Tech account.	soqlQuery (getRelatedRecords possible)	Priya Sharma and Rahul Mehta, and the query or relationship path used
6	Which accounts have I viewed recently?	listRecentSobjectRecords	Acme Global Tech appears once you have opened it in Lightning

In the org test on 2026-10-04, Claude never chose getRelatedRecords or listRecentSobjectRecords on its own: it preferred soqlQuery for contacts and cases. That's description-matching at work, not a failure. Prompt 4 showed a real gap: find returned nothing for records created minutes earlier, probably because the search index hadn't caught up, so Claude fell back to SOQL on the case Subject (Day 8 has the details).

Step 4 (optional): a read-only look at the beta server

Activate headless-360 as above, then add it to Claude Code with the same command pattern as Day 6:

claude mcp add --transport http salesforce-headless-360 "<HEADLESS_360_SERVER_URL>" \
  --callback-port 38000 --client-id "<CLAUDE_APP_CONSUMER_KEY>"
claude    # then /mcp → salesforce-headless-360 → Authenticate

Then ask two read-only questions:

• Using salesforce-headless-360, find the operation that lists permission sets, describe it, and do not change anything.
• Now use the read-only dispatch tool to list the permission sets in this org.

In the org test, signing in ended with "Authentication successful. Connected to salesforce-headless-360." and the two questions produced the PermSets recipe, the tooling-query specification and the 95 permission sets described above. Don't approve any call to dispatch itself; the org test never used it.

What can go wrong

Symptom	Cause	Fix
Claude offers to update or delete when you only asked a question	A write-capable server for a read-only job	Connect sobject-reads, or block the write tools in Configure
Slow answers or limit errors	Unfiltered queries, or searches hitting the 2,000-record cap	Ask for named fields, a filter and a limit
Everything works for you but fails for Neha	You tested as a System Administrator	Test as a user with the profile and permission sets real users have (Day 11)
Inspector sign-in returns error=redirect_uri_mismatch	Inspector 2.9.0 opened at 127.0.0.1 sends a 127.0.0.1 callback, which Salesforce won't accept over http	Open the Inspector at http://localhost:6274
npx fails with npm error code ECOMPROMISED	A stale or locked npm cache	Run it with a fresh cache: npx --cache "$TMPDIR/npm-cache-inspector" -y @modelcontextprotocol/inspector@latest
A client that worked may fail or ask you to sign in again	A sixth approval on the same app revoked the oldest (Day 5)	Re-authenticate that client, and use fewer clients per app
Fewer tools than expected	Wrong server URL, for example sobject-mutations	Copy the URL from Setup again

Security note: the tool list is your attack surface

Anything the model can call, a sentence hidden in a record can ask it to call. Every call runs as the signed-in user, so everything that user can do is reachable. Keep write tools off clients that don't need them, treat annotations as advice, and read the arguments of any dispatch call before approving it. Day 11 turns this into a threat model.

Today's checklist

• I can name the 11 sobject-all tools and say which five change data.
• I know what sobject-reads, sobject-mutations and sobject-deletes each leave out.
• I can read a tool definition: name, description, input schema, annotations.
• I know annotations are hints, not enforcement.
• I have a tool inventory for every server my clients can reach, with a "keep enabled?" decision per tool.
• I called each read tool once and recorded which tool actually ran.
• I know the five beta Headless 360 tools and use only discover, describe and dispatch_readonly while exploring.

Frequently asked questions

How many tools does the Salesforce sobject-all MCP server have?

Eleven: six that read (getObjectSchema, soqlQuery, find, getUserInfo, listRecentSobjectRecords, getRelatedRecords) and five that create, update or delete. claude.ai shows them by display name, such as Query Records (SOQL).

What is the difference between sobject-all and sobject-reads?

sobject-reads has only the six read tools: "No data changes are possible through this server." sobject-all adds create, update and delete.

Can I remove a tool from a standard hosted MCP server?

Not on the server: standard tool sets cannot be modified. Choose a smaller server, block or require approval for tools in your client, or build a custom server (Day 12).

Do tool annotations stop an AI client from deleting records?

No. Salesforce says "Annotations are hints, not enforcement," and the MCP specification tells clients to treat them as untrusted unless the server is trusted. Permissions and your client's approval settings are what stop a delete.

Is the Headless 360 MCP Server generally available?

No. It has been a Beta Service since July 2026. The docs list four tools (Discover, Describe, Dispatch and Dispatch Read-Only); Claude Code showed a fifth, display_widget, on 2026-10-04. They front a growing library of recipes and operations, mostly Setup tasks today.

Does MCP Inspector work with Salesforce hosted MCP servers?

Yes. On 2026-10-04 Inspector 2.9.0 connected to sobject-reads over Streamable HTTP and negotiated MCP 2025-06-18. Open it at http://localhost:6274, not 127.0.0.1, and register http://localhost:6274/oauth/callback on your External Client App.

What's next

You now know every tool your client can reach and what each one needs. On Day 8 we put the read tools to work: Neha prepares for her Acme call with plain-language questions, and we look at how the model turns a question into a query, which prompts produce reliable reads, and how to check an answer before you act on it.

Sources

Verified against the sources below on September 30, 2026. Salesforce ships Headless 360 changes often: check the linked docs if a screen looks different.

1. SObject All (Salesforce Hosted MCP Servers) — the 11 tools and their parameters
2. SObject Reads
3. General Best Practices: tool annotations
4. Headless 360 MCP Server (Beta)
5. Announcing the Headless 360 MCP Server Beta
6. MCP specification 2026-07-28: Tools
7. MCP Inspector
8. Authentication Issues (Salesforce Hosted MCP Servers)