Skip to main content
Glama

contacts_write

Destructive

Merge, split, update consent of, or delete a contact. merge and delete cannot be undone automatically — confirm with the user. Actions: merge — merge two contacts that are the same person Needs: sourceIdentityId, targetIdentityId. | unmerge — split conversations out of a contact Needs: identityId, convoIds. | set_consent — record the contact marketing consent Needs: identityId, consentStatus. | delete — delete the contact record Needs: identityId.

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": {
      "action": "<action>",
      "agentId": "<agentId>"
    },
    "name": "contacts_write"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNocompact (default) = light mode: long text is cut and bulky blobs are replaced by a size marker. full = complete API response.
actionYes
agentIdYes
convoIdsNoFor unmerge: conversations to split into a new contact.
identityIdNo
consentSourceNoWhere the consent came from, e.g. "web form".
consentStatusNo
sourceIdentityIdNoFor merge: the contact that disappears.
targetIdentityIdNoFor merge: the contact that is kept.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds critical value beyond them: it explicitly states merge and delete cannot be undone automatically and should be confirmed with the user. That irreversibility context for the destructive actions is exactly the supplemental detail wanted.

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?

The irreversibility warning is front-loaded before the action list, and each action entry is a tight, structured sentence. There is minor repetition in restating the action names, but overall it is efficient and easy to scan.

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 destructive, multi-action mutation tool with no output schema, the description covers the intent, per-action requirements, and the key safety caveat. It does not explain return values or the mode parameter, but the schema handles mode, leaving only minor gaps.

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?

With schema coverage at 56%, the description meaningfully compensates by mapping which parameters each action requires (e.g., sourceIdentityId/targetIdentityId for merge, identityId/convoIds for unmerge). It adds the action-to-parameter relationship the schema alone does not express, though agentId and the delete/set_consent specifics remain lightly documented.

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?

The description opens with specific verbs (merge, split, update consent, delete) and the resource (contact), and enumerates each action with its own meaning. This clearly distinguishes it from the read sibling contacts_read and lets an agent understand the tool without opening the 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?

It gives per-action guidance (what each action does and which params it needs) and an explicit prerequisite-style warning to confirm merge/delete with the user. It does not name an alternative sibling (e.g., contacts_read) or state when-not-to-use, so it falls just short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources