Skip to main content
Glama

Create customer

create_customer

Create a customer for shipping marks and sales orders. Name is required. Optional default_shipping_mark_profile_id must be a shipping_mark profile in this org. Optional idempotency_key. Omit this field when it is not used. Null, an empty string, or only spaces are also treated as omitted. Use a unique value such as a UUID. The same key and the same arguments return the stored result for 24 hours and set idempotent_replay to true. A key still in progress is rejected until the lease expires (15 minutes by default). The same key can also stay reserved until the lease expires (15 minutes by default) after a call failed after writing rows, so check whether those rows were saved before trying again. The same key with different arguments is rejected. A stored result over 200 KB is replaced by a short summary of ids and counts.

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

Input Schema

NameRequiredDescriptionDefault
cityNo
nameYes
emailNo
notesNo
phoneNo
regionNo
countryNo
org_numberNo
vat_numberNo
postal_codeNo
account_codeNo
billing_cityNo
contact_nameNo
address_line1No
address_line2No
payment_termsNo
billing_regionNo
extra_contactsNo
billing_countryNo
idempotency_keyNoOptional. Omit this field when it is not used. An empty string is also treated as omitted. Use a unique value such as a UUID when you send one. Same key and same arguments return the stored result for 24 hours in this organization, with idempotent_replay true. A different payload is rejected.
billing_postal_codeNo
billing_address_line1No
billing_address_line2No
default_shipping_mark_profile_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior4/5

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

Beyond the annotations, the description provides substantial behavior: idempotency-key replay semantics, lease expiry behavior, rejection when the same key is used with different arguments, and truncation of stored results over 200 KB. It does not cover permissions or the normal return shape, but the idempotency disclosure is unusually detailed for a write tool.

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

Conciseness3/5

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

The description is front-loaded with purpose and then moves into parameters, which is structurally sound. However, idempotency edge cases occupy most of the text while many common customer fields are not mentioned, making the balance uneven.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 24-parameter write tool with no output schema, the definition is incomplete. It explains idempotency thoroughly and states the required field, but does not describe the successful creation result or the meaning of most customer attributes an agent may need to populate.

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

Parameters2/5

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

Schema description coverage is only 4% across 24 parameters. The description adds meaning for name, default_shipping_mark_profile_id, and idempotency_key, but leaves most other fields such as email, contact_name, payment_terms, address fields, and extra_contacts undocumented beyond their names and max lengths.

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 clear verb and resource: 'Create a customer for shipping marks and sales orders.' This is distinguishable from siblings like update_customer and create_supplier by resource and action. It stops short of explicitly naming alternatives, so a 4 rather than 5.

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 the intended domain context ('for shipping marks and sales orders') and required inputs, but does not explain when to use this tool versus alternatives such as update_customer or list_customers. Usage is implied rather than explicitly guided.

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