mcp-creatio

Update a record

update

DestructiveIdempotent

Change selected columns of a Creatio record by ID while preserving omitted fields; resolve lookup IDs first instead of guessing them.

Instructions

Change columns of one record by id; columns you leave out keep their values. Resolve lookup ids instead of guessing them (e.g. a new StatusId from ActivityStatus via read); owner/user lookups take a contact id (get-guide: contactid-guide). Example: { entity: "Activity", id: "", data: { StartDate: "2026-03-02T12:00:00", DueDate: "2026-03-02T12:30:00" } } (the user's Creatio time zone).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "entity": "<entity>",
      "id": "<id>",
      "data": "<data>"
    },
    "name": "update"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Id of the record to update.
`data`	Yes	Only the columns to change. Values: text, numbers, booleans; a lookup by its id — `AccountId: "<guid>"` (find ids with read, dataforge-lookup-values or global-search; never guess them). Date/times are in the user's Creatio time zone, as in the Creatio UI: "2026-03-01T09:30:00" is 09:30 there; a value with an offset or Z ("2026-03-01T09:30:00+02:00") is that exact instant. A Date column takes "YYYY-MM-DD". (get-guide: datetime-guide)
`entity`	Yes	Entity (object schema) name, e.g. "Contact", "Account", "Activity".

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.8.0Oct 25, 2026

changedInput schema / properties / data / description

Previous value: -"Partial fields to change. Only include properties that should be updated.\n\nDATA TYPES:\n- Strings: \"John Doe\", \"john@example.com\"\n- Numbers: 1000, 25.99\n- Booleans: true, false\n- Dates: ISO 8601 format with Z for UTC: \"2025-10-08T19:00:00Z\"\n- GUIDs (lookups): \"8ecab4a1-0ca3-4515-9399-efe0a19390bd\" (no quotes in value!) (same as create)\n\n⏰ DATES & TIME:\n- Always use UTC time with Z suffix\n- Convert local time to UTC: subtract timezone offset\n- Format: \"YYYY-MM-DDTHH:mm:ssZ\"\n- Example: \"2025-10-08T19:00:00Z\" for 22:00 local (UTC+3)\n\nCOMMON UPDATE SCENARIOS:\n- Change Activity time: { StartDate: \"2025-10-09T14:00:00Z\" }\n- Update status: { StatusId: \"<GUID from ActivityStatus>\" }\n- Reschedule with reminder: { StartDate: \"...\", RemindToOwnerDate: \"...\" }\n- Change account: { AccountId: \"guid...\" }\n\n💡 For Activities: Query lookup tables (ActivityStatus, ActivityPriority) to get new IDs dynamically!"New value: +"Only the columns to change. Values: text, numbers, booleans; a lookup by its id — `AccountId: \"<guid>\"` (find ids with read, dataforge-lookup-values or global-search; never guess them). Date/times are in the user's Creatio time zone, as in the Creatio UI: \"2026-03-01T09:30:00\" is 09:30 there; a value with an offset or Z (\"2026-03-01T09:30:00+02:00\") is that exact instant. A Date column takes \"YYYY-MM-DD\". (get-guide: datetime-guide)"

changedInput schema / properties / entity / description

Previous value: -"Entity set to update (e.g., Contact, Account)."New value: +"Entity (object schema) name, e.g. \"Contact\", \"Account\", \"Activity\"."

changedInput schema / properties / id / description

Previous value: -"Primary key of the record. Pass GUIDs as-is (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). Non-GUID strings will be quoted automatically."New value: +"Id of the record to update."

First observedv0.6.5Jun 28, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With annotations already declaring destructiveHint=true and idempotentHint=true, the description adds the important behavioral fact that omitted columns keep their values, so the agent knows this is a partial merge rather than a replace. It does not mention permission requirements or failure modes, which keeps it short of a 5.

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

Conciseness4/5

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

The core behavior is front-loaded in the first clause, and the example earns its place by showing the nested data shape. The remaining guidance is packed into a dense run-on with parentheticals, which costs some 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?

For a three-parameter partial-update tool with a nested data object and full schema coverage, the description supplies the missing operational context (lookup resolution, time-zone handling, worked example). It omits error behavior and any note on which columns are immutable, minor gaps for a destructive write.

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 extra credit by adding cross-references (contactid-guide for owner/user lookups, datetime-guide) and a concrete worked example mapping entity/id/data to a realistic Activity update. The time-zone rule largely restates the schema text.

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?

The description states a specific verb and resource: change columns of one record by id, with partial-update semantics made explicit. That differentiates it from create/delete siblings in the same family, though the generic name 'update' means the description carries most of the differentiation load.

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

Usage Guidelines3/5

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

It gives concrete guidance on how to supply values (resolve lookup ids via read/ActivityStatus, use contactid-guide for owner lookups, datetime-guide for time zones), which is useful procedural context. It never says when to use update versus create or an upsert-style sibling, nor what happens if the id does not exist.

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