Fetch customer details by loyalty customer ID. Use this tool to retrieve specific customer information from iikoCloud for verification, lookups, or data processing.
Получить клиента по ID (loyalty customer id). Это тул-обёртка: своего троттлинга нет, но вызов расходует квоту нижележащего метода API — кэшируйте результат в диалоге.
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | Yes | ||
| organization_id | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false, but the description adds significant behavioral insight: it is a wrapper with no own throttling, yet consumes the underlying API's quota. It also advises caching results in the dialogue. This goes beyond annotation data and helps the agent plan calls safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, with the core purpose front-loaded and the behavioral note placed after. Every word adds value, with no repetition or filler. It is structurally optimal for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with low complexity, the description covers purpose and a key behavioral caveat. However, it omits meaning for organization_id and does not describe the return value or any pagination/error behavior (no output schema exists). An agent could call it, but might misuse organization_id or misinterpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for both parameters. It only clarifies customer_id as 'loyalty customer id'; organization_id is not mentioned at all. The description does not explain the role or format of organization_id, leaving a significant gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Get a customer by ID (loyalty customer id)'. It names the exact resource (customer) and the identifier type (loyalty customer id), distinguishing it from sibling lookup tools that use phone, email, or card track. This makes the purpose unambiguous and differentiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only implies usage: when you have a loyalty customer ID. It does not explicitly state when to use this tool versus alternatives like get_customer_by_phone or get_customer_by_email, nor does it provide conditions or exclusions. The caching advice is operational guidance, not tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.