Capable

Create record

create_record

Create a built-in or custom record with object_type + data; relationships take ids; built-ins use typed domain logic. Custom owners default to the caller; set display_field (usually name) for propose_updates matching. Sequence plans save atomically and never send. Touches record confirmed work; reuse captured source_touch_id or request_id + occurred_at. For lead/task, data.request_id (UUID) durably deduplicates retries; changed data conflicts. Task due: use due_at with the person's UTC offset and due_has_time:true for a stated time; a bare date is date-only. Returns the record. See data for sequence and activity fields.

When to use: Create built-in or custom records with object_type + data using the same domain logic.

Example: Add a partner 'Globex' with tier gold.

Input Schema

Name	Required	Description
`data`	Yes	New fields as key → value; relationships take target UUIDs; built-ins accept typed create fields. sequence: ordered steps [{title,brief,channel,day_offset}] + request_id UUID save the whole plan. timing_mode: from_start or after_previous; offsets stay cumulative; optional skip_weekends, pause_on_reply. Briefs accept CRM {{field}} tokens; preview with get_context(contact,sequence_brief). touch: source_touch_id reuses captured work, else request_id + occurred_at; sequence_action:{enrollment_id,step,outcome?,follow_up_on?} tracks confirmed work. Attempts and connection requests hold the step and require a follow-up date; not_now pauses; accepted/completed advance; retry pending tracking unchanged.
`owner_id`	No	A uuid.
`request_id`	No	Retry key: a client-generated UUID. Repeating a call with the same request_id and arguments within 24h replays the earlier result instead of creating a second record. For touch and sequence, put request_id inside data instead so the record itself stores it.
`object_type`	Yes	Object key, e.g. account, contact, opportunity, task, touch, or a custom object's key; an unknown key returns the workspace's valid types instead of creating.

Output Schema

Name	Required	Description	Default
`note`	No
`record`	No
`result`	No
`created`	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 / data / description

Previous value: -"The new record's fields as key → value (relationship fields take the target record's uuid); for a built-in object, the same fields its typed create accepts."New value: +"New fields as key → value; relationships take target UUIDs; built-ins accept typed create fields. sequence: ordered steps [{title,brief,channel,day_offset}] + request_id UUID save the whole plan. timing_mode: from_start or after_previous; offsets stay cumulative; optional skip_weekends, pause_on_reply. Briefs accept CRM {{field}} tokens; preview with get_context(contact,sequence_brief). touch: source_touch_id reuses captured work, else request_id + occurred_at; sequence_action:{enrollment_id,step,outcome?,follow_up_on?} tracks confirmed work. Attempts and connection requests hold the step and require a follow-up date; not_now pauses; accepted/completed advance; retry pending tracking unchanged."

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"
-}
```
First observedOct 6, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnly=false, destructive=false, openWorld=true, and idempotent=false. The description adds meaningful behavior beyond annotations: sequence plans save atomically and never send, touches require confirmed work or captured source_touch_id/request_id + occurred_at, lead/task retries dedupe via data.request_id while changed data conflicts, and the tool returns the record.

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?

The definition is front-loaded with the core create behavior and includes a 'When to use' section and an example. However, it is a dense wall of specialized clauses that partly duplicates the detailed schema, making it harder to scan than necessary.

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 complex nested create tool, the description covers the main creation model, built-in versus custom behavior, sequence/touch edge cases, retry semantics, task due-date handling, and return behavior. With annotations and an output schema also present, an agent has enough context to invoke it correctly.

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, but the description adds useful semantics beyond the schema: custom owners default to the caller, display_field is usually name for propose_updates matching, task due_at should include the person’s UTC offset and due_has_time for stated times, and sequence/touch fields have special meaning.

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: create a built-in or custom record using object_type + data, with built-ins using typed domain logic. That distinguishes creation from update/delete, but it does not explicitly differentiate this tool from siblings such as log_touch, add_note, create_quote, or add_account_contact.

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

Usage Guidelines2/5

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

The 'When to use' section mostly restates the purpose: create built-in or custom records with object_type + data. It gives field-level guidance for sequences, touches, and task due dates, but does not say when to choose this tool over update_record, log_touch, add_note, or other create siblings.

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?