Skip to main content
Glama

List customers

easybill_list_customers
Read-onlyIdempotent

List easybill customers with filters for name, email, country, and more. Paginate through results to retrieve customer data efficiently.

Instructions

List customers from easybill with optional filters and pagination.

NOTE: easybill has no fuzzy full-text customer search. The filters below match exact values (though each accepts several comma-separated values). To find a customer by a partial name, filter on company_name or last_name with the exact spelling, or page through the list and match locally.

Returns a compact field set by default; pass 'fields' for specific columns or ['all'] for everything.

Returns: { total, count, page, pages, has_more, next_page, items[] }. Use 'next_page' to continue paging. Monetary values are integers in cents (150 = 1.50 EUR).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number, starting at 1. Use 'next_page' from a previous response to continue.
limitNoItems per page, 1-1000 (default 25). Keep this small unless you need bulk data.
emailsNoFilter by email address. Accepts one value or a list of values.
fieldsNoLimit returned columns to these field names (e.g. ['number','amount','paid_at']). Pass ['all'] for every field. Omit for a compact default set. Fewer fields = less context used.
numberNoFilter by your customer number. Accepts one value or a list of values.
countryNoFilter by country (ISO 2-letter code, e.g. 'DE' or 'DE,AT,CH'). Accepts one value or a list of values.
group_idNoFilter by customer group ID. Accepts one value or a list of values.
zip_codeNoFilter by postal code. Accepts one value or a list of values.
last_nameNoFilter by exact last name. Accepts one value or a list of values.
created_atNoFilter by creation date. Single date 'YYYY-MM-DD' or an inclusive range 'YYYY-MM-DD,YYYY-MM-DD'
first_nameNoFilter by exact first name. Accepts one value or a list of values.
company_nameNoFilter by exact company name. Accepts one value or a list of values.
response_formatNoOutput format: 'markdown' for readable prose, 'json' for machine-readable datamarkdown
additional_group_idNoFilter by an additional customer group ID. Accepts one value or a list of values.
Behavior5/5

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

Beyond the readOnlyHint/idempotentHint annotations, the description reveals important behavior: filters match exact values, returns a compact field set by default, monetary values are integers in cents, and pagination uses 'next_page'. This is substantial added context about how the tool behaves.

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

Conciseness5/5

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

The description is well-structured, leading with purpose, followed by a brief note on limitations, then output format and response structure. Each sentence adds essential information without redundancy, making it both concise and highly informative.

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 list tool with 14 parameters and no output schema, the description covers return structure, pagination, default fields, and the exact-match behavior, which are all critical. It also preempts confusion with the fuzzy-search note, making it complete for the tool's complexity.

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

Parameters4/5

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

Schema description coverage is 100%, so parameters are documented. The description adds extra value by explaining that all filters match exact values (including comma-separated inputs), and clarifies the 'fields' parameter's effect on output. This goes beyond the schema's individual property descriptions.

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 action 'List customers' with the resource 'from easybill' and notes optional filters and pagination. This distinguishes it from sibling tools like get_customer or find_customer, and the NOTE adds meaningful scope by clarifying there is no fuzzy search.

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?

Explicitly warns that 'easybill has no fuzzy full-text customer search' and instructs users to filter on partial names via exact spelling or page through the list, effectively explaining when to use this tool and how to work around its limitations. This is clear usage guidance with alternatives.

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/stack74/easybill-mcp'

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