Skip to main content
Glama

get_customer

Read-only

Retrieve a single customer by ID from your Checkout Page account.

Returns one customer record directly by ID, without pagination.

Use list_customers first if you need to discover a customer ID by email or name. Use this tool when you already have the ID.

If the customer ID does not exist, returns a 404 error: "Customer not found".

For modification requests, show what's currently stored. The merchant can edit the customer record directly in the Checkout Page dashboard. The customer can also update their own details through the customer portal. For data deletion (GDPR/privacy), this requires human intervention in the dashboard.

The top-level address field is the billing address. The shipping.address field is the shipping address. These are separate and often don't match. When asked about "my address" without specifying which, present both addresses clearly labelled (e.g. "Billing address: … / Shipping address: …"). Don't return only one when both exist, and don't return the billing address in response to a shipping address question.

Customer records are identity/profile only — no purchase history, no transaction amounts.

Cross-tool routing:

To see what this customer has bought, use their id as the customerId filter on the transaction tools:

  • list_payments(customerId: "...") — one-time purchases, digital products, invoices.

  • list_bookings(customerId: "...") — event tickets and registrations.

  • list_subscriptions(customerId: "...") — recurring billing.

Records do not overlap between transaction tools — a transaction only appears in one tool. No risk of double-counting when combining results.

For a complete customer picture, call get_customer for profile data, then query the transaction tools with the same ID.

Example uses (not exhaustive):

  • "Fetch customer 6812fe6e9f39b6760576f01c" → direct lookup by ID

  • "Show me the full customer profile for this customer ID" → returns all available fields

  • "Show me the profile and orders for customer X" → get_customer for profile, then fan out to transaction tools with customerId

Example customer support uses:

  • Customer asking what information is stored about them — look up by ID, return all stored profile fields. Note that customer records only contain profile data — for a complete picture of what's stored, also query the transaction tools with customerId to show their purchase history.

  • Customer wants to update their address, phone number, or email — look up current profile, present what's on file. The merchant can edit the customer record directly in the Checkout Page dashboard. The customer can also update their own details through the customer portal.

  • Customer says the name on their account is wrong — look up profile, check name field. If a shipping.name also exists and differs, present both. The merchant can update the name in the Checkout Page dashboard; the customer can update it via the portal.

  • Customer requesting deletion of their personal data — GDPR/privacy request. Look up the full profile, show what's stored, and explain that data deletion requires human intervention in the Checkout Page dashboard.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
customerIdYesThe ID of the customer to retrieve. Use `list_customers` first if you need to discover the customer ID by name or email.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover the read-only/non-destructive profile, and the description adds substantial context beyond them: the 404 error text for missing IDs, no pagination, the identity-only scope (no purchase history), the non-overlapping transaction tools, and that deletion requires human intervention in the dashboard.

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?

Well front-loaded with purpose and routing, but bloated and repetitive: the dashboard/portal edit path and the GDPR deletion requirement each appear twice (once in the body, once under 'Example customer support uses'). Multiple example sections restate the same guidance.

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 an output schema exists, return values needn't be explained, yet the description still covers the billing vs. shipping address distinction, identity-only scope, and routing to transaction tools. Nothing an agent needs to call it correctly is missing.

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 coverage is 100% with a documented pattern and the 'use list_customers first' hint already in the schema, so the description largely repeats the schema's ID semantics. Baseline 3 is appropriate since the schema does the heavy lifting for the single parameter.

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 ('Retrieve a single customer by ID') and immediately scopes it ('without pagination', 'one customer record directly by ID'). It explicitly distinguishes itself from the sibling list_customers by clarifying that it is for when you already have the ID.

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?

Names the alternative (list_customers) and the exact condition that selects it (discovering an ID by email/name), and adds cross-tool routing to list_payments/list_bookings/list_subscriptions with the customerId filter. It also states when-not behavior (ID not found returns 404).

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