mcp-creatio

Create a record

create

Inserts a single record into a specified Creatio entity using provided data and returns the new record's ID. Verify required columns with describe-entity first.

Instructions

Create one record: { entity, data } → the new record's id. Check required columns and types with describe-entity first; send only the columns you set. Owner/author lookups (OwnerId, AuthorId, …) of records the user creates for themselves get their contact id — userInfo.contactId from get-current-user-info — unless the user names someone else (get-guide: contactid-guide). Activities (tasks, meetings, calls): follow get-guide: create-activity-guide. Tags: get-guide: tagging-guide. An unknown column fails as "unknown_column:X (Entity). Did you mean: …?". Example: { entity: "Account", data: { Name: "Acme Corp", Phone: "+1 234 567", OwnerId: "" } }.

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>",
      "data": "<data>"
    },
    "name": "create"
  }
}

Input Schema

Name	Required	Description	Default
`data`	Yes	Column values of the new record. 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.

Changed2 schema fields changedv0.8.0Oct 25, 2026

changedInput schema / properties / data / description

Previous value: -"Field map for new record.\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!)\n\nLOOKUP FIELDS:\n- Use field name ending with Id: AccountId, ContactId, TypeId, etc.\n- Value must be valid GUID from related entity\n- Example: AccountId: \"8ecab4a1-0ca3-4515-9399-efe0a19390bd\"\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\n💡 TIP: Call 'describe-entity' first to see required fields and their types!"New value: +"Column values of the new record. 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 create a record in (e.g., Contact, Account). Tip: use \"describe-entity\" to find required fields and types before creating."New value: +"Entity (object schema) name, e.g. \"Contact\", \"Account\", \"Activity\"."

First observedv0.6.5Jun 28, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds real behavioral context beyond the annotations: the exact failure string for an unknown column, the defaulting rule that OwnerId/AuthorId resolve to the caller's contactId unless someone else is named, and partial-write semantics (only submitted columns are set). It does not spell out the duplicate-record consequence implied by idempotentHint=false, which is the one notable omission for a create tool.

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?

Front-loaded with the contract and example at the end; every sentence is operational (prerequisite, lookup defaulting, guide pointers, error format). Dense but not padded, though the chain of guide references makes it read as a run-on in the middle.

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 a two-parameter mutation with nested data and no output schema, it covers the return value (the new record's id), the error case, ownership defaulting, and the special-case guides. An agent has everything needed to call it correctly without opening other tools first, apart from the deliberate describe-entity prerequisite.

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 adds meaning on top by explaining the `data` payload's intent (only columns you set), how lookup columns must be supplied by id, and a worked example. The datetime/time-zone detail lives in the schema rather than the description, so it isn't double-counted.

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?

Opens with a precise verb-resource-outcome mapping: 'Create one record: { entity, data } → the new record's id.' That signature distinguishes it immediately from sibling `update` and from `read`/`describe-entity`, which are framed elsewhere in the description as preparatory steps rather than substitutes.

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 states the prerequisite ('Check required columns and types with describe-entity first'), a usage rule ('send only the columns you set'), and routes conditional cases to specific guides (contactid-guide for OwnerId/AuthorId, create-activity-guide for activities, tagging-guide for tags). Alternative lookup paths for ids are named (`read`, `dataforge-lookup-values`, `global-search`).

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