Skip to content
Truto
Back
AI & Agents

Connect Salesforce to ChatGPT: Manage Records and Object Metadata

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

Uday Gajavalli Uday Gajavalli · · 11 min read
Connect Salesforce to ChatGPT: Manage Records and Object Metadata

Giving a Large Language Model (LLM) read and write access to a Salesforce environment is an intense engineering challenge. You want your AI agents to query deal pipelines, update custom fields, and orchestrate complex account lifecycles. If your team uses Claude, check out our guide on connecting Salesforce to Claude or explore our broader architectural overview on connecting Salesforce to AI Agents.

To bridge the gap between ChatGPT's tool calling capabilities and the Salesforce API, you need a Model Context Protocol (MCP) server. You can either spend weeks building, hosting, and maintaining a custom MCP server that translates JSON-RPC requests into SOQL, or you can use a managed infrastructure layer to generate a secure, authenticated MCP server URL dynamically.

This guide breaks down exactly how to use Truto to generate a managed MCP server for Salesforce, connect it natively to ChatGPT, and execute complex CRM workflows - from querying data to altering object schemas - using natural language.

The Engineering Reality of the Salesforce API

A custom MCP server is a self-hosted integration layer that sits between the LLM and the upstream API. While the open MCP standard provides a predictable way for models to discover tools, implementing it against Salesforce is notoriously painful. You are not dealing with a simple CRUD API; you are dealing with a platform that allows enterprise customers to completely mutate their underlying database schemas.

If you decide to build a custom MCP server for Salesforce, you own the entire API lifecycle. Here are the specific integration challenges that break standard assumptions when connecting ChatGPT to Salesforce.

The SObject Schema Mutation Problem

Standard JSON schemas do not work with Salesforce. Every Salesforce instance is heavily customized. A field that exists as Status in a developer org might be Deal_Stage__c in a production org. An LLM cannot simply guess the schema. Your MCP server must provide a mechanism for the AI to dynamically discover custom objects (ending in __c) and interrogate their structure before attempting to write data. If your server cannot execute SObject Describe calls to fetch picklist values and field types, the LLM will hallucinate field names and every write request will fail.

SOQL Instead of RESTful Listing

Salesforce does not use standard REST conventions for fetching records. You cannot reliably execute a GET /accounts?status=active request and expect complex filtering to work. Instead, you must use the Salesforce Object Query Language (SOQL). Your MCP server must expose a tool that allows the LLM to write raw SOQL strings, handle the resulting nested JSON payload, and manage the pagination cursors that Salesforce returns for large datasets.

Tooling API vs REST API

If you want an AI agent to act as an administrator - modifying custom fields or creating new objects - the standard REST API is insufficient. You must interact with the Salesforce Tooling API. The Tooling API uses an entirely different set of metadata objects, deployment statuses, and sharing models. Building an MCP server that accurately maps LLM intent to the Tooling API requires maintaining massive, complex JSON schemas for metadata deployment.

Strict Concurrency and Rate Limits

Salesforce enforces strict API Request Limits per 24 hours, as well as concurrent API request limits. If your AI agent gets stuck in a loop executing expensive SOQL queries, Salesforce will return an HTTP 429 Too Many Requests error.

It is critical to note that Truto does not retry, throttle, or apply backoff on rate limit errors. When Salesforce 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 - in this case, the framework executing your AI agent - is strictly responsible for reading these headers and implementing its own exponential backoff logic.

The Managed MCP Architecture

Instead of forcing your engineering team to build and maintain this translation layer, Truto handles it via dynamic tool generation. When a customer connects their Salesforce instance, Truto derives MCP tools directly from the integration's resource definitions and API documentation.

flowchart TD
    A["ChatGPT Client<br>(MCP Client)"] -->|"JSON-RPC over HTTPS"| B["Managed MCP Server<br>(/mcp/:token)"]
    
    subgraph Truto Infrastructure ["Truto Infrastructure"]
        B --> C["Token Validation<br>& Auth Middleware"]
        C --> D["Tool Generator<br>(Dynamic Schema Assembly)"]
        D --> E["Proxy API Handler"]
    end
    
    E -->|"SOQL / Tooling API / REST API"| F["Salesforce API<br>(Upstream)"]

Tools are never hardcoded or cached. When ChatGPT connects to the server, Truto reads the environment's specific integration documentation, injects required query parameters (like pagination cursors), and formats the output into an MCP-compliant JSON Schema.

Step 1: Generating the Salesforce MCP Server

To expose Salesforce to ChatGPT, you must first create an MCP server scoped to a specific integrated account. This generates a cryptographic token embedded in a unique URL. You can do this via the Truto UI or programmatically via the API.

Method A: Via the Truto UI

  1. Navigate to the Integrated Accounts page in your Truto dashboard.
  2. Select the connected Salesforce account you want to expose to the LLM.
  3. Click the MCP Servers tab.
  4. Click Create MCP Server.
  5. Configure the server settings. You can optionally restrict the server to specific tags or methods (e.g., read-only).
  6. Click Save and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4...).

Method B: Via the API

If you are building an application that provisions AI agents on behalf of your users, you can generate this server programmatically. The API will validate the configuration, store the token in distributed key-value storage, and return the ready-to-use URL.

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

The response contains the exact URL ChatGPT needs to connect.

{
  "id": "mcp-789",
  "name": "Salesforce RevOps Agent",
  "config": { "methods": ["read", "write", "custom"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

Step 2: Connecting the MCP Server to ChatGPT

Once you have the URL, you must register it with ChatGPT. Because MCP relies on a standardized protocol, no custom SDKs are required. You can connect it directly via the ChatGPT interface or use a local Server-Sent Events (SSE) proxy for specific desktop configurations.

Method A: Via the ChatGPT UI

  1. Open ChatGPT and navigate to Settings.
  2. Go to Apps and select Advanced settings.
  3. Enable Developer mode (MCP support is currently behind this flag).
  4. Under MCP servers / Custom connectors, click to add a new server.
  5. Enter a recognizable name (e.g., "Salesforce (Truto)").
  6. Paste the Truto MCP URL into the Server URL field.
  7. Click Save.

ChatGPT will immediately ping the endpoint, execute the handshake, and request the tools/list payload to understand what Salesforce capabilities are available.

Method B: Via Manual Config File (SSE Proxy)

If you are running specific local agent frameworks or need to route the HTTP MCP endpoint through a standard stdio wrapper for local desktop testing, you can use the official @modelcontextprotocol/server-sse package.

Create a configuration JSON file to define the execution path:

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

This configuration instructs the local MCP client to spin up a process that forwards stdio messages over Server-Sent Events to the remote Truto endpoint.

Core Salesforce Hero Tools

Once connected, ChatGPT gains access to a dynamic suite of tools. Rather than generic CRUD operations, these tools are tailored to Salesforce's specific architectural requirements. Here are the most critical tools for AI automation.

1. Execute SOQL Queries (list_all_salesforce_query)

This is the workhorse tool for data retrieval. Instead of navigating complex REST endpoint paths, the LLM uses this tool to pass a raw SOQL string. It supports relationship queries, aggregation, and filtering across any standard or custom object.

Usage Context: ChatGPT should always use this tool when searching for records based on specific criteria (e.g., "Find all closed deals over $10k").

"Use the list_all_salesforce_query tool to execute a SOQL query finding the Id, Name, and Amount of all Opportunity records where StageName is 'Closed Won' and Amount > 10000. Limit the results to 5."

2. Discover Organization Schema (list_all_salesforce_objects)

Before an AI agent can reliably query or write data, it needs to know what objects actually exist in the tenant's specific Salesforce org. This tool returns the API names and labels for every standard object and every __c custom object deployed in the environment.

Usage Context: Use this when ChatGPT needs to map a user's natural language request (e.g., "check our invoices") to the actual underlying database table (e.g., Acme_Invoice__c).

"Before writing any queries, use list_all_salesforce_objects to check if there is a custom object related to 'Invoices' or 'Billing'. Return the exact API name of the object."

3. Interrogate Object Metadata (get_single_salesforce_object_describe_by_id)

Once the LLM knows the object name, it must understand the fields. This tool hits the SObject Describe endpoint, returning the full schema for a specific object, including field types, picklist values, relationship names, and required flags.

Usage Context: This is a mandatory prerequisite step before the LLM attempts to create or update a record, ensuring it does not hallucinate field names or pass invalid picklist values.

"Use get_single_salesforce_object_describe_by_id to get the metadata for the 'Contact' object. Analyze the payload to identify which fields are required, and list the valid options for the 'LeadSource' picklist."

4. Create Standard or Custom Records (create_a_salesforce_record)

This tool allows the LLM to insert a new row into any Salesforce object. It requires the object API name and a flat key-value object representing the fields.

Usage Context: Creating new leads, logging call tasks, or generating custom object records.

"Using the exact field names discovered in the previous describe step, call create_a_salesforce_record to create a new Contact. Set object_name to 'Contact', FirstName to 'Alice', LastName to 'Smith', and LeadSource to 'Web'."

5. Scaffold New Database Objects (create_a_salesforce_custom_object)

This tool interacts with the Tooling API, allowing the LLM to act as a system administrator and programmatically generate new database tables in Salesforce. It requires specific metadata properties like deploymentStatus, sharingModel, and nameField.

Usage Context: Used for AI agents tasked with RevOps automation, setting up new tracking infrastructure based on user prompts.

"Call create_a_salesforce_custom_object to create a new object. Set the DeveloperName to 'Project_Tracker'. Include a Metadata object with label 'Project Tracker', pluralLabel 'Project Trackers', deploymentStatus 'Deployed', and sharingModel 'ReadWrite'."

6. Mutate Field Definitions (update_a_salesforce_custom_field_by_id)

Also utilizing the Tooling API, this tool allows the LLM to modify the definition of an existing custom field using its Tooling API ID. It can adjust help text, update descriptions, or modify type-specific properties (like expanding the length of a text field).

Usage Context: Used when an administrator asks ChatGPT to clean up technical debt, update outdated field descriptions, or align help text with new company policies.

"Use update_a_salesforce_custom_field_by_id to update the custom field with ID '00N1a00000abcde'. Pass a Metadata object that updates the description to 'Tracks the ARR at the time of contract signature' and sets the inlineHelpText."

For the complete inventory of available operations, including tools for deleting metadata, fetching individual records, and managing custom fields, visit the Salesforce integration page.

Workflows in Action

When connected to ChatGPT, these tools combine to automate complex, multi-step Salesforce operations. Here is how specific personas utilize the integration in the real world.

Persona 1: RevOps Administrator Auditing Schemas

A RevOps admin needs to clean up a heavily customized Salesforce org and fix a broken picklist on a custom object.

"We have a custom object for tracking feature requests, but I am not sure what it is called. Find the object, check the fields to find the status picklist, and add 'Under Review' as a valid option to that field's help text description so the team knows what it means."

Execution Flow:

  1. ChatGPT calls list_all_salesforce_objects and scans the results, identifying Feature_Request__c.
  2. It calls get_single_salesforce_object_describe_by_id with id: "Feature_Request__c" to inspect the fields.
  3. It locates the Status__c field within the describe payload and extracts its Tooling API ID.
  4. It calls update_a_salesforce_custom_field_by_id to push a new Metadata payload, updating the inlineHelpText to include the new guidelines.

Persona 2: Sales Operations Managing Pipeline Data

A Sales Ops manager wants to query recent pipeline activity and automatically log a follow-up task.

"Find the last 3 Opportunities that were marked 'Closed Lost' this month. Then, create a Task assigned to the owner of the largest opportunity, reminding them to conduct a win/loss post-mortem."

Execution Flow:

  1. ChatGPT calls list_all_salesforce_query with a raw SOQL string: SELECT Id, Name, OwnerId, Amount FROM Opportunity WHERE StageName = 'Closed Lost' AND CloseDate = THIS_MONTH ORDER BY Amount DESC LIMIT 3.
  2. It parses the JSON result, identifying the Id and OwnerId of the Opportunity with the highest Amount.
  3. It calls create_a_salesforce_record with object_name: "Task" and a body containing the OwnerId, WhatId (linked to the Opportunity), Subject, and Status.
sequenceDiagram
    participant User
    participant ChatGPT
    participant MCP as Truto MCP Server
    participant SF as Upstream API (Salesforce)

    User->>ChatGPT: "Find largest Closed Lost opp..."
    ChatGPT->>MCP: Call list_all_salesforce_query (SOQL)
    MCP->>SF: GET /services/data/vxx.0/query?q=...
    SF-->>MCP: Returns JSON with 3 records
    MCP-->>ChatGPT: Returns formatted tool result
    ChatGPT->>MCP: Call create_a_salesforce_record (Task)
    MCP->>SF: POST /services/data/vxx.0/sobjects/Task
    SF-->>MCP: Returns new Task ID
    MCP-->>ChatGPT: Success confirmation
    ChatGPT-->>User: "Task created for the account owner."

Security and Access Control

Granting an LLM autonomous access to a production Salesforce instance introduces significant risk. Truto's MCP architecture provides multiple layers of control to restrict what the AI agent can do.

  • Method Filtering: When generating the MCP server, you can restrict the configuration to specific HTTP methods. Passing methods: ["read"] ensures the server will only expose get and list operations. If the LLM attempts to hallucinate a write tool, the server rejects it at the protocol layer.
  • Tag Filtering: You can restrict the server to specific resource tags. For example, generating a server with tags: ["metadata"] will only expose the Tooling API tools, preventing the agent from reading or writing standard CRM record data.
  • Extra Authentication (require_api_token_auth): By default, possessing the MCP URL is enough to authenticate. For enterprise deployments, setting require_api_token_auth: true forces the MCP client to also pass a valid Truto API token in the Authorization header. This guarantees that even if the MCP URL is leaked in a log file, the endpoints remain secure.
  • Automatic Expiration (expires_at): You can bind a time-to-live to the MCP server. Setting an ISO datetime ensures the server's cryptographic token is automatically purged from distributed key-value storage at the exact expiration time. This is ideal for granting a contractor or temporary AI agent short-lived access to Salesforce.

Moving beyond hardcoded point-to-point scripts is the only way to build reliable AI agents for enterprise environments. By leveraging a managed MCP server, you abstract away the complexities of the Salesforce Tooling API, SOQL pagination cursors, and OAuth token lifecycles. Your engineering team can focus on agent reasoning and prompt architecture, while the infrastructure layer dynamically handles the reality of the upstream API.

More from our Blog