Skip to main content
Glama

Cirra AI Salesforce Admin MCP Server

bulk_dml

Destructive

Insert, update, upsert, delete, or hard-delete large Salesforce record sets via Bulk API 2.0 ingest jobs. Use this instead of sobject_dml when processing more than ~200 records. Pass records/recordIds to upload inline, or omit them to open a job so the user can upload a CSV from an in-chat control or a simple upload page (the file never goes through the chat). The tool waits up to 90 seconds; if the job is still running it returns a jobId you can pass back to wait or abort.

Input Schema

NameRequiredDescriptionDefault
abortNoWhen true, abort the ingest job identified by `jobId`. Requires `jobId`.
jobIdNoExisting ingest job ID or Cirra CSV upload handle (`bih_…`). Pass this to wait for a previously submitted job or to abort it. When set, `records` are ignored. If the handle is still waiting for a CSV, the response repeats the upload URL instead of creating a Salesforce job.
recordsNoRecords to ingest. For update the records must include `Id`. For upsert they must include the external ID field. For delete/hardDelete you may pass records with `Id` instead of `recordIds`. Omit `records` and `recordIds` (with `operation` + `sObject`) to open a job so the user can upload a CSV from chat or a browser page (bypasses the LLM).
sObjectNoAPI name of the sObject. Required to start a new job.
sf_userNo(optional) Salesforce username to identify the connection to use. Omit this to use the current default connection.
pageSizeNo(optional) Maximum number of records to return per page when the response requires pagination, including the first page. If omitted, the first page is a short preview and later pages use an automatically calculated size.
operationNoIngest operation. Required to start a new job. Always ask for explicit user approval before executing, and do not proceed without it. hardDelete permanently removes records (they skip the Recycle Bin) and requires the Bulk API Hard Delete permission.
recordIdsNoRecord IDs for delete or hardDelete. Takes precedence over `records` for those operations.
cirra_ai_teamNo(optional) Cirra team ID or name that owns the Salesforce connection to use for this call. Must be provided together with 'sf_user'. Use it to run against a specific team's connection without changing your default team — e.g. to keep separate chats on Salesforce orgs in different teams. Omit it when this call carries the context_handle from cirra_ai_init, which names the team for the conversation. A user with more than one place to work (several teams, or a team and a personal account) must pass either the context_handle or 'cirra_ai_team' + 'sf_user'.
context_handleNo(recommended) The conversation context handle returned by cirra_ai_init in this conversation. Pass the exact context_handle value from the most recent cirra_ai_init result so this call runs against the team and Salesforce connection selected for this conversation. A user with more than one place to work (several Cirra AI teams, or a team and a personal account) must pass either this handle or 'cirra_ai_team' + 'sf_user'; a call with neither is refused.
externalIdFieldNoExternal ID field API name. Required for upsert, ignored otherwise.

Output Schema

NameRequiredDescriptionDefault
uiNoWhat the in-chat control should render. `csv_upload` is the only kind that needs a file picker.
jobIdNo
stateNo
messageYes
resultsNo
sObjectNo
successYes
warningNo
timedOutNo
csvUploadNo
errorCodeNo
operationNo
errorCountNo
resultCountNo
artifactTypeNo
instructionsNo
requestCountNo
skippedCountNo
successCountNo
schemaVersionNo
salesforceJobIdNo
artifactCategoryNo
awaitingCsvUploadNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructive/openWorld, and the description adds real context on top: 90-second wait ceiling with a resumable jobId, the fact that CSV uploads bypass the model, that hardDelete skips the Recycle Bin and needs a specific permission, and that CSV jobs return an upload URL instead of a Salesforce job. No annotation is contradicted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Lead sentence states the operation surface, second routes away from the sibling, third explains the two upload modes, fourth explains the timeout/jobId lifecycle. Every sentence carries distinct information with no restatement of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, zero-required, destructive job-orchestration tool this covers the essentials an agent must know to act correctly: when to use it, how to start a job, how to wait or abort, and the async failure mode. An output schema exists, so return-shape detail is not required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description still earns above that by explaining the records/recordIds/jobId interaction — jobId causes records to be ignored, and recordIds take precedence for deletes. It does not touch pageSize or the connection-selection params, which is acceptable given the schema documents them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names the exact verb set (insert/update/upsert/delete/hardDelete) and resource (large Salesforce record sets) plus the mechanism (Bulk API 2.0 ingest jobs). It is immediately distinguishable from the single-record siblings sobject_dml/sobject_create/sobject_update.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: 'Use this instead of sobject_dml when processing more than ~200 records,' with a concrete threshold. It also disambiguates the two invocation modes — pass records/recordIds for inline upload, omit them to open a CSV job.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources