Kash.click

Edit a client

client_edit

Idempotent

Edit an existing customer by their ID. All fields are optional except the ID. Use data_list_clients to find the customer ID first.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	ID of the customer to modify
`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

A4/5.0

Behavior3/5

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

Annotations already provide idempotentHint and destructiveHint. Description adds that all fields except ID are optional, implying partial updates, but doesn't detail behavior beyond annotations.

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?

Two concise sentences that front-load the core purpose and essential usage note. No superfluous information.

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?

Description covers the essential workflow (find ID first, then edit) and tool purpose. With 26 parameters well-documented in schema, no further detail is crucial. Lacks output format info, but acceptable without output schema.

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%, so description adds no additional meaning to parameters beyond what the schema already provides. Baseline score is appropriate.

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?

Title and description clearly state 'Edit a customer by their ID', with explicit field constraints and a prerequisite tool mention. Distinguishes from sibling tools like client_add and client_delete.

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?

Explicitly instructs to use data_list_clients to find the customer ID first, guiding when to use this tool. No explicit when-not, but the guidance is clear and practical.

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?