Skip to content

Connect Salesforce to Claude: Query Data and Customize Field Schemas

Learn how to connect Salesforce to claude using Truto. Step-by-step guide to tool calling, API quirks, and autonomous workflows.

Uday Gajavalli Uday Gajavalli · · 10 min read
Connect Salesforce to Claude: Query Data and Customize Field Schemas

If you need to connect Salesforce to Claude to automate CRM administration, execute complex SOQL queries, or dynamically alter object schemas, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's natural language tool calls and Salesforce's complex web of REST and Tooling APIs. You can either build and host this integration infrastructure yourself, or use a managed platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on connecting Salesforce to ChatGPT or explore our broader architectural overview on connecting Salesforce to AI Agents.

Giving a Large Language Model (LLM) read and write access to a sprawling enterprise ecosystem like Salesforce is a difficult engineering challenge. You have to handle OAuth 2.0 token lifecycles, map massive metadata schemas to MCP tool definitions, and deal with Salesforce's strict API governors and limits. Every time Salesforce updates an endpoint or an admin modifies a custom object, your integration risks breaking.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Salesforce, connect it natively to Claude, and execute complex data and schema workflows using natural language.

The Engineering Reality of the Salesforce API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against Salesforce's APIs is painful. You are not just integrating a standard REST interface - you are interacting with a highly complex, multi-tenant platform with distinct API surfaces for different tasks.

If you decide to build a custom MCP server for Salesforce, you own the entire API lifecycle. Here are the specific challenges you will face:

The Tooling API vs. The Data API Salesforce splits its capabilities across different APIs. Reading and writing standard records (like Accounts or Contacts) happens via the standard REST Data API. However, if you want an AI agent to create a new custom field or modify an object's schema, you must use the Tooling API. The Tooling API requires deeply nested JSON Metadata structures. For example, creating a custom picklist field requires specifying valueSet configurations, deployment statuses, and sharing models. LLMs routinely hallucinate these nested structures if you do not provide perfect, highly constrained JSON schemas in your MCP tool definitions.

SOQL Execution and Complex Pagination Salesforce Object Query Language (SOQL) is incredibly powerful, but querying it via API introduces pagination challenges. When an agent queries a large dataset, Salesforce returns a nextRecordsUrl rather than a standard offset or cursor. If you expose this raw URL concept directly to Claude, the model will often attempt to manipulate the URL string or hallucinate parameters. A production-grade MCP server must normalize this pagination model so the LLM receives simple, predictable cursors.

Strict API Limits and Rate Limiting Salesforce enforces strict concurrent API request limits, total daily request limits, and specific governor limits on the Tooling API. If an overly ambitious AI agent attempts to rapidly scan every custom object in your org or runs inefficient SOQL loops, Salesforce will respond with a 429 Too Many Requests error.

It is critical to note that Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Salesforce API returns an HTTP 429, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller (your AI agent framework or Claude client) is strictly responsible for interpreting these headers and executing its own retry and exponential backoff logic.

How to Generate a Salesforce MCP Server with Truto

Truto dynamically generates MCP tools based on active API documentation. Rather than hand-coding tool definitions for Salesforce, Truto derives them from predefined resource configurations and JSON schemas. A tool only appears in the MCP server if it has a corresponding documentation entry - this acts as a strict quality gate, ensuring the LLM only sees well-defined, curated endpoints.

Each MCP server is scoped to a single integrated account (a connected instance of Salesforce for a specific tenant) and generates a secure URL containing a cryptographic token. You can provision this server via the Truto UI or via the API.

Method 1: Creating the Server via the Truto UI

For internal automation and testing, you can spin up an MCP server directly from the dashboard.

  1. Navigate to the Integrated Accounts page in your Truto environment.
  2. Select the connected Salesforce account you want to expose to Claude.
  3. Click the MCP Servers tab.
  4. Click Create MCP Server.
  5. Select your desired configuration (name, allowed methods, tags, and expiry).
  6. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4...).

Method 2: Creating the Server via the Truto API

If you are building an application that dynamically provisions Claude environments for your users, you should generate the MCP server programmatically.

Make an authenticated POST request to the /mcp endpoint for the specific integrated account. Truto validates that the integration has tools available, generates a secure token, and returns a ready-to-use URL.

curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Salesforce Admin MCP",
    "config": {
      "methods": ["read", "write", "custom"]
    }
  }'

The response contains the secure endpoint URL you will pass to Claude:

{
  "id": "mcp_srv_987654321",
  "name": "Salesforce Admin MCP",
  "config": { "methods": ["read", "write", "custom"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

Connecting the MCP Server to Claude

Once you have the secure MCP URL, connecting it to Claude requires zero additional code. You simply register the URL as a Server-Sent Events (SSE) remote server.

Method A: Via the Claude UI

If you are using the Claude web interface or an equivalent enterprise chat UI that supports custom connectors:

  1. Open Settings and navigate to Integrations (or Connectors).
  2. Click Add MCP Server or Add custom connector.
  3. Paste the Truto MCP URL generated in the previous step.
  4. Click Add. Claude will instantly execute an MCP handshake (initialize -> tools/list) and discover all available Salesforce tools.

Method B: Via Manual Configuration File (Claude Desktop)

If you are using the Claude Desktop application locally, you can register the remote Truto URL by modifying your claude_desktop_config.json file. Since Truto provides a standard HTTP endpoint, we use the official @modelcontextprotocol/server-sse transport wrapper to bridge the local CLI to the remote REST endpoint.

Open your configuration file:

  • Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
  • Windows: %APPDATA%\Claude\claude_desktop_config.json

Add the Salesforce configuration:

{
  "mcpServers": {
    "salesforce_admin": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f6..."
      ]
    }
  }
}

Restart Claude Desktop. The model now has direct access to your Salesforce instance.

Salesforce MCP Tools in Action

When Claude connects, Truto exposes a curated set of proxy tools derived from the Salesforce integration's resource definitions. All inputs are strictly typed via auto-generated JSON schemas.

Here are the hero tools available for advanced Salesforce automation.

1. Execute SOQL Queries

Tool: list_all_salesforce_query

This tool allows the LLM to execute raw Salesforce Object Query Language (SOQL) against the org. This is the primary mechanism for fetching, filtering, and aggregating records. The model passes a complete SOQL string in the q parameter.

Usage Note: The model can execute relationship queries (e.g., SELECT Id, Account.Name FROM Contact) but must adhere to Salesforce SOQL syntax restrictions.

"Find the names and email addresses of the last 10 Contacts created in Salesforce, along with the Name of their associated Account."

2. Inspect Object Schemas

Tool: get_single_salesforce_object_describe_by_id

Before an AI agent can write data to a custom object or formulate a complex query, it needs to understand the object's schema. This tool calls the Salesforce Describe API to return full metadata, including field data types, picklist values, and relationship limits. This is particularly useful when connecting Salesforce to AI Agents to perform metadata-aware operations.

Usage Note: The agent passes the API name of the object (e.g., Account or Invoice__c) as the id.

"I need to update the Lead object. Please describe the Lead object schema and tell me exactly what the API names are for the status and rating picklist fields, and list their valid values."

3. Provision Custom Objects

Tool: create_a_salesforce_custom_object

This tool leverages the Salesforce Tooling API to create brand new custom objects directly from a natural language prompt.

Usage Note: The LLM must nest properties inside a Metadata object, including label, pluralLabel, deploymentStatus (Deployed or InDevelopment), and a nameField configuration. Truto's strict schema definitions guide the LLM to format this correctly.

"Create a new custom object in Salesforce called 'Vendor Assessment'. Set the deployment status to Deployed and make the primary name field an auto-number format starting at VA-0001."

4. Provision Custom Fields

Tool: create_a_salesforce_custom_field

Also utilizing the Tooling API, this tool adds new fields to existing standard or custom objects. The LLM formats the FullName as ObjectName.FieldName__c. This capability allows Claude to manage records and object metadata just as effectively as it does in ChatGPT.

Usage Note: Type-specific configuration is required. A Text field needs a length property, while a Number field requires precision and scale. The underlying MCP schema enforces these rules.

"Add a new custom currency field to the Opportunity object called 'Partner Margin'. Make it 16 digits of precision with 2 decimal places."

5. Update Existing Records

Tool: update_a_salesforce_record_by_id

Standard CRUD operation for modifying data. The LLM passes the object API name, the record ID, and a flat JSON object containing only the fields that need to be changed.

Usage Note: Agents will typically use the SOQL query tool first to locate the record ID before executing an update.

"Find the Account with the name 'Acme Corp' and update its annual revenue field to 5000000 and change its SLA status to Gold."

For the complete inventory of available tools, detailed parameter schemas, and pagination mechanics, review the Salesforce integration page.

Workflows in Action

Individual tools are powerful, but the true value of MCP emerges when Claude chains these tools together to execute complex, multi-step workflows. Because Claude maintains context between calls, it can read data, interpret schemas, and write updates autonomously.

Scenario 1: Provisioning a New Custom Field for Lead Scoring

Marketing operations requests a new way to track behavioral lead scores. Instead of a human logging into the Salesforce Setup menu, finding the Object Manager, and clicking through the field creation wizard, the user asks Claude to do it.

"We need to track a new 'Behavioral Score' on our Leads. Please check if the Lead object already has a field like this. If not, create a new custom number field on the Lead object called 'Behavioral Score' with 3 digits of precision and no decimal places."

Step-by-Step Execution:

  1. Claude calls get_single_salesforce_object_describe_by_id(id: "Lead") to fetch the current schema.
  2. Claude analyzes the returned JSON and confirms no field named Behavioral_Score__c exists.
  3. Claude calls create_a_salesforce_custom_field formatting the FullName as Lead.Behavioral_Score__c and passing the exact Metadata payload for a Number field type.
  4. Claude reads the success response and informs the user the field is ready.
flowchart TD
    User["User prompt: Create Behavioral Score on Lead"]
    Claude["Claude"]
    MCP["Truto MCP Server"]
    SF["Salesforce API"]

    User --> Claude
    Claude -->|"1. describe object (Lead)"| MCP
    MCP -->|"GET /sobjects/Lead/describe"| SF
    SF -->|"Schema JSON"| MCP
    MCP --> Claude
    Claude -->|"2. analyze fields"| Claude
    Claude -->|"3. create custom field"| MCP
    MCP -->|"POST /tooling/sobjects/CustomField"| SF
    SF -->|"201 Created"| MCP
    MCP --> Claude
    Claude -->|"Status update"| User

Scenario 2: Data Cleansing and Escalation via SOQL

A sales manager needs to identify stagnant deals and flag them for executive review.

"Find all Opportunities in the 'Negotiation' stage that have not had their CloseDate updated in the last 30 days. For each of these, set a custom field 'Needs_Executive_Review__c' to true."

Step-by-Step Execution:

  1. Claude formulates a SOQL query using current date math: SELECT Id, Name, CloseDate FROM Opportunity WHERE StageName = 'Negotiation' AND LastModifiedDate < LAST_N_DAYS:30.
  2. Claude calls list_all_salesforce_query with this string.
  3. The MCP server returns the record array.
  4. For every ID in the array, Claude iteratively calls update_a_salesforce_record_by_id(object_name: "Opportunity", id: "<id>", body: { "Needs_Executive_Review__c": true }).
  5. Claude summarizes the updated records for the user.
sequenceDiagram
    participant User as User
    participant Claude as Claude
    participant Truto as Truto MCP
    participant Salesforce as Salesforce API

    User->>Claude: "Find stalled Negotiation Ops and flag for review"
    Claude->>Truto: list_all_salesforce_query(q: "SELECT Id... WHERE Stage = 'Negotiation'")
    Truto->>Salesforce: GET /services/data/vxx.0/query/?q=...
    Salesforce-->>Truto: 200 OK (Records)
    Truto-->>Claude: JSON Array (e.g. 3 records found)
    
    rect rgb(235, 232, 226)
    note right of Claude: Loop over returned IDs
    Claude->>Truto: update_a_salesforce_record_by_id(id: "006...", body: { Needs_Executive_Review__c: true })
    Truto->>Salesforce: PATCH /services/data/vxx.0/sobjects/Opportunity/006...
    Salesforce-->>Truto: 204 No Content
    Truto-->>Claude: Success
    end
    
    Claude-->>User: "Updated 3 Opportunities successfully."

Security and Access Control

Exposing a production Salesforce environment to an autonomous agent requires strict security guardrails. Because MCP URLs act as bearer tokens to the server, Truto provides several mechanisms to lock down access at the server creation level:

  • Method Filtering: You can restrict a specific MCP server to read-only operations by passing methods: ["read"] during creation. This ensures an agent can execute SOQL and describe schemas, but is structurally blocked from creating or deleting records.
  • Tag Filtering: You can restrict the server to specific functional areas using tags. If you only want the agent to access standard CRM objects and not Tooling API metadata operations, you can filter tools by tag during server generation.
  • Authentication Requirements: Setting require_api_token_auth: true on the MCP configuration forces the client to pass a valid Truto API token in the Authorization header. This means possessing the MCP URL alone is useless; the caller must also be explicitly authenticated.
  • Time-to-Live Expiry: By providing an expires_at timestamp, you can provision temporary MCP servers for external contractors, ephemeral workflows, or short-lived AI agent instances. Truto automatically destroys the token and revokes access when the time expires.

Moving from Boilerplate to Agentic Workflows

Connecting Salesforce to Claude should not require weeks of engineering time spent wrestling with Tooling API metadata schemas, unpredictable pagination tokens, or OAuth refresh cycles. By utilizing a managed MCP infrastructure, you bypass the boilerplate entirely.

Your engineering effort shifts from maintaining integration code to designing the natural language prompts and validation logic that drive actual business value. Whether you are building an internal admin assistant to manage custom objects or a fully autonomous revenue operations agent, dynamic tool generation ensures your LLM always has safe, documented access to the exact shape of your Salesforce environment.

More from our Blog