Simpler.Asia

contact_create

Create a contact and, in the same call, log its first note and/or first interaction — the composite first-touch door. Children validate before the contact write; if the contact commits but a child then fails, the error names the contact's id plus the exact call to finish it, never a silent orphan. A contact with the same email or phone already in this tenant refuses with CONFLICT. NEXT: contact_upsert merges into an existing contact instead of creating a duplicate.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "contact_create"
  }
}

Input Schema

Name	Required	Description
`name`	No
`note`	No	Log a first note in the SAME call — ONE call makes both.
`tags`	No
`email`	No
`notes`	No	Alias of note.
`phone`	No
`source`	No
`status`	No
`address`	No
`company`	No
`interaction`	No	Log the first interaction in the same call: {type, summary, occurred_at?} — occurred_at takes "YYYY-MM-DD".
`last_contact_at`	No
`first_interaction`	No	Alias of interaction.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only say it is a non-idempotent, non-destructive write. The description adds substantial context beyond that: children validate before the write, partial failure leaves a recoverable contact whose id is returned with a completion call, and duplicate email/phone in the tenant yields CONFLICT. This is exactly the non-atomicity and uniqueness behavior an agent needs to plan retries.

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 core purpose, then failure semantics, then the sibling pointer. Slightly dense sentences ('the error names the contact's id plus the exact call to finish it') but every clause carries real information; no filler.

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 13-param mutation tool with no output schema and no annotations covering failure modes, the description covers the riskiest behaviors: atomicity, conflict handling, and recovery. It falls short only on per-parameter meaning and on what a successful response contains beyond the id hint in the failure path.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 31% across 13 params, so the description must carry weight; it only clarifies the composite note/interaction inputs, which the schema already describes. Nine-plus params (name, email, phone, tags, source, status, address, company, last_contact_at) get no semantic help in the description. The composite first-touch explanation is useful, but it does not compensate for the coverage gap.

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?

States a specific verb and resource (create a contact) plus a distinctive composite capability (log first note and/or first interaction in the same call) and labels it the 'composite first-touch door'. This is clearly distinguishable from contact_upsert and from contact_note_create/interaction_create, which the description implies would otherwise be separate calls.

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 names the alternative: 'contact_upsert merges into an existing contact instead of creating a duplicate', giving the agent a decision rule. The composite framing ('and, in the same call') also tells the agent when this is preferable to separate note/interaction calls.

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

All Simpler.Asia 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?