Nextmail

Update contact

updateContact

Destructive

Change a contact’s name, the notes kept against it or its custom fields. Passing null clears a field; leaving it out leaves it alone. attributes changes only the custom fields it names. The address cannot be changed here. A contact IS its address, so a different address is a different contact: createContact makes it and deleteContact removes the old one.

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": "updateContact"
  }
}

Input Schema

Name	Required	Description
`name`	No
`email`	Yes
`notes`	No
`attributes`	No	Custom 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.

First observedOct 25, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds the crucial destructive detail the annotations cannot express: null clears a field while omission preserves it, and attributes is a partial merge rather than a wholesale replacement. The remaining gap is that it never says what the response looks like or what happens on an unknown email, which matters with no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences with no filler; the mutable-field list and the null/omit rule come first, and the address restriction follows immediately as the reason an agent might pick a sibling instead.

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 4-parameter mutation tool with a nested object, no output schema and only partial schema descriptions, it covers the destructive edge cases and the sibling routing well. It is only incomplete on invocation outcomes (error behavior, whether the update is atomic) and on the role of the required email parameter.

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?

At 25% schema coverage only the attributes object is documented structurally, so the description carries most of the weight: it explains null-vs-absent semantics for name/notes, that attributes touches only named keys, and that the address is not editable here. It does not explain that the required email parameter is the identifier of the contact being modified, which is the one remaining ambiguity.

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?

Names a specific verb and resource (update a contact) and enumerates exactly which parts of it are mutable: name, notes, custom fields. It explicitly carves out the address and points to createContact/deleteContact, so an agent can tell it apart from saveContact, updateContactCard and createContact without opening their schemas.

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?

Gives explicit when-to-use semantics ('passing null clears a field; leaving it out leaves it alone' and 'attributes changes only the custom fields it names') plus a clear when-not: the address cannot be changed here, and a different address is a different contact handled by createContact/deleteContact. Alternatives are named with the condition that selects them.

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

All Nextmail tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.