Retrieve inventory counteragents (suppliers, clients, employees) for an organization to support invoice processing. Filter by type and apply pagination.
Список контрагентов. Где взять ID: organizationId → organizations__get_organizations. Троттлинг MCP-сервера (не лимит iikoCloud): не чаще 10 запрос(ов) за 60 с — кэшируйте результат в диалоге.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool's safety profile is covered. The description adds a valuable behavioral constraint: the MCP server rate limit (10 requests/60s) and a recommendation to cache results, which goes beyond the structured annotations.
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 two sentences, front-loads the primary purpose, and contains no filler. It efficiently communicates the action, the ID source, and the throttling constraint, making every sentence earn its place.
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 read-only list tool with a safe annotation profile, the description covers the essential operational details: purpose, ID sourcing, and rate limiting. It does not describe the response format, but with no output schema and a straightforward list return, this is acceptable. The absence of an explicit note about the 'request' wrapper in the schema is mitigated by the schema itself.
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?
With 0% schema description coverage at the top level, the description needs to compensate for parameter meaning. It adds one useful piece: how to source organizationId via organizations__get_organizations. However, it does not explain the type, limit, or offset parameters, leaving them entirely to the schema's nested descriptions.
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 states 'List of counterparties' (Список контрагентов), which is a specific verb and resource. It clearly identifies the tool's purpose, and no sibling tool targets the same resource, so it is distinguishable. However, it does not explicitly mention the 'inventory' context beyond the tool name, which slightly limits differentiation.
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 provides explicit guidance on obtaining the organizationId via organizations__get_organizations, and includes a concrete rate-limit and caching instruction. This gives the agent clear operational context, though it does not explicitly contrast the tool with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.