Connect Claude to Salesforce

Run a SOQL query and return the matching records. This is the main way to read anything out of Salesforce: it reaches every standard and custom object, follows relationships (Account.Name from a Contact), filters, sorts and aggregates. Name the fields you want rather than guessing - SOQL has no SELECT * - and call describe_object first when you are not sure a field exists, because a bad field name comes back as an error rather than as an empty result. Salesforce returns the first 2,000 records and sets done to false when there are more; this connector has no follow-the-cursor operation, so page with LIMIT and OFFSET in the statement itself, or narrow the WHERE clause.

Run a SOSL search - full-text matching across several objects at once, which SOQL cannot do. Use it when you have a name, a phone number or a fragment of an email address and do not yet know which object it lives on; use soql_query when you know the object and the field. The statement carries its own structure, e.g. FIND {Acme} IN ALL FIELDS RETURNING Account(Id, Name), Contact(Id, Name, Email), Lead(Id, Name).

Fetch one record by its 15 or 18 character Salesforce id, on any object. Ask for the fields you need - without `fields` Salesforce returns every field on the record, which on a customised Account or Case is thousands of tokens of mostly empty columns. Ids come from soql_query, sosl_search or list_recent_items; describe_object lists the field names this object actually has.

Return one object's full metadata: every field with its API name, label, data type, whether it is required, and the picklist values it accepts. This is the operation to call before writing anything, because a Salesforce org's schema is whatever its admins built - field names, required fields and picklist values are all local. The response is large; ask for one object at a time.

List every object in the org - standard and custom - with its API name, label and what can be done to it. Call this first when you do not know what the org calls something: a company's Accounts may be Accounts, or they may have a custom object beside them. Then call describe_object for the one you want. This is also the connection check, because it is a metadata read that touches no records.

Return the records the signed-in user viewed most recently, across objects, newest first. Useful as an opening move when somebody says "the opportunity I was just looking at" and gives you nothing else to go on. Returns ids and names only; pass an id to get_record for the rest.

Return the identity this connection is signed in as: the Salesforce user id, username, display name, email address and organization id. Call it to confirm which org and which user a write would be attributed to before making one. It needs the `id` scope, which this connector's sign-in requests; list_objects is the check used at install because it needs only `api`.