Create a record. data is the object's fields (see relm_describe_schema). Custom fields must be registered first (relm_create_field). A contact needs at least one of: a name, an identifier (email/phone/linkedin_url), a company, or a custom field (email is unique per workspace) - don't invent a placeholder email.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| object | Yes | Which core object. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds behavioral rules: custom fields must be registered first, contact records need at least one identifier or custom field, and email uniqueness per workspace. These constraints go beyond what annotations convey, though return value and failure behavior are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all information-dense: the action, the data shape reference, and domain-specific rules. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given minimal schema and no output schema, the description covers key aspects: how to discover fields, prerequisites for custom fields, and contact validation rules. It does not explicitly detail requirements for company/deal/activity records, but the pointer to relm_describe_schema addresses that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only documents the 'object' enum; the 'data' parameter is just 'type: object'. The description explains that 'data' contains the object's fields and directs to relm_describe_schema, while also giving concrete examples of valid contact identifiers, adding substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a record' and the input schema's enum (contact/company/deal/activity) defines the resource. This distinguishes it from sibling create tools like relm_create_field and relm_create_pipeline, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage context: it references relm_describe_schema for field discovery, points to relm_create_field as a prerequisite for custom fields, and specifies contact data requirements. It also warns against inventing placeholder emails, offering clear exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
