Capable

Create record

create_record

Create a record of ANY object type. Pass object_type + a data object of the object's fields (relationship fields take the target record's id). Works for custom objects (partner, product, investor — records-backed) AND the built-in objects (account, contact, opportunity, subscription, task, signal, touch), where it routes to the same domain logic as the typed create tools. The caller becomes the owner of custom records unless owner_id is given. For custom records, set the object's display-name field (usually name, or the object's display_field) so the record is findable by name in the propose_updates matcher. For sequence, include ordered steps [{title,brief,channel,day_offset}] and request_id (UUID) in data to save a whole plan atomically; timing_mode is from_start or after_previous, offsets remain cumulative, and skip_weekends/pause_on_reply are optional. A sequence saves a plan; it never sends messages. For touch, request_id (UUID) plus occurred_at makes the activity retryable; sequence_action:{enrollment_id,step} records an outbound activity and advances that exact sequence step through governance. Its sequence_tracking result says updated, pending or unchanged; retry the same payload to finish a pending step update. Returns the created record (its full fresh state).

When to use: The generic create. Pass object_type + a data object of its fields. Routes built-in objects to the same domain logic as the folded typed create tools; custom objects are records-backed.

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

Input Schema

TableJSON Schema

Name	Required	Description
`data`	Yes	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.
`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

TableJSON 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.

First observedOct 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations: caller becomes owner unless owner_id is given, request_id replay semantics within 24h, atomic sequence saving with timing_mode/skip_weekends behavior, and the explicit side-effect disclaimer 'A sequence saves a plan; it never sends messages.' It also documents the touch sequence_tracking result states and retry guidance — rich, non-obvious behavioral context.

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?

Front-loaded with the core purpose, but the middle is a dense run-on covering sequence/touch edge cases, and the 'When to use' paragraph restates the opening contract ('Pass object_type + a data object of its fields') almost verbatim. The short example is marginal. Length is defensible for the complexity, but there is avoidable redundancy.

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?

Given an output schema exists, return values needn't be spelled out, and the description still notes it returns the created record's full fresh state. Combined with the custom-vs-built-in routing, ownership, and sequence/touch specifics, coverage is strong; only minor gaps (error/validation behavior beyond the unknown-object_type note) remain.

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 real meaning: relationship fields take the target record's id, custom records need a display-name field, and the sequence/touch data payloads (ordered steps, timing_mode from_start/after_previous, request_id placement) are elaborated beyond the schema's generic data object.

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 specific verb+resource and scope: 'Create a record of ANY object type.' It explicitly distinguishes itself from the folded typed create tools (built-in objects route to the same domain logic) and from update_record/delete_record by framing itself as 'the generic create.' An agent can place it 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 Guidelines4/5

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

Provides a 'When to use' section and states the calling contract (object_type + data). It explains routing behavior for built-in vs custom objects but never names an explicit alternative or a when-not-to-use case (e.g. when to prefer a typed create sibling). Clear context, no exclusions.

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?