Skip to main content
Glama

Find a customer by name, email or number (fuzzy)

easybill_find_customer
Read-onlyIdempotent

Find existing customers by name, email, number, or city. Prevent duplicate records before creating invoices or offers, with fuzzy matching for typos and legal form differences.

Instructions

Search for an existing customer by company name, person name, email, customer number or city.

USE THIS FIRST whenever you need to know whether someone is already a customer — for example before creating an offer or invoice from an inbound inquiry. The easybill API has no full-text search, so this tool combines exact filters with a local fuzzy match over the customer list.

It tolerates the differences that break exact matching: legal forms ('GmbH & Co. KG'), punctuation ('M.B. MUSTERMANN' vs 'MB Mustermann'), umlauts, and word order.

Args:

  • query (string): what to search for. A company name, surname, email or customer number.

  • limit (number): max candidates to return, 1-25 (default 5).

  • min_score (number): 0-1 match threshold (default 0.5). Lower it to cast a wider net.

  • max_pages (number): how many pages of 1000 customers to scan in the fallback (default 3). Each page is one API request, so keep this low on a plan with a 10 req/min limit.

Returns: { query, match_count, exact_match (boolean), candidates[] } where each candidate has its easybill 'id', 'match_score' (1 = certain) and the usual summary fields.

Next steps based on the result:

  • Exactly one strong candidate (score 1) -> use its 'id' as customer_id.

  • Several candidates -> show them to the user and ask which one, do NOT guess.

  • No candidates -> the customer does not exist yet. Create it with easybill_create_customer, then use the returned 'id'.

Examples:

  • "Is Mustermann Handels GmbH & Co. KG already a customer?" -> query="Mustermann Handels GmbH & Co. KG"

  • "Find the customer with email einkauf@example.com" -> query="einkauf@example.com"

  • "Look up customer number 10023" -> query="10023"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax candidates to return.
queryYesCompany name, person name, email address, customer number or city.
max_pagesNoPages of 1000 customers to scan in the fuzzy fallback. Each costs 1 request.
min_scoreNoMinimum match score, 0-1. Lower for a wider net.
response_formatNoOutput format: 'markdown' for readable prose, 'json' for machine-readable datamarkdown
Behavior5/5

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

The description richly discloses behavior beyond the readOnly/idempotent annotations: it explains the fuzzy matching process, tolerance for legal forms/punctuation/umlauts/word order, the paginated fallback over 1000-customer pages, and rate-limit implications ('keep this low on a plan with a 10 req/min limit'). It also details the exact return structure and operational next steps, providing full transparency.

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 front-loaded with the essential purpose ('Search for an existing customer...') followed by usage guidance and a well-structured Args/Returns/Examples format. Every sentence earns its place, and the length is justified by the tool's complexity. The structure makes it easy to scan and extract key decision rules.

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?

The description is highly complete for a complex tool: it explains purpose, usage, fuzzy matching behavior, return shape, and next-step actions even without an output schema. The only notable gap is the undocumented response_format parameter, which could alter the return format despite the 'Returns' section assuming a JSON object. Otherwise, the description covers all critical aspects.

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?

Although the schema covers 100% of parameters, the description adds operational context: min_score is described as a 'match threshold' with advice to 'lower it to cast a wider net'; max_pages notes each page costs one API request; limit is tied to candidate count. However, response_format is absent from the description's Args list despite being in the schema, and its behavioral impact (markdown vs. JSON) is not explained, so the added value is slightly reduced.

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 a specific verb+resource: 'Search for an existing customer by company name, person name, email, customer number or city.' It explicitly distinguishes itself from siblings by stating 'USE THIS FIRST whenever you need to know whether someone is already a customer' and highlighting fuzzy matching capabilities, which list_customers and get_customer lack.

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?

The description gives explicit when-to-use guidance: 'USE THIS FIRST whenever you need to know whether someone is already a customer — for example before creating an offer or invoice.' It also explains why (API has no full-text search) and provides 'Next steps' that dictate when to use this tool vs. creating a new customer, offering clear decision support.

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