Skip to main content
Glama

Update Customer

updateCustomer
DestructiveIdempotent

Update Customer

Partially update a customer by id. Only fields present in the body are changed: email, phone, first_name, last_name, location_slug, and address fields. Phone is stored and normalized to E.164 the same way as POST /customers. Returns 409 when the new email or phone already belongs to a different customer in this project. Updating a customer to its own current email or phone is allowed. To create or match by contact fields without an id, use POST /customers (email first, then phone).

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": {
      "id": "<id>"
    },
    "name": "updateCustomer"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesUnique numeric identifier for the customer.
cityNoCity for the address.
emailNoEmail address for the person or customer.
phoneNoPhone number for the person or customer. Normalized to E.164 when saved, the same way as create/upsert.
stateNoState, province, or region for the address.
address1NoPrimary street address line.
address2NoSecondary street address line, such as suite or apartment.
last_nameNoCustomer last name.
first_nameNoCustomer first name.
postal_codeNoPostal or ZIP code for the address.
location_slugNoSlug of an existing project location. Returns 404 if the slug is not found. Accepts at most 100 characters.

Output Schema

NameRequiredDescriptionDefault
codeNoApplication-level status code returned by this API.
dataNoCustomer record with optional nested entities.
successNoIndicates whether the request completed successfully.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / location_slug / description
      Previous value: -"Slug of an existing project location. Returns 404 if the slug is not found."New value: +"Slug of an existing project location. Returns 404 if the slug is not found. Accepts at most 100 characters."
  2. Added

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 idempotentHint=true, but the description adds real context beyond them: 409 on duplicate email/phone, the carve-out that re-submitting a customer's own current values is allowed, E.164 phone normalization, and partial-update semantics. It does not explain what the destructiveHint actually implies for address fields (e.g. whether omitted address parts are preserved or cleared), which is the one behavior an agent still has to guess.

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-loads the operation and the partial-update rule, then layers conflict, normalization, and alternative-tool guidance in a logical order with no filler. The only waste is the redundant 'Update Customer' heading repeating the title, and the API-route phrasing ('POST /customers') assumes REST familiarity.

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?

With an output schema present, return values need not be described, and the definition covers mutation semantics, conflict handling, normalization, and the sibling alternative. What remains unstated is the failure mode when the id itself does not resolve and the precise interaction between destructiveHint and address subfields, a modest gap for an 11-parameter mutation.

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

Parameters3/5

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

Schema description coverage is 100%, so every one of the 11 parameters is already documented, including phone normalization and the location_slug 404. The description mostly restates the field list the schema already carries, adding only the confirmation that absent fields are untouched. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Partially update a customer by id') plus the exact scope of what changes ('Only fields present in the body are changed'), then enumerates the mutable field set. An agent can distinguish this from createCustomer or the sibling updateCustomerNotes/updateCustomerTags tools without opening any schema.

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 an explicit alternative and the condition that selects it: 'To create or match by contact fields without an id, use POST /customers (email first, then phone).' It also clarifies the id-required precondition, so the agent knows this tool is never the right choice without an existing customer id.

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