Cirra AI Salesforce Admin MCP Server

sobject_dml

Destructive

Create, update, delete, or upsert Salesforce sObject records via DML operations. For more than ~200 records use bulk_dml instead.

Input Schema

Name	Required	Description
`records`	No	Array of records to process. For an 'update' operation the records must include an `Id` property`. For 'create' or 'upsert' the records may not have an `Id`. Do not use this property for the 'delete' operation
`sObject`	Yes	API name of the sObject
`sf_user`	No	(optional) Salesforce username to identify the connection to use. Omit this to use the current default connection.
`operation`	Yes	Type of DML operation to perform. Always ask for explicit user permission before executing any of these operations
`recordIds`	No	Only used for the 'delete' operation: the IDs of the record to deletes
`dmlOptions`	No	Optional DML options to use for the operation
`cirra_ai_team`	No	(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_handle`	No	(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.
`externalIdField`	No	External ID field name. Required for upsert operations, ignored in other cases

Output Schema

Name	Required	Description	Default
`message`	Yes
`results`	No
`success`	Yes
`warning`	No
`errorCode`	No
`errorCount`	No
`resultCount`	No
`artifactType`	No
`requestCount`	No
`skippedCount`	No
`successCount`	No
`artifactCategory`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 1, 2026

changedInput schema / properties / cirra_ai_team / description

Previous value: -"(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 to use your current/default team."New value: +"(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'."

addedInput schema / properties / context_handle

Added value: +{
+  "description": "(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.",
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "artifactCategory": {
+      "type": "string"
+    },
+    "artifactType": {
+      "type": "string"
+    },
+    "errorCode": {
+      "type": "string"
+    },
+    "errorCount": {
+      "type": "number"
+    },
+    "message": {
+      "type": "string"
+    },
+    "requestCount": {
+      "type": "number"
+    },
+    "resultCount": {
+      "type": "number"
+    },
+    "results": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {},
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "skippedCount": {
+      "type": "number"
+    },
+    "success": {
+      "type": "boolean"
+    },
+    "successCount": {
+      "type": "number"
+    },
+    "warning": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "success",
+    "message"
+  ],
+  "type": "object"
+}

Changed1 schema field changedJul 27, 2026

addedInput schema / properties / cirra_ai_team

Added value: +{
+  "description": "(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 to use your current/default team.",
+  "type": "string"
+}

AddedMay 8, 2026
RemovedMay 8, 2026
Changed1 schema field changedMar 11, 2026
- changedInput schema / properties / records / items / additionalProperties
```
Previous value: -{}New value: +true
```
AddedFeb 26, 2026
RemovedFeb 26, 2026
First observedJan 31, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true and non-idempotency, so the safety profile is covered structurally. The description adds one genuinely useful behavioral constraint — the ~200-record threshold implying partial-failure/perf limits — but says nothing about allOrNone semantics, partial success handling, or the permission-before-execute requirement that matters for a destructive tool.

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?

Two sentences, zero filler, with the core capability first and the routing constraint immediately after. Nothing redundant with the name or annotations.

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

Completeness4/5

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

With an output schema, full annotations, and 100% schema coverage, the description only needs to cover routing and scope, which it largely does. The remaining gap is disambiguation from the dedicated sobject_create/sobject_update/tooling_api_dml siblings in a very crowded namespace.

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

Parameters3/5

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

Schema description coverage is 100% and every parameter including records/recordIds/upsert's externalIdField and the context_handle gating is documented in-schema, so baseline is 3. The description contributes no additional parameter semantics beyond restating the operation types.

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

Purpose4/5

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

States a specific verb set (create, update, delete, upsert) and resource (Salesforce sObject records) via DML, which is clear and actionable. However, it never addresses the overlapping siblings sobject_create and sobject_update, so an agent cannot tell from the description alone whether to use this multi-purpose tool or the dedicated per-operation ones.

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

Usage Guidelines4/5

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

Gives an explicit, quantified routing rule: use bulk_dml for more than ~200 records. That is a concrete when-to-use-else condition. But it gives no guidance relative to sobject_create/sobject_update or tooling_api_dml, and no prerequisites (though the safety gate lives in the schema's operation description, not here).

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

All Cirra AI Salesforce Admin MCP Server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?