Kash.click

Add a client

client_add

Add a new customer to the shop's customer file. All fields are optional: name, surname, email, phone, address, company registration number, VAT number, barcode, private/public comment, blacklist status, birth date, etc. Use data_list_clients to check if the customer already exists first.

Input Schema

TableJSON Schema

Name	Required	Description
`lat`	No	GPS latitude of the customer address
`lng`	No	GPS longitude of the customer address
`city`	No	City
`name`	No	Customer first name
`email`	No	Customer email address
`phone`	No	Primary phone number
`title`	No	Honorific or title (e.g. Mr, Mrs, Company)
`VATnum`	No	VAT registration number
`phone2`	No	Secondary phone number
`barcode`	No	Customer loyalty card barcode
`country`	No	Country
`surname`	No	Customer surname / last name
`position`	No	Sort order / priority within the customer list
`postcode`	No	Postal/ZIP code
`birthDate`	No	Date of birth (YYYY-MM-DD or timestamp)
`blacklist`	No	1 to blacklist this customer
`activityCode`	No	Accounting activity code
`addressline1`	No	Street address line 1
`addressline2`	No	Street address line 2
`adressComment`	No	Delivery instructions or address comment
`clientGroupID`	No	ID of the customer group/segment
`commentPublic`	No	Note visible to the customer
`commentPrivate`	No	Internal staff-only note
`identificationID`	No	National ID or passport number
`registrationNumber`	No	Company registration number (SIRET, etc.)

TDQS

A3.9/5.0

Behavior2/5

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

Annotations only show idempotentHint=false and destructiveHint=false, placing the transparency burden on the description. The description does not disclose behavioral traits beyond creation, such as whether duplicate checks occur, required permissions, or what happens on failure. It simply states 'Add a new customer,' lacking depth.

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?

Three sentences with no waste: first sentence states purpose, second lists fields and optionality, third gives usage guidance. Front-loaded with the core action. Every sentence earns its place.

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

Completeness3/5

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

Given 25 optional parameters and no output schema, the description covers purpose, optionality, and a pre-check step. However, it omits what the tool returns (e.g., client ID) and any error or side-effect behavior, leaving gaps for an agent to operate correctly.

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 baseline is 3. The description adds value by explicitly stating 'All fields are optional' and listing key fields like name, surname, email, etc., which reinforces the schema's implication of optionality and highlights important parameters.

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 'Add a new customer to the shop's customer file.' using a specific verb ('add') and resource ('customer'). It distinguishes from sibling tools like data_list_clients (listing) and client_delete (deletion) by focusing on creation.

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 explicit when-to-use guidance: 'Use data_list_clients to check if the customer already exists first.' This encourages a best practice prerequisite. However, it does not explicitly mention when not to use this tool (e.g., for updating existing customers, which would be client_edit).

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

All Kash.click tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct entity or action (account, client, order, product, payment, VAT, etc.), with clear naming like 'account_create' vs 'account_edit' and 'data_list_' prefixed listings. No overlapping purposes detected.

Naming Consistency5/5

All tool names use snake_case and follow a consistent verb_noun pattern (e.g., account_create, client_add, data_list_clients). Even compound names like auth_login_with_otp adhere to this structure.

Tool Count4/5

41 tools is high but justified by the wide scope of a POS/accounting system (accounts, clients, orders, products, payments, VAT, reports). Slightly above the typical range but well-scoped.

Completeness5/5

The tool surface covers CRUD for all major entities (clients, departments, products, VAT, payment modes, orders), plus queries, reports, and authentication. No obvious gaps for a small business management server.

Resources

Need Help?