MoySklad MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v3.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but there is some overlap among stock reports (get_stock, get_stock_by_store, get_stock_current) and among search tools (search_products, search_assortment, search_variants). The descriptions help resolve ambiguity, but an agent might still struggle to pick the right one in edge cases.
Naming Consistency4/5
The naming mostly follows a consistent verb_noun pattern (search_*, get_*, create_*, update_*, list_*, delete_*). However, there is a mix of 'get' and 'list' for collection endpoints (get_orders vs list_invoices_out), and some verbs are more specific than others (update_prices, update_customer_order_status). Overall, the pattern is readable and predictable.
Tool Count2/5
With 60 tools, this is far beyond the 25+ threshold for 'too many'. Even for an ERP-like system like MoySklad, the sheer number makes the toolset unwieldy and difficult for an agent to navigate efficiently. The scope is broad, but the count is excessive.
Completeness3/5
The toolset covers a wide range of MoySklad operations, including products, orders, stock, payments, webhooks, and reports. However, there are notable gaps: many entities only have create and read but lack update and delete (e.g., products, counterparties, payments). The generic get_documents/get_document partially compensate, but the missing CRUD operations create dead ends.
Average 3.4/5 across 60 of 60 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on June 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to lean on, the description carries the full burden of behavioral disclosure. It says nothing about pagination, read-only nature, result format, or any constraints, making it completely uninformative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not appropriately concise; it is under-specified and repeats the name without earning its place. It provides zero informational value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain what services are, how search behaves, and pagination details. It does none of this, and the sibling list shows many similar tools but no differentiation.
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?
The schema provides 100% parameter description coverage for limit, offset, and search. The tool description adds no parameter information, but the high schema coverage establishes a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search services.' simply restates the tool name without adding any specificity. It gives a verb and resource but fails to distinguish this tool from sibling search tools like search_products or search_assortment, making it a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context, exclusions, or alternative tool references are provided, leaving the agent without any decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. The only behavioral detail is 'Prices in RUBLES (converted to kopecks),' which repeats the schema field description and does not disclose side effects, permissions, response format, or workflow implications. The tool might create a draft order or finalize it, but no such detail is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the second sentence about currency is redundant with the schema's price field description. It does not add new information, so it does not fully 'earn its place.' Still, it is not verbose, and the main purpose is stated clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and minimal description, the tool lacks essential context for safe and correct invocation. It doesn't mention, for example, whether the created order is final or draft, what permissions are needed, or what the response contains. The schema covers parameters, but the description fails to provide workflow or side-effect context.
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 description coverage is 100%, with every parameter given a description. The tool description adds no additional parameter meaning beyond what the schema already provides (e.g., the rubric note about prices appears in both places). Baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Create a customer order.' This is specific and unambiguous. However, it does not explicitly distinguish from the sibling 'create_purchase_order' tool, so it misses the opportunity to differentiate beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_purchase_order, update_customer_order_status, or create_sales_return. The description gives no context for selection, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It states the basic intended action but does not disclose side effects (e.g., stock balance impact), required permissions, or what the response contains. This is a thin behavioral description for a mutating operation.
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 concise sentence that front-loads the main purpose. It is efficient, though it omits potentially important guidance, making it slightly under-specified for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no annotations, and no output schema, the description leaves significant context gaps. It does not explain return values, prerequisites, or how this tool fits among many sibling inventory operations, making it incomplete for correct selection and invocation.
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?
The input schema provides descriptions for all parameters (100% coverage), so the description does not need to elaborate on them. The description adds no parameter-level meaning beyond the schema, hence a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('stock enter'), with an added Russian term for context. It explains the effect as adding stock into a warehouse, but does not explicitly distinguish this from related tools like create_supply or create_purchase_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_supply or create_inventory. The description only says what the tool does, not when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions that prices are in RUBLES, which is a behavioral detail already present in the schema. It does not disclose any side effects, permissions required, return value, or whether the operation is reversible. As a mutation tool, this is a significant gap.
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 extremely concise, with two short sentences front-loading the main purpose. However, the second sentence 'Prices in RUBLES' is redundant with the schema, so it doesn't fully earn its place. Still, it's well-structured and quick to read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a create operation with no output schema and no annotations. The description does not explain what happens after creation (e.g., return value, confirmation), nor does it provide context on how this differs from related tools. The parameter schema is complete, but the overall description is incomplete for an agent to fully understand the tool's behavior.
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 description coverage is 100%, so every parameter is described in the schema. The description 'Prices in RUBLES' adds no new information beyond the schema's note on price_rubles. Thus, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a supplier invoice (счёт поставщика)'. It uses a specific verb and resource, and the parenthetical clarifies the Russian term. The currency note 'Prices in RUBLES' adds specificity. However, it doesn't explicitly distinguish from similar tools like create_invoice_out or create_purchase_order, though the tool name suggests the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool versus alternatives, nor any prerequisites or exclusions. For example, there's no mention that this is for supplier invoices as opposed to customer invoices (create_invoice_out) or purchase orders (create_purchase_order).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only states that it creates a service and notes prices are in RUBLES. There is no mention of side effects, required permissions, reversibility, or response characteristics. This is insufficient for a creation operation.
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 very concise with two short sentences, no fluff, and front-loaded with the primary action. However, the second sentence about RUBLES is largely redundant given the schema's field description, slightly reducing its earned value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a creation tool with six parameters, no output schema, and no annotations, the description is extremely minimal. It does not explain what constitutes a 'service' in this domain, how it relates to products, or any business rules. More context is needed for an agent to use it correctly.
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 description coverage is 100%, so the schema documents all six parameters. The description adds a minor emphasis on currency (RUBLES), which is already stated in the sale_price_rubles property description. This adds little value beyond the schema, matching the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a service,' which is a specific verb plus resource. However, it does not differentiate from the sibling tool create_product, which likely has overlapping functionality. The phrase 'Prices in RUBLES' hints at a key constraint but doesn't distinguish the service context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_product or update_prices. There is no mention of prerequisites, use cases, or exclusions. The description simply states what the tool does without contextualizing when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden. It only restates the search parameters and omits behavioral details such as pagination, result type, search matching semantics, or any access constraints.
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?
The description is a single concise sentence, front-loaded with the verb and resource, and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with five optional parameters and no output schema, this description is too sparse. It doesn't mention that it returns a list, how limit/offset work, or how it relates to the singular 'get_counterparty' tool.
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 description coverage is 100%, so the baseline is 3. The description just re-lists name, INN, and phone without adding meaning beyond the schema, such as how filters combine or search behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (search), the resource (counterparties), and the scope (by name, INN, or phone). It does not explicitly distinguish this from the sibling tool 'get_counterparty', which may confuse an agent about which to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description doesn't explain when to choose this tool over alternatives like 'get_counterparty', nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only adds 'Sums in RUBLES' as an additional behavioral detail. It does not disclose pagination behavior, default response format, or that this is a read-only operation. The description is too minimal to provide adequate transparency for a list endpoint with 7 parameters.
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?
The description is extremely concise, consisting of two short sentences. It is front-loaded with the core purpose ('Get customer orders') and the second sentence adds a valuable currency detail. Every sentence earns its place, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema, no annotations), the description is incomplete. It does not explain response structure, pagination behavior, or constraints like the expand limit. The lack of behavioral context makes it insufficient for an agent to fully understand what to expect from the tool.
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 parameters are fully described in the schema. The description adds no parameter-specific meaning beyond 'filtering and sorting', which the schema already covers. Baseline 3 is appropriate since the schema does the heavy lifting and there is no need for description compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves customer orders, with filtering and sorting capabilities. 'Get customer orders' is a specific verb+resource pair, and the plural form implies a list operation, distinguishing it from singular 'get_customer_order'. However, it doesn't explicitly say it lists multiple orders or contrast with purchase orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description mentions filtering and sorting, implying use for listing with options, but it does not explicitly state when to prefer this over get_customer_order for a single order or over get_purchase_orders for purchase orders. No when/when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral details, but it only states that the tool shows quantities and revenue. It does not mention pagination behavior, date filtering, sorting, or whether the operation is read-only. The minimal output summary leaves significant behavioral traits undisclosed.
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?
The description is two short sentences, front-loaded with the primary action and resource, and provides a succinct summary of the output. There is no filler or redundant information, making it an efficient and well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four optional parameters, no output schema, and no annotations. The description only provides a high-level summary of the report, lacking details about response structure, pagination, date range behavior, or how this report differs from similar sibling tools. This is insufficient for an agent to confidently invoke the tool in complex scenarios.
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?
The input schema covers all four parameters with descriptions, so the baseline is 3. The description adds some context by indicating the report is 'by product' and covers quantities and revenue, but it does not clarify parameter-specific behaviors like date range defaults or pagination semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get sales report by product' with a specific verb and resource, and further specifies output as 'quantities sold and revenue'. This provides a clear purpose, though it does not explicitly differentiate from sibling report tools like get_profit_report or get_turnover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to choose this tool over alternatives such as get_profit_report or get_money_report. It lacks any context about use cases, exclusions, or prerequisites, leaving the agent to infer when this report is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. While it implies a read operation via 'Get', it does not explicitly state that the tool is read-only, nor does it mention any limitations, permission requirements, or how pagination/filtering behaves. The return content is partially described, but critical behavioral details are absent.
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?
The description is a single, focused sentence that front-loads the core purpose ('Get current stock/inventory report') and adds a brief but relevant detail about the contents. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's five parameters, lack of output schema, and the existence of sibling tools with overlapping names, this description is under-specified. It does not explain the output structure, how the grouping/filtering options affect results, or how this tool relates to 'get_stock_current' and 'get_stock_by_store'. The absence of usage guidelines and behavioral details leaves significant gaps for an agent.
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?
The input schema has 100% description coverage across all five parameters, so the baseline is 3. The tool description itself adds no additional parameter-level semantics beyond what the schema already provides, such as the meaning of 'stock_mode' or 'group_by'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current stock/inventory report', and mentions the specific data fields (quantities, reserves, in-transit). However, it does not distinguish itself from the similarly named siblings 'get_stock_current' and 'get_stock_by_store', which could lead to confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternative stock-related tools such as 'get_stock_current' or 'get_stock_by_store'. The description provides no exclusions or context for choosing between them, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description was expected to carry behavioral disclosure. It only states 'List product groups/folders' and adds no detail about pagination behavior, ordering, filtering limitations, permissions, or whether archived/inactive groups are included. The schema's limit/offset parameters imply pagination but the description itself is silent.
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?
The description is a single short sentence, instantly conveying the action and resource. There is no filler or redundant information, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description might suffice on its surface, but the lack of annotations, output schema, and any context about what constitutes a 'product group/folder' leaves significant gaps. An agent has no way to know what kind of results to expect or when this tool is more appropriate than search_products. The description is incomplete in guiding correct usage.
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 description coverage is 100% (both limit and offset have descriptions), so the baseline is 3. The description adds no additional meaning about parameters, but it doesn't need to given the schema already documents them clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description has a specific verb ('List') and a resource ('product groups/folders'), making the core purpose clear. However, it does not explicitly distinguish this from sibling tools like search_products or get_product, which could also involve listing/fetching product-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., search_products for filtered queries, get_product for individual items). There is no mention of context, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'search bundles', implying a read-only query but offering no details about pagination, result format, or potential side effects. The behavior is under-specified.
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?
The description is a single, clear sentence with no redundant words. It efficiently communicates the core function, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, yet the description fails to explain return values, pagination behavior, or any other contextual details. For a search tool with optional pagination parameters, this leaves significant gaps in the agent's understanding.
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?
The schema covers all three parameters (limit, offset, search) with descriptions, achieving 100% coverage. Since the description adds no parameter-specific information beyond the schema, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' and resource 'bundles', clarifying with '(kits/sets)'. This clearly states the tool's function, but it does not explicitly distinguish it from sibling search tools like search_products or search_variants beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as search_products or search_variants. There is no mention of context, prerequisites, or exclusions, leaving the agent without direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It identifies the mutation but fails to disclose side effects, permissions, idempotency, or what happens on success/failure. This is a significant gap for a write operation.
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?
The description is a single, efficient sentence that clearly conveys the tool's purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple signature but no output schema, and the description lacks details about return value, error conditions, or state transition constraints. It is minimally adequate but leaves important behavioral questions unanswered for a mutation tool.
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?
The schema provides 100% coverage with meaningful descriptions for both parameters. The tool description adds no parameter information, but since schema coverage is high, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Change') and specific resource ('status/state of a customer order'), making its purpose unambiguous. It doesn't explicitly contrast with sibling tools like create_customer_order or get_customer_order, but the name and verb are distinctive enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, prerequisites, or alternatives. There is no mention of the state transition process or that states should be obtained via get_metadata, though this is hinted in the schema. No exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely states 'Create an inventory count' without mentioning side effects, permission requirements, idempotency, or response format. The behavior is entirely implicit in the tool name.
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?
The description is a single, focused sentence with no filler. It front-loads the key action and resource, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers parameters, the description lacks essential context for a create tool: no return value description, no usage flow, and no tie-in to get_inventories. With no output schema, an agent cannot know what to expect after invoking this tool.
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 description coverage is 100%, so all parameters are fully documented there. The description adds nothing beyond the implied need for a warehouse, matching the baseline for high schema coverage.
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 the specific action (create) and resource (inventory count) with warehouse context. This distinguishes it from sibling tools like get_inventories and other create_* operations by naming a unique object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only states the action without any context on use cases or relationships to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details. It only restates the core action without mentioning side effects (e.g., posting a document), required permissions, or whether the order is draft or final. This is insufficient for a create operation.
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, front-loaded sentence with no wasted words. It is concise, though extremely minimal, earning a high score for structure but not perfection due to lack of useful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no annotations, and no output schema, the description does not explain the return value or the document's lifecycle (e.g., whether it is posted). It also fails to mention prerequisites like having an organization and counterparty href, leaving significant gaps.
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?
The input schema has 100% description coverage, so the baseline is 3. The description adds only a redundant 'RUBLES' note that is already present in the schema, providing no additional parameter meaning.
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 the action ('Create a cash receipt order') and names a specific accounting document type, distinguishing it from sibling tools like create_cash_out and create_payment_in. The Russian term adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention scenarios such as receiving cash from a customer or contrast with create_cash_out or create_payment_in, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the amount is in RUBLES, but does not disclose any behavioral traits such as required permissions, side effects of creating the order, or the fact that expense_item_href may be required. With no annotations provided, this leaves the agent without safety or prerequisite information.
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?
The description is a single short sentence that is easy to parse and front-loads the key information. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema or annotations, the description needs to explain what the tool returns and any prerequisites. It only states the action and currency. This is insufficient for an agent to understand the full context, especially the requirement for organization and agent hrefs and the optional expense item, even though these are in the schema parameters.
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?
The schema descriptions cover all 5 parameters, including how to obtain hrefs and the internal kopecks conversion. The description adds only the note that the amount is in RUBLES, which is already present in the schema (sum_rubles). Therefore, it provides minimal added value over the schema, so the baseline of 3 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?
The description clearly states the action ('Create') and the resource ('cash expense order' / расходный кассовый ордер), and specifies the currency (RUBLES). This distinguishes it from sibling tools like create_cash_in or create_payment_out, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_payment_out or create_cash_in. The description only states what it does, leaving the selection decision to the agent without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and currency, but does not mention side effects, permissions, reversibility, validation requirements, or what happens on creation. The currency note adds minor value but is insufficient.
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?
The description is a single concise sentence, front-loaded with the action and resource. It includes only essential information (purpose and currency) with no wasted words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is extremely terse for a creation tool with a nested positions array. It does not mention the return value, how to retrieve the created invoice (e.g., via get_invoices_out), or any operational context beyond the schema. The schema covers parameter details but not the overall workflow.
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?
The input schema provides 100% coverage for all parameters, each with meaningful descriptions. The tool description adds no parameter-specific semantics beyond the generic 'Prices in RUBLES' note, so the baseline score of 3 applies.
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 the verb 'Create' and the resource 'sales invoice' (with Russian equivalent 'счёт покупателю'), distinguishing it from sibling tools like create_purchase_order or create_invoice_in. The added currency note 'Prices in RUBLES' further specifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_customer_order or create_invoice_in. The agent must infer usage solely from the tool name and generic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source for behavioral disclosure. It adds only that the amount is in RUBLES, but omits details like required permissions, side effects of creation, or response format. The 'Create' verb implies mutation but nothing more.
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?
The description is extremely concise: two short sentences with no fluff. The Russian parenthetical is informative for a multilingual context and does not detract. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a rich schema, the description is too thin for a 6-parameter creation tool with no annotations and no output schema. It lacks usage context, behavioral expectations, and any mention of required fields or how hrefs are obtained (though the schema covers parameter origins).
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 description coverage is 100%, and the schema already provides detailed parameter descriptions (e.g., sum_rubles notes conversion to kopecks). The tool description's mention of 'Amount in RUBLES' is redundant with the schema and adds no new semantic meaning.
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 the tool's function: 'Create an incoming bank payment' with a specific resource type ('incoming bank payment') and action ('Create'). It distinguishes from siblings like create_payment_out and create_cash_in by specifying 'incoming' and 'bank'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_payment_out or create_cash_in. The description only states what it does without specifying context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the basic action and currency, omitting important aspects such as whether expense_item_href is required in some cases, side effects, or prerequisites. This is a significant gap for a create tool.
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?
The description is a single concise sentence that front-loads the core action and currency. Every word earns its place, and there is no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 5 parameters, no output schema, and no annotations, the description is too minimal. It does not mention required fields, conditional requirements (like expense_item_href), or what the response will contain. The schema covers parameters but not the broader execution context.
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 description coverage is 100%, so the baseline is 3. The description adds only 'Amount in RUBLES,' which is already covered by the schema's parameter description. It provides no additional meaning or context for the 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 the action ('Create'), the resource ('outgoing bank payment'), and a key constraint ('Amount in RUBLES'), effectively distinguishing it from sibling tools like create_payment_in and create_cash_out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives (e.g., cash payments or incoming payments). The only hint is the inherent 'outgoing bank' qualifier, but there is no explicit mention of when not to use it or which sibling to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only notes 'Prices in RUBLES', but does not explain the consequences of creating a purchase return (e.g., stock adjustments, document creation, permissions required) or what the response contains. This is a significant gap for a mutation tool.
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?
The description is a single, well-structured sentence that front-loads the action and includes the critical currency note. There is no filler or redundancy, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite moderate complexity (nested positions array, 5 parameters), the description is minimal. It lacks context about the business meaning of a purchase return, what happens after creation, return format, and any constraints. The отсутствие output schema further increases the need for description-completeness, which is not met.
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?
The input schema provides 100% coverage with descriptions for all parameters, including the currency note in price_rubles. The tool description adds no additional parameter meaning beyond what the schema already states, so baseline 3 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?
The description states the specific action 'Create a purchase return' and clarifies with Russian 'возврат поставщику', indicating a return to supplier. This distinguishes it clearly from sibling tools like create_sales_return (return from customer) and create_purchase_order (purchase).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_sales_return or create_purchase_order. The description does not mention prerequisites, use cases, or exclusions, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only says 'List' without disclosing side effects, return format, pagination behavior, or any caveats. The read-only nature is implied but not explicit.
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?
The description is a single sentence with no filler, immediately stating the action and resource. Every word is purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not explain what a move document contains, whether the response includes full objects or summaries, or how pagination works. With no output schema, this leaves significant gaps for the agent.
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%: limit, offset, and search each have descriptions. The description adds no additional parameter meaning, so the baseline of 3 applies.
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 the tool lists stock transfer (move) documents. The parenthetical '(move)' clarifies the terminology and distinguishes it from sibling tools like get_stock (stock levels) and get_documents (general documents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_stock or get_documents. The description only states what it does, without any contextual or exclusionary information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior, but it only says 'List employees' and gives a contextual hint. There is no mention of read-only nature, pagination behavior, sorting, or response contents. This leaves the agent to infer basic list semantics without additional guidance.
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?
The description is a single, concise sentence that immediately states the action and resource. There is no redundant information, and the parenthetical adds a useful context hint without excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a relatively simple list tool with no output schema, yet the description does not explain the response structure, pagination limits, or any default behaviors. The minimal detail is likely insufficient for an agent to fully understand what to expect from the call, especially given the lack of annotations.
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?
The input schema fully describes both parameters (limit and offset) with descriptions, achieving 100% schema coverage. The tool description adds no parameter-specific meaning beyond what the schema already provides, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists employees, using a specific verb and resource. The parenthetical 'for document owners/responsible persons' hints at a use case, though it is somewhat vague. It is distinct from other list tools like list_stores or list_organizations, though there are no direct sibling tools for employees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (for document owners/responsible persons), suggesting when this list might be needed. However, it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions. Since no sibling tool is employee-specific, it appears to be the only option, but that is not explicitly clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure, but it only states 'Search product variants' and reveals nothing about result format, pagination behavior, authentication requirements, or how matches are determined. This is minimal transparency.
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?
The description is a single concise sentence with no filler words. It communicates the core purpose efficiently and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool with well-documented parameters, the description lacks any context about return values, usage scenarios, or its relationship to the many sibling search tools. With no output schema or annotations, the description should provide more behavioral context to be fully complete.
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?
The input schema already provides descriptions for all three parameters (limit, offset, search) at 100% coverage. The tool description adds no additional meaning, so the baseline score of 3 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?
The description uses a specific verb 'Search' and a clear resource 'product variants (modifications)', which distinguishes it from sibling tools like search_products. The parenthetical clarifies that variants are modifications, reducing ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like search_products, search_assortment, or search_bundles. The description simply states what it does without any context or exclusions, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description must carry the burden of behavioral disclosure. It only mentions that prices are in RUBLES and does not disclose whether updates are partial (only provided fields), what happens to omitted prices, return values, or any side effects.
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?
The description is a single, concise sentence that conveys the core purpose and currency with zero wasted words. It is well-structured and easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It fails to explain partial update behavior, return format, or any prerequisites, leaving critical context gaps for an AI agent.
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 description coverage is 100%, so parameters already have self-explanatory descriptions like 'New buy/cost price in RUBLES'. The tool description adds no additional semantic meaning beyond the schema, so the baseline of 3 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?
The description uses a specific verb 'Update' and clearly identifies the resource: sale/buy/min prices for a product. It also notes the currency (RUBLES), making the purpose unambiguous and distinct from any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor are there any exclusions or prerequisites. The description only states what the tool does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It discloses the RUBLES-to-kopecks conversion, which is useful, but it does not mention return values, error behavior, required permissions, or other side effects. This is a significant gap for a mutating tool.
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?
The description is extremely concise: two short sentences with no filler. It front-loads the core purpose and includes the essential currency caveat. Every word 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?
The description is adequate for a simple create tool with a well-specified schema. It lacks information about the return value or failure modes, which is notable given there is no output schema and no annotations. However, it is not completely insufficient because the schema covers all parameters and the purpose is clear.
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?
The schema has 100% description coverage for all 11 parameters, so the baseline is 3. The top-level description adds a general note about prices being in RUBLES, which is slightly redundant for buy_price_rubles and sale_price_rubles but adds context for min_price_rubles and the overall intent.
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 the tool's purpose: 'Create a new product.' The verb 'create' and resource 'product' are specific, and this distinguishes it from sibling read tools like search_products and get_product, as well as other create tools for different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, or any prerequisites. The description only states what it does, not when to choose it over other tools like create_service or update_prices. There are no exclusions or contextual hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the currency, but does not disclose side effects, permissions, validation behavior, or whether the order is created as a draft or finalized.
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?
The description is one short sentence plus a currency note. It is front-loaded with the action and resource, and every word 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?
For a tool with 5 parameters and a nested positions array, the description is helpful but minimal. It does not explain the overall process or mention the response, but the schema already covers parameter details. This is a minimum-viable level of contextual completeness.
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?
The schema provides 100% coverage with descriptions for all parameters, earning a baseline of 3. The description adds a note about prices being in RUBLES, which reinforces the price_rubles parameter, but does not explain parameter relationships or formatting beyond the schema.
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 uses a specific verb 'Create' with a clear resource 'purchase order' and even provides a Russian translation 'заказ поставщику' for disambiguation. This clearly distinguishes it from similar tools like create_customer_order or create_supply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as create_supply or create_demand. The only usage-related information is 'Prices in RUBLES', which is a constraint rather than a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a webhook but does not disclose whether deletion is permanent, idempotent, or requires specific permissions. The brevity leaves significant behavioral aspects unexplained.
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?
The description is a single, clear sentence that directly states the tool's purpose and key parameter. It is concise and front-loaded with the action verb, with no wasteful words.
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 the tool's simplicity (one parameter, no output schema), the description is minimally adequate, covering what the tool does and the parameter. However, the lack of annotations and behavioral details (e.g., error handling, permanence) leaves gaps that could affect correct invocation.
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?
The schema describes the 'id' parameter as 'Webhook UUID to delete', which matches the description. Since schema coverage is 100%, the description adds no additional meaning beyond what the schema already provides, warranting the baseline score of 3.
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 the action (delete), the resource (webhook), and the identifier (UUID). This distinguishes it from sibling tools like create_webhook, update_webhook, and list_webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as the webhook needing to exist or potential consequences of deletion. Usage is implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'List' which implies a read operation, but does not disclose authentication needs, return format, or any side effects. The meaning of 'enter' is partially clarified by the Russian term, but no additional behavior is described.
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?
The description is a single, front-loaded sentence that conveys the core function without unnecessary words. Every element is essential, and it is appropriately sized for a simple list endpoint.
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?
While the tool is simple and the schema covers parameters, the absence of an output schema and annotations means the description should provide more context. The meaning of 'enter' is clarified with the Russian term, but there is no information about the response structure or typical usage scenarios. It is adequate for basic invocation but not fully complete.
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?
The input schema provides descriptions for all three parameters (limit, offset, search) with 100% coverage. The description adds only the context that these are 'stock enter' documents, which is more about purpose than parameter semantics. Since schema coverage is complete, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List stock enter (оприходование) documents.' It uses a specific verb and resource, distinguishing it from general document listing tools like get_documents. However, it doesn't explicitly differentiate from sibling tools with similar names, so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to list enter documents. But it provides no explicit guidance on when to prefer this over alternatives, no exclusions, and no mention of common use cases. The basic scenario is clear, but alternatives and when-not-to-use are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states the action without mentioning pagination, response format, permission requirements, or filtering behavior, offering minimal value beyond the tool's name.
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?
The description is a single, efficient sentence that front-loads the verb and resource. It contains no redundant words or fluff, making it highly concise and well-structured.
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?
This is a simple list tool with full schema coverage, but the absence of annotations and output schema means critical context (e.g., read-only nature, pagination semantics, response structure) is missing. The description is minimally viable but leaves gaps for an agent.
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?
The input schema already covers all three parameters with clear descriptions (100% coverage), reaching the baseline. The tool description adds no parameter-specific meaning, but the schema is sufficient, so this is adequate.
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 uses a specific verb ('List') and a clear resource ('stock write-off documents'), with the Russian gloss providing additional clarity. It effectively distinguishes from sibling tools like get_documents or get_stock by targeting only loss documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_documents, get_enters, or search_products. The description only states what it does, leaving the agent to infer usage context from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only adds 'Sums in RUBLES.' and the return components, but lacks any statement about read-only safety, side effects, or pagination behavior. The date-range scope is implied but not explicitly linked to parameters.
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?
The description is a single concise sentence, front-loaded with the verb and resource. Every word adds value—no filler, no redundancy.
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?
The tool has no output schema and no annotations, so the description must cover return values and context. It explains the main output fields and currency, but leaves ambiguity about whether turnover is for all products or a specific product, and does not describe limit/offset behavior. Adequate for a simple query but with clear gaps.
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's 'over a period' hints at moment_from/moment_to but does not add meaningful detail beyond the schema definitions. No parameter-level semantics are enriched beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches product turnover over a period and lists the components (opening, income, outcome, closing). It is specific and uses a clear verb+resource, though it does not explicitly differentiate from similar reporting tools like get_profit_report or get_sales_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'over a period' implies it is for time-based turnover reporting, but there is no explicit guidance on when to use this tool versus alternatives such as get_stock or get_profit_report, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the returned fields but does not disclose pagination behavior despite limit/offset parameters being present. The word 'all' may mislead an agent into thinking a single call returns everything, and no annotations are available to cover safety or side effects.
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?
A single sentence that is clear, front-loaded with the action, and contains no redundant information. It efficiently states what the tool does and what it returns.
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?
For a simple list tool, the description covers the core purpose and return fields, but the absence of an output schema and lack of mention of pagination leave gaps. The agent would need to infer pagination from the parameters.
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 description coverage is 100% for both limit and offset, with defaults and constraints fully documented. The description itself adds no parameter-level details, so the baseline of 3 applies.
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 verb 'List' and resource 'warehouses/stores' are specific, and the description clearly states the returned fields (names, addresses, meta hrefs). It distinguishes from sibling search/get tools by implying a complete listing rather than a filtered lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like search_products or get_stock_by_store. There are no explicit exclusions or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the update is partial or full replacement, any permission requirements, effects of updating an enabled webhook, or whether changes are immediately active. The description mentions what can be updated but not the behavior beyond that.
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?
The description is a single sentence that is front-loaded with the action and resource, followed by a compact parenthetical list. Every word adds value, and there is no redundancy or filler.
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?
The tool has 6 parameters and no output schema or annotations. While the schema fully documents parameters, the description does not mention partial update semantics, the diffType field, or any potential consequences. However, for a straightforward update operation with a well-described schema, the description is adequate but not comprehensive.
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 description coverage is 100%, with each parameter having a clear description. The tool description merely lists some parameter names (URL, action, entity type, enabled state) without adding insight beyond the schema. Notably, it omits diffType, which is a valid parameter. The schema handles the heavy lifting, so baseline 3 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?
The description uses a specific verb 'Update' with a clear resource 'webhook' and lists the key attributes (URL, action, entity type, enabled state). This clearly distinguishes it from sibling tools like create_webhook, delete_webhook, and list_webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or when a different webhook tool would be more appropriate. The usage context is implied only by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply states 'Create a new counterparty' without mentioning side effects, idempotency, required fields beyond what the schema already shows, or any post-creation behavior. This is minimal and fails to add meaningful context beyond the name.
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?
The description is extremely concise—two sentences with no filler. It front-loads the core purpose and then provides a single, useful parameter hint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no annotations and no output schema, the description is incomplete. It fails to mention that 'name' is required, any uniqueness constraints, or what response the caller should expect. The schema covers parameter syntax, but the description does not provide sufficient behavioral context for a mutation tool.
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?
The schema describes all 6 parameters with 100% coverage, so the baseline is 3. The description adds the values for companyType ('legal', 'entrepreneur', 'individual'), but these are already enumerated in the schema, adding no new semantic meaning.
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 'Create a new counterparty' using a specific verb and resource, and it is distinct from sibling tools like get_counterparties and get_counterparty. The additional instruction about companyType reinforces the purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name and description: use it when creating a counterparty. However, there is no explicit guidance on when not to use it or which alternatives might be more suitable, such as get_counterparties for reading or update tools for modifying. The companyType instruction is parameter 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral transparency. The description only states 'Create a stock write-off' with no information about side effects (e.g., reducing stock), permissions, reversibility, or return values. This is a significant gap for a mutation tool.
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?
The description is a single, front-loaded sentence with zero unnecessary words. It immediately identifies the verb and resource, making it concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has no annotations and no output schema, yet the description is minimal. It fails to explain what a stock write-off entails (e.g., reducing inventory, recording loss reasons), any prerequisites, or the resulting document behavior. The completeness is inadequate compared to the sibling tools and the complexity of the operation.
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 description coverage is 100%, with all four parameters having clear descriptions (e.g., 'Meta href of the warehouse/store'). The description adds minimal semantic value beyond the schema by mentioning 'from a warehouse', which aligns with store_href. Baseline 3 is appropriate because the schema handles parameter semantics.
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 the action ('Create a stock write-off') and the resource ('списание' in Russian) with a source context ('from a warehouse'). It distinguishes this tool from siblings like create_move, create_enter, and create_demand by naming the specific document type and operation, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a write-off document, but it does not explicitly state when to use this tool versus alternatives. No exclusions, prerequisites, or alternative tools are mentioned. The guidance is minimal but the purpose itself provides a clear enough reason to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects (e.g., stock level changes), required permissions, or what the response contains. For a create/mutation tool, this is a significant gap.
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?
The description is a single, front-loaded sentence that clearly states the tool's purpose with no unnecessary words. It is an example of efficient writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite full schema coverage, the description lacks critical context for a create operation: no mention of the operational effect (e.g., stock movement), prerequisites, or expected outcome. With no annotations or output schema, the description is insufficient for a tool with this complexity.
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?
The input schema has 100% description coverage for all parameters, including helpful notes like 'Get from list_organizations'. The description itself adds no parameter-specific meaning, but since the schema fully documents parameters, the baseline 3 applies.
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 uses a specific verb 'Create' and clearly identifies the resource as a 'stock transfer (move)' between two warehouses. This distinguishes it from sibling tools like create_supply or create_demand, which handle different document types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies usage for transferring stock between warehouses, but there is no explicit mention of when to use this tool versus alternatives, nor any exclusions. The context is somewhat clear but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only mentions that prices are in RUBLES, but does not disclose side effects such as inventory updates, document creation details, authorization requirements, or reversibility. For a mutation tool, this is insufficient.
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?
The description is two short sentences, front-loaded with the core action ('Create an incoming supply') and a key constraint ('Prices in RUBLES'). Every word earns its place, with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no annotations, and no output schema. The description does not explain the operational context (e.g., receiving goods, posting to inventory), prerequisites, or how it relates to purchase orders or enters. This leaves significant gaps for an agent attempting to decide when and how to use this tool.
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?
The input schema has 100% description coverage for all 7 parameters, including the price_rubles parameter which already states 'in RUBLES (converted to kopecks internally)'. The tool description merely repeats the currency note, adding no new semantic meaning beyond what the schema 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 uses the specific verb 'Create' with the resource 'incoming supply' and clarifies it as a 'purchase receipt'. This distinguishes it from sibling tools like create_purchase_order, create_enter, or create_demand. The purpose is immediately clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for recording incoming supplies/purchase receipts, but provides no explicit when-to-use guidance or alternatives. It does not mention when not to use this tool versus create_purchase_order or create_enter, leaving the agent to infer from the parenthetical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and event types, omitting side effects such as whether the webhook is immediately active, authentication requirements, or response behavior. For a mutation tool, this is a significant gap.
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?
The description is a single, focused sentence that front-loads the verb and resource, includes the relevant event types, and contains no filler words. It is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema and no annotations, the description is sparse. It does not mention what the tool returns (e.g., webhook ID), activation behavior, error conditions, or the meaning of the custom 'PROCESSED' event. This leaves the agent without critical operational context.
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 description coverage is 100%, with all four parameters documented, including enum values for action and diffType. The tool description adds no new semantic information beyond listing the action enum, so it does not enhance 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 uses the specific verb 'Register' with the resource 'webhook' and clarifies it is for entity events with enumerated action types (CREATE/UPDATE/DELETE/PROCESSED). This clearly distinguishes it from sibling webhook management tools like list_webhooks, update_webhook, and delete_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new webhook, and the sibling names (list/update/delete) indicate alternatives, but the description itself does not explicitly state when to use this tool versus those alternatives, nor does it mention prerequisites or use cases. Context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds a useful behavioral detail (money values in kopecks), which goes beyond the schema, but it does not disclose return structure, timezone handling, or aggregation nuances. The transparency is moderate but incomplete.
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?
The description is a single, front-loaded sentence that states the core action and includes a crucial unit detail. Every word contributes value, with no redundancy or unnecessary elaboration.
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?
For a simple one-parameter tool without an output schema, the description conveys the essential behavior: retrieving aggregated metrics for a period and noting the kopeck denomination. It could be enhanced by distinguishing itself from more granular report tools, but it is largely complete for its complexity.
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?
The schema covers 100% of parameters with a clear description for 'period', including an enum and default. The tool description adds little beyond restating the period options; the kopeck note is not parameter-specific. Thus, the baseline of 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves dashboard metrics (sales, orders, money) aggregated by day, week, or month, with a specific verb and resource. However, it does not explicitly distinguish itself from sibling reporting tools like get_sales_report or get_money_report, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_sales_report or get_money_report. It neither mentions prerequisites, exclusions, nor alternative tools, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'List', which implies read-only, but does not disclose any further behavioral traits such as pagination behavior, ordering, required permissions, or whether the list includes both paid and unpaid invoices. This is insufficient for an agent to understand side effects or access requirements.
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?
The description is one concise sentence with zero wasted words. It is front-loaded with the verb 'List' and immediate resource clarification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simplicity of the tool, the description lacks key contextual information. Without an output schema, it does not describe the return structure or fields of the invoice list. It also does not mention any filtering or default behavior beyond what the schema implies. Given the sparse description and no annotations, the tool is not fully contextualized for an agent.
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?
The input schema provides 100% coverage for limit, offset, and search parameters with clear descriptions. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 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?
The description clearly states 'List sales invoices' with the Russian equivalent 'счета покупателям', making the action and resource unambiguous. It distinguishes itself from create_invoice_out and other get tools by explicitly specifying the resource (sales invoices).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage as a read/list operation for sales invoices, but it provides no explicit guidance on when to use this tool versus alternatives like get_documents or search_assortment. No exclusions or alternative tool references are made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It only repeats the tool's name and does not disclose pagination, default ordering, result structure, or any side effects. The sparse description adds no value beyond what the name already implies.
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?
The description is a single, front-loaded sentence that communicates the core purpose efficiently. No excessive words or redundant details, making it appropriately sized for a simple list operation.
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?
For a straightforward list tool with fully documented parameters, the description is adequate. It lacks return-value details, but this is acceptable given no output schema and the tool's simple nature. While annotations are absent, the read-only nature is implied by 'List', making the tool usable.
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?
The input schema describes all three parameters (limit, offset, search) with clear descriptions, covering 100%. The tool description adds no parameter details, so it does not enhance schema semantics. Baseline 3 is appropriate since schema already handles explanation.
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 the tool lists purchase orders, using a specific verb ('List') and resource ('purchase orders'). It distinguishes from sibling tools like get_orders by narrowing to purchase orders, and the Russian translation adds clarity about the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives like get_orders or get_customer_order. The description implies usage but does not state exclusions or prerequisites, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions the currency context ('Prices in RUBLES') but does not disclose side effects, permissions, or response behavior for this mutation tool.
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?
The description is a single sentence, extremely concise and to the point. It includes necessary context (sales return, Russian translation, currency) without wasted words.
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 the tool's complexity (multiple required hrefs, nested positions array) and lack of output schema, the description provides minimal context. It lacks information about expected responses or side effects. The complete schema helps, but the description alone is thin.
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?
The input schema already provides full descriptions for all parameters (100% coverage). The description adds minimal value beyond the schema—the currency note is helpful but redundant with the parameter names and descriptions. Baseline 3 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?
The description clearly states the tool's action: creating a sales return (возврат покупателя). The inclusion of the Russian term further clarifies the domain. It distinguishes from sibling tools like create_purchase_return by specifying 'sales' return.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. The tool's name and description imply usage when creating a sales return, but no exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only mentions the content ('who changed what, when') but does not describe any limitations, pagination behavior, date range semantics, or permission requirements. For a read-only audit tool, some minimal behavioral context (e.g., 'returns most recent events first') is expected.
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?
The description is a single concise sentence that is front-loaded with the key action ('Get the account audit/event log') and adds a useful parenthetical clarification. No unnecessary information or repetition.
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 the low complexity of a simple audit log retrieval with optional pagination and date range, the description provides a reasonable but minimal overview. However, since there is no output schema, it lacks details about the return format or how to interpret the log entries, and it does not clarify ordering or default behavior beyond what the schema implies.
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?
The schema has 100% coverage for all four parameters (limit, offset, moment_to, moment_from), so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides, which is acceptable but does not enhance understanding.
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 the tool retrieves the account audit/event log, specifying the resource (audit log) and the action (get). It also distinguishes from the sibling 'get_entity_audit' by focusing on account-level events, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for account-wide audit events, which contrasts with the entity-specific sibling 'get_entity_audit', but it does not explicitly state when to use this over alternatives or provide exclusions. A clear 'use for account-level, use get_entity_audit for entity-level' would improve this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states the listing action and does not mention pagination behavior, return structure, sorting, or any additional operational details. While 'list' implies read-only, the description adds no meaningful behavioral context beyond the verb.
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?
The description is a single, concise sentence that is front-loaded with the action and resource. There is no redundant phrasing or irrelevant detail, so every word 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?
With no output schema and no annotations, the description provides only the core listing purpose. While the parameter schema covers the input side, the absence of any mention of return format, pagination behavior, or other context leaves the description minimally adequate but not complete. It is clear enough for a straightforward read-only list tool, but richer context would improve it.
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?
The input schema has 100% coverage for all three parameters (limit, offset, search), so the description doesn't need to explain them. The description adds no parameter-specific information, but the schema already documents each parameter clearly. Baseline 3 is appropriate given the high schema coverage.
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 uses a specific verb and resource ('List inventory count documents') and clearly identifies the resource type with the Russian term in parentheses. This distinguishes it from sibling tools like get_documents and search_assortment, which target broader or different document sets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving inventory count documents, but it provides no explicit context on when to choose this tool over alternatives such as get_documents or search_assortment. There are no when-not-to-use conditions or named alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It conveys a read-only operation via 'Get' and states the output (stock quantities per store), but it does not disclose pagination behavior, whether zero-stock items are included, or response format. For a simple getter, this is adequate but not rich in behavioral detail.
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 concise and front-loaded with the primary action in the first sentence. The second sentence is redundant, rephrasing the same concept, and there is a minor typo ('is is' instead of 'is in'). It could be tightened into a single sentence, but overall it is efficient.
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 the tool's simplicity and schema coverage, the description is not entirely inadequate, but it omits important context such as how this differs from other stock-related siblings, pagination details, and response structure. With no output schema and no annotations, more behavioral context would improve completeness.
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?
The input schema already covers all three parameters (limit, offset, search) with descriptions, achieving 100% schema coverage. The description does not add any additional meaning or usage hints for these parameters, so the baseline of 3 applies.
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 the tool's function with a specific verb and object: 'Get stock report broken down by warehouse/store.' It also adds detail about the output ('Shows how much of each product is in each store'), which distinguishes it from sibling tools like get_stock or get_stock_current that may provide aggregate or current stock levels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a per-store stock breakdown is needed, but it does not explicitly mention when not to use it or name alternative tools. Given the existence of sibling tools like get_stock and get_stock_current, this lack of explicit guidance leaves some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds behavioral context by stating 'fast' and 'current' and specifying the 'assortment id -> stock' mapping. However, it does not disclose return structure, pagination, or handling of zero-stock items, leaving some behaviors implicit.
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?
The description is a single sentence, front-loaded with the core purpose and scoping option. Every word earns its place; no filler or redundancy.
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?
For a simple read tool with one optional parameter, the description is mostly sufficient. The mapping format is stated, but without an output schema or annotations, details about the exact response format and coverage are left to inference.
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% for the sole parameter store_href, and the description's 'optionally for one warehouse' adds no meaning beyond the schema's 'Limit to one warehouse (meta href). Omit for all.' Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a stock report keyed by assortment id with optional warehouse scoping. However, it does not distinguish itself from sibling tools like get_stock or get_stock_by_store, so it's not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a quick current stock snapshot and mentions the optional warehouse filter, but it provides no explicit guidance on when to choose this over alternatives or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the high-level action without mentioning side effects (e.g., stock impact, document status), permissions, reversibility, or return behavior, which is a significant gap for a create operation.
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?
The description is extremely concise at two short sentences, front-loading the core purpose without any fluff. Every word adds value.
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?
The tool has a nested positions array and no output schema. The description covers the primary purpose but does not explain what the created document looks like or any prerequisites. Given the complexity, it is minimally adequate but leaves gaps about the result and usage constraints.
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 description coverage is 100%, so parameters are already documented. The description adds minimal context about the warehouse link and customer order purpose, but does not significantly enhance parameter understanding beyond what the schema 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 clearly states the verb ('Create'), the resource ('shipment (demand)'), and the purpose ('to fulfill a customer order'). It distinguishes from sibling tools like create_customer_order and create_move by specifying the shipment/demand context and the warehouse linkage.
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 phrase 'to fulfill a customer order' provides clear context for when to use this tool, implying shipment against a sales order. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It only states the operation ('get change history') without disclosing response format, pagination, permissions, or how it differs from get_audit. For a read-only tool, this is minimal but lacks transparency about what the change history contains or its structure.
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?
The description is a single, clear sentence that front-loads the action and scope. It is concise with no filler or redundant information, making it easy for an agent to quickly understand the purpose.
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 the simple two-parameter schema and no output schema, the description is adequate but incomplete. It does not clarify the structure of the change history response or explain the distinction from the broader get_audit sibling. These omissions could lead an agent to under-utilize the tool or misinterpret its granularity.
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% with clear descriptions for both id ('Entity UUID') and entity_type ('Entity type, e.g. 'customerorder', 'product''). The description merely restates these as 'by type and UUID' without adding new constraints, formatting guidance, or examples, so it stays at the baseline for high schema coverage.
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 the tool's function: 'Get the change history of a single entity by type and UUID.' It uses a specific verb and resource, and explicitly mentions the scope (single entity) and the required parameters (type and UUID). This differentiates it from the sibling get_audit, which likely covers broader audit logs.
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 phrase 'single entity' provides clear context for when to use this tool (when you need history for one entity), implying a contrast with get_audit for bulk or multi-entity queries. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses the report content (sales, costs, returns, profit, margin), but it does not explicitly mention read-only behavior, pagination, or any data aggregation nuances. The description adds some value but lacks deeper behavioral context.
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?
The description is extremely concise, with two short sentences. The action is front-loaded ('Get profit report by product'), and every word contributes meaning. No filler or repetition.
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?
This is a simple report tool with four optional parameters and no output schema. The description explains the purpose and key data fields, but it does not describe the response structure (e.g., whether it returns a list or aggregated object) or clarify pagination behavior. Given no output schema, the description could be more explicit about the return format.
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?
The input schema has 100% parameter coverage with descriptions for each parameter. The description itself adds no parameter-specific meaning, so the baseline score of 3 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?
The description clearly states a specific verb and resource: 'Get profit report by product.' It also lists the fields (sales, costs, returns, profit, margin), which differentiates it from sibling report tools like get_sales_report or get_money_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for profit reporting by product, but it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions. No guidance is given on how it differs from other report tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses the return fields ('Returns name, type, price'), which is useful, and the name 'search' strongly implies a read-only operation. However, it does not explain what fields are searched against (e.g., name, SKU) or any other behavioral traits such as result ordering or potential lack of support for partial matches.
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?
The description is two sentences, front-loaded with the core purpose, and contains no filler. Every phrase provides value: the scope ('across products, variants, services and bundles') and the return fields.
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?
There is no output schema, so the description's mention of 'Returns name, type, price' partly compensates. However, the tool is a unified search that likely aggregates multiple entity types, and the description does not explain how results are combined, whether pagination applies uniformly, or any search semantics (e.g., case-insensitive, field-matching). This leaves gaps for an agent to correctly predict behavior.
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 description coverage is 100%, with each parameter (limit, offset, search) having a description. The tool description adds no extra parameter semantics beyond clarifying that the search spans multiple types, but it doesn't explain how limit/offset interact or what the search query targets. Since the schema already documents the parameters, a baseline score of 3 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?
The description clearly states the tool performs a 'Unified search across products, variants, services and bundles' with a specific verb and resource. It also lists the return fields ('name, type, price'), which distinguishes it from sibling tools like search_products that focus on a single type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'Unified' implies this tool should be used when searching multiple assortments at once, but there is no explicit guidance on when to use it versus the specific search tools (search_products, search_variants, etc.) or any exclusion criteria. The usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds one useful detail ('Prices returned in RUBLES') but does not mention pagination behavior, result structure, or confirm that it is a read-only operation. The search intent implies non-destructive behavior, but more transparency would be needed for a higher score.
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?
The description is a single sentence, front-loaded with the core purpose, and wastes no words. It conveys the essential function and the key currency detail in minimal space.
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?
The tool has 4 optional parameters and no output schema, but the description only provides the core search purpose and currency information. It does not disclose what fields are returned or any response structure, leaving the agent partially uninformed. However, for a straightforward search tool, it is minimally adequate.
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?
The input schema has 100% description coverage for all four parameters (limit, offset, search, filter_article), so the baseline is 3. The description's phrase 'by name or article' aligns with the 'search' and 'filter_article' parameters but does not add new meaning beyond the schema descriptions.
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 the tool's function: 'Search products in MoySklad by name or article.' This specifies the verb (search), resource (products), and search criteria (name/article), effectively distinguishing it from sibling tools like search_variants or search_bundles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for product searches but does not explicitly state when to use it over alternatives such as search_assortment or search_variants. No when-not-to-use guidance is provided, leaving the agent to infer usage from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It discloses a useful trait: 'positions expanded'. However, it does not mention whether the operation is read-only (though 'get' implies it), error behavior, permissions, or response structure details beyond expanded positions. The description adds some value but lacks 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?
The description is a single sentence that is front-loaded with 'Generic' and packs the core purpose, scope, and a key behavioral detail into a compact form. There is no wasted text; every word contributes to understanding.
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?
For a simple 2-parameter tool with no output schema, the description adequately covers the core functionality and notes the expanded positions return detail. It could be more explicit about the return structure or mention that dedicated getters exist for common entities, but the description is sufficiently complete for its complexity.
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?
The schema already documents both parameters clearly with 100% coverage: id is 'Document UUID' and entity_type includes examples. The description merely echoes 'by UUID' and 'any entity type' without adding new semantic meaning. Baseline 3 is appropriate since the schema handles parameter documentation.
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 states a specific verb and resource: 'get a single document of any MoySklad entity type by UUID'. The 'Generic' prefix and 'any entity type' clearly distinguish it from the plural get_documents and dedicated getters like get_customer_order. This is a precise, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'Generic' implies it can be used for any entity type, providing some context for when to use it. However, it does not explicitly say when to prefer this over dedicated getters or when not to use it. No alternatives or exclusions are mentioned, so guidance is implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that prices are in RUBLES and that it fetches a single product, which implies a read operation. But it does not mention authorization, error behavior, or the effect of the `raw` parameter beyond the schema, leaving the behavioral profile somewhat thin.
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?
The description is a single, front-loaded sentence that states the core action ('Get a single product by UUID') and a key output detail ('Prices returned in RUBLES'). Every word serves a purpose; no redundancy or filler.
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?
For a simple get-by-id tool with two well-documented parameters and no output schema, the description is largely complete. It could be improved by noting the alternative search_products for cases where the UUID is unknown, but the current information is sufficient for straightforward use.
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?
The input schema fully describes both parameters: `id` as a Product UUID and `raw` as a boolean for returning the raw MoySklad object. The description adds no additional parameter semantics, so the baseline of 3 for high schema coverage applies.
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 'Get a single product by UUID' is a specific verb+resource+method that precisely defines the tool's function. It also adds 'Prices returned in RUBLES', a distinctive detail that differentiates it from other retrieval tools like search_products or get_stock.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'by UUID'—the tool is for when you have a product UUID. However, it does not explicitly state when NOT to use it or mention alternatives like search_products for finding products without a known UUID. Thus, guidance is present but implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. The verb 'List' implies a read-only operation, but the description does not explicitly state side effects, pagination behavior, or how rates are expressed. It adds clarity on the returned data but lacks further behavioral context.
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?
The description is a single, front-loaded sentence with no unnecessary words. It earns high marks for conciseness.
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?
For a simple listing tool, the description effectively communicates the purpose and key output fields. Combined with the well-described pagination parameters in the schema, it is mostly complete, though it lacks exact response formatting or field names.
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?
The input schema already describes both parameters (limit, offset) with descriptions, yielding 100% schema description coverage. The description adds no additional parameter semantics, so a baseline score of 3 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?
The description uses the specific verb 'List' with the resource 'currencies' and specifies the output as 'ISO codes and rates,' clearly distinguishing it from sibling tools that handle products, orders, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool vs alternatives. Since no other currency-listing tool exists among siblings, usage is implied, but there is no mention of context, prerequisites, or cases where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. 'List' implies a read-only operation and 'your legal entities' clarifies scope, but it does not mention pagination behavior, authentication requirements, or potential rate limits. It adds some context but lacks deep behavioral detail.
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?
The description is a single, well-structured sentence that includes the action, resource, a clarifying parenthetical, and output fields. Every word earns its place with no redundancy or filler.
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?
For a simple list tool with two optional parameters and no output schema, the description adequately specifies return fields (names, INN, meta hrefs). The lack of output schema means the description's mention of return data is useful. It could mention pagination, but the schema already covers limit/offset, making the description complete enough for this complexity.
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?
The input schema fully documents both parameters (limit and offset) with descriptions, so schema coverage is 100%. The description adds nothing about parameter usage beyond what the schema already provides, matching the baseline of 3.
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 uses the specific verb 'List' with the resource 'organizations' and clarifies with 'your legal entities'. It also names the returned fields (names, INN, meta hrefs), making the purpose unambiguous and distinct from sibling list tools like list_employees or list_stores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'List all organizations' implies use when a complete list of legal entities is needed, but there is no explicit guidance on when to prefer this tool over alternatives or any exclusions. The description does not name sibling tools or edge cases, so usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The word 'List' suggests a read-only operation, but the description does not explicitly confirm no side effects, mention pagination behavior, or disclose any caveats. It adds minimal behavioral context beyond what the name alone suggests.
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?
The description is a single concise sentence that front-loads the primary purpose and lists the return fields. Every word is informative, with no redundant or filler content.
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?
The description names the exact fields returned (URL, action, entity type, status), which helps the agent understand the output despite lacking an output schema. However, it does not explain pagination behavior or whether all fields are always included, leaving minor gaps for a simple list tool.
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 description coverage is 100% for both parameters (limit and offset), so the schema already documents their semantics. The description does not add additional context about parameters, such as how pagination works or the impact of the limit, so the baseline score of 3 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?
The description clearly states the action ('List all registered webhooks') and the resource (webhooks), with a specific verb and scope. It distinguishes itself from sibling tools (create_webhook, update_webhook, delete_webhook) by focusing on listing existing webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool versus alternatives. However, the verb 'List' and the resource 'webhooks' imply that this is the appropriate tool for retrieving registered webhooks, making usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the basic action (list) and its generic/fallback nature. It omits any information about return format, pagination behavior, error handling, or whether filtering is applied consistently. As a read-only list tool, the lack of side-effect disclosure is less critical, but the description still carries too little behavioral context to be transparent.
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?
The description is a single sentence, front-loaded with 'Generic,' and every word serves a purpose. It immediately conveys the tool's role as fallback for listing documents. There is zero redundancy or filler, making it exceptionally concise and well-structured.
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?
For a tool with 5 parameters, no output schema, and no annotations, the description is minimal but not hopeless. It explains the core purpose and fallback behavior, and the schema covers parameter details. However, it does not clarify what a 'document' entails, what return data looks like, or how it differs from dedicated tools beyond the fallback note, leaving gaps for an agent trying to predict output shape and limitations.
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 description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; it only reiterates the entity_type concept that the schema already describes with examples. Since all parameters have well-documented descriptions in the schema, the tool description adds no extra semantic value.
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 the tool lists documents of any MoySklad entity type, using the specific verb 'list' and resource 'documents of any MoySklad entity type.' The phrase 'fallback for entities without a dedicated tool' distinguishes it from sibling tools that target specific entity types, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this is a 'fallback for entities without a dedicated tool,' which tells the agent when to use this tool versus alternatives. It sets clear usage boundaries: use when no specialized tool exists for the requested entity type. This is the kind of exclusion guidance that is often missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states the tool 'get full details' but does not specify what 'full details' includes, whether the response is a summary or raw object (though the 'raw' parameter hints at this), or any error behavior. It is not misleading but lacks depth beyond the basic read operation.
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?
The description is a single, concise sentence that conveys the core purpose without unnecessary words. It is front-loaded and easy to scan.
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?
Given the simplicity of the tool (2 parameters, no output schema) and the clear sibling context, the description is largely sufficient. It does not explain what a counterparty is or detail the return format, but these are reasonable omissions for a get-by-id tool. The description is complete enough for an agent to select and invoke it correctly.
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 description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema, which already clearly describes 'id' as 'Counterparty UUID' and 'raw' as returning the full raw object. The description's phrase 'full details' somewhat overlaps with the parameter semantics but does not add new information.
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 the verb ('Get'), resource ('counterparty'), and scope ('by UUID'). It effectively distinguishes this tool from sibling tools like get_counterparties (plural) by indicating it retrieves a single entity by its identifier.
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 phrase 'by UUID' provides clear context that this tool is for retrieving a specific counterparty when the UUID is known. While it doesn't explicitly mention alternatives or exclusions, the usage scenario is self-evident given the sibling tool names and the parameter requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description itself conveys the tool's read-only nature via 'Get' and additionally discloses a behavioral trait: 'with expanded positions' indicates the response includes nested position data. It does not mention error behavior or permissions, but for a simple lookup this is reasonable transparency.
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?
The description is a single concise sentence, front-loaded with the action and resource. Every word contributes meaning, with no fluff or redundancy.
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?
For a simple single-resource lookup with one parameter and no output schema, the description covers the essential purpose and the notable behavior of expanded positions. It does not describe response format or error handling, but these are less critical given the tool's simplicity.
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?
The input schema already documents the only parameter 'id' as 'Customer order UUID' with 100% coverage. The description's 'by UUID' restates the schema without adding new syntax, format details, or parameter semantics, so the description adds no meaningful value beyond the structured field.
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 uses a specific verb 'Get' and resource 'customer order', scoped to a single UUID, and mentions 'expanded positions' to indicate the response richness. This clearly distinguishes it from sibling list tools like get_orders or mutation tools like create_customer_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific order UUID is known and the caller needs the order with its positions. However, it does not explicitly state when to prefer this over get_orders or any alternative, nor does it mention prerequisites beyond having a UUID. Guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the data scope (current balances, bank accounts, cash registers, RUBLES) but does not mention return format, data freshness, permissions, or any limits. It adds useful context but remains minimal.
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 short, front-loaded sentences convey the tool's purpose and currency scope with no wasted words. The key information is immediately available.
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?
For a zero-parameter report tool, the description adequately covers what data is returned and how it is grouped. The lack of an output schema leaves a minor gap around the exact return structure, but the core purpose is complete.
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?
The input schema has zero parameters and 100% coverage, so there is no parameter burden on the description. The baseline of 4 applies because no parameter meaning is needed; the description confirms the tool requires no inputs.
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 the tool retrieves current money balances, grouped by bank account and cash register, with currency specified as RUBLES. This is specific and distinguishes it from sibling report tools like profit or sales reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this when you need current balances across accounts and registers. However, there are no explicit alternatives, exclusions, or when-not-to-use guidance relative to sibling cash/report tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a safe read-only operation via 'Get' and indicates the type of data returned. However, it does not disclose return format, pagination, or other behavioral details. For a simple metadata lookup, this is adequate but not rich.
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 sentences, front-loaded with the verb and resource, and zero wasted words. The first sentence states the purpose; the second provides a practical example.
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?
For a low-complexity tool with one parameter and no output schema, the description gives the essential purpose, the types of metadata, and a usage scenario. It lacks explicit return structure, but the provided details are sufficient for basic selection and invocation.
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?
The schema provides 100% parameter coverage with an explanatory description for entity_type. The tool description adds a concrete use case (order state hrefs) that helps an agent decide which entity_type to pass, going beyond the schema's generic examples.
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 the tool retrieves metadata for entity types, naming the kinds (states, attributes, price types) and a concrete use case (finding order state hrefs for update_customer_order_status). This is a specific verb+resource that distinguishes it from sibling tools.
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 explicitly says 'Use to find order state hrefs for update_customer_order_status,' providing a clear context for when to invoke it. It does not explicitly list alternatives or when-not-to-use, but the scenario is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden for behavioral disclosure. It implies a read-only list operation and adds valuable behavioral details: the ordering (first is default) and the role of the href in setting prices. It does not explicitly state 'read-only' but the verb 'list' makes that clear.
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 short, information-dense sentences. The first states the core function, the second adds practical usage context. Every word earns its place with no filler or repetition.
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?
Given the simple nature (no parameters, no output schema), the description is quite complete: it states what is listed, notes the default ordering, and explains how to use the returned hrefs. It could be more explicit about the return format, but the information provided is sufficient for an agent to use the tool 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?
The tool has zero parameters, so the baseline is 4. The schema is empty, and the description contains no parameter-related information, which is appropriate since there are no parameters to explain.
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 the tool's function with a specific verb and resource: 'List the account's price types'. It also adds useful context about the first item being the default, which distinguishes the tool's purpose and provides deeper meaning beyond the name.
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 gives practical guidance on when to use the tool's output ('Use a price type href when setting product prices'), effectively explaining the purpose of calling this tool. While it doesn't explicitly discuss alternatives, the tool is unique among siblings for listing price types, so this level of guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![moysklad-mcp MCP server](https://glama.ai/mcp/servers/theYahia/moysklad-mcp/badges/card.svg)](https://glama.ai/mcp/servers/theYahia/moysklad-mcp)

Score Badge

Copy to your README.md:

[![moysklad-mcp MCP server](https://glama.ai/mcp/servers/theYahia/moysklad-mcp/badges/score.svg)](https://glama.ai/mcp/servers/theYahia/moysklad-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/theYahia/moysklad-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server