Cirra AI Salesforce Admin MCP Server

profile_update

Idempotent

Update settings stored on a Salesforce user profile, such as record type visibility, page layout assignments, login IP ranges, system permissions and the description. For object, field and tab access, use sobject_dml on the profile's ObjectPermissions, FieldPermissions or PermissionSetTabSetting records instead: it changes only those records.

Input Schema

Name	Required	Description
`patch`	Yes	The array of modifications that need to be applied. This should be provided in the `JSON Patch` format
`profile`	Yes	The name or ID of the Profile
`sf_user`	No	(optional) Salesforce username to identify the connection to use. Omit this to use the current default connection.
`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.
`confirmLoginIpRestriction`	No	(optional) Required to add the first Login IP Range to a profile. Login IP Ranges are an allowlist: users with the profile are blocked from logging in from any other IP address. Set to true only after the user has explicitly confirmed they want to restrict logins for this profile. To waive identity verification for trusted addresses instead, use the org-wide Network Access trusted IP ranges.

Output Schema

Name	Required	Description
`message`	Yes
`results`	No
`success`	Yes
`warning`	No
`errorCode`	No
`errorCount`	No
`resultCount`	No
`artifactType`	No
`requestCount`	No
`skippedCount`	No
`successCount`	No
`appliedMetadata`	No	The metadata payload that was actually sent to Salesforce for this operation (post-normalization/defaulting), so you can verify it matches what was intended without a separate read.
`artifactCategory`	No
`verifiedChangeCount`	No	Number of requested changes confirmed by re-reading the profile after the update.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 1, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

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 / confirmLoginIpRestriction

Added value: +{
+  "description": "(optional) Required to add the first Login IP Range to a profile. Login IP Ranges are an allowlist: users with the profile are blocked from logging in from any other IP address. Set to true only after the user has explicitly confirmed they want to restrict logins for this profile. To waive identity verification for trusted addresses instead, use the org-wide Network Access trusted IP ranges.",
+  "type": "boolean"
+}

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"
+}

removedInput schema / properties / patch / items / properties

Removed value: -{
-  "from": {
-    "description": "For move and copy operations only: a JSON Pointer path specifying the source",
-    "type": "string"
-  },
-  "op": {
-    "description": "The operation to perform",
-    "enum": [
-      "add",
-      "remove",
-      "replace",
-      "move",
-      "copy",
-      "test"
-    ],
-    "type": "string"
-  },
-  "path": {
-    "description": "An enhanced JSON Pointer path specifying where the change should be applied.",
-    "type": "string"
-  },
-  "value": {
-    "description": "The value to add, replace, or test. Set to null for move and copy operations"
-  }
-}

removedInput schema / properties / patch / items / required
```
Removed value: -[
-  "op",
-  "path",
-  "value"
-]
```
removedInput schema / properties / patch / items / type
```
Removed value: -"object"
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "appliedMetadata": {
+      "additionalProperties": true,
+      "description": "The metadata payload that was actually sent to Salesforce for this operation (post-normalization/defaulting), so you can verify it matches what was intended without a separate read.",
+      "properties": {},
+      "type": "object"
+    },
+    "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"
+    },
+    "verifiedChangeCount": {
+      "description": "Number of requested changes confirmed by re-reading the profile after the update.",
+      "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
AddedFeb 26, 2026
RemovedFeb 26, 2026
First observedJan 31, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, but the description adds real behavioral context beyond them: it identifies the concrete settings mutated and explains the login IP range semantics as an allowlist that blocks users from any other address, plus the requirement for explicit confirmation before adding the first range. It stops short of stating required permissions ('Manage Profiles') or whether a multi-element JSON Patch applies atomically.

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, both load-bearing: the first states scope with concrete examples, the second routes the agent away to the correct sibling. No restatement of the tool name, no filler, and the alternative-tool routing is front-loaded where the agent can act on it.

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?

For a mutation tool with rich annotations, an output schema and 100% parameter coverage, the description covers what it changes, which sibling handles adjacent cases, and the highest-risk side effect with its confirmation gate. The gaps are minor: authentication/permission prerequisites for updating profiles and the behavior on partial patch failure are unstated.

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%, so all six parameters, including the JSON Patch format for 'patch' and the connection-selection logic, are already documented. The description contributes only indirect guidance by enumerating which profile aspects can be patched, which helps an agent construct the patch but adds little the schema does not already contain. Baseline 3 applies when the schema carries the parameter burden.

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?

States a specific verb (Update) and resource (Salesforce user profile) and enumerates the concrete settings in scope: record type visibility, page layout assignments, login IP ranges, system permissions, description. It also explicitly carves out the object/field/tab-permission territory to sobject_dml, so an agent can distinguish it from sibling tools without opening a schema.

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 names the alternative and the condition that selects it: 'For object, field and tab access, use sobject_dml on the profile's ObjectPermissions, FieldPermissions or PermissionSetTabSetting records instead.' The confirmLoginIpRestriction schema entry further states when to set the flag ('only after the user has explicitly confirmed') and points to the org-wide Network Access trusted IP ranges as the non-restrictive alternative.

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?