cdek

by dontsovcmc

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.6.0
Disambiguation4/5
Most tools have distinct purposes, but cdek_barcode and cdek_label both print barcodes with only format difference, causing slight confusion. Similarly, cdek_calculate_tariff, cdek_calculate_tarifflist, and cdek_calculate_tariff_and_service overlap in function. Overall, boundaries are clear for the majority.
Naming Consistency3/5
CDEK operations consistently use 'cdek_verb_noun' pattern, but local tools (goods_list, goods_add, config_show) break the prefix convention, creating inconsistency. Some names like cdek_order_intakes or cdek_delivery_points use noun_noun instead of verb_noun.
Tool Count2/5
With 49 tools, the server attempts to cover the full CDEK API plus local catalog/configuration. This is excessive for an MCP server, overwhelming agents and making tool selection error-prone. A more focused subset (15-20) would be appropriate.
Completeness4/5
The tool set covers major CDEK operations: order lifecycle, tracking, printing, tariff calculation, intakes, deliveries, webhooks, and location services. Only minor gaps exist (e.g., missing order status history or some document types), but core workflows are well-supported.
Average 3.7/5 across 49 of 49 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it changes status via PATCH. It does not disclose behavioral traits such as idempotency, error conditions, or side effects beyond the basic update.
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 to the point, but the structure could be improved by separating the English and Russian parts or adding a more formal structure. It is adequately 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?
Given the tool is a mutation (PATCH) and has an output schema, the description does not contextually explain how this updates differ from similar operations, error handling, or what happens to related entities. It lacks completeness for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description's 'Args' section adds minimal value by repeating parameter names and providing one-line explanations. It lacks details like possible status_code values or constraints.
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 changes the status of a courier call request (intake) to 'Needs processing' with additional statuses, specifying the HTTP method and endpoint. However, it does not explicitly differentiate from sibling tools like cdek_create_intake or cdek_delete_intake.
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 (e.g., creating a new intake or deleting one). No context about prerequisites or typical scenarios is 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, the description fails to disclose behavioral traits such as whether the tool is read-only, destructive, or requires authentication. It only mentions it's a POST request, which is minimal.
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 reasonably sized with a clear structure (endpoint, explanation, args). However, it repeats information from the schema and could be more front-loaded with essential 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?
Despite the existence of an output schema, the description does not mention return values or structure. It lacks context to distinguish from many sibling tariff tools, making it incomplete for effective selection.
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 description adds basic semantics for parameters (e.g., 'Package weight in kg', 'length in cm') and provides defaults. However, it does not explain permissible formats for city names or other constraints, leaving gaps.
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 it calculates cost and delivery time for available tariffs with additional services using a POST endpoint. However, it does not explicitly differentiate from sibling tools like cdek_calculate_tariff or cdek_calculate_tarifflist, leaving 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?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context for its invocation. The agent receives no help in selecting this tool over similar ones.
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 provided. The description does not disclose behavioral traits beyond the HTTP method. Missing details on authentication, error handling, pagination, or idempotency.
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?
Very concise at two sentences. Front-loaded with purpose. Could be slightly more structured but no unnecessary 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?
Incomplete for an agent. Lacks explanation of what an 'intake' is, how to obtain order_uuid, error cases. Output schema exists but description should still cover basics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds minimal value, only restating 'order_uuid: Order UUID'. Does not explain format, source, or constraints.
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 it retrieves info about all intakes for an order, specifying the HTTP method and endpoint. It distinguishes from sibling tools like cdek_get_intake which retrieves a specific intake.
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 on when to use this tool vs alternatives like cdek_get_intake or cdek_create_intake. Usage is only implied by the 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?
No annotations are provided, so the description must disclose behavioral traits. However, it only mentions it is a POST request and registers a prealert, without detailing side effects, idempotency, authorization needs, or whether it is destructive. This is insufficient for safe invocation.
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 short and front-loaded with purpose, using two clear sentences plus parameter lines. It is efficient but could be more structured (e.g., sections). 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?
Despite having an output schema, the description does not mention what the response looks like. It also lacks information on prerequisites (e.g., orders must exist), error handling, or next steps. For a tool in a complex logistics system, this is incomplete.
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?
Input schema has 0% description coverage, so the description adds critical meaning: specifies format for planned_date (YYYY-MM-DD), gives an example for shipment_point ('MSK005'), and clarifies that cdek_numbers are comma-separated. This goes beyond the schema names.
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 registers a prealert and informs CDEK about intention to transfer orders, using the verb 'регистрация' and 'информирование'. It is specific to creating a prealert, distinguishing it implicitly from siblings like cdek_get_prealert.
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 explicit guidance on when to use this tool versus alternatives. It only states the action, leaving the agent to infer context from sibling names. No 'when not to use' or alternative tools 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?
No annotations are provided, so the description carries the full burden. It identifies the operation as a POST to retrieve intervals but does not disclose if it is read-only, idempotent, or if it modifies any state. The word 'получить' suggests a read, but behavioral traits like side effects or authorization needs 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence stating purpose, followed by a clean parameter list. Every element adds value, though the parameter list could be slightly more compact. No extraneous information.
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 5 parameters and no annotations, the description covers the basics. However, it does not mention the output format or what the intervals contain (e.g., dates, times, availability). The presence of an output schema is noted but not leveraged in the description.
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 0%, so the description compensates with an Args section that adds meaning (e.g., 'Recipient city name', 'CDEK tariff code (default 136)', 'Date-time ISO format'). However, some parameters like date_time lack explicit format guidance, and shipment_point is only partially explained.
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 it retrieves delivery intervals before creating an order, with specific mention of 'до двери' (to door) and reference to the API endpoint. It distinguishes from siblings like cdek_create_order but does not explicitly differentiate from the sibling cdek_delivery_intervals, which may overlap.
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 'before creating an order' but does not provide explicit guidance on when to use this tool versus alternatives like cdek_delivery_intervals or cdek_calculate_tariff. No when-not-to-use or exclusions 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?
No annotations provided, so description must disclose behavioral traits. It states it's a GET request, implying non-destructive, but omits details like authentication needs, rate limits, or side effects. The description is too minimal for full 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?
Two short sentences: first defines purpose, second lists parameter. No wasted words, front-loaded with essential 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?
Although an output schema exists (not shown), the description does not elaborate on what information is returned or the structure. For a retrieval tool, more context about the response would be valuable. Current description is too brief.
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?
Only one parameter (uuid). The description adds 'Delivery UUID' which clarifies the parameter's role beyond the schema's type and title. With 0% schema description coverage, the description provides necessary minimal semantics but is not detailed.
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?
Description clearly states it retrieves information about a delivery agreement using a GET endpoint. The verb 'получение информации о договоренности о доставке' precisely indicates the action and resource, distinguishing it from sibling creation tools like cdek_create_delivery.
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 on when to use this tool versus alternatives like cdek_get_order or when not to use it. The description only explains what it does, not the context of use.
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. It only states it downloads a zip archive via GET, but does not disclose what happens if the file already exists, network error handling, size limits, or that it is a read-only 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 brief and front-loaded with the main action. It includes an args list but could be slightly more concise by integrating the parameter explanations into the prose; however, it is not overly verbose.
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 an output schema exists, the description lacks important context: it does not mention the dependency on cdek_request_photos, file overwrite behavior, or error handling. For a tool with no annotations, these gaps reduce completeness.
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 description explains both parameters: uuid is 'Photo document request UUID' and output_path is 'Absolute path to save the zip archive'. Since schema coverage is 0%, this adds necessary meaning 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 clearly states the tool downloads a ready archive of photos in zip format, and mentions the specific HTTP method and endpoint. Among siblings, it distinguishes itself from cdek_request_photos which likely is used to request the photos initially.
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 cdek_request_photos, or what prerequisites are needed (e.g., a valid UUID from a prior request).
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 carry full burden. It omits side effects like making an HTTP POST request, authorization needs, or any destructive actions. The only behavior stated is saving a PDF.
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 uses a structured docstring style but is somewhat verbose with Russian text. Could be more concise while retaining clarity.
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 presence of an output schema, return values are likely covered. However, the description lacks usage guidance and behavioral details, making it marginally adequate.
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?
With 0% schema description coverage, the description adds significant meaning by explaining cdek_number as tracking number, output_path as absolute path, and format with size details. However, it lacks enum or format constraints for format.
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 generates and downloads a barcode label with format selection, distinguishing it from sibling tools like cdek_barcode.
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 guidance on when to use this tool versus alternatives, nor mentions 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must bear full burden. It implies a read-only operation (GET endpoint) and specifies data returned (registries for a given date), but does not mention permissions, rate limits, or side effects. Adequate but not thorough.
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?
Two sentences with an args section. Efficient and front-loaded with the endpoint. Slightly unstructured but appropriate for a simple tool.
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 simple tool with one parameter and existing output schema, the description covers the basic purpose and parameter format. However, it lacks details on the structure of returned data or pagination, which could be important. Adequate but not 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?
Schema has 0% description coverage, but description adds format hint (YYYY-MM-DD) for the required 'date' parameter. This clarifies input beyond what the schema provides, though does not explain the exact meaning of the date (e.g., payment date vs. registry date).
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?
Description clearly states the tool retrieves information about registries of cash on delivery payments (реестры наложенных платежей) and provides the endpoint. It is distinct among siblings with 'registries' in name but lacks explicit differentiation from other cdek tools.
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 on when to use this tool versus alternatives like cdek_waybill or cdek_get_order. It simply describes functionality without specifying context 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?
No annotations exist, so the description carries full burden. It only mentions the HTTP endpoint and parameter names, lacking details on side effects, authentication, error handling, or behavior beyond the basic calculation. No information on return format or potential limitations.
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 structured with a title line, a summary sentence, and a parameter list. It is concise but could omit the redundant title line. The use of 'Args:' with bullet points is clear.
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 6 parameters (3 required) and no annotations, the description covers usage basics but omits return value details. Although an output schema exists, the description does not hint at what it contains. Behavior with invalid inputs or city resolution is unexplained.
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 0%, so the description must compensate. It lists parameters with minimal descriptions (e.g., 'Sender city name') and defaults, but adds no semantics on format, constraints, or allowed values. This is adequate but not enriching.
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 calculates cost and delivery times for all available tariffs between two cities. The verb 'calculate' and resource 'tarifflist' (all tariffs) differentiate it from siblings like cdek_calculate_tariff for a specific tariff.
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 use when all tariffs are needed, but does not explicitly state when to prefer alternatives like cdek_calculate_tariff or cdek_calculate_tariff_and_service. No when-not-to-use or exclusion criteria are provided.
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 states the action and HTTP method, but does not disclose side effects, authentication needs, idempotency, or any other behavioral traits.
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 main action, followed by a list of types and parameter explanations. It is efficient with no 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 two simple parameters and an output schema, the description covers the basic functionality. However, it lacks behavioral context and usage guidance, leaving gaps in 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?
With 0% schema description coverage, the description adds value by listing the parameters and giving examples for 'type' (e.g., ORDER_STATUS), though it lacks format constraints or further details for 'url'.
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 it is for adding a webhook subscription, specifies the HTTP method and path, and lists the available webhook types, distinguishing it from sibling tools like list, get, delete.
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 creating webhooks, but does not provide explicit guidance on when to use it versus alternatives like cdek_list_webhooks or cdek_delete_webhook.
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. It mentions the output (status, history, delivery details) and that it can access orders from other channels, but it does not disclose error handling, rate limits, authentication needs, 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 very concise: two sentences plus a parameter line, no redundancy. The main purpose is front-loaded, making it easy for an agent to parse quickly.
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 annotations), the description covers the basic purpose and parameter. However, it lacks guidance on sibling differentiation and behavioral details such as errors or prerequisites, which would be helpful for full autonomous use.
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?
Since schema description coverage is 0%, the description adds essential meaning by naming the parameter 'cdek_number' as the CDEK tracking number and providing an example (1234567890). This compensates for the bare 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 it retrieves order information by CDEK tracking number, specifying the API endpoint and returned data (status, history, delivery details). However, it does not distinguish itself from sibling tools like cdek_get_order or cdek_get_order_by_im_number, which may have overlapping functionality.
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 explicit guidance on when to use this tool versus alternatives. While it mentions it works for orders created through personal account and other channels, it lacks exclusion criteria or pointers to other tracking 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 should disclose behavioral traits. It only states it returns all tariffs, but does not mention that it is a read-only GET operation, whether authentication is required, or any side effects. The simplicity of the tool mitigates this somewhat, but the description still lacks important 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, one for return value, and one line for the parameter. It is front-loaded with the main purpose. However, the first line is simply the endpoint URL, which is redundant with the tool name and could be omitted for brevity. Overall, it is efficient with minimal waste.
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 that an output schema exists (though not shown), the description does not need to explain return values. However, it lacks context such as authentication requirements, contractual prerequisites, or how the tariff list relates to other tools (e.g., for use in calculation). For a simple list tool, this is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), so the description must compensate fully. It does so by explaining the meaning of the 'lang' parameter, listing allowed values ('rus', 'eng', 'zho'), and stating the default. This is clear and complete for a single parameter, adding significant value 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 'List of available tariffs' and 'Returns all available and actual tariffs by contract.' It identifies the resource (tariffs) and the action (list). However, it does not explicitly differentiate from sibling tools like cdek_calculate_tariff, which also deal with tariffs but for cost calculation, so the distinction is implied rather than explicit.
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 the list of tariffs, but it provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or when not to use it. The context among many sibling tools suggests it may be used before tariff calculation, but this is not stated.
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 carry the burden. It states it's a DELETE operation (destructive) but does not disclose side effects, return value, authorization requirements, or error handling. This is insufficient for a tool that performs a mutation.
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?
Extremely concise with only two lines (one for endpoint, one for parameter). No wasted words; information is front-loaded. For a simple tool with one parameter, this structure is ideal.
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 param, deletion operation) and the existence of an output schema, the description is minimally adequate. However, it lacks context about when deletion is appropriate, what happens after, or any notes on idempotency. It meets the bare minimum but could be more helpful.
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 0% coverage (parameter only titled 'Uuid'), but the description adds semantic value: 'uuid: Webhook subscription UUID' clarifies the parameter's purpose and domain. This compensates for the schema deficiency.
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 subscription) and the resource (webhook by UUID), with the HTTP method and endpoint. It distinguishes from sibling webhook tools (create, list, get) by specifying deletion.
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 on when to use this tool versus alternatives (e.g., when you need to remove a webhook subscription). No prerequisites or conditions mentioned. The description assumes the user already knows the UUID and the need for deletion.
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?
Without annotations, the description carries the full burden. It mentions the HTTP method (GET) implying idempotence, but lacks details on error handling, authorization requirements, or what happens with invalid UUIDs. Minimal behavioral disclosure.
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 covering the purpose and the parameter. Every word adds value with 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?
For a simple one-parameter retrieval with an output schema, the description covers the basics. However, it lacks context on typical usage scenarios or preconditions, leaving it minimally 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 single parameter 'uuid' has no description in the input schema (0% coverage), but the description adds 'Intake request UUID', providing essential meaning. This compensates for the schema gap.
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 that the tool retrieves information about an intake by its UUID, specifying the HTTP endpoint. This distinguishes it from sibling tools like cdek_get_order or cdek_get_delivery.
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 other retrieval tools or when not to use it. The description only states what it does.
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 provided, so description must disclose behavior. It states GET method (safe, read-only) and returns detailed info. No mention of auth requirements, rate limits, or error handling. Adequate but could be more transparent about response format.
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?
Description is reasonably concise, with a clear structure including an Args section. The information is front-loaded with the main action. Could be slightly shorter, but effective.
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?
Simple retrieval tool with one parameter and output schema provided elsewhere. Description covers the basic purpose and parameter. Lacks mention of error responses or common pitfalls, but sufficient for a straightforward read 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?
Only one parameter (uuid) with 0% schema coverage. Description adds that it is the order UUID in CDEK system, but does not specify format or constraints. Partially compensates for missing schema descriptions.
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?
Description clearly states the tool retrieves order information by UUID via GET endpoint. It mentions it works for orders created through other channels. However, it does not explicitly differentiate from sibling cdek_get_order_by_im_number, which serves a similar purpose but by IM number.
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?
Description implies use when UUID is available, but no explicit guidance on when not to use or alternatives like cdek_get_order_by_im_number. No exclusions or prerequisites mentioned.
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 exist, so the description bears full responsibility. It mentions GET, implying a read-only operation, but does not disclose error behavior, permissions, or side effects. This is adequate but 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?
The description is two sentences: a purpose statement and a parameter list. No wasted words, front-loaded with the operation. Ideal conciseness.
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 an output schema present, return values need not be explained. However, the description lacks usage guidelines and behavioral details, making it incomplete for a tool with no annotation support.
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 0%, so the description must compensate. It clarifies that 'uuid' is the webhook subscription UUID, adding meaning beyond the schema's empty string. However, it is only a brief restatement.
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 it retrieves information about a webhook subscription by UUID, with the HTTP endpoint. This distinguishes it from sibling webhook tools (create, list, delete) and functions as a specific verb+resource.
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 like cdek_list_webhooks or cdek_create_webhook. It only states what it does, without specifying 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?
No annotations exist, and the description does not disclose behavioral traits such as whether the operation is idempotent, if duplicates are allowed, or any side effects. The description relies solely on the action name.
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 well-structured with a clear header and Args list, but the Args section repeats parameter names unnecessarily. Slightly verbose but overall concise.
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 covers all parameters adequately but does not mention return value (despite output schema existing) or any constraints on values (e.g., valid ranges). Missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by providing examples, units (kg, cm, rubles), and default value for price. This adds substantial meaning beyond the schema titles.
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 'Add a new good to local catalog', specifying the verb and resource. It distinguishes from sibling tools like goods_list and goods_remove.
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 on when to use this tool versus alternatives, no prerequisites or context provided. The description lacks exclusions or specific 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?
The description lacks details beyond the basic action. It does not disclose that this is a read-only operation, any rate limits, or what the response contains. Since no annotations are provided, the description carries the full burden, but it fails to add 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 extremely concise: two sentences for purpose and a clear parameter list. No redundant or extraneous information. Every word contributes to clarity, making it efficient for quick comprehension.
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 coordinate lookup with two numeric parameters and an output schema, the description is largely sufficient. It defines inputs and purpose. However, it doesn't mention coordinate range limits or that it returns address details, which could be inferred from the output schema but is not stated. With many sibling tools, a bit more context (e.g., 'Returns address components') would improve completeness.
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 has 0% description coverage for parameters, but the description lists both parameters with example values (latitude 55.7558, longitude 37.6173). This adds practical meaning, helping the agent understand the expected format. The description compensates well for the lack of 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 retrieves a location by coordinates using GET /v2/location/coordinates. It specifies the resource ('локация по координатам') and the action ('получение'), making the purpose unambiguous. The sibling tools include different lookups (cdek_cities, cdek_delivery_points), so this tool is distinct.
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 siblings. While the purpose is clear, the description does not explicitly state when it is appropriate (e.g., 'Use when you have latitude/longitude') or mention any prerequisites or alternatives.
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 bears full burden. It explains the action (registering an agreement) and conditions for time/address fields but omits side effects, permissions, or error cases.
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 mixes Russian and English, and includes an API path and parameter list. It is somewhat verbose; could be more concise by removing redundant 'Args' lines after already listing them.
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?
Output schema exists, so return values need not be described. However, the description lacks usage scope (when to use) and does not cover non-parameter behaviors like side effects or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description lists all 7 parameters with explanations and additional constraints (e.g., time_from/time_to mandatory for 'до двери', delivery_point for 'до склада', and the requirement for at least one of cdek_number/order_uuid).
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 registers a delivery agreement via POST /v2/delivery, fixing date/time and allowing address changes. It distinguishes from siblings like cdek_create_order and cdek_get_delivery.
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 (e.g., cdek_get_delivery, cdek_create_order). Only parameter constraints (at least one of cdek_number or order_uuid) are given.
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 discloses the deletion condition (not final status) but does not mention idempotency, reversibility, side effects, or return behavior.
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 short and front-loaded with the main purpose. It contains only two sentences, no fluff, but the inclusion of an Args section is slightly redundant given the parameter is already in the schema.
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 that there is an output schema (though not shown), the description does not need to explain return values. However, it lacks context on error responses, idempotency, or prerequisites beyond the status condition. Adequate for a simple delete but could be more 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 parameter 'uuid' is described as 'Intake request UUID', which adds meaning beyond the schema's type definition. However, with 0% schema description coverage, the description only provides basic identification without format or source details.
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 deletes an intake request, specifies the HTTP method and endpoint, and differentiates itself from sibling tools like cdek_delete_order or cdek_delete_webhook by focusing on intakes.
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 notes that the intake can be deleted only in non-final status, providing a clear condition. However, it lacks guidance on when not to use it or mentions of alternative actions like updating the intake.
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?
Since no annotations are provided, the description carries full burden. It explicitly states it is a GET operation that returns dates and intervals, implying no side effects. Could mention that no modifications occur.
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?
Description is reasonably concise and structured: API endpoint, functionality, parameter requirement, and parameter list. Mixing Russian and English is a minor drawback but not excessive.
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 an output schema present, the tool description does not need to detail return format. However, it does not explain the business context (e.g., when intervals apply) or any constraints on the intervals.
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 has 0% description coverage, so description must compensate. The Args section gives one-line descriptions for cdek_number and order_uuid and states that at least one is required. This adds some meaning but is minimal; e.g., no format or source details.
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?
Description clearly states it retrieves delivery intervals for an existing order (GET endpoint). However, it does not differentiate from sibling tools like cdek_estimated_intervals, which might serve a similar 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?
Specifies the prerequisite that at least one of cdek_number or order_uuid must be provided. Does not provide guidance on when to use this over other tools, nor 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?
No annotations are provided, so the description carries full responsibility. It discloses the HTTP method (GET), hinting at read-only behavior, but lacks details on authentication, error handling, rate limits, or what happens if the order is not found. Minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with a one-sentence purpose and a clear Args line. However, there is some duplication between Russian and English text that could be streamlined. The structure is logical.
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 that an output schema exists (not shown), return values are presumably documented. The description covers the tool's primary function and parameter meaning, but lacks behavioral transparency (errors, edge cases) and usage guidance, leaving gaps for an agent.
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?
Although the input schema has 0% description coverage (no description field in schema), the description compensates by explaining that im_number is 'Order number in client's system'. This adds crucial meaning beyond the schema's type-only definition.
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 it gets order information by IM number (client's system order number), using the specific verb 'получение' (get) and resource 'заказ' (order). It distinguishes from sibling tools like cdek_get_order by specifying the identifier 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 description implies usage for retrieving orders by client system number, but does not explicitly state when to prefer this over alternatives like cdek_get_order (which likely uses CDEK's internal order number). No exclusion criteria or when-not-to-use guidance is provided.
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 should disclose behavioral traits like error handling, authentication, or rate limits. It only indicates it's a GET (read) operation but nothing else.
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 sentences, no fluff. The purpose is front-loaded with the HTTP method and path.
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 tool's simplicity (one parameter, read-only, output schema present), the description is mostly complete. It lacks details on error conditions but the output schema covers return values.
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 has 0% description coverage; the description adds meaning by explaining that the uuid parameter is a Prealert UUID. This compensates for the missing 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 retrieves information about a prealert using HTTP GET, and the path includes the UUID parameter. It distinguishes itself from its sibling cdek_create_prealert.
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, nor any context or exclusions. The description only states the basic operation.
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 provided, so description carries full burden. It only states basic functionality and HTTP endpoint; no disclosure of side effects, authorization needs, rate limits, or response behavior.
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?
Description is very concise (3 short sentences + 2 parameter lines), well-structured with clear separation of purpose and arguments. No wasted words.
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?
Output schema exists, so return value explanation not needed. Covers both parameters adequately. Could mention date format or error handling, but for a simple lookup tool this is sufficient.
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?
Schema has 0% description coverage, so description must compensate. It explains both parameters: 'city' as city name (example Москва) and 'date' as inclusive end date with default (today+2 weeks). This adds meaningful context beyond 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 clearly states the tool returns available dates for courier pickup (POST /v2/intakes/availableDays), using specific verb 'получение' and resource 'дат вызова курьера'. It is distinct from sibling tools like cdek_create_intake or cdek_get_intake.
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 on when to use this tool versus alternatives. No mention of prerequisites, limitations, or comparison with 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 provided, so description must disclose behavioral traits. It mentions the HTTP method and endpoint but does not state that the operation is read-only, does not describe error handling, auth needs, or rate limits.
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?
Very concise: two lines of purpose followed by a structured Args section. No redundant information, front-loaded with the main functionality.
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?
Adequate for a simple retrieval tool with an output schema (not shown). The description explains parameters and the type of restrictions (by route and tariff). Could be slightly more explicit about the output nature, but sufficient.
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?
With 0% schema coverage, the description provides clear semantics for all three parameters (tariff_code, from_city, to_city), explaining default behavior and what each represents, compensating well for the missing 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?
Description clearly states the tool retrieves international order restrictions via a POST endpoint, specifying the resource and action. It distinguishes from siblings like tariff calculations by focusing on restrictions.
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 on when to use this tool vs alternatives (e.g., cdek_all_tariffs, cdek_calculate_tariff). No mention of 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?
No annotations provided, so description carries full burden. It only states the operation (GET request) with no mention of side effects, authorization needs, rate limits, or return value structure beyond the bare action.
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?
Single sentence, no superfluous text. Content is front-loaded and efficient.
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 parameterless list operation with an output schema, the description is adequate. However, it could clarify that it lists all webhook subscriptions (versus a single webhook).
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?
Input schema has zero parameters, so description adds no param info, but baseline is 4 per rules. The provided endpoint info is not param-related.
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?
Description clearly states the verb (Получение информации) and resource (подписках на вебхуки) with the HTTP endpoint. It distinguishes from sibling tools like cdek_get_webhook (singular) by implying listing all subscriptions.
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 on when to use this tool versus alternatives like cdek_get_webhook or cdek_create_webhook. The description only states what it does, not usage 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 present, so the description must cover behavioral traits. It mentions saving a PDF to a path but omits side effects (e.g., overwriting), authentication needs, rate limits, or what happens on error. The POST method is noted but without additional 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 concise: two sentences and a simple argument explanation. It is front-loaded with the core action and uses a structured format. Every sentence provides essential information without 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?
Given the tool's simplicity (2 parameters, no nested objects) and the presence of an output schema, the description covers the main purpose and parameter meanings. Missing details like expected return or error handling are acceptable for a straightforward file-download tool.
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?
Schema coverage is 0%, but the description compensates by explaining each parameter: cdek_number is a CDEK tracking number, output_path is an absolute path to save the PDF. This adds clear meaning beyond the schema's bare type and title, though constraints like file extension or size are missing.
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 forms and downloads a receipt (waybill) in PDF format, specifying the HTTP method and endpoint. The verb 'формирует и скачивает' and resource 'квитанции к заказу' are specific, and the tool is distinct from siblings like cdek_barcode and cdek_label which handle other print formats.
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. The description merely states what it does, without mentioning prerequisites, exclusions, or comparisons to sibling tools like cdek_label or cdek_barcode.
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 states 'Remove' indicating a destructive action, but does not disclose if the operation is reversible, any side effects, or required permissions. For a simple deletion, 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 extremely concise with two sentences and an Args list. Every sentence earns its place, and the main action is front-loaded. No 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?
For a simple removal tool with one parameter and an output schema, the description is adequate but lacks details on error behavior (e.g., what if name not found) and confirmation requirements. It borders on minimal.
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?
Schema description coverage is 0%, but the description adds an Args section specifying that the name must be exact. This adds meaningful information beyond the schema, though it could be more detailed (e.g., case-sensitivity).
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 ('Remove'), the resource ('a good'), the scope ('from local catalog'), and the condition ('by exact name'). It distinguishes from sibling tools like goods_add and goods_list.
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 name must be exact, but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention common pitfalls such as case sensitivity or what happens if the name does not match.
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 should disclose behavioral traits. It mentions the POST endpoint but lacks details on rate limits, idempotency, side effects (e.g., does it mutate anything?), or auth requirements. For a calculation tool, it's likely read-only, but not explicitly stated.
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 well-structured with a header, summary, and parameter list. It is clear but could be slightly more concise (e.g., 'Package' repeated). Still efficient for the information provided.
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 complexity (7 params, 4 required) and presence of an output schema, the description adequately covers purpose and parameters. It lacks details on error handling or validation, but overall is sufficiently complete for a calculation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: tariff_code with examples, units for weight and dimensions, and default values. This adds significant value beyond the raw 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 clearly states the tool calculates cost and delivery time for a specific tariff based on weight and dimensions. It distinguishes from sibling tools like cdek_calculate_tarifflist and cdek_all_tariffs by focusing on a single tariff code.
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 concrete tariff but does not explicitly state when to use this vs alternatives like cdek_calculate_tariff_and_service. No exclusions or when-not-to-use guidance provided.
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. The description states it returns a list of cities and codes but does not disclose behavioral details like pagination, authentication, or error handling. The GET nature is implied by the endpoint but not stated.
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 short and front-loads the main action. The Args section is somewhat redundant with the schema but does not waste words. Could be slightly more 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?
The description mentions city codes and a list, but lacks details on other returned fields, request format, or any limitations. Since an output schema exists, the description is adequate but has gaps.
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 description adds meaning to the 'city' parameter by stating it accepts partial names (e.g., 'Новосиб'), which goes beyond the schema's raw type/required info. With 0% schema description coverage, this is valuable.
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 returns a list of cities with their SDEC codes via GET /v2/location/cities. It distinguishes from siblings like cdek_suggest_cities and cdek_delivery_points by being a general cities list.
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 obtaining city codes needed for other operations but does not provide explicit when-to-use or when-not-to-use guidance compared to sibling tools like cdek_suggest_cities or cdek_regions.
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 discloses that the tool is a read-only GET request returning suggestions, but lacks details on authentication, rate limits, or result limits. This is adequate for a simple suggestion tool but could be improved.
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 (3 sentences) and front-loaded with the purpose. The 'Args' section clearly describes parameters. Minor redundancy due to dual-language phrasing but overall efficient.
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 tool's simplicity (2 parameters, one required) and the presence of an output schema, the description adequately covers the purpose and parameter semantics. No critical gaps remain for a suggestion tool.
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?
Schema coverage is 0%, meaning no descriptions in the input schema. The description adds value by explaining both parameters: name is a city name or prefix, and country_code is an ISO_3166-1_alpha-2 code with an example. This is more helpful than the schema alone.
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 suggests cities by name ('Подбор локации по названию города' / 'возвращает подсказки по подбору населенного пункта'). It distinguishes itself from siblings like cdek_cities (full list) and cdek_delivery_points (specific locations) by focusing on autocomplete suggestions.
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 state when to use this tool versus alternatives like cdek_cities for full city lists. Guidelines are implied but not articulated, leaving the agent to infer context from sibling names.
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 burden. It mentions the tool saves a file to a specified path and uses POST, but does not discuss side effects, permissions, error handling, or file overwrite behavior. Adequate but not thorough.
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 brief, structured with a title line, a single-sentence explanation, and clear Args list. Every sentence adds value, with no 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?
Given the tool's simplicity (2 required params, output schema exists), the description covers purpose, parameters, and output format (PDF). It lacks details on errors or idempotency, but is largely complete for a straightforward file-generation tool.
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?
Schema coverage is 0%, so the description compensates well. It explains cdek_number as 'CDEK tracking number' and output_path as 'Absolute path to save PDF', adding critical meaning beyond the schema's type-only definitions.
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 generates and downloads a barcode in PDF format for an order, using the verb 'формирует и скачивает'. It distinguishes from siblings like cdek_label or cdek_waybill by specifying 'ШК-место' (barcode place), 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 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 versus its siblings (e.g., cdek_label, cdek_waybill). It implies usage for printing barcodes but does not contrast or exclude other 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 cover behavioral traits. It discloses the precondition but omits details about the destructive nature of deletion, irreversibility, authentication needs, or side effects. This is insufficient for a delete 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 concise with three short sections: action summary, precondition, and parameter description. Every sentence adds value without 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 deletion tool with one parameter and an output schema, the description covers the core purpose and usage condition. It lacks information on irreversibility and error conditions, but these are minor gaps.
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 description includes an 'Args' section that explains the only parameter (uuid) as 'Order UUID to delete', adding meaning beyond the schema's title. Since schema coverage is 0%, the description compensates effectively.
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 (deleting an order) with the HTTP method and resource. It unambiguously identifies the operation and distinguishes it from sibling tools like cdek_create_order and cdek_update_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific condition for usage: deletion is only possible when the order status is "Created" (no cargo movement). This implies when not to use the tool, though explicit alternatives are not 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?
No annotations are provided, so the description carries the full burden. It only states the endpoint and parameter, omitting any behavioral traits such as error handling, rate limits, or side effects. For a GET endpoint, minimal disclosure but still lacking 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: one sentence plus a parameter list. Every part is front-loaded and necessary, with no extraneous information. It efficiently communicates the tool's purpose and parameter.
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 output schema exists, the description adequately covers the input parameter. It could mention potential error scenarios (e.g., invalid city_code), but for a simple retrieval tool, it is sufficiently 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 schema has 0% description coverage, and the description adds crucial meaning by explaining that city_code is a CDEK city code and referencing cdek_cities for lookup. This compensates well for the schema's lack of parameter 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 returns postal codes of a city, mentions the API endpoint, and explains the required city_code parameter with a cross-reference to cdek_cities. This distinguishes it from sibling tools like cdek_cities or cdek_delivery_points.
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 instructs to use city_code from cdek_cities, providing a prerequisite. However, it does not discuss when not to use this tool or suggest alternatives among siblings, which is acceptable for a simple lookup tool.
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 full burden. It discloses the key constraint (status condition and no cargo movement) and that it is a PATCH operation. It does not mention side effects, authentication requirements, or response details, so the transparency is moderate.
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 with only a few lines, front-loading the purpose and the key condition. It mixes English and Russian but is reasonably structured. Minor improvement could be separating the condition more clearly.
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 complexity (4 params, 0 required, no annotations) and presence of an output schema, the description covers the essential update condition and parameter roles. However, it lacks details about error handling, return values (though output schema exists), and usage compared to sibling order tools. It is adequate but not thorough.
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?
Schema description coverage is 0%, so the description must compensate. It explains each parameter: uuid (CDEK system ID), cdek_number (alternative tracking number), comment (new comment), delivery_point (new pickup point code). It also clarifies that uuid and cdek_number are mutually exclusive but at least one required. This adds meaning beyond the schema's titles and defaults.
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 updates an existing order ("Изменение заказа") and specifies the HTTP method (PATCH /v2/orders). It distinguishes itself from siblings like cdek_create_order, cdek_get_order, and cdek_delete_order.
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 specifies the condition: update is possible only when the order status is 'Created' and no cargo movement at the CDEK warehouse. It states the requirement that at least one of uuid or cdek_number must be provided. However, it does not explicitly list when to use this tool versus alternatives.
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 asynchronous behavior and the need for subsequent verification, but lacks details on permissions, error conditions, rate limits, or side effects. For a mutation tool, this is adequate but not comprehensive.
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 well-structured: a brief summary, followed by async note, then direction details, and finally an args list. It is front-loaded with purpose. While slightly verbose for some args, it remains readable and avoids unnecessary fluff.
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 tool's complexity (13 params, async behavior) and the presence of an output schema (so return values are covered), the description is fairly complete. It explains two usage directions, default parameter behaviors, and the need to check results. It could include error handling or edge cases, but overall it provides sufficient context for usage.
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?
With 0% schema description coverage, the description provides meaning for all 13 parameters via the 'Args' section. It explains each parameter's role (e.g., pvz is PVZ code or address, recipient_phone format), defaults, and overrides. However, some parameters (e.g., address format) lack precise constraints, preventing a perfect score.
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 'Создает в ИС СДЭК заказ на доставку' (creates an order in CDEK IS), with explicit reference to endpoint POST /v2/orders. It distinguishes from sibling tools like cdek_update_order and cdek_delete_order by focusing on creation, and further specifies two directions (from_me/to_me), leaving no ambiguity about the tool's purpose.
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 explains when to use the tool (to create a delivery order) and includes important context: asynchronous behavior (status ACCEPTED does not guarantee creation), the need to verify via other methods, and two usage scenarios with specific tariffs. However, it does not explicitly state when not to use it or list alternative tools, though siblings imply this.
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?
The description discloses the HTTP method (POST) and endpoint, and the action of registering refusal. However, it does not mention side effects like status changes, notifications, or permissions. With no annotations, it is adequate but not comprehensive.
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?
Concise with two meaningful sentences plus an args line. Structure is clear: purpose, conditions, parameter. No unnecessary words.
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 tool's simplicity (one required parameter) and existence of output schema, the description covers the essential: action, conditions for use, and alternative. It could add more on response but is sufficiently 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 description specifies that the 'uuid' parameter is the order UUID to refuse, adding meaning beyond the schema's type-only definition. With 0% schema description coverage, this compensates partially but lacks format or source details.
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 registers a refusal (cancellation) of an order and triggers return to the online store. It specifies the HTTP endpoint and distinguishes itself from deletion for 'Created' status orders.
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?
Explicitly states cancellation is allowed in any status before 'Delivered'/'Not delivered' and recommends using delete order for 'Created' status, providing clear when-to-use and when-not-to-use guidance with an alternative.
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 indicates the tool performs a read operation (GET) and requires at least one parameter. However, it does not disclose authentication needs, rate limits, or failure behaviors, leaving some gaps.
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, with key information front-loaded (Russian then English, though some redundancy). The Args section is clear and structured. It could be slightly more streamlined but is well-sized.
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 that an output schema exists, the description adequately covers purpose, parameters, and a core constraint (provide at least one parameter). It does not detail error handling or permissions, but for a straightforward GET endpoint, it is mostly 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 0% description coverage, so the description adds crucial meaning: it explains that cdek_number is a tracking number, order_uuid is an order UUID, and client is a filter that defaults to both sender and recipient. This goes beyond the raw 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 clearly states the tool's purpose: retrieving passport data for customs readiness of international orders. It specifies the HTTP method and endpoint (GET /v2/passport) and distinguishes itself from sibling tools, none of which focus on passport data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool: for passport information related to transferring orders to customs for international orders. It does not explicitly mention when not to use it or compare to alternatives, but the context is clear enough.
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 burden. It discloses the success response (empty body with 200) but omits behavior on failure (e.g., error code) and any side effects. This is minimal but acceptable for a simple check endpoint.
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 brief, starting with purpose, then behavior, then parameter list. No redundant sentences, though the parameter list could be integrated into the schema. Front-loads the core function effectively.
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 tool has an output schema (so return values are covered elsewhere) and parameters have context from the description, it is fairly complete. Could mention that this is a prerequisite for reverse orders, but not critical.
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?
Schema coverage is 0%, so the description compensates by explaining each parameter's role, including nuances for shipment and delivery points ('от склада' / 'до склада'). It adds value beyond the schema's type/defaults, though defaults could be noted.
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 checks reverse delivery availability (реверса) before creating a direct order, and refers to the specific endpoint POST /v2/reverse/availability. This verb+resource combination distinguishes it from sibling tools like cdek_create_order or cdek_calculate_tariff.
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 implies use before creating a direct order when reverse delivery is needed ('до создания прямого заказа'). However, it does not explicitly state when not to use it or mention alternatives, though no alternative reverse-check tool exists among siblings.
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 provided, so the description carries full burden. It mentions the HTTP method (GET), implying a read-only operation, but does not explicitly state non-destructiveness or side-effect absence. It does not disclose authentication needs, rate limits, or error behavior. Moderate transparency for a simple fetch 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 very concise: a single paragraph with a clear purpose, usage constraint, and parameter explanations. No redundant or wasteful sentences. Front-loaded with the main purpose and HTTP endpoint.
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 tool's low complexity (3 parameters, read-only, output schema exists), the description covers purpose, parameter semantics, and usage constraint. It does not explain return values (reasonable since output schema exists) or error handling. One could argue that explicit mention of read-only behavior would improve completeness, but overall it's adequate.
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?
Schema description coverage is 0%, so the description adds crucial meaning: explanations for order_uuid (Order UUID), cdek_number (CDEK tracking number), and date (YYYY-MM-DD format). It also adds the constraint 'Provide at least one filter,' which is not in the schema. This compensates well for the lack of 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 purpose: getting check information (чеков) via GET /v2/check. It specifies it provides info by order or day, and requires at least one filter. The name 'cdek_checks' and the description distinguish it from sibling tools focused on orders, tracking, deliveries, etc. No tautology or ambiguity.
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 states to provide at least one filter (order_uuid, cdek_number, or date), which is a key usage constraint. It implies when to use this tool (to retrieve check info) but does not explicitly contrast with siblings. However, given the distinct purpose and naming, the context is clear enough for an agent to select correctly.
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 provided, so description carries full burden. Discloses that it creates a client-return only for delivered orders, but lacks details on side effects (e.g., order status changes), authentication, or success/error outcomes.
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?
Concise, front-loaded with purpose and endpoint, then conditions and args. No unnecessary words.
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?
Covers purpose, conditions, and parameters. Output schema exists (context signal), so return info is not needed. But missing behavioral details like error cases or permissions, which could improve completeness.
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?
Schema has 0% description coverage; description adds meaning for both parameters: uuid is Order UUID, tariff_code is Tariff code for return delivery with an example. This compensates for schema gaps.
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?
Description clearly states it registers a client return, specifies endpoint, and distinguishes from ordinary returns. It is specific to client returns for internet shops and only for delivered orders, differentiating it from siblings like cdek_order_refusal.
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?
Specifies when to use: for internet shops, only for orders in 'Delivered' status. Contrasts with ordinary return, but does not explicitly mention when not to use or name 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 burden. It states the tool returns a list of active delivery points, but does not disclose whether it's read-only, rate limits, or authentication needs. The recommendation for daily updates suggests infrequent changes, but more explicit behavioral context would be helpful.
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 concise and well-structured: a header line, a line about the return value, a usage recommendation, and the arguments with examples. No wasted words, clear and easy to parse.
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 tool has an output schema (not shown), the description doesn't need to detail return values. It covers the essential: what it does, required parameter, optional filter. It lacks information on error handling or edge cases, but for a simple list retrieval, it is fairly 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?
Schema description coverage is 0%, but the description adds examples and explanations for both parameters (city and search). It provides concrete examples like 'Москва' and 'Тверская', adding meaning beyond the schema titles. This compensates well for the lack of 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 'Получение списка офисов СДЭК' (Getting list of CDEK offices) and specifies the API endpoint. It distinguishes from sibling tools like cdek_cities by focusing on delivery points, and mentions return of active pickup points and postomats.
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 includes a recommendation to update the list once a day, providing a usage hint. However, it does not explicitly mention when to use this tool vs alternatives like cdek_cities or cdek_suggest_cities, though the purpose is clear enough.
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?
No annotations provided, but the description indicates a GET request (read-only) and returns detailed region info. It does not mention any side effects, rate limits, or auth needs, but for a read-only tool this is sufficient.
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?
Three concise sentences with a clear structure: endpoint, what it returns, and parameter explanations. No waste.
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 tool has an output schema, return values need not be explained. Parameters are fully covered. Minor omission: no mention of pagination or error handling, but acceptable for a simple list tool.
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?
Schema coverage is 0%, but the description adds meaning: country_codes are ISO_3166-1_alpha-2 format, size has default 5. This compensates well for the missing 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 it retrieves a list of regions with filter by country, using GET /v2/location/regions. It is distinct from sibling tools like cdek_cities or cdek_delivery_points.
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 explains filtering by country codes and a size limit, but does not explicitly say when to use this tool versus alternatives or provide exclusions. Usage is implied by the context of location data.
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 burden. It discloses the HTTP method (POST), prerequisites, and that it returns a list with links. However, it does not clarify if the operation has side effects (e.g., whether it is read-only despite being a POST) or mention limitations like pagination.
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?
Description is succinct: three short sentences covering purpose, prerequisites, and filter requirement, followed by a structured parameter list. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the essential aspects: purpose, prerequisites, filter requirement, and parameter formats. Lacks differentiation from sibling tool cdek_download_photos and does not mention error handling for missing filters, but is adequate given the tool's simplicity and the presence of an output schema.
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?
Schema coverage is 0% (only names and defaults). The description adds critical meaning: date format YYYY-MM-DD for period_begin/period_end, comma-separated format for cdek_numbers, and the requirement to use at least one filter. This compensates well for the schema's lack of detail.
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 orders with ready photos and returns links to archives. It distinguishes from siblings like cdek_download_photos by focusing on retrieval of order lists with links rather than downloading files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly requires at least one filter (date range or CDEK numbers) and lists prerequisites (photo service and project). Does not explicitly compare to siblings or state when not to use, but provides clear usage context.
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, the description carries the full burden. It discloses read behavior and the return format, but does not mention error conditions (e.g., missing file) or explicitly state it's read-only.
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 purpose, no extraneous text. Every word is functional.
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 no parameters and no annotations, the description covers purpose, source, and return format. It could mention error handling or confirm read-only nature, but it is largely 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?
No parameters exist, so the description does not need to add parameter details. Baseline for 0 parameters is 4.
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 all goods from a local catalog file, specifying the source path and the output structure (JSON array with fields). This distinguishes it from siblings like goods_add and goods_remove which perform mutations.
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 reading the catalog but does not explicitly contrast with sibling tools (e.g., goods_add for adding items). No guidance on when not to use or alternatives is provided.
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 mentions the HTTP method and parameter constraints but does not disclose side effects, idempotency, or error behavior. It is adequate but could be improved.
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 well-structured with a brief first line, usage guidelines, and a clear Args section. It is slightly verbose in repeating constraints but remains efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters with only 1 required, the description covers all essential details: purpose, usage guidelines, and parameter semantics. An output schema exists, so return value documentation is not required. The description is complete for an AI agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all 7 parameters: format for intake_date, the relationship between cdek_number and order_uuid, default values and time constraints for intake_time_from/to, and the purpose of comment and name. This adds significant meaning 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 clearly states the tool's action: registration of a courier pickup request via POST /v2/intakes. It distinguishes from sibling tools like cdek_get_intake, cdek_update_intake, and cdek_delete_intake by focusing on creation.
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?
It provides explicit usage constraints: recommended minimum 3-hour time range, and that at least one of cdek_number or order_uuid must be provided. It does not explicitly state when to use alternatives, but the context is clear.
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?
No annotations provided, so description carries full burden. It discloses file source (~/.config/mcp-server-cdek/config.json) and explicitly states it does not show API credentials, which is important safety info.
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, no filler. Front-loaded with the main purpose, followed by key details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, has output schema), the description fully covers what it does, where it reads from, and what it excludes. No gaps remain.
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?
Input schema is empty (0 parameters), so schema coverage is 100%. Description adds no parameter info beyond schema, which is adequate for a parameterless tool.
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 shows current CDEK server configuration, listing specific sections (sender, PVZ, product defaults). It distinguishes from siblings like config_set, which is the write counterpart.
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 makes usage clear: to view current config. While it lacks explicit when-not guidance, the context of sibling tools (e.g., config_set for updates) implies the divide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses file path, auto-conversion of numbers for product_defaults, and that key is ignored for my_pvz section. Provides sufficient 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?
Concise overall statement followed by a clear, structured list for arguments. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All three required parameters are explained with constraints. Output schema exists, so return values need not be covered. Description is complete for correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description adds extensive meaning: valid keys per section, auto-conversion, and behavior for my_pvz section. Fully compensates for lack of 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?
Explicitly states the tool updates a configuration value in a specific file. Clearly distinguishes from sibling config_show by describing the write operation.
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?
States the purpose clearly and lists valid sections and keys, implying when to use. Does not explicitly mention alternatives or when not to use, but the sibling config_show is the only other config tool.
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:

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

Score Badge

Copy to your README.md:

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

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/dontsovcmc/mcp-server-cdek'

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