Capable

Update record

update_record

DestructiveIdempotent

Patch object_type + id; returns the fresh record. Built-ins use typed domain logic; custom data is shallow-merged and owner-scoped unless shared. Update an existing View with report + patch:{definition}; create a View only for a different perspective. Touch patches correct subject/summary/time/type. Sequence plans save together with saved step ids, revisions and an identical-retry request_id; enrollment fences timing/channel/order changes. Maintenance fields each run alone: task subtasks replaces the checklist; contact engaged:true is a ratchet; opportunity board_rank orders its column; sequence_step position swaps neighbours, fenced while people are partway through. See patch for syntax; task due follows create_record.

When to use: Edit fields (stage, task status:'done'). Retire converted leads LAST: status:'converted', account/contact/opportunity ids, converted_at, deleted_at; see an MCP resource at capable://guide/leads.

Example: Update opportunity : set stage to verbal.

Input Schema

Name	Required	Description
`id`	Yes	A uuid.
`patch`	Yes	Changed fields only, key → value; at least one required. Null clears custom data or a built-in custom_fields key; custom data is shallow-merged. Sequence: steps (keep saved ids), expected_revision (sequence mcp_revision), expected_steps:[{id,revision}] for every live step, request_id UUID reused only for an identical retry. Maintenance, each alone: task subtasks:[{id?,title,done?}] replaces the entire checklist; contact engaged:true; opportunity board_rank:{before?,after?}; sequence_step position swaps with the neighbour occupying that slot.
`object_type`	Yes	Object key of the record being patched, e.g. account, contact, task, report, a custom object's key, or rollup / automation / field (admin-only; the id from describe_schema); an unknown key returns the valid types and writes nothing.
`expected_revision`	No	Optional record revision from a reviewed update, as the text a review sealed or the number a record read shows in mcp_revision; a changed record is refused without writing.

Output Schema

Name	Required	Description	Default
`note`	No
`record`	No
`result`	No
`updated`	No
`object_type`	No
`custom_field_definitions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

changedInput schema / properties / patch / description

Previous value: -"Only the fields to change, key → new value; at least one key is required, and null clears a custom-object field or a built-in object's custom_fields key (custom data is shallow-merged, not replaced)."New value: +"Changed fields only, key → value; at least one required. Null clears custom data or a built-in custom_fields key; custom data is shallow-merged. Sequence: steps (keep saved ids), expected_revision (sequence mcp_revision), expected_steps:[{id,revision}] for every live step, request_id UUID reused only for an identical retry. Maintenance, each alone: task subtasks:[{id?,title,done?}] replaces the entire checklist; contact engaged:true; opportunity board_rank:{before?,after?}; sequence_step position swaps with the neighbour occupying that slot."

Changed1 schema field changedOct 24, 2026

changedInput schema / properties / patch / description

Previous value: -"Only the fields to change, key → new value; at least one key is required, and null clears a custom-object field (custom data is shallow-merged, not replaced)."New value: +"Only the fields to change, key → new value; at least one key is required, and null clears a custom-object field or a built-in object's custom_fields key (custom data is shallow-merged, not replaced)."

Changed1 schema field changedOct 22, 2026

changedInput schema / properties / object_type / description

Previous value: -"Object key of the record being patched, e.g. account, contact, task, report, a custom object's key, or rollup / automation (admin-only; the id from describe_schema); an unknown key returns the valid types and writes nothing."New value: +"Object key of the record being patched, e.g. account, contact, task, report, a custom object's key, or rollup / automation / field (admin-only; the id from describe_schema); an unknown key returns the valid types and writes nothing."

Changed1 schema field changedOct 20, 2026
- removedInput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
Changed8 schema fields changedOct 19, 2026
- removedOutput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```
- removedOutput schema / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / custom_field_definitions / items / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / custom_field_definitions / items / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / record / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / record / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```
- removedOutput schema / properties / result / additionalProperties
```
Removed value: -{}
```
- removedOutput schema / properties / result / propertyNames
```
Removed value: -{
-  "type": "string"
-}
```

Changed3 schema fields changedOct 17, 2026

addedInput schema / properties / expected_revision / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "maximum": 9007199254740991,
+    "minimum": -9007199254740991,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / expected_revision / description

Previous value: -"Optional record revision from a reviewed update; a changed record is refused without writing."New value: +"Optional record revision from a reviewed update, as the text a review sealed or the number a record read shows in mcp_revision; a changed record is refused without writing."

removedInput schema / properties / expected_revision / type
```
Removed value: -"string"
```

First observedOct 6, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already say destructive/idempotent, but the description adds substantial behavior the agent could not otherwise know: built-ins use typed domain logic, custom data is shallow-merged and owner-scoped unless shared, sequence plans must be saved atomically with expected revisions and a reused request_id, enrollment fences timing/channel/order changes, maintenance fields must each run alone, and contact engaged:true is a ratchet. That is concrete, consequential context beyond the structured data.

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

Conciseness3/5

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

Information-dense but front-loaded poorly after the first sentence; the middle is a long run-on packing per-object-type rules, which is hard to scan and mixes syntax pointers ("See patch for syntax") with behavior. Every fact is arguably useful, but the packaging costs readability.

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?

An output schema exists, so return values needn't be explained, and the description covers mutation semantics, concurrency refusal, ordering, and admin-only object types. Remaining gap is minor: permissions/error paths beyond the unknown-key case are only implied.

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 adds meaning: null clears custom data, patch is changed-fields-only, and the semantics of sequencing fields (request_id reused only for an identical retry, expected_steps required for every live step, position swaps with the neighbour). Much overlaps the schema, but the operational rationale is extra.

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?

Opens with a specific verb and resource: "Patch object_type + id; returns the fresh record." It distinguishes itself from create_record ("task due follows create_record") and from create for Views. The pile of domain-specific edge cases that follows dilutes focus slightly, but the core purpose is unmistakable.

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?

Has an explicit "When to use" section (edit fields, retire converted leads last with exact field list), and explicitly routes the View case: "Update an existing View... create a View only for a different perspective." It also notes task due dates follow create_record. No real when-not guidance beyond those cases, but the alternatives are named.

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

All Capable 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?