Skip to main content
Glama

Save contact

saveContact
Destructive

Save somebody as a contact, the way Add to contacts and Keep in contacts do on the Contacts page. An address that is not a contact yet becomes one; one recorded from a send is kept as added by hand; one already saved stays as it is. A name given replaces the stored name and one left out keeps it; notes given replace the stored notes, null clears them. attributes sets the custom fields it names and keeps the rest. A deleted address is brought back. Adding a contact sends nothing and subscribes nobody.

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": {
      "email": "<email>"
    },
    "name": "saveContact"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNo
emailYes
notesNo
attributesNoCustom fields to set on the contact, as an object of keys and text values. A key starts with a letter and holds up to 64 letters, digits and underscores, a value is text of at most 500 characters, and a contact holds at most 50 fields. Null or an empty string removes a field, and a field left out keeps its value.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Despite destructiveHint=true, the description discloses exactly what is destroyed or overwritten: name replaces stored name, notes replace (null clears), attributes sets named fields and keeps the rest, deleted addresses are revived. It also states the absence of side effects: 'Adding a contact sends nothing and subscribes nobody.' This is materially richer than the annotations.

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 operation and behavior in dense, purposeful sentences. The 'the way Add to contacts and Keep in contacts do on the Contacts page' clause is UI-oriented padding that adds little for an agent.

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 4-param mutation with no output schema, the description covers creation, merge behavior, revival of deleted contacts, and side-effect absence — everything needed to call it safely. Only the response shape is unspecified, which is acceptable given no output schema.

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 only 25%, and the description compensates by defining merge semantics for name, notes and attributes (given replaces, omitted keeps, null clears) that the schema does not convey. Email is only implied via 'address', keeping it just short of full coverage.

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 ('Save somebody as a contact') and immediately defines the operation as an upsert: 'An address that is not a contact yet becomes one.' An agent can distinguish this from createContact/updateContact from the text alone.

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?

Explains the three states (not a contact, recorded from a send, already saved) and how each is handled, which effectively tells an agent when this tool applies. It does not explicitly name createContact or updateContact as alternatives, so it stops short of full routing guidance.

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.