Skip to main content
Glama
Sign In

Mailercloud

by com.mailercloud.mcp
OverviewDiscussionsAdmin

update_contact

DestructiveIdempotent

Update fields on an existing contact. Allowed fields: first_name, middle_name, last_name, phone, company_name, city, state, country, postal_code, job_title, department, industry, lead_source, contact_type (active, bounce, abuse, unsubscribe, suppressed, spam complaints — e.g. unsubscribe to stop Marketing Platform campaigns reaching the contact; a contact_type change returns a preview and applies only with confirm: true), tags, custom_fields. Do not include sensitive personal data (health, financial, government ID, payment card, passwords).

Input Schema

NameRequiredDescriptionDefault
fieldsYesFields to update
confirmNoRequired when fields include contact_type: set true only after the user agrees to the status change shown in the preview
dry_runNoValidate and show what would be sent without changing anything
contact_idYesContact ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / contact_id / description
      Previous value: -"Contact ID,required"New value: +"Contact ID"
    • changedInput schema / properties / fields / description
      Previous value: -"Fields to update,required"New value: +"Fields to update"
  2. Changed1 schema field changed
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "Required when fields include contact_type: set true only after the user agrees to the status change shown in the preview",
+  "type": "boolean"
+}
  3. Changed2 schema fields changed
    • removedInput schema / properties / api_key
      Removed value: -{
-  "description": "MailerCloud API key",
-  "type": "string"
-}
    • addedInput schema / properties / dry_run
      Added value: +{
+  "description": "Validate and show what would be sent without changing anything",
+  "type": "boolean"
+}
  4. First observed

TDQS

A4/5.0
Behavior4/5

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

The annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true. The description adds useful behavior beyond annotations: contact_type changes are previewed and applied only with confirm: true, and sensitive data must be excluded. It does not fully describe the destructive scope or return behavior, but the annotations lower that burden.

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 description is front-loaded with the action and allowed fields, and the sensitive-data warning is relevant. It is dense because of the long field list and parenthetical contact_type guidance, but every part serves a purpose.

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 mutation tool with nested fields and no output schema, the description covers the key operational constraints: allowed fields, sensitive-data exclusion, and the contact_type preview/confirm flow. It could say more about return values or partial-update behavior, but the core calling information is present.

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?

Schema coverage is 100%, but the schema only describes the fields object generically as 'Fields to update' with additionalProperties true. The description supplies the critical allowed field list and clarifies contact_type values and the preview/confirm condition, adding substantial meaning beyond the structured schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: update fields on an existing contact. It clearly scopes the operation with an explicit list of allowed fields. It does not explicitly distinguish itself from the sibling upsert_contact tool, though 'existing contact' implies that distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives field-specific operational guidance, notably that contact_type changes return a preview and require confirm: true, and it warns against including sensitive personal data. However, it does not explicitly say when to use update_contact versus alternatives such as upsert_contact, create_contact, or remove_tag_from_contact.

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

All Mailercloud toolsInspect
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