Run a SOQL query and return matching records.

Follows nextRecordsUrl automatically so the full result set is returned in one call, regardless of Salesforce's per-page row limit.

Run a raw SOSL search and return matching records grouped by object type.

Example: FIND {Acme} IN ALL FIELDS RETURNING Account(Name), Contact(Name, Email)

Complements sf_query: SOSL matches keywords across multiple object types and text fields at once, where SOQL needs an exact object and field match.

Fetch a single record by ID. Pass fields to restrict which fields come back.

Create a new record of the given object type with the given field values.

Update an existing record's field values.

Create or update a record identified by an external ID field.

The standard idempotent create-or-update integration pattern: safe to call repeatedly with the same external ID without creating duplicates.

Delete a record by ID.

Return field metadata (names, types, picklist values, etc.) for one object.

List objects available in the org (global describe), for discoverability.

A Developer Edition org alone has 800+ standard objects, so the result is trimmed to name/label/custom/queryable/createable/ updateable/deletable per object rather than Salesforce's full raw payload. Narrow further with name_contains (matches name or label, case-insensitive) or custom_only=True if you don't need the full list.

Run a SOQL query via Bulk API 2.0, for result sets too large for sf_query.

Slower (job-based, polls until complete) but not subject to sf_query's interactive per-request limits. Prefer sf_query for everyday lookups; reach for this when you expect a very large result set.

Insert/update/upsert/delete a batch of records via Bulk API 2.0.

Use for record volumes too large for sf_create_record/sf_update_record's one-record-per-call REST endpoints. operation is one of "insert", "update", "upsert", "delete". external_id_field is required for "upsert". For "delete", each record dict needs only an "Id" key.

Bundle multiple sub-requests into one atomic Salesforce API call.

Each entry in requests is a Salesforce composite sub-request, e.g.: {"method": "POST", "url": "/services/data/v61.0/sobjects/Account", "referenceId": "NewAccount", "body": {"Name": "Acme"}} A later sub-request can reference an earlier one's result with "@{NewAccount.id}" inside its own body or url. With all_or_none true (the default), the whole batch rolls back if any sub-request fails.

Report current Salesforce REST API usage against the org's daily limit.

Reads the Sforce-Limit-Info header from the most recent API call when available (no extra request needed); falls back to a /limits call otherwise (e.g. right after server startup, before any other tool ran).

Call a custom Apex REST endpoint exposed by the org.

For any org-specific capability beyond this server's built-in standard-API tools: an Apex class annotated @RestResource(urlMapping=...) with @HttpGet/@HttpPost/etc. methods. path is that class's URL mapping, e.g. "/MyApi/v1/accounts/001xx0000000001AAA" for a class registered with @RestResource(urlMapping='/MyApi/v1/accounts/*'). method must match whichever HTTP method the class handles.

This is a thin, generic pass-through — it has no idea what any particular custom endpoint does, expects, or returns; that's between the caller and whatever the org's Apex class implements.

Report the org's overall health: what kind of org it is, current API/ storage/async limits, and license seat usage (user licenses, permission set licenses, installed package licenses).

A heavier, broader report than sf_api_usage (which only checks the daily API request limit) — use this for "what does this org have and how much of it is used", not for a quick mid-conversation limit check.