Kash.click

Create a Kash account

account_create

Create a new Kash / free-cash-register.net account. Requires an email address and a shop name (accountTitle). Optional: configType to pre-load a dataset matching your business type (e.g. 'Restaurant', 'Bakery', 'Bar', 'Retail'...), plus address and legal info. On success, returns APIKEY and SHOPID and automatically initializes the session so all other tools can be used immediately. IMPORTANT: the user must validate their email via the link sent automatically, otherwise the account may be deleted after a period of inactivity.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No	City name
`email`	Yes	Email address for the new Kash account
`phone`	No	Contact phone number
`country`	No	Country code or name
`currency`	No	Currency code (e.g. EUR, USD)
`language`	No	Language code (e.g. fr, en)
`postCode`	No	Postal/ZIP code
`configType`	No	Pre-loaded dataset type (e.g. Restaurant, Bar, Bakery)
`adressline1`	No	Street address line 1
`accountTitle`	Yes	Display name for the new account
`taxRegistrationNum`	No	VAT / tax registration number
`companyRegistrationNum`	No	Company registration number (SIRET, etc.)

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations (openWorldHint, idempotentHint, destructiveHint), the description discloses critical behavior: returns API key and shop ID, automatically initializes the session for immediate use, and warns about email validation and potential deletion. No contradictions with annotations.

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

Conciseness4/5

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

The description is a single paragraph that front-loads the purpose and efficiently covers required/optional fields, success outcome, and a critical note. It could be slightly more structured, but it is clear and not verbose.

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?

Given the tool's complexity (12 parameters, session initialization, email validation requirement), the description covers all essential aspects: what it does, what is required, what is optional, what happens on success, and an important limitation. No output schema exists, but the description states what is returned (API key and shop ID), which is sufficient.

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 the baseline is 3. The description mentions required fields (email, accountTitle) and points out optional parameters like configType with examples, but adds little meaning beyond what the schema already provides.

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 starts with 'Create a new Kash / free-cash-register.net account,' which is a specific verb+resource. It clearly distinguishes from sibling tools like account_edit, account_list, and account_show_infos, as creation is unique.

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 context on when to use this tool (when creating an account) and includes an important prerequisite: email validation. While it does not explicitly list when not to use it, the context is sufficient to guide the agent.

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?