Skip to main content
Glama
chartmogul

ChartMogul MCP Server

Official
by chartmogul

list_customers

Retrieve and filter customer data from ChartMogul to manage subscription relationships, track statuses like Active or Cancelled, and analyze metrics including MRR and ARR.

Instructions

[ChartMogul API] List customers with optional filtering. LIMIT WARNING: Default limit 20. Discourage requesting more than 20 items to avoid excessive token usage. Returns customer objects with: id (integer: internal ChartMogul ID), uuid (string: customer UUID with cus_ prefix), external_id (string: your system ID), name (string: customer/company name), email (string), status (string: New_Lead/Working_Lead/Qualified_Lead/Unqualified_Lead/Active/Past_Due/Cancelled), customer_since (ISO 8601 datetime), attributes (object with tags array of strings and custom object with key-value pairs), address (object with address_zip, city, state, country), data_source_uuid (string), data_source_uuids (array), external_ids (array), company (string), country (string: ISO-3166 alpha-2), state (string), city (string), zip (string), lead_created_at (ISO 8601 datetime or null), free_trial_started_at (ISO 8601 datetime or null), mrr (INTEGER CENTS - divide by 100 for actual amount), arr (INTEGER CENTS - divide by 100), billing_system_url (string), chartmogul_url (string), billing_system_type (string), currency (string), currency_sign (string). FILTERS: data_source_uuid (string), external_id (string), status (string: exact match from status values above), system (string: billing system type, case-sensitive). Response includes cursor (string) and has_more (boolean) for pagination. Example: status="Active", system="Stripe"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
data_source_uuidNo
external_idNo
statusNo
systemNo
limitNo
Behavior5/5

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

With no annotations provided, the description carries full burden and delivers excellent behavioral disclosure. It explains the default limit (20), warns about token usage, describes pagination behavior (cursor and has_more), details the return format comprehensively, and specifies filtering options with examples. This goes well beyond basic functionality.

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 information-rich but somewhat dense and could be better structured. While all content is valuable, the single paragraph format with detailed return field listing makes it less front-loaded. The warning and filtering details are well-placed, but the extensive field enumeration could be more efficiently organized.

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?

For a tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description provides exceptional completeness. It covers purpose, usage guidance, behavioral details, parameter semantics, return format, pagination, and examples. Nothing essential appears missing for effective tool invocation.

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?

With 0% schema description coverage, the description fully compensates by explaining all 5 parameters. It details what each filter does (data_source_uuid, external_id, status, system), provides status enum values, specifies system is case-sensitive, and explains the limit parameter with default value and usage warning. This adds substantial meaning beyond the bare schema.

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 clearly states the tool's purpose: 'List customers with optional filtering.' It specifies the resource (customers) and action (list) while distinguishing it from siblings like 'search_customers' by focusing on listing with filters rather than searching. The mention of ChartMogul API context further clarifies scope.

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

Usage Guidelines4/5

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

The description provides clear context for usage with the 'LIMIT WARNING' and filtering options, but doesn't explicitly state when to use this tool versus alternatives like 'search_customers' or 'retrieve_customer'. It mentions filtering capabilities which helps guide usage, but lacks explicit sibling comparison.

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

Install Server

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/chartmogul/chartmogul-mcp-server'

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