Skip to main content
Glama

Update contact

update_contact
DestructiveIdempotent

Update a contact's full record in MailFathom, setting name, addresses, preferred address, and note. Read the existing record first to avoid overwriting needed data.

Instructions

Amends one person in MailFathom's own contact book. State the whole record you want them to have — the name, every address, which one is preferred, and the note — rather than only what changes: an address the new record does not name is removed, and an omitted note clears the one held. Read the contact with get_contact first so nothing is dropped by accident. Writes to local state only, and touches no mail. A contact this deployment collected from arriving mail answers contactWasCollected: only the operator can take such a record on, through mfctl, and it can then be amended.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoWhat the note is to say afterwards, up to 4000 characters. Omit or send empty to clear it; sending the note back unchanged is what keeps it.
addressesYesEvery mail address the contact is to hold afterwards, at most 32 entries, two spellings of one address counting as two entries and stored as one. An address the record no longer names is removed and becomes free for another contact to claim; one another contact already holds refuses the write.
contactIdYesThe contactId of the person to amend, as a listing or an earlier write returned it.
displayNameYesThe name the contact is to carry, up to 256 characters. Characters that render as nothing are refused.
preferredAddressYesThe address to use by default afterwards. Must be one of addresses.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
stateYesHow the write ended. written means the book holds the record; notFound means no contact of that identifier is in the book; addressHeldByAnotherContact means one of the addresses already belongs to somebody else, named by addressHolderContactId; contactWasCollected means the record came from mail that arrived rather than from somebody writing it down, so promote_contact it before amending it; alreadyAsserted means a promotion had nothing left to do.
contactNoThe record as the book now holds it, or null. Only a write whose record you supplied publishes one: create_contact, update_contact, add_contact_address, and remove_contact_address answer with the record when they succeed, while promote_contact answers with the outcome alone and is read back with get_contact.
addressHolderContactIdNoThe identifier of one contact that already holds an address this write claimed, or null when that is not what stopped it. Read that contact with get_contact to see who it is; a record may clash with more than one person, and this names one of them.
Install Server

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=true), the description discloses specific destructive behaviors: 'an address the new record does not name is removed, and an omitted note clears the one held.' It also states the scope of side effects ('Writes to local state only, and touches no mail') and the contactWasCollected restriction, providing rich operational context that annotations do not cover.

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?

Three sentences, each earning its place: the first states purpose, the second explains the whole-record replacement model and key consequences, the third covers scope, prerequisites, and special limitations. The information is dense but structured, with no filler or repetition of the schema.

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?

Given moderate complexity (5 params, output schema present), the description covers purpose, usage guidance, preconditions, destructive side effects, scope (local state only, no mail), and a specific exception (contactWasCollected). It does not need to list return values because an output schema exists. The description is sufficient for an agent to safely and correctly invoke the tool.

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

Parameters5/5

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

Although the schema already describes each parameter 100%, the description adds critical collective semantics: 'State the whole record you want them to have — the name, every address, which one is preferred, and the note — rather than only what changes' explains that the parameters jointly define the desired final state, not a delta. It also explains consequences (removal of unnamed addresses, note clearing) that tie parameters together, going beyond the isolated per-field schema descriptions.

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 'Amends one person in MailFathom's own contact book,' using a specific verb ('Amends') and resource ('one person' in the contact book), clearly distinguishing it from siblings like create_contact (new), delete_contact (removal), and get_contact (read). It further clarifies it is not a mail operation, avoiding confusion with mail-focused tools.

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?

It provides explicit when-to-use guidance: 'Read the contact with get_contact first so nothing is dropped by accident' establishes a prerequisite. It also gives an exclusion/alternative: for contacts collected from arriving mail (contactWasCollected), only an operator via mfctl can take on the record, implying the tool should not be used for such contacts. Additionally, 'Writes to local state only, and touches no mail' sets boundaries for its scope.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Krzysztof318/MailFathom'

If you have feedback or need assistance with the MCP directory API, please join our Discord server