Avito MCP

by elchin92

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation2/5
Many tools have overlapping purposes due to multiple versions (v1, v2, v3), deprecated methods, and sandbox vs production variants. Agents must carefully read descriptions to distinguish between similar tools, increasing the risk of misselection.
Naming Consistency4/5
Most tool names follow a consistent domain_verb_noun pattern with version suffixes, but there are occasional irregularities like 'delivery_v1_cancel_announcement' vs 'delivery_cancel_announcement_3pl' and some tools are missing version numbers.
Tool Count2/5
With 144 tools, the surface is excessively large and includes many deprecated or redundant methods, indicating poor scoping and version management. Most servers should have far fewer tools.
Completeness3/5
The tool set covers a wide range of Avito features, but the presence of many deprecated and sandbox-only tools suggests incomplete production coverage; key areas like order management have some gaps (e.g., no direct order cancellation tool).
Average 4.4/5 across 144 of 144 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 108 commits in the last 12 weeks
- Last stable release on August 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds context: 'The address classifier is Russian Post postal codes (1 postal code = all addresses belonging to it).' However, it does not clarify whether the upload replaces or appends existing areas, or mention sandbox-specific behavior beyond the tag.
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 three sentences, each serving a clear function: purpose, classifier detail, and audience. No redundant information. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high schema coverage, the description lacks key contextual details for a mutation tool. It does not explain whether the upload replaces or appends areas, what validation occurs, or sandbox environment implications. The tool's complexity (nested objects) is not addressed 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 100% with detailed descriptions for all parameters. The main description adds minimal extra meaning: it explains that areas are an array and that zipCodes are Russian postal codes. This is useful but not significant 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: 'Uploads the areas where courier delivery/pickup is available for the specified tariff.' It specifies the classifier (Russian Post postal codes) and audience (delivery-service partners only). This distinguishes it from siblings like delivery_add_terminals_sandbox or delivery_add_sorting_center.
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 mentions it is for delivery-service partners only, but does not state prerequisites (e.g., tariff must exist) or when not to use it. No mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims idempotency ('Idempotent: calling it again on an already-read chat is safe'), but annotations set 'idempotentHint' to false, creating a direct contradiction. As per instructions, this warrants a score of 1.
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 three sentences that efficiently convey purpose, side effects, idempotency, and prerequisites. Every sentence adds value, and the information is front-loaded, making it easy for an agent to quickly understand the tool's behavior.
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 action with no output schema and 4 parameters, the description covers the essential aspects: purpose, side effects (no notification), idempotency, and source of required parameter. It does not mention error handling or return values, but the action is straightforward and likely returns a status. With openWorldHint true, some behaviors may be unknown, but the description is reasonably 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?
Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying the prerequisite for 'chat_id' (from messenger_get_chats_v2), but the other parameters are already well-documented in the schema. Thus, no significant additional meaning is provided.
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 'marks unread messages as read', using a specific verb ('marks') and resource ('chat'). It distinguishes itself from sibling tools like 'messenger_get_chats_v2' and 'messenger_delete_message' by focusing solely on the read-marking action, leaving no ambiguity about its function.
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 clear context: it informs that the action does not notify the other party and is not visible to them, and states idempotency. It also specifies a prerequisite ('Requires chat_id from messenger_get_chats_v2'). While it does not explicitly list alternatives or when not to use it, the context is sufficient for correct invocation.
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?
Annotations indicate write operation (readOnlyHint=false) and non-idempotent. The description adds that it sends the outcome and includes an edge case (403/404 on regular accounts). However, it does not explain potential side effects or state changes beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a brief note about production behavior. It is concise, front-loaded with the main action, and contains no unnecessary 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?
Given the tool's simplicity and no output schema, the description adequately covers the purpose, result statuses, and a key behavioral note. It could briefly mention the 'options' parameter's role but is sufficient overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has a description. The tool description does not add significant new meaning beyond the schema, meeting the baseline expectation.
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 sends the outcome of a parcel change request (approved/declined) to Avito, referring to the related tool delivery_change_parcels. It distinguishes itself as the follow-up result reporting tool.
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 mentions that this is for 3PL and that on regular seller accounts it returns 403/404, but does not explicitly state when to use this tool versus alternatives or when not to use it. The reference to delivery_change_parcels helps but lacks explicit exclusions.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. Description adds minor context: 'starts the process' implying potential async behavior, and 'on success the response has a success status' (obvious). No additional behavioral traits disclosed beyond what annotations provide.
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 are concise and front-load the key information (sandbox, cancellation, success status). Minor redundancy with '[SANDBOX v1]' prefix could be integrated better, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should give more detail on return values beyond 'success status'. Also lacks guidance on error cases or side effects. Given the tool's simplicity and 5 parameters, the description is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage of parameter descriptions, including the nested options object. The description only mentions 'required options field' without adding meaning beyond the schema. Baseline 3 is appropriate as schema does the heavy lifting.
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 cancels a test announcement in the sandbox, using specific verb 'cancelling' and resource 'test announcement'. It distinguishes from sibling tool delivery_cancel_announcement_3pl by noting sandbox vs production and different contract versions.
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 states availability only in Sandbox for delivery-service partners and contrasts with the production alternative. However, it does not provide explicit when-not-to-use scenarios beyond the environment restriction.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it is read-only and returns a paginated response with items and hasNext flag. While it does not contradict annotations, it only adds moderate behavioral context beyond what annotations imply.
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 three sentences, front-loaded with the primary purpose, followed by key details and usage notes. Every sentence adds value without redundancy, achieving high efficiency.
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 3 parameters and no output schema, the description adequately describes the return structure (items array, hasNext flag) and constraints (per employee, permissions required). It covers essential aspects for an agent to use the tool, though slightly more detail on the response format would be ideal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all three parameters having descriptions. The description adds minimal extra semantics: it notes that employeeId should be taken from hierarchy_get_employees_v1 and that lastItemId is a pagination cursor. These reinforce the schema but do not significantly extend meaning.
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 returns IDs of listings assigned to a specific employee, filtered by category. It specifies the resource (listings) and action (list items by employee). However, it does not explicitly distinguish itself from sibling hierarchy tools beyond mentioning that employeeId comes from hierarchy_get_employees_v1.
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 explicit guidance on when to use: requires hierarchy permissions, employeeId must come from hierarchy_get_employees_v1, and it notes that fetching for the whole company is not available (only per employee). This sets clear usage boundaries. It does not list alternative tools for company-wide fetching, but the context is sufficient.
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?
Annotations already indicate it is a write operation (readOnlyHint=false), not destructive, and not idempotent. The description adds that it returns an empty 200 on success and mentions it is a sandbox tool, but does not elaborate on authorization, rate limits, or failure behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences), front-loads key purpose, and includes essential distinctions and constraints. It could be slightly more structured, but it efficiently conveys necessary 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 complexity (4 parameters, nested objects, 100% schema coverage, no output schema), the description provides sufficient context: sandbox environment, partner-only usage, return value, and relationship to sibling. It covers the main aspects for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning for parameters; it broadly explains the address parameter as 'actual pickup point' but the schema already provides detailed descriptions, including nested fields and 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 the verb ('sends'), the resource ('actual pickup point'), and the scope ('for parcel acceptance/return'). It distinguishes from the sibling tool delivery_set_order_properties by specifying that this tool only sets the address.
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 explicit context: it is needed for agent and customer returns, and it is for delivery-service PARTNERS only. It differentiates from the sibling tool, but does not explicitly state when not to use it aside from the partner restriction.
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?
Discloses that it creates an asynchronous task with validation, returns a taskID, and is a sandbox operation. Consistent with annotations (no contradiction).
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 concise (few sentences) and front-loaded with [SANDBOX]. Could be slightly more structured, but no unnecessary 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 complex nested schema and no output schema, the description covers the essential flow but lacks details on error responses or the taskID structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters. Description adds only that the body is an array directly, which is minimal additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it creates a task to upload sorting centers with validation, returns a taskID, and distinguishes from sibling tools like delivery_add_tags_to_sorting_center and delivery_get_task.
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 it's for delivery-service partners and mentions the follow-up step of assigning tags. Does not explicitly state when not to use, 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?
Adds value beyond annotations: 'Returns 200 on accept', limits (400MB body, 1 million directions), and partner-only restriction. No contradiction with annotations (destructiveHint, readOnlyHint, idempotentHint are consistent). Could mention side effects more explicitly.
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 front-loaded main action. Each sentence adds value: action, context, limits, audience, recommendations. Could be slightly more structured (e.g., bullet points) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers high-level purpose and limits but lacks output schema details (only 'Returns 200 on accept'). No error info or permission specifics beyond partner. For a complex 8-param tool, more completeness would help, but schema covers parameters well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description adds no parameter-specific info beyond schema; it only gives context (body size limit). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Creates or replaces a tariff' and specifies the resource (tariff for delivery service). Distinguishes from siblings by explicitly recommending v2 over v1 and pairing with related tools. Includes scope (controls direction availability, cost, terms).
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?
Provides clear context: when to use (to control delivery parameters), target audience (PARTNERS only), and a recommendation (prefer v2 over v1). Suggests complementary tools. Lacks explicit 'when not to use' but limits and audience exclusion suffice.
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?
Annotations already indicate read-only, idempotent, non-destructive. Description adds valuable behavioral context: asynchronous nature, processing time (5-20 minutes), and possible statuses (processing, success, error). No contradictions.
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, front-loaded with [SANDBOX] indicator. No unnecessary words; 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?
For a simple tool with one parameter and no output schema, the description is complete: it explains when to use, what to expect (statuses, timing), and target audience. Sufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers task_id syntax well (100% coverage). Description supplements by explaining the source of taskID (from upload operations), adding meaningful context beyond 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 returns the status of an asynchronous task by taskID from upload operations, listing statuses. However, it does not explicitly differentiate from sibling tools like delivery_tracking or delivery_get_sorting_center.
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?
It states it is for delivery-service partners and implies use after upload operations. But no explicit when-to-use or when-not-to-use guidance, nor alternatives.
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 claims idempotent behavior ('Idempotent by overwrite'), but annotations set idempotentHint=false, a direct contradiction. This undermines trust. Annotations already indicate destructiveHint=true, so the overwrite disclosure adds value, but the idempotency contradiction is a serious flaw.
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 focused sentences plus a sibling comparison. No filler, front-loaded with purpose and audience, every sentence adds value.
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, audience, usage guidelines, important behavioral nuance (overwrite), and sibling differentiation. Minor gap: no mention of output (returns empty 200) is fine since no output schema. The annotation contradiction slightly reduces completeness but overall is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The description adds no parameter-level detail beyond the schema, but the overwrite instruction contextualizes usage of the 'properties' object. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets parcel delivery parameters (e.g., final delivery cost) on Avito, specifies it is for delivery-service PARTNERS only, and distinguishes from siblings (address setting and tracking).
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 tells when to use (set cost/parameters), provides a critical usage instruction (send complete set, not delta due to overwrite), and clarifies what it is not for (address or tracking) with sibling references.
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?
Annotations already declare readOnlyHint, idempotentHint, etc. Description adds typical return values and usage order but no further behavioral details (e.g., error handling, performance).
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 sentences, front-loaded with purpose, efficient use of words, 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 no output schema, description sufficiently explains return flags and provides a usage hint. Could mention error scenarios but overall adequate for a simple read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters; the description does not need to add parameter meaning. Baseline score of 3 applies, though description does explain return values which aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks user status in hierarchy and lists specific returned flags. It distinguishes itself from 'hierarchy_link_items_v1' by recommending to call this first.
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?
Provides explicit usage context: call before 'hierarchy_link_items_v1' to ensure proper role. Does not mention other alternatives, but guidance is clear and actionable.
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?
Annotations already provide destructiveHint and idempotentHint; the description adds that the confirmation_id becomes invalid after cancellation. No contradiction, and the description adds useful context beyond annotations.
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 wasted words, essential information front-loaded.
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 low complexity, no output schema, and annotations covering safety, the description sufficiently explains the tool's effect. Could mention success/error responses, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add any extra meaning or examples for the single parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool cancels a deferred action and that the confirmation_id becomes invalid, distinguishing it from siblings like meta_confirm_action and meta_list_pending_actions.
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 previously deferred actions but does not explicitly state when to use it versus alternatives like confirming or listing pending actions.
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?
Annotations already declare destructiveHint=true, so the description adds error code context (1001, 1002) but no additional behavioral traits beyond what annotations provide. The description does not contradict annotations.
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 sentences, front-loaded with purpose, no redundant information. Each sentence adds value: purpose, effect, response/alternatives.
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 high schema coverage and annotations, the description provides necessary context: cancellation scope, reverting effect, error codes, and related tools. Without an output schema, the response hint is helpful. Minor gap: no mention of idempotency behavior details, but that's covered in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions the three parameters implicitly (dryRun, itemIDs, idempotencyKey) but adds little meaning beyond the schema's own descriptions. The reference to siblings is not about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (cancels) and resource (active and scheduled transactional promo for listings), and distinguishes from siblings by referencing trxpromo_apply and trxpromo_get_commissions.
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: to cancel active/scheduled promo, and provides alternatives: apply with trxpromo_apply, check with trxpromo_get_commissions. It does not explicitly state when not to use, 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?
Annotations already communicate destructiveHint=true and readOnlyHint=false. The description adds specifics: it overwrites existing settings and creates if none exists, clarifying the upsert behavior. This is beyond what annotations provide.
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 and a deprecation note. All sentences add value, with the primary action 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?
Despite lacking an output schema, the description does not mention return values or success/error behavior. For a destructive tool with 7 params, this is a gap. The idempotencyKey behavior is in schema but not in description. It's adequate for simple use but not 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?
Schema description coverage is 100%, so the tool description does not need to add parameter details. The description mentions 'single URL feed' and references upload_url, but does not add significant meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates or updates (upsert) a v1 autoload profile with a single URL feed. It distinguishes from the v2 sibling via deprecation notice and recommendation to use v2 for multiple feeds.
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 deprecation note explicitly tells users to prefer autoload_create_or_update_profile_v2 for multiple feeds, implying this tool is for legacy single-feed use. It does not list all alternatives but provides clear guidance on when to use the v2 tool.
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?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description reinforces this with 'Read-only, spends no money' and adds a rate limit of 40 requests/min, providing useful operational context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long and front-loaded with the core purpose. It is efficient, though the last sentence about limit could be integrated. Overall, it avoids unnecessary detail and is well-structured 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?
Given the absence of an output schema, the description mentions that returned actionId values are suitable for specific follow-up tools, providing critical context. However, it does not describe the full structure of a chat object, which might be needed for complete understanding. Overall, it's sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. The description adds minor context like 'starting from the given moment (by the date field)' and 'paginated list', but does not provide significant new parameter-specific guidance beyond what the schema already offers.
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 paginated list of target CPA chats by date, distinguishes itself from the deprecated v1 version, and specifies it is the current version (v2). The verb 'Returns' and resource 'paginated list of target CPA chats' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is read-only and spends no money, guiding appropriate use. It also recommends this over the deprecated v1 and explains that returned actionId values are suitable for follow-up tools (cpa_chat_by_action_id or filing a complaint). However, it does not mention alternatives or scenarios where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, idempotent, non-destructive. Description adds pagination behavior and rate limit, plus confirms 'Read-only, spends no money'. No contradictions.
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, each serving a purpose: functionality and safety/use case/rate limit. No fluff.
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?
Missing output schema; description does not specify return fields (e.g., phone number, chat ID). Pagination and start time are covered, but the exact data shape is unclear. Adequate but not fully complete for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter descriptions. Description only references 'starting from the given moment' and 'paginated set', adding no new semantic value 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 it returns paginated info on phone numbers from CPA chats, with specific verb and resource. It distinguishes from siblings like cpa_get_call or cpa_chats_by_time_v2.
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?
Provides explicit use case: 'Use to export customer contacts from correspondence over a period.' Mentions rate limit (5 req/min). No when-not-to-use or alternatives, but the context is clear for a specialist tool.
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?
Annotations already indicate destructive and non-idempotent behavior. The description adds valuable context: 'Replaces the tariff's terminal set' (destructive), the auto-approval vs. manual review process, and partner-only restriction. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. The description is front-loaded with the primary action, includes the [SANDBOX] tag, and provides essential behavioral details efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While input schema coverage is 100% and annotations are present, the description lacks information about the response format or error cases. For a tool that replaces a terminal set, an agent would benefit from knowing what the 200 response contains or what triggers manual review.
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 100%, but the description adds the crucial hint that the request body is the terminals array directly (the tool wraps it). This clarifies that the main payload is the terminals parameter, adding 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 replaces the tariff's terminal set by uploading terminals (pickup points/parcel lockers). The verb 'replaces' and resource 'terminals for a tariff' are specific, and it distinguishes from sibling tools like delivery_add_areas_sandbox which deal with areas, not terminals.
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 specifies it is for 'delivery-service PARTNERS only' and explains auto-approval vs. manual review. However, it does not explicitly state when not to use this tool or suggest alternatives among the many delivery siblings, leaving usage guidance incomplete.
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?
Annotations already signal destructiveness; description adds emphasis on irreversibility and reveals authorization behavior (403/404 for regular sellers). No contradiction with annotations, but could detail more 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?
Three sentences are front-loaded with purpose, then key traits (irreversibility, prerequisite creator, authorization). No redundant 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?
No output schema is provided, and description does not explain return values or error states beyond the 403/404. It also lacks guidance on optional parameters (e.g., dryRun, idempotencyKey) and prerequisites beyond existence of announcement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already described in detail. Description adds no additional parameter-level information, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (cancel) and resource (announcement), explicitly ties to 3PL-specific creation tool, and distinguishes from siblings by noting its exclusive use for 3PL accounts and the 403/404 response for regular sellers.
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?
Description indicates usage context (cancelling a previously created announcement) and implicitly restricts to 3PL accounts via error mention, but does not explicitly compare with sibling cancel tools or state when NOT to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructive and non-idempotent behavior. The description adds that cancellation is on behalf of the receiver, returns a success status, and is limited to test parcels. It provides context beyond annotations but does not detail potential error cases or side effects like rollback.
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 key information (sandbox, actor, success status, constraints). It efficiently differentiates from a sibling tool. Minor improvement could be breaking into shorter sentences or bullet points.
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 sandbox context, 4 parameters, and no output schema, the description adequately covers the purpose, constraints, and comparison. It leaves out details about dryRun and idempotencyKey (handled by schema) and error scenarios, but for a sandbox cancel tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description repeats that actor must be 'receiver' but does not add significant new meaning beyond the schema's const declaration.
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 cancels a test parcel on behalf of the receiver, with a specific verb and resource. It distinguishes itself from the sibling tool delivery_v1_cancel_parcel by mentioning the actor field and base contract.
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 that only parcels created via delivery_create_sandbox_parcel_v2 can be cancelled, and that it's for delivery-service partners only. It also contrasts with delivery_v1_cancel_parcel, providing clear context for when to use this tool. However, it does not explicitly state when not to use it for non-sandbox scenarios.
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?
Discloses important behavioral traits: does not modify existing history, not idempotent (re-sending logs duplicate), returns empty 200, and notes the event progression order. Annotations confirm destructiveHint=false and idempotentHint=false, and the description adds context beyond these.
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 detailed but each sentence adds value. It is front-loaded with the main purpose and well-structured. Could be slightly trimmed, but efficient overall.
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 output schema, the description covers return value (empty 200). It explains sandbox nature, event progression, non-idempotence, and partner restriction. Fairly complete for a sandbox tracking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minor context by listing the event progression order and mentioning dryRun and idempotencyKey features, but does not significantly enhance parameter understanding 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 verb 'appends' and the resource 'tracking event for an announcement', with the context 'sandbox'. It distinguishes itself from the sibling tool 'delivery_tracking' which reports parcel-level status events.
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 describes when to use: to simulate announcement progression (ACCEPTANCE_DONE → RECEIVED → DELIVERED, or CANCELLED). Also notes it is for delivery-service PARTNERS only and distinguishes from the parcel-level analogue. Lacks explicit 'when not to use' but provides sufficient context.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, covering safety and behavior. Description adds that it returns the 'last registered event', but does not expand beyond what annotations imply. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with a brief note, no wasted words, and key information front-loaded.
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?
For a simple tool with one parameter, clear annotations, and no output schema, the description covers purpose, scope, and audience completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described as 'Test announcement identifier'. Description does not add further meaning. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Returns' and the resource 'last registered event for a test announcement', with a specific use case (debugging integration) and scope (Sandbox only), distinguishing it from siblings.
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 states availability only in Sandbox and for delivery-service partners, indicating when to use (debugging) and who can use. No explicit exclusions or alternatives, but 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?
Beyond annotations (destructiveHint: true), the description adds important behavioral context: the user will be blocked from messaging, it affects a third party, and requires confirmation. This goes beyond the structured data.
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 two main sentences and a brief enum listing. It is front-loaded with the purpose and warning, but the all-caps may be slightly noisy.
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 (4 parameters, no output schema), the description covers the essential purpose, warnings, and parameter summary. It omits details like error handling and return values, but is adequate for a destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description summarizes the parameter structure and lists reason IDs, but this adds marginal value 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 action ('Adds one or more users to the account's BLACKLIST') and the resource (blacklist). The verb 'Adds' and resource are specific, and the tool is distinct from sibling messenger tools (e.g., sending messages, deleting messages).
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 clear context by warning about the irreversible effect and requirement for confirmation. However, it does not explicitly state when not to use this tool or name alternative tools for similar actions.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds details about returned fields and that it returns current status, reinforcing the read-only nature. No contradictions.
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 concise sentences that quickly convey purpose, scope, and usage. No filler or redundant 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?
Given the simple parameter and comprehensive annotations, the description is sufficient for an agent to understand when and how to use the tool. Could mention response format but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and provides clear description for the single parameter 'query'. The description mentions 'by their IDs from the file' and '1-100 per request', which adds context but does not significantly enhance 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 it returns the current state of listings in autoload by IDs, listing specific fields. It distinguishes from sibling tools like `autoload_get_report_by_id_v3` by noting it is not tied to a specific report.
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 says 'Use it for targeted checks of selected listings (1-100 per request)', providing clear context for when to use. Does not explicitly mention when not to use or name alternatives, but scope is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the complaint is irreversible and cannot be withdrawn, aligning with the destructiveHint: true annotation. It also mentions a rate limit of 3 requests/min and that confirmation is required by default, adding behavioral context beyond annotations without contradiction.
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, using bullet points effectively. Every sentence adds value: purpose, irreversibility, prerequisite, preference over sibling, and rate limit. 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?
Given the tool has 4 parameters, no output schema, and annotations indicating destructive action, the description covers the required context: irreversible nature, prerequisite actionId, preferred sibling, and rate limit. It does not explain return values, but that is acceptable without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description reinforces the importance of actionId from preceding calls and provides context for dryRun and idempotencyKey usage, but does not add new semantic 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 files an external complaint against a CPA target action by actionId to dispute a charge. It specifies the type of action (call or chat) and distinguishes from the sibling tool cpa_post_create_complaint by noting it covers both calls and chats, making the purpose very specific.
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 (to dispute off-target charges), the prerequisite of obtaining actionId from specific tools (cpa_chats_by_time_v2 / cpa_get_calls_by_time_v2), and indicates preference over a sibling tool. It does not explicitly state when not to use, 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?
Adds value beyond annotations: describes async task, re-binding constraint, status via delivery_get_task. Annotations already indicate non-read-only and non-destructive; description adds operational detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, no waste, front-loaded with the main purpose. Every sentence adds value.
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?
Completeness is good: mentions taskID, follow-up tool, constraints, and audience. With no output schema, it compensates by explaining the return and next steps. Could be more explicit about error handling but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description only adds 'The body is an array directly,' which is a minor structural hint. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a task to assign direction tags to sorting centers within a tariff, with specific verb and resource. It distinguishes from siblings by being specifically about tagging, while other tools like delivery_add_sorting_center are for adding centers.
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?
Provides context: task creation for tagging, re-binding not possible, and for delivery-service partners only. Does not explicitly state when not to use or list alternatives, but the sibling context makes it clear.
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?
Annotations already provide read-only, non-destructive, idempotent semantics. Description adds that it returns verification status, but no additional behavioral details like error handling or side effects beyond annotations.
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 redundant words. Front-loaded with action and return value, followed by domain clarification.
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?
No output schema, but description mentions return status. Tool is simple verification; description covers purpose, input, output, and domain restrictions adequately.
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 100% description coverage for both parameters, so baseline is 3. Description does not add extra meaning beyond what the schema already states.
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 verb (verifies), resource (confirmation code), and context (pickup point handover). It also distinguishes from the sibling in orders domain, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says it's for delivery-service partners and contrasts with the same-named endpoint in orders domain. This helps the agent choose correctly between delivery_check_confirmation_code and orders_check_confirmation_code.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. Description adds that it is sandbox-only and for partners, which is useful context beyond annotations. No contradictions.
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 concise sentences with front-loaded key information. Every word earns its place; no 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?
For a simple read tool with one parameter and no output schema, the description is complete enough. Specifies sandbox environment and intended audience. Could mention output format but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, which already has a description. The tool description adds minimal extra meaning beyond listing some codes and saying 'and others'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Returns the sorting centers (hubs) for specified delivery services' with a specific verb and resource. Distinguishes itself from sibling tools like delivery_add_sorting_center by being read-only.
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?
Indicates it is for delivery-service partners only and lists delivery service codes, providing context on when to use. However, it does not explicitly exclude alternatives or provide when-not-to-use guidance.
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?
Annotations declare destructiveHint: true, idempotentHint: false, readOnlyHint: false. The description adds that it returns a success status, is implemented on the delivery-service side, and that regular sellers receive 403/404. This adds behavioral context beyond annotations. No contradiction.
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 sentences that front-load the main action. It avoids unnecessary words and uses clear language. Every sentence provides useful 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?
The description covers the tool's purpose, usage context, and access limitations. It mentions it returns a success status but does not specify the response structure. Given the tool's simplicity and missing output schema, this is adequate for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions for dryRun, orderId, and idempotencyKey. The tool description does not add any additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Prohibits the delivery service from accepting a parcel from the sender — the parcel will not be taken into processing.' It also positions it as a step in the parcel-cancellation flow and distinguishes from siblings by specifying it's for delivery-service PARTNERS only.
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 usage context by mentioning it's a step in the parcel-cancellation flow and pairs with delivery_sandbox_cancel_parcel. It also explicitly states that regular seller accounts get 403/404, guiding who should use it. However, it does not explicitly list when not to use it or compare to other tools.
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?
Description adds beyond annotations: specifies data depth limit, rate limit, and that grouping is a string format. Annotations already cover safety (readOnlyHint=true, destructiveHint=false), so description's additional constraints are useful but not critical.
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 concise, front-loaded with main purpose, and packs relevant details efficiently. Could be better structured with bullet points but remains dense and informative.
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?
Despite high schema coverage and annotations, the tool lacks an output schema. Description does not detail the returned report structure or fields, leaving the agent without full context on what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions in schema are detailed. Description reiterates required parameters and format but adds little new meaning beyond what is in 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?
Clearly states it returns a REPORT of profile's spendings over a period by Avito spending category, with specific verb and resource. Notes difference from sibling tool items_post_item_analytics regarding grouping format, aiding differentiation.
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 when to use (read-only, no money spent), provides period format, data depth limit (270 days), rate limit (1 per minute), and required parameters. Also clarifies exclusions like employeeIDs not supported in filter.
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?
Description adds behavioral context beyond annotations: price is immediately visible to buyers (open world detail), no money spent, rate limit 150 req/min. It also notes this is a live change, confirming destructiveHint. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a parenthesis. Front-loaded with purpose, followed by key constraints. No superfluous 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 no output schema, description covers impact (public visibility), rate limit, category restrictions, and user confirmation. Missing details on dryRun preview, but overall sufficiently complete for a simple mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. Description reiterates required params (item_id, price as integer in rubles) but adds no new semantic value beyond what schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes a listing's price, using a specific verb ('Changes') and resource ('listing's price'). It distinguishes itself from sibling tools (e.g., items_get_item_info, items_apply_vas) by focusing on price modification only.
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 clear when-to-use context: requires item_id and price, specifies allowed categories (with explicit exclusion), and advises user confirmation for live changes. It does not explicitly contrast with alternatives, but no direct sibling for price update exists.
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?
Describes key behaviors beyond annotations: irreversible, starts return process, visible to buyer, and returns success flag. Annotations indicate destructive (true) and non-idempotent, which align. No contradictions.
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 sentences, front-loaded with main action. Includes warning icon and essential details. 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 5 parameters, no output schema, and nested objects, description covers purpose, precondition, effect, and response. Could mention error scenarios but is fairly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about terminalNumber being the post office, but does not elaborate on other parameters beyond schema descriptions. Minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: confirms the buyer's return and selects the Russian Post office. It distinguishes itself from other order tools by specifying it is for the acceptReturnOrder action, and mentions it is a write/public operation for courier delivery.
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?
Provides clear precondition: call when the order has an available acceptReturnOrder action. It also notes the operation is irreversible and visible to the buyer, which guides appropriate use. Does not explicitly list alternatives but context is sufficient.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context: 'Read-only, changes nothing' (consistent), and discloses B2C seller restriction and pagination flag (hasMore), adding value beyond annotations.
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 sentences, each essential: purpose+read-only, usage guidance, and restrictions+pagination. Front-loaded with core purpose. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 5 optional params and no output schema, the description covers purpose, usage as starting point, B2C restriction, and pagination flag. It could mention response structure or error handling, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with full parameter descriptions. The description only summarizes filters (ID, status, creation date) without adding new meaning. Baseline applies as description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Returns a list', specifies the resource 'delivery orders', and outlines filters. It explicitly says 'Read-only, changes nothing', distinguishing it from write-oriented sibling tools like orders_apply_transition.
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 usage context: 'Use it as a starting point' and mentions taking available actions from the response for subsequent write operations. It also states 'Available only to B2C sellers', but does not explicitly list when not to use or compare with alternatives.
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?
The description reinforces the read-only nature already indicated by annotations (readOnlyHint) by stating 'READ-ONLY: spends NO money.' It also outlines the response structure (budgets with oldPrice/price, duration with from/to/recommended) beyond what annotations provide, which is valuable since there is no output schema.
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 that cover purpose, safety, and the complete flow with field-level extraction guidance. No wasted words, and key information is front-loaded.
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 output schema, the description provides sufficient context about what the response contains (budgets and duration) and how to use it in subsequent calls. It could be improved by explicitly stating that the response also contains item IDs, but the field paths imply this. Overall, it is complete enough for a simple parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'itemIds' is well-documented in the input schema (description and constraints). The tool description does not add any additional semantic information about the parameter, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns recommended BBIP promotion bid/budget options for listings and explicitly distinguishes it as the first step of the BBIP flow, with references to sibling tools for subsequent steps.
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 clear context: it is the first step of the BBIP flow, and it tells the agent to take specific fields from the response and pass them to two named sibling tools (forecast and order). However, it does not explicitly state when not to use this tool, but the flow context is strong.
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?
Annotations already declare read-only, idempotent, non-destructive. Description reinforces with 'Read-only' and explains mapping direction, adding some 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?
Two concise sentences with no fluff. Action is front-loaded.
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?
Complete for a simple mapping tool. Annotations cover safety, schema covers parameter, description adds usage context and sibling reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes the parameter well. Description does not add extra meaning about the parameter format 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?
Clearly states it returns ad_ids from avito_ids, a mapping. Mentions reverse tool by name, distinguishing it from siblings.
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 says when to use: when you have Avito IDs and need ad_ids. Also references the reverse tool. No exclusions, but context is clear.
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?
Annotations already declare readOnlyHint=true, so the description's 'Read-only' adds no new behavioral information. No contradictions; no additional behavioral traits disclosed beyond safety profile.
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 sentences, front-loaded with key purpose and return fields, no unnecessary words, efficient and clear.
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 simple tool with one param, no output schema, and rich annotations, description covers what it does, input source, alternatives, and version differentiation completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with thorough parameter description. Description adds minor guidance on obtaining report_id via autoload_get_reports_v2, but baseline 3 applies as schema does heavy lifting.
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 returns summary statistics for an upload by report_id, lists the return fields (section_stats, listing_fees, etc.), and distinguishes from v2 and the items breakdown tool.
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 says get report_id from autoload_get_reports_v2, recommends autoload_get_report_items_by_id for line-by-line breakdown, and advises preferring v3 over v2.
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?
The description declares 'Read-only', aligning with annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true). It adds the prerequisite workflow, but no additional behavioral details beyond what annotations provide.
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 with no waste. First sentence clearly lists return information, second sentence gives usage guidance. Front-loaded with essential purpose.
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?
For a single-parameter tool with no output schema, the description adequately explains what it returns and the prerequisite. It provides enough context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for node_slug. The description adds context that the slug comes from autoload_user_docs_tree, but this is already implied in the schema description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns category fields (tags) with their types, required status, dependencies, allowed values, and references. It distinguishes itself from sibling autoload_user_docs_tree by positioning itself as a follow-up step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to first call autoload_user_docs_tree to get the slug, then use this tool. It also states the use case: preparing XML/Excel files. It lacks explicit 'when not to use' but 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?
Annotations are basic (readOnlyHint false, etc.). The description adds valuable context: it is a real parcel creation, and regular accounts get 403/404. This goes beyond annotations without contradicting them.
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 two sentences that front-load the key purpose and then provide usage context. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has complex nested parameters, but schema descriptions are thorough. The description does not explain return values (no output schema) or provide behavioral details beyond basic permissions. Adequate 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?
Schema coverage is 100%, so baseline is 3. The description lists required parameters by name but adds little beyond the schema, only noting version stamps on dryRun and idempotencyKey.
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 creates a parcel in production, with a specific verb and resource. It distinguishes itself from the sandbox sibling (delivery_create_sandbox_parcel_v2) by noting it is 'production, the creation of a real parcel.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates this is for production use, not for regular seller accounts (which get 403/404), implying 3PL accounts. It lists required parameters and contrasts with the sandbox version, providing clear when-to-use guidance.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds sandbox-only scope and test-parcel context, providing useful behavioral clues without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant information. Every word serves a purpose.
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?
For a simple read with one parameter and no output schema, the description fully explains the tool's purpose, constraints, and prerequisite. 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?
With 100% schema description coverage, the description adds no extra meaning beyond the schema's definition of 'applicationID' as 'Identifier of the parcel change request.' Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Returns information about a test-parcel change request by its applicationID', specifying the verb ('returns') and the resource ('test-parcel change request'). It distinguishes from siblings like delivery_v1_get_parcel_info (for regular parcels) and references the creation tool delivery_v1_change_parcel.
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 clarifies it's sandbox-only and for delivery-service partners, and mentions the prerequisite (request created via delivery_v1_change_parcel). While it doesn't explicitly state when not to use alternatives, the context implies exclusive use for change requests.
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?
Annotations already declare readOnlyHint and destructiveHint. The description adds important constraints (sandbox-only, dependency on a specific creation tool) that enhance transparency beyond annotations.
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 three concise sentences with no unnecessary words. It front-loads the sandbox context and directly states functionality.
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?
For a simple lookup tool with one parameter, the description covers purpose, constraints, and return value (parcelID). No output schema exists, but the description compensates adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already adequately describes the orderID parameter. The description reiterates 'by its orderID' but adds no new semantic value 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 verb 'Returns', the resource 'parcelID', and the input 'orderID'. It also distinguishes this tool from siblings by specifying it works only with sandbox parcels created via a specific tool.
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 limits usage to sandbox parcels and those created via delivery_create_sandbox_parcel_v2, providing clear context. However, it does not name alternative tools for production use.
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?
Annotations already indicate destructive, but description adds critical context: charges money irreversibly, response includes charged amount, and errors may not mean failure. No annotation contradictions.
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 compact yet informative, with warnings and contrasts front-loaded. Every sentence adds value, though minor restructuring could improve readability.
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 output schema, the description covers purpose, differentiation, prerequisites, error handling, and deprecation. Missing details on success effects beyond charged amount, but sufficient for a well-informed call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, so description adds only the context that package_id comes from items_post_vas_prices. This is useful but not essential; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a VAS package to a listing, explicitly contrasting it with sibling tools items_put_item_vas (single service) and items_apply_vas (arbitrary set). It also notes deprecation and the recommended replacement.
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?
Provides explicit when-to-use guidance (pre-assembled package), distinguishes from alternatives, gives prerequisite (check price via items_post_vas_prices, confirm with user), and warns about error handling (verify purchase if error).
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds 'Read-only' and lists return fields, which reinforces annotations but offers no new behavioral traits beyond what annotations provide. No contradictions.
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: first states purpose and return data, second gives usage guidance. No extraneous text, front-loaded, 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?
Despite no output schema, description adequately describes what is returned (participants, linked item, context, last message) and what is not (messages delegated to other tool). Sufficient for this simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter comments. chat_id description mentions source (messenger_get_chats_v2) and user_id mentions default. The tool description does not add new semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it 'Returns the details of a SINGLE chat by a known chat_id' and lists returned data (participants, linked item, context, last message). Differentiates from siblings messenger_get_chats_v2 and messenger_get_messages_v3.
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 says 'Use it when the chat_id is already known; to find a chat_id or get a list of conversations, use messenger_get_chats_v2' and notes that messages come from messenger_get_messages_v3. Provides clear when-to-use and when-not with named alternatives.
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?
Annotations already declare readOnly and idempotent; description adds value by detailing what configuration fields are returned (mode, allow/deny lists, etc.), complementing annotations.
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 core functionality, no wasted words.
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?
For a zero-parameter tool with annotations and output schema, description fully conveys purpose and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema description coverage is 100%, baseline applies. Description adds no parameter info, but none is needed.
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?
Clearly states it returns a machine-readable description of current configuration and lists specific items, distinguishing it from sibling meta tools like health or rate limits.
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 suggests using it to understand available operations before calling tools, but does not explicitly contrast with other meta tools.
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?
Beyond destructiveHint annotation, it adds specific warnings: status visible to buyer, affects deal, irreversible. Adds response info (success flag). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, efficient. Starts with action, then warning, then guidance. No fluff. Slightly more verbose than minimal but well-structured.
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?
No output schema, but description mentions success flag. Given 5 params (one nested) and annotations, covers key aspects like irreversible effect and dependency on current status. Could add error info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minimal extra param meaning (e.g., transition depends on status), but schema already describes each parameter well.
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 applies order status transitions (confirm, cancel, etc.) and distinguishes from sibling tools like orders_get_orders by referencing availableActions. It uses specific verbs and resource.
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 tells users to check availableActions from orders_get_orders to see allowed transitions, providing context on when to use. It lacks explicit when-not-to-use or alternatives but provides clear guidance.
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?
Annotations already indicate destructiveHint=true. The description adds that it is a write operation and the tracking number becomes visible to the buyer, plus error scenarios. It does not contradict annotations and provides useful behavioral context beyond safety hints.
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 at three sentences, front-loading the purpose and key constraints. It includes a warning emoji but no 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 lack of output schema, the description adequately explains the response (success flag, error codes) and usage conditions. It covers when to call and potential errors, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter descriptions. The tool description does not add significant new meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits a parcel tracking number for delivery, specifying it's a write/public operation visible to the buyer. It distinguishes from sibling tools by mentioning DBS and the setTrackNumber action, providing a specific verb and resource.
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 when to call: when the order has an available setTrackNumber action or fixTrackNumber to correct it. Also provides error codes (incorrect_number, already_set) for handling failures, giving clear context for use.
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?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. Description adds that it spends no money and requires no parameters, which is consistent and slightly extends the safety profile. No contradictions.
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 sentences, front-loaded with purpose, followed by behavioral note and usage guidance. No unnecessary words, efficient and clear.
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 no output schema, description adequately describes the return structure (dictionary with slug, name, isDeprecated). Tool is simple and self-contained; no additional context needed. Annotations cover safety.
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 schema covers 100%. Description does not need to add parameter details; it confirms no parameters are needed. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns a dictionary of promotion service types with fields slug, name, isDeprecated. It distinguishes itself from other promotion methods by indicating its use as a reference for resolving slugs.
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 states usage context: 'Use it as a reference to resolve slugs in the responses of other promotion methods.' Also notes it's read-only and requires no parameters. Does not explicitly exclude any scenarios but guidance is sufficient.
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?
Annotations already provide readOnlyHint, etc. Description adds value by emphasizing 'spends NO money' and clarifying the return structure (service details and dates). No contradictions.
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: first explains output, second reinforces read-only and differentiates from suggests. No wasted words, front-loaded with purpose, excellent structure.
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?
For a simple tool with no output schema, the description sufficiently explains return format (slug, name, dates). Input schema is well-documented, annotations are present, and the description covers behavioral and usage context completely.
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 covers itemIds with description, achieving 100% coverage. The tool description does not add extra semantic beyond what schema provides, thus baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 active promotion services for specified listings, including slug, name, and dates. It distinguishes itself from sibling 'suggests' tool, making purpose very specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use case ('find out which promotion is already enabled') and warns not to confuse with 'suggests'. However, it does not differentiate from other sibling tools like promotion_get_bbip_forecasts_by_items_v1, leaving some gaps.
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?
The description discloses the upsert behavior (overwrites or creates) and that it is destructive (annotation destructiveHint=true). It adds context about overwriting existing settings. Could mention behavior for unspecified fields, but sufficient given annotations.
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 sentences pack essential information: core function, upsert and v2 advantage, and separation from uploads. No redundancy, front-loaded.
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?
Description covers key behavioral aspects for a complex tool with 7 params. Missing explicit mention of agreement parameter behavior, but schema provides that. Overall 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 coverage is 100% with detailed parameter descriptions. The tool description adds value by highlighting dryRun's purpose and the multiple feeds advantage over v1, beyond 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 creates or updates an autoload profile (upsert), specifies it is v2 (current), and distinguishes it from v1 by supporting multiple feeds. It also separates profile management from uploads, differentiating from autoload_upload.
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 advises preferring this method over v1 due to multiple feed support and notes that uploads are handled separately via autoload_upload. It lacks explicit exclusion scenarios but provides clear context on when to use the tool.
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?
Annotations already indicate read-only and idempotent. Description adds context about deprecated feed_url and replacement, and lists output fields, going beyond annotations.
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 concise sentences plus deprecation note. Front-loaded with purpose and output fields. 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?
Covers purpose, output fields, deprecation, and prerequisite. Lacks mention of error handling but is adequate for a simple read tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for report_id. Tool description reiterates schema info but adds no new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns summary statistics of a specific upload by report_id, listing specific fields. It distinguishes from the sibling v3 by noting deprecation and recommending v3.
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 says to obtain report_id from autoload_get_reports_v2 and to prefer v3 due to deprecation, providing clear when-to-use and when-not-to-use guidance.
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?
The description adds valuable behavioral context beyond annotations: it warns about financial impact ('affects auction spending (money)'), clarifies the meaning of pricePenny and expirationTime, and notes the limits. No contradiction with annotations (destructiveHint=true). Annotations already mark as destructive and non-idempotent; description reinforces and elaborates.
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: three sentences covering purpose, warning, parameter details, limits, and cross-reference. No unnecessary words. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, financial implications, parameter semantics, limits, and where to find current bids. Missing only what the tool returns (no output schema), but this is partially compensated by the clear mutation nature and the sibling reference.
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 100%, so baseline is 3. The description adds meaning beyond the schema: it explains pricePenny is 'in kopecks per action' and expirationTime 'omitted or null — indefinite', and states the array limit and request rate limit. This provides practical usage guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the strong verb 'saves (overwrites)' and clearly specifies the resource (CPA auction bids for listings). It distinguishes from the sibling tool cpa_auction_get_user_bids, which is for viewing bids.
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 clear context: it overwrites bids, affects spending, and includes limits (200 listings, 200 req/min). It also directs users to the sibling tool for current bids. However, it does not explicitly state when not to use this tool (e.g., for read-only purposes).
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?
Annotations already declare readOnly and idempotent hints. Description adds value by stating 'Read-only, spends no money', empty body requirement, and rate limit, providing context beyond annotations.
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, each informative. Front-loaded with purpose, 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?
For a simple read-only balance tool, description covers purpose, version preference, and rate limit. Lacks explicit response format but acceptable given no 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?
No parameters in schema; description confirms empty request body, which is sufficient. Baseline 4 applies as no parameter details are needed.
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 specifies the tool returns the current CPA wallet balance in kopecks, distinguishes v3 from v2, and mentions it is the preferred version.
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?
Provides rate limit (1 req/min) and notes empty request body. Implicitly guides to use v3 over v2, but does not explicitly list when to use alternatives among sibling tools.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds useful context like 'Read-only, spends no money' and mentions pagination, which complements the annotations without contradiction.
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 that first state purpose and deprecation, then add safety and comparison. Every sentence serves a purpose, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (list endpoint with three parameters), no output schema, and comprehensive annotations, the description covers the essential aspects. It could mention the return format (e.g., array of chat objects) but this is not critical for functionality.
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 100% and the description adds meaning for the key parameter dateTimeFrom by stating 'created starting from the given moment'. It also implies the role of limit and offset via 'paginated list', adding value 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 explicitly states the verb 'Returns', the resource 'target CPA chats', and the scope 'created starting from the given moment'. It also distinguishes from the sibling cpa_chats_by_time_v2 by noting deprecation and identical semantics with a higher request limit.
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 clearly indicates the tool is deprecated and recommends v2 with reasoning (higher request limit). It also notes read-only nature and no monetary cost. While it does not explicitly list when-not conditions, the deprecation statement provides strong guidance.
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?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false. Description adds 'spends no money' and 'including a link to the recording', providing useful output detail beyond annotations.
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 wasted words. First sentence delivers core purpose and key output feature; second sentence gives usage context and replacement info. Ideally concise.
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?
Despite no output schema, description explains return value (full CPA call model with recording link) sufficiently for a simple one-param tool. Completeness is 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 covers parameter fully. Description adds value by linking callId to cpa_get_calls_by_time_v2 and specifying it's an int64, exceeding the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (returns), resource (CPA call model), and distinguishing features (full model, recording link, v2). Explicitly contrasts with deprecated v1 and context from cpa_get_calls_by_time_v2, differentiating it from siblings.
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?
Provides explicit usage context: use when callId is known (from cpa_get_calls_by_time_v2) and notes it replaces deprecated v1. Lacks explicit when-not-to-use but 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds 'Read-only, spends no money' and mentions the rate limit, which are useful behavioral details beyond the annotations. It does not contradict annotations.
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 long, with the first sentence stating the core purpose and the second providing usage guidance. Every word earns its place; no 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 there is no output schema, the description mentions it returns a paginated list and that the results contain callId/actionId. It also includes the rate limit. While it doesn't detail pagination mechanics (like using offset vs max startTime), the parameter descriptions in the schema cover that. Overall, it is sufficiently complete for a list tool with well-covered annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for all 3 parameters (dateTimeFrom, limit, offset). The description mentions 'by startTime' which reinforces the dateTimeFrom parameter, but adds no new details beyond the schema. Baseline score of 3 is appropriate as the description does not need to compensate.
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 returns a paginated list of CPA calls filtered by startTime. The verb 'Returns' and resource 'CPA calls' are specified, and it distinguishes from sibling 'cpa_get_call_by_id_v2' by mentioning that the returned IDs can be used with it.
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 when to use: 'Use to iterate over calls for a period'. It also gives a concrete workflow: the returned callId/actionId can be used with cpa_get_call_by_id_v2 or for filing a complaint. Additionally, it provides a rate limit warning (1 req/min), which helps the agent plan usage.
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?
Annotations already indicate non-read-only, non-destructive, open-world, non-idempotent. The description adds that the tool is for 3PL accounts and returns 403/404 otherwise, which is important behavioral context. It also clarifies this is an announcement, not a parcel, distinguishing 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 concise (two sentences) with the most critical information front-loaded: purpose, applicability, and distinction from sibling. No extraneous text.
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 9 parameters with nested objects and no output schema, the description provides sufficient context about the tool's purpose, authorization constraints, and relationship to sibling tools. It lacks return value details but that is not required without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description does not add additional meaning beyond what the schema provides. For example, it mentions barcode and packages but the schema already describes them. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates an announcement of a planned shipment between delivery services, specifies it is for 3PL accounts, and distinguishes it from delivery_create_parcel by noting this is a shipment announcement, not parcel creation. The verb 'creates' and resource 'announcement' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('notify the receiving party about an upcoming parcel handover') and what not to use (unlike delivery_create_parcel for parcel creation). It also notes the tool is for delivery-service side and returns 403/404 on regular seller accounts, providing 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?
The description discloses the destructive behavior (overwrites previous schedules) and the sandbox environment, adding value beyond annotations. It does not contradict the annotations (destructiveHint=true). It could mention authentication or rate limits, but overall transparency is good.
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 focused sentences: purpose, overwrite behavior and scope, and body format. No unnecessary words, and the key information is front-loaded.
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 output schema, the description covers purpose, behavior, scope, and input format. It does not describe return values or error handling, but for a sandbox tool with clear annotations, 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?
With 100% schema description coverage, the schema already documents parameters. The description adds clarity by noting that the body is 'an array of schedules directly (no wrapper),' which helps the agent understand the input format beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a custom working schedule for a delivery zone on specific days (e.g., holidays). It distinguishes the custom schedule from the regular schedule and specifies it's for delivery-service partners, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by noting the tool is for delivery-service partners and mentions that re-uploading overwrites previous schedules. However, it does not explicitly state when to use this tool versus alternatives like delivery_add_areas_sandbox or delivery_add_tariff_sandbox, so guidance is clear but lacks exclusions.
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?
Annotations already indicate the tool is not read-only, not idempotent, and not destructive. The description adds behavioral context: 'after creation the announcement is routed to the delivery service specified in receiver' and 'no consequences' for sandbox. It does not cover rate limits or auth needs, but overall 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?
The description is extremely concise: two sentences plus a tag. Every sentence adds value—purpose, audience, and differentiation. 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?
Given the complexity (9 parameters, nested objects) and lack of output schema, the description provides essential context (sandbox, routing, no consequences). It could mention what is returned, but schema descriptions cover parameters well. Reasonably complete for a sandbox tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in the schema. The description does not add any additional meaning beyond what is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'creates' and the resource 'announcement', with explicit differentiation from the production sibling 'delivery_create_announcement_3pl'. It also specifies the sandbox environment and target audience.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'for delivery-service partners only' and 'unlike delivery_create_announcement_3pl... this is a sandbox, with no consequences', providing clear when-to-use and when-not-to-use guidance with a named alternative.
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?
Annotations indicate it is not read-only, not idempotent, and not destructive, which aligns with the description stating it 'Creates a task to update'. The description adds behavioral context: it returns a taskID and is asynchronous (status via delivery_get_task), and specifies that it operates in a sandbox. This goes beyond annotations by clarifying the async nature and authorization requirement.
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: three sentences that front-load purpose, then provide a key constraint, and finally specify audience and body format. Every sentence adds value without repetition or 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 (4 parameters, no output schema, async task), the description covers purpose, constraint, audience, and follow-up status check. It lacks details on error handling or response shape, but the schema covers parameter details. The presence of annotations for safety traits reduces the need for further behavioral description.
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 100%, so baseline is 3. The description adds extra meaning by emphasizing that the 'zones' array must fully match the tariff's deliveryProviderZoneId values, and that the body is an array of zones directly. This provides value beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Creates a task to update the delivery-term zones in a tariff', specifying the verb (creates a task to update) and resource (delivery-term zones in a tariff). It also distinguishes itself by noting it's for delivery-service partners and uses a sandbox environment, which helps differentiate from siblings.
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 important usage constraints: the list of new terms must fully match the tariff's deliveryProviderZoneId values, and it's for delivery-service partners only. It also mentions that status is obtained via delivery_get_task. However, it does not explicitly state when to use this tool versus alternatives in the sibling list.
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?
Annotations already mark as destructiveHint=true. The description adds context about the two-step process (initiate acceptance prohibition, then cancel) and the sandbox-only scope, which goes beyond what annotations provide. Does not discuss dryRun or idempotency, but these are partially covered in the schema.
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 sentences, each providing essential information: purpose, prerequisite, and sibling distinction. No redundancy or unnecessary details.
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, scope, prerequisites, and key behavioral details. Lacks description of return values or error handling, but given the tool's sandbox context and no output schema, it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions 'options field' in the sibling comparison, but does not add significant meaning beyond the schema's own 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 it cancels a test parcel in the sandbox, specifies the prerequisite (only parcels from delivery_create_sandbox_parcel_v2), and distinguishes it from a sibling tool (delivery_sandbox_cancel_parcel) by noting the v1 contract with an options field.
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 when to use this tool (sandbox only, for parcels created via a specific tool) and how it differs from delivery_sandbox_cancel_parcel, providing clear context for choosing between alternatives.
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?
Annotations provide readOnlyHint=false and openWorldHint=true but the description adds critical async behavior: 'The call only QUEUES the request — poll delivery_v1_get_change_parcel_info for the outcome.' This is beyond what annotations convey. No contradictions.
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 with no wasted words. The first sentence covers purpose and type, the second covers async behavior and sibling alternative. Front-loaded with essential 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?
For a sandbox-only tool with no output schema, the description covers key aspects: purpose, async nature, polling, bulk alternative, and sandbox restriction. It could mention potential error responses or success indicators, but overall it is sufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions the type enum values and the async polling concept but does not add significant meaning beyond the schema for individual parameters. The parameter details are already well-documented in 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 verb ('Creates a request to change') and resource ('ONE test parcel's data'), specifies the type enum values, and distinguishes from siblings by noting 'For bulk changes use delivery_change_parcels instead.' It also clarifies it's sandbox-only and for partners.
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 tells when to use this tool (to change one parcel) and explicitly advises using delivery_change_parcels for bulk changes. It lacks explicit prerequisites or conditions when not to use, but the sibling differentiation 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?
Disclosures: sandbox-only, no real-world effect, returns success status. Annotations already indicate non-readOnly and non-destructive. Description adds context but could mention more about side effects or reversibility.
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 concise sentences, front-loaded with purpose and scope. No waste; every sentence adds value.
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 complexity (10 params, nested) and no output schema, the description covers key context: sandbox, partnership, and sibling differentiation. Could elaborate on return value details but sufficient for a test tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds minimal param info beyond the schema, only highlighting that v1 requires the options field. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a test shipment announcement in the Sandbox with no real-world effect. It distinguishes itself from the sibling tool delivery_sandbox_create_announcement by noting the v1 shape requires the options field.
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?
Explicit usage guidance: use the base contract unless v1 is specifically needed due to the options requirement. Also specifies sandbox-only and for delivery-service PARTNERS.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, etc., and the description consistently states 'Read-only'. It adds valuable context about cursor-based pagination (response contains phones array and cursor) and the requirement for an active plan, going beyond the schema.
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 sentences with no fluff: first states purpose and method, second describes response format, third covers requirements and safety. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, pagination, and a key prerequisite. While it does not detail error conditions or the exact format of phone numbers, the combination of schema, annotations, and description provides sufficient completeness for a simple tool with one parameter and no 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?
The only parameter 'cursor' is fully described in the schema with 100% coverage. The description adds that it should be omitted for the first page, providing extra guidance for pagination. This exceeds the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns phone numbers of the managing company in the account hierarchy with cursor-based pagination. It specifies the internal function (list_company_phones) and distinguishes from sibling hierarchy tools like hierarchy_get_employees_v1 and hierarchy_list_items_by_employee_id_v1 by focusing on company phones.
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 mentions the prerequisite of an active account-hierarchy plan, guiding when the tool is usable. It does not explicitly state when not to use it or compare to alternatives, but the context is clear enough for an agent to infer its purpose relative to sibling tools.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds that it is read-only and does not return statistics, which aligns with annotations. It provides additional context on returned data but no contradictions.
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 with no waste: first sentence states purpose and key return fields, second sentence gives usage guidance and alternatives. Information is well front-loaded.
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 lack of output schema, the description covers what data is returned (status, price, address, VAS services) and provides usage context. Could be slightly more detailed about the scope of 'detailed information'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters clearly. The description does not add extra semantic value beyond the schema, but it is not needed. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns detailed information for a single listing, listing specific fields like status, price, address, and VAS services. It distinguishes from sibling tools like items_get_items_info and items_post_item_stats_shallow.
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 says when to use ('item_id is already known'), when not to, and names alternatives (items_get_items_info for list, items_post_item_stats_shallow for statistics). Also includes rate limit (500 req/min).
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds context by stating 'Read-only analytics' and specifying that it returns extended statistical metrics with flexible grouping, filters, and sorting, plus the limit constraint. This adds value beyond annotations, though it could further describe the output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with high information density: first sentence states purpose and key features, second sentence provides usage guidance. No unnecessary words, front-loaded with core purpose.
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 tool with 9 params, 6 required, no output schema, and annotations present, the description covers purpose, usage guidance, key constraints, and differentiator. It lacks details on output format but is largely complete given the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The description briefly summarizes key parameters (grouping, filters, sorting, metrics) and mentions limit ≤ 1000, but adds limited new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns extended statistical metrics for profile/listings over a period, with examples (views, contacts, presenceSpending). The title 'Listing analytics' reinforces the resource, and it distinguishes from the sibling items_post_item_stats_shallow by specifying advanced capabilities like filters and sorting.
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 advises when to use this tool over items_post_item_stats_shallow: when filters by category/employee, sorting by a metric, or presence-spending metrics are needed. Also mentions limit ≤ 1000, providing clear guidance.
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?
Annotations already declare readOnlyHint, idempotentHint, etc. Description confirms 'Read-only analytics' and adds operational limits (200 listings, 270 days) not in annotations. No contradictions.
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: first defines purpose and metrics, second provides usage guidance and limits. No wasted words, front-loaded with key 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?
No output schema, so return values are not required. Description covers purpose, all parameters (via schema), limitations, and sibling differentiation. Missing explicit pagination or response format, but acceptable for a read-only stats tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 6 parameters described). Description adds context like 'calls are not supported here' and 'group by day/week/month', but most info is already in schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns counters (shallow statistics) for listings over a period, listing specific metrics (unique views, contacts, favorites). It distinguishes from siblings by naming alternative tools for extended analytics and calls.
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 when to use this tool vs alternatives: for specific item_id metrics grouped by time; for extended analytics use items_post_item_analytics; for calls use items_post_calls_stats. Also includes limits (200 listings, 270 days) as usage constraints.
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?
The description adds significant context beyond annotations: irreversibility, visible deletion marker, and ownership constraint. It aligns with destructiveHint and readOnlyHint annotations without contradiction.
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 plus warning), front-loads the action, and avoids unnecessary details. Every sentence serves a clear purpose.
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 output schema, the description adequately explains effects (deleted marker) and preconditions. It could mention error scenarios or rate limits, but is sufficient for a straightforward deletion 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 covers 100% of parameters, but the description adds value by specifying the source of chat_id and message_id (from dependent tools) and the dryRun/idempotencyKey usage, aiding agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it deletes a single message by message_id, using specific verbs and resource identification. It distinguishes from sibling tools like messenger_post_send_message or messenger_get_messages_v3, making the purpose clear.
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 explains when to use (requires chat_id and message_id from other tools) and advises user confirmation. It implicitly warns against deleting other users' messages but lacks explicit when-not-to-use statements or alternative tool references.
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?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds value by noting the temporary nature of URLs, which is beyond the annotations. No contradictions.
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 plus a note, zero wasted words, and all essential information is front-loaded.
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 tool with no output schema, the description adequately explains the return format (temporary download URLs) and the source of input. It is complete for the tool's complexity.
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 100%, and the description adds context by explaining that voice_id values originate from messenger_get_messages_v3 and that a legacy CSV string is accepted, enhancing understanding 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 that the tool returns temporary download URLs for voice messages by voice_id. It distinguishes itself from sibling tools like messenger_get_messages_v3 by specifying that voice IDs come from that tool, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that voice_ids come from messenger_get_messages_v3 and that links are temporary, advising immediate download. It provides clear context for when to use this tool, though it does not explicitly list alternative tools for different scenarios.
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?
The description adds significant behavioral context beyond the annotations: it reads from an 'in-process buffer filled by the webhook receiver', does NOT call the Avito API, and does NOT mark anything as read. This aligns with the annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) and provides crucial details about side effects and data source.
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 (three sentences) and front-loaded with the core purpose. Every sentence adds value: purpose, operational details, prerequisites, filters, and cross-reference to status tool. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, full schema coverage, no output schema), the description covers prerequisites, filtering, side-effect details, and references to related tools. However, the absence of an output schema means the agent might lack details on the event structure. The description mentions 'new chat messages', which gives a hint, but a richer description of the return format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all three parameters have descriptions). The description summarizes the parameters: 'Supports filtering by chat_id, a `since` cutoff (ISO-8601 timestamp or epoch seconds/ms), and a `limit`.' This is a helpful recap but does not add new meaning beyond the schema. Following the guidelines, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns'), the exact resource ('Avito messenger webhook events'), and the context ('received by this server', 'newest-first'). It explicitly distinguishes itself from sibling tools by stating what it does NOT do (calls Avito API or marks as read), which sets it apart from related tools like messenger_get_chats_v2 or messenger_get_messages_v3.
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 prerequisites: 'Requires the receiver to be enabled (set AVITO_MCP_WEBHOOK_SECRET) and Avito subscribed to the receiver URL (messenger_register_webhook).' It also references a related tool for checking status (messenger_get_webhook_status). However, it does not explicitly state when one should NOT use this tool, which would strengthen the guidelines further.
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?
Annotations already indicate destructiveHint=true, so the destructive nature is known. The description adds context: 'Changes account settings' and that resubscription is required. No contradictions.
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 sentences, front-loaded with action and consequence. No wasted words. Clear 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 simple unsubscribe tool with annotations covering safety, the description provides sufficient context: what happens (stops events) and next steps (resubscribe). No output schema, but not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented. The description adds a hint for the URL parameter to use the exact subscribed URL, but this is minimal additional value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'UNSUBSCRIBES', the resource (URL from messenger webhook notifications), and the result (stops sending events). It distinguishes from sibling tools by explaining how to resume and referencing the subscription list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use the tool (to stop notifications), what not to do (need exact URL), and provides alternatives: 'to resume notifications you will have to subscribe again via messenger_post_webhook_v3' and 'see the list in messenger_get_subscriptions'.
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?
Description confirms the destructive nature (changes account settings, causes external events) and mentions confirmation required. No contradiction with annotations. Adds value beyond annotations by explaining security and default confirmation.
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 description with no redundant sentences. Each sentence adds necessary 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 main purpose, security, confirmation, and related tools. Without output schema, does not explain return values, which is acceptable. Fairly complete for this 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 provides full parameter descriptions (100% coverage). Description adds context about URL matching and security, enhancing understanding beyond schema. Baseline 3, extra context merits 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?
Description clearly states it subscribes the server's URL to webhook notifications for messenger events. It distinguishes from siblings like messenger_get_subscriptions and messenger_post_webhook_unsubscribe.
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?
Describes when to use (to subscribe for webhooks) and specifies security constraint. Mentions related tools for checking and unsubscribing. Does not explicitly state when not to use, but 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?
The description identifies the tool as a write operation, matching the readOnlyHint=false annotation. It adds behavioral context by noting the prerequisite (available action) and the buyer-facing outcome (sends details). However, it does not describe error conditions or the exact state changes beyond what annotations imply. Given the annotations already provide safety hints, this is sufficient but not exhaustive.
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 four sentences long, each serving a clear purpose: stating the action, explaining what the seller sets, specifying when to call, and indicating the next step. It is front-loaded with the core purpose and avoids unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides necessary context for using the tool: prerequisite, action details, and subsequent step. However, it does not describe the return value or what the tool outputs (e.g., success/error), which would be helpful given no output schema. Still, the combination with the schema and annotations makes it largely complete for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already documents all 7 parameters. The description highlights three key parameters (address, bookingPeriod, details) but does not add new meaning beyond the schema. The baseline of 3 is appropriate since the description does not reduce clarity but also does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool prepares a click-and-collect order and sends details to the buyer. It defines the acronym CNC and specifies the seller sets the pickup address, booking period, and comment. It distinguishes from sibling tools by mentioning the prerequisite (available setCNCDetails action) and the subsequent confirmation step via orders_apply_transition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call the tool: 'Call it when the order has an available setCNCDetails action.' It also provides a clear alternative for the next step: 'After handover, confirmation is done via orders_apply_transition (receive) with the buyer's code.' This gives concrete context and excludes other use cases.
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?
Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false, which is consistent with the description. The description adds that it's a 'write operation' and notes the response contains a success flag. It also mentions it can be called again to change the time, implying no destructive side effects. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences), front-loaded with the purpose and key distinction, and every sentence adds value. No redundant 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?
Given the complexity (10 parameters, 7 required, no output schema), the description explains the workflow, mentions the response contains a success flag, and covers key behavioral aspects. It could mention idempotencyKey safety, but that is covered in the schema description.
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 100% with detailed parameter descriptions. The description adds critical context for startDate, endDate, and intervalType by instructing to take them from the get method response, which is not evident from 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 verb 'selects (books)' and the resource 'a specific time slot for a courier to pick up the item', and distinguishes from the sibling tool orders_get_courier_delivery_range. It specifically mentions 'for seller-courier delivery', 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: it says to call orders_get_courier_delivery_range first and use its response values (interval and intervalType). It also states that the tool can be called again to change the time before pickup. No exclusion criteria are given, 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds context 'spends NO money' and 'forecast effect,' reinforcing safety and read-only nature. No contradictions.
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 comprehensive but slightly long; however, every sentence adds value. Front-loaded with main purpose. Could be tightened, but adequate.
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?
Covers input parameter sourcing, output structure (items[].{min,max,totalPrice} and overall totalPrice), and ties to sibling tools. No output schema, but description compensates well. Complete for forecasting context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description. The description adds useful context on where to get parameter values (from suggests) but does not introduce new parameter meaning beyond what schema provides. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Returns the forecast effect of BBIP promotion: expected increase in views (min/max) and total cost for the period.' Distinguishes from sibling tool promotion_create_bbip_order_for_items_v1 by stating this is to estimate return before creating the order.
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 says 'READ-ONLY: spends NO money; use BEFORE promotion_create_bbip_order_for_items_v1 to estimate the return.' Also guides to take values from promotion_get_bbip_suggests_by_items_v1, providing clear when-to-use and data sourcing.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds beyond annotations by disclosing pagination behavior (limit/offset), active review filtering, and that reviewId is needed for answers. This is strong context but not full coverage of all 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 three sentences, concise and front-loaded. The first sentence is a bit long including the tool name in parentheses, which is slightly redundant but not excessive. No wasted words, but could be slightly streamlined.
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 no output schema, the description fully explains the returned fields and pagination. It also references sibling tools and usage context. The tool is well-framed for an agent to understand its role and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with thorough descriptions for limit and offset. The description adds minimal extra meaning beyond the schema, only mentioning pagination and active reviews context. Baseline 3 is appropriate as schema does the heavy lifting.
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 paginated list of active reviews for the current user, enumerating the fields (review id, score, text, author, listing, photos, seller answer, total). It distinguishes from siblings by mentioning the alternative for aggregate scores and linking to the review answer tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (to browse individual reviews and get reviewId for reviews_create_review_answer_v1) and when not to (if only aggregate score is needed, use reviews_get_ratings_info_v1). Provides clear exclusions and context.
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?
The description fully aligns with annotations (readOnly, idempotent, not destructive) and adds valuable context: the output fields (quantity, is_unlimited, is_multiple, is_out_of_stock), the cache behavior, and the formula for available quantity ('submitted/edited minus reserved'). No annotation contradiction.
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 purpose and output, plus one sentence for alternative. It is front-loaded with the primary action and immediately provides key details. 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?
Given the tool's simplicity (2 params, no output schema), the description provides sufficient context: purpose, behavior, output fields, and alternative. It could mention error scenarios or rate limits, but annotations already cover safety. Slight gap in explaining item_ids reference (assuming listings), but overall complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds some value by explaining the return structure and the computation of 'available' quantity, but does not enhance parameter definitions beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reads current stock'), the resource ('listings in the warehouse'), and provides the function name and alternative tool ('To change stock, use stock_update_stocks'). It distinguishes from siblings by explicitly naming the mutation tool.
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 tells when not to use the tool (for changing stock) and directs to stock_update_stocks. It also explains optional strong_consistency parameter and cache behavior, providing clear context for usage. However, it does not contrast with other read tools like items_get_items_info, which might also provide stock-related info.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds 'Read-only' which is consistent and reinforces the safe behavior. No additional behavioral traits beyond annotations are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains no redundant information.
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 rich annotations and full schema coverage, the description adequately explains the mapping direction, use case, and relationship to sibling tool. It is complete for a read-only lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description of the query parameter (list of IDs separated by ',' or '|'). The tool description adds context about mapping but does not add parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns Avito listing identifiers (avito_id) from autoload file identifiers (ad_id), specifying a mapping from ad_id to avito_id. It distinguishes from sibling tool autoload_get_ad_ids_by_avito_ids by mentioning the reverse direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'when you have an ID from the feed and need to find the published listing on Avito'. It also mentions the alternative sibling tool for the reverse mapping.
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?
Annotations already cover read-only, idempotent, open-world, not destructive. Description adds specific return fields and deprecation context, exceeding annotation detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first summarizes functionality and return data, second provides deprecation advice. No wasted words, front-loaded with key information.
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?
Tool is simple (no parameters, read-only). Description lists return fields, deprecation status, and alternative tool. Annotations cover safety. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so description cannot add parameter semantics. Baseline of 3 is appropriate as schema coverage is 100%.
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 returns summary statistics of the last completed upload in v2 format, listing specific fields (section_stats, listing_fees, events, feed_url). It distinguishes from deprecated version and sibling v3.
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 DEPRECATED and advises to use autoload_get_last_completed_report_v3 instead, providing clear when-not-to-use guidance.
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?
Description adds behavioral context beyond annotations: explicitly states it is read-only and that the response contains a meta block with total/pages. Annotations already declare safety, and description aligns with them.
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 concise sentences: first states functionality and sorting, second provides usage guidance. No unnecessary words.
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 4 optional parameters and no output schema, description sufficiently explains returned fields, pagination, sorting, and meta block. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description mentions pagination and date filter but does not add new semantics beyond schema. No contradictions.
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 returns a list of autoload reports with specific fields (id, started_at, finished_at, status) and mentions pagination and date filtering. It distinguishes from siblings like autoload_get_report_by_id_v3 by indicating this is for listing and finding report_id.
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 tells user to use this tool to find a report_id, then fetch details via autoload_get_report_by_id_v3 or autoload_get_report_items_by_id. Provides clear context on when to use and what to do next.
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?
Beyond annotations (destructiveHint=true), the description adds crucial behavioral details: it removes active manual or auto bids, resets settings, and does not reduce spending to zero. It also explicitly warns about the continued charging at base price, providing transparency not captured by annotations alone.
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 yet thorough, using four sentences to convey the action, warning, behavior, and return value. No unnecessary words; all information is front-loaded and essential.
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 three parameters (one required), three annotations, and no output schema, the description provides sufficient context: it explains the operation, its side effects, return type (text message), and rate limit. This covers the key points an agent needs to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with parameter descriptions, so the description's job is reduced. It adds minimal value beyond schema, only contextualizing the itemID as the listing for which to stop promotion. It does not elaborate on dryRun or idempotencyKey, but the schema already handles them adequately.
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 ('stops target-action promotion for a listing') and the resource ('listing'), providing a specific verb-resource combination. It distinguishes from sibling tools like save_manual_bid/save_auto_bid by focusing on removal rather than creation or modification.
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 the effect of stopping promotion (resets bids, continued base pricing) and mentions that to resume promotion, the user must use save_manual_bid/save_auto_bid, implying when this tool is appropriate. However, it does not explicitly state when not to use it (e.g., if only adjusting bids).
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?
Annotations already mark destructiveHint=true, but description adds specific context: affects budget spending, overwrites manual strategy, and requires budgetPenny within min/max. No contradictions.
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?
One focused paragraph with warning symbols front-loading purpose and risks. Dense but efficient, though could be slightly more organized.
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, usage, constraints, warnings, rate limit, and key parameter guidance. Lacks mention of dryRun and idempotencyKey in description, but schema covers them. Still above average.
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 100%, so baseline is 3. Description adds cross-parameter constraints (budgetPenny range from cpa_target_get_bids, mutual exclusion with manual bid) that go 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 enables the automatic target-action bidding strategy and contrasts it with the manual bid sibling, providing a specific verb and resource.
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 when to use it ('delegate price management to Avito'), when not to use it (not available in 'Transport' category), and points to alternative save_manual_bid. Also includes rate limit.
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?
The description goes beyond annotations by explaining that it does not modify existing history, is not idempotent (duplicate logging), returns empty 200 on success, and provides error semantics. It also mentions retry policy and audience. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 4-5 sentences and front-loads the purpose. Every sentence adds value, though it could be slightly more structured with bullet points.
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 10 parameters, no output schema, and annotations, the description covers usage, error handling, audience, and retry policy. It lacks explanation of the response beyond empty 200, but that is acceptable for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the description does not need to repeat parameter details. It adds context by mentioning the event type and status transition as an example, but does not significantly augment the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'appends', the resource 'parcel tracking event', and scopes it to a single status transition. It distinguishes from siblings by specifying that this tool only appends status events, while others set cost/parameters or reschedule parcels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use ('report movement as it happens'), cautions about non-idempotency and duplicate logging, explains error responses (4xx rejection, 5xx retry), and limits usage to delivery-service PARTNERS. It also names sibling tools and their purposes.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds useful context: sandbox-only, works only with specific creation method, and returns info. No contradictions. Could mention error handling for invalid parcelID, but not critical.
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 concise sentences, no fluff, front-loaded with sandbox context, efficient use of words.
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?
For a simple read-only getter with one parameter and full annotations, the description provides all necessary context: domain (sandbox), resource (parcel), limitation (only from specific creator). 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?
Only one parameter (parcelID) with schema description 'Test parcel identifier.' Tool description does not add semantic details beyond the schema, but context of 'test parcel in sandbox' is inferred. Baseline 3 as schema coverage is 100%.
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 'Returns information about a test parcel by parcelID', specifying verb, resource, and scope. The sandbox-only restriction and dependency on delivery_create_sandbox_parcel_v2 differentiate it from siblings like delivery_tracking and delivery_create_sandbox_parcel_v2.
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 when to use (sandbox, test parcel by ID), when not to use (not outside sandbox, only for parcels created via delivery_create_sandbox_parcel_v2). Provides clear context and restrictions.
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?
Annotations already provide safety hints (readOnly, idempotent, not destructive). The description adds that it requires an active plan and explains the returned employeeId's role in other tools, which provides useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no superfluous information. 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 has no parameters and no output schema, the description fully covers its purpose, return fields, prerequisites, and integration with other tools. No additional information is needed.
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?
There are zero parameters, so the baseline is 4. The description does not need to add parameter 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 it returns the list of account-hierarchy employees of the managing company, specifies the returned fields (employeeId, name, email, phones, isChief), and provides a parenthetical alias (get_employees). It distinguishes itself from siblings by mentioning how the employeeId is used in hierarchy_link_items_v1 and hierarchy_list_items_by_employee_id_v1.
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 prerequisites (active account-hierarchy plan) and states it is read-only. It gives context on when the output is used (with other hierarchy tools), though it does not explicitly exclude alternative tools or provide when-not-to-use guidance.
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?
Annotations already indicate read-only and non-destructive; the description reinforces this by stating it does not purchase or spend money, adding context about its role as a price reference.
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 wasted words; the key information (purpose, usage order, safety) is front-loaded and immediately useful.
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?
For a simple price-lookup tool, the description fully covers purpose, usage guidance, and behavioral context; no output schema is needed as the tool returns straightforward cost info.
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 100% coverage for both parameters; the description adds minimal extra meaning beyond what the schema descriptions already provide, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns costs and available services for VAS, and distinguishes from purchase tools by emphasizing it is read-only and should be called before purchasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this tool before purchasing via items_apply_vas or items_put_item_vas, providing a clear usage sequence and distinction from mutating tools.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value beyond annotations by noting it returns 'most recently observed' values, grouped by domain, and across all processes in the account namespace. No contradictions.
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: first defines what the tool returns, second provides usage guidance. No extraneous text; every word earns its place.
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?
The tool has no output schema, but the description sufficiently explains the return values (rate-limit headers and grouping). It covers the key behavioral aspects needed for an agent to understand and use the tool effectively.
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 in the input schema, and schema coverage is 100% for zero params. The description need not elaborate on parameters, and thus it meets the baseline 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?
Description clearly states it returns rate-limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) grouped by API domain, across processes. Verb 'Returns' and resource are specific, distinguishing it from sibling tools which focus on autoload, calltracking, etc.
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 states usefulness for diagnosing throttling and mentions the per-minute limit enforcement by Avito. While it doesn't specify when not to use it or list alternatives, the context provided is sufficient for an agent to decide.
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?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds value by detailing the output content (no args shown, only name/risk/summary/times), beyond what annotations provide.
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, zero wasted words. First sentence states action, second explains output and use case. Efficient and well-structured.
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 parameters, no output schema), the description fully covers what it does, what it returns, and why to use it. No 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?
No parameters exist, and schema coverage is 100%. With zero parameters, the baseline is 4; the description correctly omits parameter 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?
Description clearly states it lists pending actions with specific fields (tool name, risk, summary, timestamps) and explicitly contrasts with confirmation actions, distinguishing it from siblings like meta_confirm_action.
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 clear use case: 'diagnose what did I just ask to confirm.' It gives context but does not explicitly mention when not to use, though it is sufficient for this simple tool.
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?
The description discloses that the tool creates a draft without sending or charging, returns dispatches and offers, and locks in the recipient audience. Annotations (readOnlyHint=false, openWorldHint=true) are consistent; the description adds context about side effects (locking audience, no charge). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with all essential information front-loaded. Each sentence adds value (purpose, workflow, return types, next steps). No redundancy or filler.
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?
Despite no output schema, the description adequately explains return values (dispatches with id, status, recipient count; offers with price). It covers the workflow, prerequisites (check eligibility), and distinguishes from sibling tools. For a 3-parameter tool with high schema coverage, this is 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?
Schema coverage is 100% with clear descriptions for all three parameters. The description adds minimal extra meaning beyond the schema (e.g., 'list of listing IDs selected for the campaign'). However, it does not explain parameter usage beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Creates a draft discount/special-offer messenger campaign for a list of listings (multi_create).' It specifies the action (creates draft), resource (campaign for listings), and distinguishes it from the sibling tool 'msg_discounts_open_api_multi_confirm' by noting this is the first step that does not send or charge.
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 clear workflow context: 'This is the FIRST step — the campaign is NOT sent yet and no money is charged.' It explains the next step (pick an offer and confirm via another tool) and mentions checking eligibility via a different tool. However, it does not explicitly state when not to use this tool or provide alternatives beyond the sibling confirm tool.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description reinforces that it is a read check and does not change the order. It adds value by explaining the possible response statuses (success, fail, expired, attempts), which is beyond what annotations provide. However, annotations already cover the safety profile well, so a 4 is appropriate.
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 no wasted words. It front-loads the key purpose and behavior. Every sentence contributes: purpose, read-only nature, response statuses, and sibling differentiation.
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 there is no output schema, the description adequately explains return values (statuses). It covers behavior, scope, and distinguishes from related tools. For a simple verification tool, this is 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?
Schema description coverage is 100% with both parameters documented (parcelID and confirmCode have descriptions). The description does not add new semantic information beyond the schema, so baseline 3 is correct.
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 verifies a confirmation code for handing over an order at a pickup point. It specifies it is a read check that does not change the order, and explicitly distinguishes it from delivery_check_confirmation_code. The verb 'verifies' and resource 'confirmation code for order handover' are specific and unique among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns not to confuse with delivery_check_confirmation_code, providing a clear alternative. It implies the tool is for order management handover at pickup points, giving context for when to use it.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds 'Read-only' and clarifies that it does not book slots. It also mentions response structure (dateOptions with intervals), which is useful beyond annotations.
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 wasted words. First sentence states purpose, second gives critical usage guidance. Perfectly concise for the information conveyed.
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 only 2 parameters, no output schema, and rich annotations, the description is complete. It covers purpose, usage order, key response elements, and distinction from sibling. No gaps for an AI agent to misunderstand.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The description does not add new meaning beyond what's in the schema, but the context of seller's address is reinforced. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb 'Returns' and resource 'available time slots' for courier pickup. It clearly distinguishes from the sibling tool by stating 'Read-only' and 'does not book them', ensuring no confusion.
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 to call it BEFORE orders_set_courier_delivery_range and warns not to confuse with the set version. Provides context that a specific slot is chosen from the response, guiding when to use this tool.
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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds context that it's paginated, returns specific fields, and is for current user. No contradiction.
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 fluff. First sentence defines purpose, second provides usage context. Efficient and well-structured.
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?
For a paginated list tool without output schema, description adequately explains output fields (id, createdAt, status) and pagination behavior. Also references sibling tool for detailed status, ensuring 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?
Schema coverage is 100% for pagination parameters. Description does not add new meaning beyond what schema already specifies about page and perPage. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns a paginated list of the current user's promotion orders with specific fields (id, createdAt, status). Distinguishes from sibling tool promotion_get_order_status_v1 by stating it's for overview/history.
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 when to use (order history/overview) and when not to use (for detailed status, use promotion_get_order_status_v1). Also notes it's read-only and spends no money.
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?
The description adds behavioral context beyond annotations: it warns that the answer is PUBLIC and visible to everyone after moderation, which is critical for the agent to understand consequences. No contradiction with annotations exists.
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: three sentences that front-load the purpose, add a warning, and specify requirements. No unnecessary words; 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 no output schema, the description mentions return values (id and timestamp). It covers the required parameters, provides a warning about public visibility, references sibling tools for context, and includes a usage instruction. This is complete for a mutation tool with good schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions reviewId from reviews_get_reviews_v1 and message text, but adds no new semantic details beyond what the schema provides. The dryRun and idempotencyKey parameters are not covered in the description.
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 publishes a seller answer to a review, specifying the action and resource. It distinguishes from siblings by referencing reviews_remove_review_answer_v1 for deletion and reviews_get_reviews_v1 for obtaining the reviewId, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Confirm the action with the user', providing a usage guideline to require user confirmation. It also directs to the deletion tool for when an answer needs to be removed, making the when-to-use vs when-not-to-use 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it is a 'point-in-time snapshot' and 'read-only', reinforcing the safe read-only nature. No contradictions; additional context on return fields.
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, each serving a distinct purpose: what it does, what it returns, and when to use alternatives. No redundant information.
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 no output schema, description adequately explains return fields (real and bonus amounts). Also covers scope (Personal Account vs CPA) and related operations. All necessary context for correct invocation is provided.
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?
Parameter schema covers 100% with description; the description restates that user_id is optional and defaults to own account, but adds no new semantic meaning beyond what is in the schema. Baseline score for full coverage is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States clearly that the tool reads the account wallet balance, specifies the fields (real money and bonus funds in rubles), and distinguishes from CPA balance. The verb 'reads' and resource 'account wallet balance' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (Personal Account wallet) and when not to use (CPA balance, history of charges/top-ups). Provides direct alternatives: 'see the cpa domain' and 'use post_operations_history'. Clear guidance for selection.
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?
Annotations already declare readOnlyHint and idempotentHint. The description adds 'Read-only, no parameters' but does not disclose additional behavioral context beyond what annotations provide.
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 concise sentences: first defines purpose and outputs, second gives usage guidance. No wasted words, front-loaded.
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?
Despite no output schema, the description lists all returned fields. It's complete for a simple read-only tool with no parameters.
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; schema coverage is 100% trivially. Per guidelines, 0 parameters yields baseline 4. Description adds no param info, but none needed.
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 the profile of the currently authorized account, listing specific fields (id, email, name, phone numbers, profile_url). It also distinguishes from siblings by referencing get_user_balance and post_operations_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes when to use this tool (finding Profile_id, checking account) and directs to alternatives for balance and operations history.
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?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds pagination behavior (meta with total/pages) and confirms read-only nature, which aligns with annotations. No contradictions.
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 concise sentences: first covers purpose and output, second covers usage guidance and alternative. No redundant 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?
For a read-only retrieval tool with 5 parameters and no output schema, the description covers output fields, pagination, and usage context. It could mention defaults for page/per_page but those are in the schema. Overall 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 coverage is 100%, so baseline is 3. Description adds value by listing the output fields (ad_id, avito_id, charge type, amount/package ID) and explaining pagination, which helps the agent understand the purpose of optional parameters like page and per_page.
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 returns placement charges for a specific upload, listing output fields (ad_id, avito_id, charge type, amount/package ID). It also distinguishes from sibling tool autoload_get_report_items_by_id by noting that alternative is for listing processing/statuses.
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 instructs to use this tool to break down upload cost, and explicitly directs to autoload_get_report_items_by_id for listing processing/statuses. Provides clear when-to-use and alternatives.
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?
Annotations already declare readOnlyHint true, idempotentHint true, destructiveHint false. Description adds context about read-only nature (stated explicitly) and pagination behavior, complementing annotations without contradiction.
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 sentences, front-loaded with core purpose, then requirements, then alternatives. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: what it returns, filtering, pagination, requirements, and alternatives. Lacks description of the response format or fields, but given tool complexity and rich annotations, it is 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 coverage is 100% with detailed descriptions. Description adds value by clarifying the time filter is on 'callTime' and that pagination is supported, which goes beyond schema field names.
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?
Clearly states the tool returns a list of call-tracking calls over a time range, filtered by call time, with pagination. Explicitly distinguishes from siblings by directing to other tools for single call or recording.
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?
Provides explicit guidance: requires RFC3339 time window, mentions pagination. Clearly states when not to use this tool by naming alternatives calltracking_get_call_by_id and calltracking_get_record_by_call_id.
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?
Beyond annotations (destructiveHint=true, idempotentHint=false), the description adds that the complaint is irreversible and confirmation is required by default, and mentions the rate limit. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences), each sentence adds value: purpose, irreversibility/confirmation, prerequisite, alternative and rate limit. 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 no output schema, the description could mention return value (e.g., complaint status or ID) but it does not. It hints at confirmation but lacks full detail on what happens after filing. Still fairly complete for a focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema; it mentions callId comes from a preceding call but that is already implied by the required field description.
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 files an external complaint about a CPA call by its callId, with an example of disputing an off-target call. It distinguishes itself from the sibling tool cpa_create_complaint_by_action_id which handles both calls and chats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: when to use (disputing a charge), prerequisite (callId from cpa_get_calls_by_time_v2), alternative for combined complaints (cpa_create_complaint_by_action_id), and a rate limit (1 request/min).
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds that it does not change spending, reinforces read-only nature, and provides additional constraints (max 200 items per request, rate limit).
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 well-structured with front-loaded purpose, followed by details, usage guidance, and rate limit. Every sentence adds value; 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?
Despite no output schema, the description lists returned fields (actionTypeID, strategy, price/limit/budget). It is complete enough for a batch read tool with strong annotations. Minor gap: could mention response format (e.g., array) but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the description does not add significant new meaning beyond what the schema provides for the single parameter. Mentions 'in kopecks' for prices but that applies to output, not parameter.
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 returns current target-action bids and budgets for multiple listings at once (batch up to 200). It specifies output details (actionTypeID, strategy, price/limit/budget) and distinguishes from the single-listing sibling cpa_target_get_bids.
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 says when to use (bulk-check current settings) and when not to (for a single listing with full min/max/recommendations/forecast, use cpa_target_get_bids). Also mentions rate limit of 400 requests/min.
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?
The description extensively details behavioral traits beyond annotations: irreversibility, idempotency via idempotencyKey, dryRun support, and HTTP 204 response. It aligns with annotations (destructiveHint=true) and adds significant context, enabling informed invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph with all critical information front-loaded. Every sentence adds value, and there is no redundancy or 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 destructive nature and lack of output schema, the description covers key aspects: action, permissions, parameter sources, idempotency, dry run, and response. Minor omission of error scenarios, but overall sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds value by clarifying the source of employeeId (from hierarchy_get_employees_v1) and explaining dryRun's purpose, enhancing understanding 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 action: assigning listings to an employee within the account hierarchy. It distinguishes itself from sibling tools (e.g., hierarchy_get_employees_v1) by referencing them as sources for parameters, making the tool's purpose and relationship to others explicit.
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 assign/reassign listings) and provides prerequisites (hierarchy permissions, employeeId from hierarchy_get_employees_v1). It does not explicitly state when not to use it, but the irreversible note and idempotency details offer implicit guidance.
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?
Annotations already mark readOnlyHint, idempotentHint, destructiveHint=false. Description adds 'Read-only, changes nothing' and important details: rate limit of 25 requests/min, and that it returns empty list for employees' listings—beyond annotation coverage. No contradiction.
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 yet informative: spells out purpose, usage, filters, rate limit, and employee limitation in a few sentences. Front-loaded with main action and output fields. 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?
No output schema, but description lists returned fields. Could mention response is an array or pagination metadata, but given the simple list nature and annotations, it is sufficiently complete for most contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for all 5 parameters. Description mentions pagination and filters generically but adds no new semantics beyond summarizing what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns a LIST of authenticated user's listings with specific fields (id, status, category, link). Differentiates from sibling items_get_item_info for single listing details. Specific verb 'Returns a LIST' and resource described.
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 tells when to use: 'Use it to find listing ids and get an overview; for details on a single listing, use items_get_item_info.' Also mentions limitation with employees' listings and rate limit, providing comprehensive guidance.
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?
Annotations already indicate readOnly, idempotent, non-destructive. Description reinforces 'Read-only analytics, changes nothing and spends nothing', adding clarity beyond annotations.
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 sentences: first states purpose and breakdown, second confirms safety, third covers parameters and alternative. No wasted words, front-loaded.
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?
Despite no output schema, description clarifies output is aggregated call stats by day. Somewhat vague on exact response fields, but sufficient given annotations and simplicity.
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 covers all parameters (100% coverage). Description adds context on how date range defines period and that user_id defaults from .env, improving understanding 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?
Description explicitly states the tool returns aggregated call statistics (total/new/answered/new answered) broken down by day, distinguishing it from items_post_item_stats_shallow for views/contacts.
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?
Provides clear when-to-use guidance, including default behavior without itemIds and an explicit alternative for views/contacts. Lacks explicit when-not-to-use, but sufficient.
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?
The description adds significant behavioral context beyond annotations, including a warning that the image is immediately and publicly visible, the two-step process, and the requirement for prior upload. This complements the destructiveHint and readOnlyHint annotations.
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, front-loaded with the action and warning, and every sentence adds value. It efficiently conveys the purpose, prerequisites, and caution.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's action, preconditions (two-step process), and warnings. It lacks return value details, but the tool is straightforward and no output schema exists, so it is mostly 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 schema descriptions cover 100% of parameters, and the tool description does not add new parameter meaning beyond stating that image_id comes from messenger_upload_images. With full schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends an IMAGE using an already-uploaded image_id to a chat on behalf of the account. It distinguishes from the sibling tool messenger_post_send_message for text messages, providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: first upload via messenger_upload_images, then call this tool. It states the alternative for text and emphasizes user confirmation, offering clear context and alternatives.
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?
The description adds valuable context beyond annotations, such as single-use nature, soft-confirmation mode, and the role of the env variable. It explains the behavioral intent and guard mechanisms.
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 efficient and front-loaded, though somewhat dense. It conveys necessary information in two sentences, but could be slightly more structured for readability.
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 lacks details about the return value or error conditions, which is important since there is no output schema. It does not fully explain what to expect after a successful confirmation.
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 reiterates the parameter purpose but adds context about the confirmation_secret and soft-confirmation mode. Since schema coverage is 100%, baseline is 3; the additional context raises it to 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 executes a previously deferred action by its confirmation_id, distinguishing it from sibling tools like meta_cancel_action and meta_list_pending_actions.
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 to use only after explicit human confirmation, explains the two-step guard, and discusses the soft vs hard confirmation modes. Provides clear context on when and how to use.
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?
Beyond the destructiveHint annotation (which only flags destructiveness), the description adds critical context: deletion is irreversible, immediately removes the public answer, and returns a success flag. This fully discloses 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct: two sentences plus a warning, with essential information front-loaded (action, irreversibility, alternative). Every sentence serves a purpose without 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?
The description covers the core behavior (destructive, irreversible, success flag return). Parameter schema fully covers inputs. A minor gap is that the success flag structure is not described, but for a simple deletion tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any additional meaning beyond what the input schema already provides for parameters like answer_id, dryRun, and idempotencyKey.
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 ('permanently deletes') and the resource ('review answer'), and the title adds 'Delete a review answer'. It distinguishes from sibling tool reviews_create_review_answer_v1 by mentioning the alternative for publishing again.
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 instructs to confirm the action with the user, warns of irreversibility, and points to reviews_create_review_answer_v1 as an alternative for publishing a new answer. Provides clear when-to-use and when-not-to-use 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?
Annotations declare destructiveHint=true and readOnlyHint=false, already indicating mutation. The description adds context about the effect on availability ('quantity=0 marks a listing as out of stock') and the return format ('Returns success and errors for each listing'). This provides useful behavioral insight beyond the annotations.
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 four sentences with no redundant information. It starts with the core action, then explains the effect, then the input format, and finally directs to the sibling tool. Every sentence earns its place.
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 moderate complexity (3 parameters, one nested array) and absence of an output schema, the description covers the key aspects: purpose, effect, input format, and hints at return shape. It relies on the schema for parameter details but adds high-level context. Annotations are present and consistent.
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 100%, so the description does not need to add much. However, it summarizes the main parameter ('array of {item_id, quantity, external_id?}') and explains the significance of quantity (0 means out of stock, range 0..999999). This adds clarity beyond the schema's technical 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 uses a specific verb ('Updates') and resource ('stock (quantity) of items across listings') and explicitly distinguishes from the sibling tool 'stock_get_stocks_info' by directing users to it for current stock. The purpose is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool (updating stock), what the effect is (quantity=0 marks out of stock), and which sibling to use instead for reading stock (stock_get_stocks_info). It also mentions input structure and constraints (array of objects, max 200 items).
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?
Annotations already declare readOnlyHint, idempotentHint, and nondestructive nature. The description adds context about the output fields and the version difference (v3 vs v2), but no behavioral surprises. Well aligned with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover purpose, output, usage guidance, and version differentiation. No wasted words, front-loaded with key information.
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?
Despite no output schema and zero parameters, the description explains return fields, usage timing, and distinguishes from a sibling tool. Annotations provide safety cues. Complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to provide parameter details. It confirms 'no parameters', which is sufficient. Baseline 4 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Returns') and the resource ('summary statistics of the last completed upload (v3, current format)'), listing specific output fields. It also distinguishes from the sibling tool autoload_get_report_by_id_v3.
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 when to use ('after an upload has been processed') and when not to use ('for a specific report use autoload_get_report_by_id_v3'), providing clear guidance.
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?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructive. The description adds value by specifying the exact fields returned (autoload_enabled, report_email, schedule, feeds_data), confirming read-only nature and no parameters. No contradictions.
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 concise sentences: first covers purpose and return fields, second provides version guidance. No unnecessary information.
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 no output schema, the description adequately describes the return structure and fields. It is complete for a simple read-only get operation.
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 baseline is 4. The description correctly states 'no parameters', which is sufficient given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Returns', identifies the resource 'autoload profile settings', and lists specific fields returned. It distinguishes from v1 by noting the difference in returned data (feeds_data vs deprecated single upload_url).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends preferring this method over v1 and explains why (feeds_data instead of deprecated upload_url). It also implies use for reading current profile settings, separate from create/update tools.
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?
Annotations already provide readOnlyHint=true and idempotentHint=true, and the description reinforces read-only behavior. It adds details about pagination (response contains meta with total/pages). No contradictions. Slight additional value beyond annotations, but could mention more about response format or error states.
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 plus an additional usage guideline sentence) and front-loaded with the core purpose. No unnecessary words. Every sentence adds value.
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 5 parameters and no output schema, the description covers purpose, output fields, pagination, and usage. It references where to get report_id and section slugs. Missing details about what exactly is in the 'link' and error handling, but overall complete for a read-only tool with good annotations.
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 100%, but the description adds context: for report_id it says 'obtain it via autoload_get_reports_v2', for sections 'get the slugs from the report's section_stats (e.g. via autoload_get_report_by_id_v3)'. It also clarifies default values for page and per_page, and how query and sections accept comma or pipe separators. This significantly enhances parameter 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 it returns processing results of each listing in a specific upload by report_id, listing specific fields (ad_id, avito_id, etc.). It also mentions read-only and pagination. This distinguishes it from its sibling autoload_get_report_by_id_v3 by focusing on line-by-line breakdown vs summary.
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 'Use it for a line-by-line breakdown of an upload; for an upload summary see autoload_get_report_by_id_v3.' This directly addresses when to use this tool and provides a clear alternative. It also gives guidance on obtaining section slugs from the report's section_stats, showing how to use the sections filter.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by specifying the exact read-only metadata fields returned, which is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and no redundant information. Every word serves a purpose.
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?
For a simple read tool with one parameter and no output schema, the description fully covers purpose, usage context, returned fields, and parameter origin. No 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?
Schema coverage is 100% and describes callId with its source. Description adds useful context that callId is obtained from calltracking_get_calls, which helps the agent understand where to get the parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Returns metadata for a single call-tracking call by its callId' and lists specific fields (call time, durations, phone numbers, virtual number, itemId). It also differentiates from siblings by naming them.
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 when to use this tool ('when you know a specific callId') and directs to alternatives for time-range queries (calltracking_get_calls) and audio recordings (calltracking_get_record_by_call_id).
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?
Beyond annotations (readOnlyHint, idempotentHint, etc.), description details output format (mimeType, sizeBytes, base64), decoding requirement, potential file size (several MB), availability delay (30 min), retention (3 months), and error conditions (HTTP 425, code 1005). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then key details (return format, decoding, size, delay, retention, error). No unnecessary words.
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?
For a download tool with good annotations, description covers all critical behavioral aspects: output structure, decoding, size, timing, error handling, and sibling differentiation. Complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter 'callId' is well-documented in the schema. Description does not add significant additional meaning beyond 'the call identifier'.
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?
Clearly states the action (downloads), resource (call-tracking conversation audio recording), and identifier (specific callId). Explicitly distinguishes from sibling tools calltracking_get_call_by_id (metadata) and calltracking_get_calls (list).
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 tells when to use alternative tools ('For call metadata use calltracking_get_call_by_id, and for a list over a time range use calltracking_get_calls'). Also provides temporal constraints (30-minute delay, 3-month retention) guiding when the tool is applicable.
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?
Annotations indicate readOnly, openWorld, idempotent, and non-destructive. Description adds 'Read-only, spends no money' and a rate limit. However, it does not elaborate on openWorldHint implications, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then usage guidance. Every sentence provides essential information 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?
Given the tool's simplicity (single parameter, read-only, no output schema), the description covers purpose, parameter source, usage, limitations, and rate limit. It is entirely sufficient for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and describes actionId as a CPA target-action identifier. The description adds context that the actionId is obtained from cpa_chats_by_time_v2, providing useful provenance 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?
Description clearly states it returns the CPA chat model by actionId, with explicit source and scope. Differentiates from sibling by noting it is for when you already have the actionId, not for iterating by time.
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 when to use: when you already have the actionId from cpa_chats_by_time_v2. Provides a clear exclusion: not for iterating by time. Also includes rate limit (3 req/min).
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?
Reinforces read-only nature as in annotations, adds explicit statement 'does not change spending' and rate limit. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each with distinct value: purpose, safety, usage guidance, sibling differentiation, rate limit. 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?
Despite no output schema, description details all returned fields (price, min/max/recommended, strategy, forecast) and units (kopecks). Fully covers information needs for tool 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?
Only one parameter (itemId) with full schema coverage. Description mentions 'ONE listing' but does not add semantic detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'Returns', resource 'detailed information about current and available target-action bids', scope 'for ONE listing', and lists specific data fields. Distinguishes from sibling tool cpa_target_get_promotions_by_item_ids.
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 when to use ('before save_manual_bid/save_auto_bid'), when not to use (for multiple listings), names alternatives, and provides rate limit (20 req/min).
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?
Annotations indicate readOnlyHint=false, openWorldHint=true, etc., but description adds crucial behavioral context: the call only QUEUES requests, outcomes come via delivery_change_parcel_result. This goes beyond annotations and helps the agent understand the async nature.
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?
Four sentences, front-loaded with purpose, then usage, then behavioral traits. No wasted words; each sentence adds unique information.
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?
Covers all key aspects: what it does (batch queue), when to use (bulk), who can use (partners), and what happens after (outcomes via another tool). No output schema but mentions result endpoint. Complete for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The description itself does not add significant semantic value beyond what's in the schema (e.g., 'type' enum values are already listed in schema). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queues a BATCH of parcel-property changes, lists the specific types, and distinguishes from the single-parcel sibling delivery_v1_change_parcel. Verb 'queues' and resource 'parcel-property change requests' are specific.
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 says 'Use it for bulk changes; for a single parcel use delivery_v1_change_parcel'. Also notes that it's for delivery-service PARTNERS only, with a 403/404 for regular sellers, providing clear when-to-use and when-not-to-use.
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?
Disclosures include no real-world effect, no consequences, and return of parcelID. Aligns with annotations (readOnlyHint=false implies write operation, destructiveHint=false supports no consequences).
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 two-sentence structure: first sentence defines purpose and return, second provides comparison and usage context. No redundant information.
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 complexity (7 optional parameters, nested objects, no output schema), the description covers sandbox scope, lifecycle, target audience, and key return value fully. Enough for agent to decide and invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The tool description does not add significant parameter-specific detail but provides context about the sandbox lifecycle and return value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a test parcel in the Sandbox with no real-world effect, returns parcelID, and distinguishes it from the production sibling delivery_create_parcel.
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 'For delivery-service PARTNERS testing only', contrasts with production creation, and identifies it as the entry point for a sandbox lifecycle with links to subsequent tools.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds explicit behavioral disclosure: 'Read-only — sends nothing and does not mark anything as read.' This goes beyond the annotations by clarifying side effects (no marking as read). No contradictions.
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 compact sentences: first delivers the core purpose and return value, second provides usage context and alternatives. Front-loaded, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema) and rich annotations, the description adequately covers purpose, usage context, filters, pagination, and alternatives. It explains what is returned (list with previews and unread counter) and when to use it, making it complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description mentions filters (items, types, unread) and pagination (limit/offset) but does not add new semantic information beyond what the schema already details (e.g., limits, defaults, types). The narrative summary is helpful but not additive.
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 explicitly states 'Returns a LIST of the account's chats' with details on content (last message preview, unread counter). It distinguishes from siblings by mentioning messenger_get_chat_by_id_v2 and the downstream tools that require chat_id, making the purpose clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance: 'Use it to find the needed chat_id before messenger_get_messages_v3, messenger_post_send_message or messenger_chat_read.' It also explicitly names an alternative for a single known chat: 'To get the details of a single known chat, use messenger_get_chat_by_id_v2.' This covers usage context and exclusions.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that despite the POST method, no body is required and it creates/deletes nothing, clarifying any potential confusion about the HTTP method.
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 concise sentences: first describes output, second gives usage context. Front-loaded with purpose, zero filler.
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?
For a parameterless tool without output schema, the description fully covers return content (list of subscriptions with URLs, versions, status), read-only nature, and sibling context. No gaps remain.
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 (schema coverage 100%). Description adds value by confirming no body is required for the POST method, which helps avoid unnecessary request formatting.
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?
Clearly states the tool returns a list of active webhook subscriptions with specific fields (notification URLs, versions, status). Differentiates from siblings by mentioning its role relative to subscribe/unsubscribe tools.
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 advises using this tool to check subscriptions before calling messenger_post_webhook_v3 or messenger_post_webhook_unsubscribe, providing clear when-to-use guidance.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false. The description adds that the subscription is additive (does not delete others) and requires a public HTTPS address. It also states the effect (Avito will POST events) and pairs with read tools. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action and uses multiple sentences to cover prerequisites, behavior, and sibling tools. While comprehensive, each sentence adds necessary context. Slightly verbose but efficient overall.
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 complexity of webhook registration (public URL requirement, additive behavior, multiple related tools, safety constraints), the description covers all essential aspects: purpose, distinction from similar tool, prerequisites, side effects, and pairing with read tools. No output schema, so no missing return value explanation.
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 100%, but the description adds significant value: the url parameter's safety constraint (must equal publicUrl+path+secret), the dryRun preview behavior with default from config, and idempotencyKey's duplicate protection and TTL. This goes well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action (subscribes), resource (webhook receiver URL), and outcome (messenger events start flowing). It explicitly distinguishes from sibling tool messenger_post_webhook_v3 by noting the auto-fill behavior, and mentions pairing with messenger_get_webhook_events and messenger_get_webhook_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (to start receiving events), alternatives (messenger_post_webhook_v3 for manual URL), prerequisites (public HTTPS address), and how to unsubscribe (messenger_post_webhook_unsubscribe). Provides clear guidance on when to use this tool vs. others.
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?
Annotations already declare readOnlyHint=true, so description not needed for that. But it adds context beyond annotations: token never returned, and that probe may trigger a refresh side effect. This is valuable behavioral disclosure. Could mention idempotency or rate limits, but 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 sentences, each with a distinct purpose: what it reports, what it never returns (and alternative), and probe behavior. No fluff, front-loaded with key info.
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 it's a simple status check with one optional parameter and an output schema (presumably documenting return fields), the description covers all necessary context: function, safety, parameter behavior, and alternatives. Complete for its complexity.
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 covers the parameter with description, and the description adds context about refresh behavior. Schema coverage is 100%, so baseline 3; description adds extra nuance, earning a 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 it reports token metadata (present/absent, expiresInSec, last refresh error) and explicitly says what it does NOT do (never returns the token). It also distinguishes from the auth_* tools, which do return the token. The verb 'reports' and resource 'token metadata' are specific and immediate.
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?
Provides explicit guidance on when to use (check token status) and when not (need actual token, use auth_* tools). Explains the probe parameter's effect: default no refresh, probe=true may trigger refresh. Clearly references alternatives under AVITO_MCP_EXPOSE_AUTH_TOOLS=1.
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?
Declares read-only, no sends, no charges, and lists return fields. Annotations already indicate safety; description reinforces and adds detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short, front-loaded, no redundancy. Every sentence adds value: purpose, read-only note, return content, usage guidance.
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?
Describes return fields despite no output schema, provides usage context, and distinguishes siblings. Complete for a stats tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions (100% coverage). Description does not add parameter-specific detail beyond stating the period, but baseline is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns statistics for already-sent discount campaigns over a period, and distinguishes from sibling tools for eligibility checks and tariff info.
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 says to use for analyzing results and provides alternatives for eligibility checks (msg_discounts_open_api_available) and remaining balance (msg_discounts_open_api_tariff_info).
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?
Discloses behavioral traits beyond annotations: async task creation (returns taskID), limit of 100 orders, availability constraint (pickup-point only). Annotations already indicate non-read-only, non-destructive, so description adds valuable 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?
Three sentences, each carrying essential information. Front-loaded with purpose and limit, then availability and flow, then alternative. No redundant words.
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?
Covers all necessary context: input (orderIDs), constraints (pickup-point only, max 100), output (taskID), follow-up action (download label). No output schema but description compensates. Complete for a task-generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented. The description mentions the orderIDs limit but doesn't add new semantics beyond schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a task to generate PDF labels for orders, specifying the resource and action. It distinguishes from sibling tools like orders_generate_labels_extended (higher limit, rate limit) and orders_download_label (download step).
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?
Provides explicit when to use: only for pickup-point orders and for up to 100 orders. Directs to alternative for larger batches. Clarifies the async flow: returns taskID, then download via orders_download_label.
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?
Discloses that it creates an async task, returns a taskID, has a rate limit of 1 request per minute, and is non-idempotent (idempotencyKey optional). Annotations already indicate non-read-only, non-idempotent, non-destructive; description adds valuable 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?
Four tightly packed sentences, front-loaded with main purpose, no redundant or unnecessary information. Each 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?
Covers purpose, constraints, async nature, rate limit, follow-up steps, and sibling comparison. No output schema exists, but description adequately explains return value (taskID) and next steps. Annotations complement well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds some context (e.g., 'up to 1000 orders', 'pickup-point only') but does not provide additional parameter-level semantics beyond what the schema already offers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a task to generate PDF labels for large batches of orders (up to 1000), distinguishes from sibling tool orders_generate_labels by specifying higher limit and rate limit, and notes it is only for pickup-point 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 when to use (for large batches of pickup-point orders), contrasts with sibling tool (higher limit but strict rate limiting), and advises waiting for task completion and downloading via orders_download_label.
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?
Annotations already indicate a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds value by explaining the write stores codes on Avito side, maximum 50 records, and per-item results in the response. No contradictions.
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 at 3-4 sentences, front-loaded with a warning icon and clear purpose. Every sentence adds necessary context without 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?
Given 3 parameters (1 required), no output schema, and no enums, the description covers all necessary aspects: operation, constraints (max 50), response structure, and differentiation from sibling tools. No 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?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining dryRun as a preview feature, detailing markings structure (itemId, orderId, markings array with code constraints), and providing idempotencyKey behavior (duplicate protection, TTL, conflict errors).
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 explicitly states the tool submits 'Chestny Znak' marking codes for items in an order, distinguishing it from the sibling tool orders_apply_transition (status transitions). The specific verb 'submits' and resource 'marking codes' clearly define purpose.
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?
It specifies when to use: when the order has a setMarkings action (via availableActions from orders_get_orders). It also explicitly warns not to confuse with orders_apply_transition, providing clear usage guidance.
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?
Annotations already indicate readOnlyHint and destructiveHint false. Description reinforces with 'READ-ONLY: spends NO money.' Adds value beyond annotations by explicitly stating financial impact (spends no money) and specifying return fields.
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: first states purpose and return fields, second declares read-only nature, third gives usage guidance. No filler, front-loaded with essential info.
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?
For a single-parameter read-only tool, description fully covers what it does, what it returns, and when to use it. No gaps given lack of 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 description coverage is 100% with orderId described as 'Promotion order identifier in UUID format...'. Description adds context by explaining the return value relationships, but parameters are well-covered in 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?
Description clearly states 'Returns the status of a BBIP order by its orderId' and lists return fields (overall status, totalPrice, per-item status). Specifies exact verb+resource and distinguishes from sibling promotion_create_bbip_order_for_items_v1 by indicating this is for tracking after creation.
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 tells when to use: 'Call it AFTER promotion_create_bbip_order_for_items_v1 to track the order's execution.' Clearly communicates the sequential usage pattern without ambiguity.
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?
Annotations already declare readOnlyHint and idempotentHint. Description adds context that it takes no parameters and returns no paginated data, and lists return fields, which complements annotations without contradiction.
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 core purpose and return data, immediately followed by sibling reference. No unnecessary words.
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?
For a simple read-only tool with no parameters and no output schema, description covers all essential information: return fields, no pagination, and sibling differentiation. Completely 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 has no parameters (100% coverage). Description confirms 'Takes no parameters', which is sufficient. No additional parameter details needed.
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 explicitly states 'Returns the aggregated rating of the current user' and lists specific fields (average score, total active reviews, etc.). Clearly distinguishes from sibling tool 'reviews_get_reviews_v1'.
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 it takes no parameters and directs user to 'reviews_get_reviews_v1' for list of reviews, providing clear when-to-use and alternative.
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?
Annotations already set readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description adds 'Read-only' and clarifies these are wallet movements not CPA balance, and date constraints. No contradiction, but could add pagination or error 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?
Four sentences, front-loaded with purpose and key details. No fluff, 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?
No output schema, but description lists returned fields and explains scope. With strong annotations and schema, it's complete for an agent to understand what to expect.
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 covers 100% of parameters with descriptions. Description adds constraints (date range limits) and context, enhancing schema. No param info 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?
Description clearly states it returns list of account wallet operations, specifying types (charges, top-ups) and fields (amountRub, amountBonus, etc.). It distinguishes from CPA balance and references get_user_balance for current balance, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (wallet history), when not to (for current balance use get_user_balance), and provides date constraints. Implicitly distinguishes from other history tools by specifying wallet operations.
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?
Annotations indicate destructive (destructiveHint=true) and not idempotent. Description adds critical context: side effect of publishing/updating listings, publication limits do NOT apply, and the one-per-hour rate limit. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph densely packs purpose, side effects, limits, and parameter explanations. Slightly dense but each sentence is justified. Could be broken into shorter sentences for readability.
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?
No output schema, but description adequately explains return ('launch confirmation') and directs to polling via a sibling tool. Covers all necessary aspects for a 2-param tool: behavior, params, limits, and follow-up.
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 100%, baseline 3. Description adds meaning: dryRun as safe preview, idempotencyKey with conflict handling and key storage details. This improves understanding beyond 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 immediately launches an unscheduled upload of listings from the feed URL set via autoload_create_or_update_profile_v2. It distinguishes from sibling tools by mentioning the dryRun and idempotencyKey, and directs polling via autoload_get_last_completed_report_v3.
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?
Explicit guidelines: use to trigger immediate upload, notes that all listings are processed without limit from settings, mentions one upload per hour, and explains when to use dryRun (preview) and idempotencyKey (duplicate protection). Indirectly tells when not to use (if you want scheduled uploads or to avoid all listings).
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?
Annotations already provide readOnlyHint, idempotentHint, etc. The description adds context on output structure, cacheability, and change frequency, going beyond annotation info without contradiction.
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, front-loaded with purpose, then usage instructions, then caching hint. No verbosity.
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 zero parameters, well-covered annotations, and description of output structure and usage, it's fully complete for this 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?
No parameters exist; description clearly states 'no parameters', fully covering 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?
Describes exactly what the tool does: returns the full Avito category tree with specific structure (name, slug/id, nested children), and distinguishes from sibling by stating its role in preparing an autoload feed.
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 when to use (to find a category slug) and what to do next (pass it to autoload_user_docs_node_fields), plus notes cacheability and rare changes.
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?
Discloses financial impact ('affects budget spending'), daily spending cap via limitPenny, and overwrites auto strategy. Annotations already flag destructiveHint=true, but the description adds essential monetary context beyond what annotations provide.
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?
Four concise sentences, each serving a distinct purpose: purpose, warning, exclusivity/usage, validation/rate limit. Efficient and front-loaded with the core action.
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 output schema, the description does not explain return values but covers prerequisites (minBidPenny), constraints (limitPenny?), and rate limit. Missing idempotency mention from schema, but overall sufficient for a mutation tool with good annotations.
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 100% so baseline is 3. The description adds value by cross-referencing minBidPenny from cpa_target_get_bids and clarifying actionTypeID values (1,5,7). It also reiterates bidPenny lower bound, but that's already in schema. Slight improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource combination: 'Sets a MANUAL (fixed) target-action bid for a listing.' It clearly distinguishes from the sibling tool 'save_auto_bid' by contrasting manual vs. auto bidding.
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 says when to use ('control per-action price yourself') and when not (use save_auto_bid for delegation). Also notes mutual exclusivity with auto bid and provides a rate limit (20 req/min).
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?
Annotations already indicate destructive and non-read-only behavior. Description adds crucial context: charges money (irreversible), and an error does not guarantee no purchase. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with main action and warning. Every sentence provides useful information (purpose, monetary impact, deprecation, prerequisites, error handling). No unnecessary text.
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?
No output schema, so description partially compensates by noting response contains service data and charged amount. Covers prerequisites, alternatives, and error handling. Lacks detailed output structure but provides enough context for a complex monetary 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 100%, so baseline is 3. Description adds value by advising to call items_post_vas_prices for current slug and price, aiding vas_id selection. No additional detail on other parameters, but context improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool applies one additional promotion service (VAS) to a listing, using the verb 'applies' and specific resource 'listing'. Differentiates from siblings by explicitly stating deprecation and alternatives: prefer items_apply_vas for one or more services, and use items_put_item_vas_package_v2 for a package.
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?
Provides explicit guidance: call items_post_vas_prices first for slug and price, confirm with user, and check again on error. Also tells when not to use this tool (for multiple services or packages), directing to alternatives.
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?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds behavioral context: it's read-only, details what the response includes, and specifies the 404 error condition for invalid tariff categories. No contradictions.
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 two-sentence description is efficient: first sentence states purpose and read-only nature, second sentence lists response components and usage. No wasted words; key information is front-loaded.
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?
Despite having no output schema, the description enumerates all key response elements (tariff level, activity status, dates, bonuses, prices, listing packages, etc.) and covers the error condition. This provides sufficient contextual completeness for a read-only info 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?
The description explicitly states 'Takes no parameters,' which fully informs the agent given the input schema is empty (schema coverage 100%). No parameter details needed.
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 account tariff information for the Transport category, lists specific response contents (current/scheduled contracts, tariff level, etc.), and distinguishes it from CPA tariff with a note about 404 return. The name and title are aligned.
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 'Use it to check tariff terms and the remaining listing balance' and provides a clear condition: 'Available only for tariffs in the Transport category and not for the CPA tariff; otherwise it returns 404.' It does not compare to sibling tools, but the condition is sufficiently specific.
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?
Discloses that promo fee is added on top of base commission, response includes success flag per listing, and error codes (1001 validation, 1002 promo unavailable) with allowed commission range. Adds value beyond annotations (destructiveHint=true, etc.) but could mention idempotency implications.
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 two-sentence description plus error details. Front-loaded with main action, no redundant info.
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?
Covers purpose, parameters, error handling, response shape, and related tools. No output schema but description adequately replaces it for the agent.
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?
All parameters described with clear syntax: commission in hundredths of a percent (1500=15%), date format YYYY-MM-DD, dryRun and idempotencyKey with detailed behavior. Schema coverage 100%, and description adds meaning 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?
Clearly states 'Applies transactional promo/promotion with a pay-per-result commission to listings' with specific verb (applies), resource (promotion), and context (listings). Distinguishes from siblings by referencing trxpromo_get_commissions and trxpromo_cancel.
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 advises to 'First check the limits via trxpromo_get_commissions; cancel a running promo with trxpromo_cancel', providing clear prerequisites and when to use alternative tools.
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?
Annotations already indicate read-only. The description adds deprecation details, field replacement (upload_url -> feeds_data), and confirms no parameters, going beyond annotations to explain 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a deprecation note, each sentence adds value without redundancy. Front-loaded with purpose, no wasted words.
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?
For a simple read-only tool with no parameters and no output schema, the description covers all necessary context: what it returns, deprecation status, and preferred alternative.
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; description explicitly states 'no parameters', confirming what the schema already shows. Schema coverage is 100%, so baseline 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 returns autoload profile settings (v1), lists specific fields (autoload_enabled, report_email, schedule, upload_url), and distinguishes from v2 by noting deprecation and directing to the alternative.
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 says the tool is deprecated and to use autoload_get_profile_v2 instead, providing clear when-to-use and when-not-to-use guidance.
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?
Description adds context beyond annotations: confirms read-only nature (does not change spending), explains pagination cursor behavior, and specifies 200 requests/min limit. No contradictions.
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 sentences with no redundancy. Each sentence adds value: purpose, return fields, pagination, rate limit. Front-loaded with key action.
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?
Despite no output schema, description lists returned fields (pricePenny, expirationTime, availablePrices) and covers pagination and rate limits. Fully sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters fully. Description adds meaningful context on pagination (fromItemID as cursor) and batch size default/range, slightly elevating beyond baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it reads active/available CPA auction bids for user's listings. Clearly distinguishes from sibling cpa_auction_save_item_bids.
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?
Provides when to use (to read bids) and when not (to change bids, use sibling). Includes pagination details and rate limit, guiding correct usage.
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?
Discloses read-only nature ('spends no money') and empty request body, adding value beyond annotations that already indicate readOnlyHint and idempotentHint. No contradictions.
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 unnecessary words. Purpose, usage, and constraints are front-loaded and clearly communicated.
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?
For a simple tool with no parameters or output schema, the description covers return values, idempotence, deprecation, and rate limit comprehensively.
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; schema coverage is 100%. Description notes empty request body, which is sufficient. Baseline 4 for zero-parameter tools.
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?
Clearly states the tool returns CPA wallet balance in kopecks (balance, debt, advance) and that it is a deprecated v2. Distinguishes from sibling cpa_balance_info_v3.
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 advises to prefer cpa_balance_info_v3 and specifies a rate limit of 1 request/min, providing clear usage context.
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?
Discloses that it charges money and is irreversible, exceeding annotations. Mentions dryRun for safe preview. Response includes purchase IDs for tracking.
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 yet comprehensive. Front-loads key info with warning emoji. Every sentence provides value without 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?
Covers all aspects: prerequisites, side effects, response content, parameter behaviors, and alternative methods. No gaps given complexity and lack of 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 100% but description adds context like 'each service applied only once' and 'stickers only with XL listing', which is helpful beyond 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?
Clearly states it applies one or more promotion services and/or stickers to a published listing. Identifies as v2 method and distinguishes from deprecated siblings.
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?
Provides explicit prerequisites: check availability and price via items_post_vas_prices, confirm with user. Also notes limitations (one service per request, stickers limited to 3 with XL listing).
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?
Discloses that it does NOT call the Avito API, which is critical behavior not in annotations. Annotations already declare readOnlyHint, idempotentHint, destructiveHint false, and description adds context about local check.
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 wasted words. First sentence states the return value, second provides usage context. Efficient and info-dense.
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?
Without output schema, description explains all returned fields (enabled, URL, subscribe URL, ring-buffer counters). Also includes behavioral note about not calling API. Complete for a no-param 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?
No parameters, baseline 4. Schema coverage is 100%, description adds no param details but none needed.
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 returns configuration and live stats of the Avito webhook receiver, listing specific fields. It distinguishes itself from messenger_register_webhook and messenger_get_webhook_events by name and purpose.
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 tells when to use this tool: 'Use it to verify the receiver is set up before messenger_register_webhook, then read collected events with messenger_get_webhook_events.' Provides a clear usage order.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds critical behavioral context: message is immediately and publicly visible, not automatically removed, can be deleted via messenger_delete_message, and requires user confirmation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 4 sentences. First sentence front-loads the core purpose. Subsequent sentences add essential warnings, requirements, and alternatives without redundancy. Every sentence earns its place.
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 output schema, 2 required params), the description is complete. It covers purpose, behavioral warnings, prerequisites, constraints, and alternatives. An agent has all necessary context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and provides detailed descriptions. The description adds value by specifying the source of chat_id (from messenger_get_chats_v2) and reinforcing the visibility implication for text. While helpful, it largely reinforces schema info.
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 sends a TEXT message to a chat on behalf of the account. It distinguishes from the sibling messenger_post_send_image_message by explicitly noting the alternative for images. The verb 'sends' and resource 'message' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidelines: warning about public visibility, requirement to confirm text with user, required parameters and their source (chat_id from messenger_get_chats_v2), text limit, and alternative for images. It effectively tells when to use and when not to use this tool.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it makes no external API calls, providing behavioral insight beyond the annotations. No contradiction.
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 concise sentences, front-loaded with the key purpose and data returned. No filler; every sentence adds value ('lists what it returns' and 'clarifies safety/external behavior').
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 zero parameters, full annotation coverage, and existence of an output schema, the description is complete. It tells what the tool returns, that it is safe, and that it requires no external calls—enough for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema coverage (empty schema). The description correctly adds no param info because there are none. Baseline 4 for 0 parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Universal health-check' and enumerates specific data fields it returns (package version, capabilities, rate-limit status, etc.), distinguishing it from sibling tools that perform domain-specific operations.
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 it does not call the Avito API and is safe to call as often as desired. This tells the agent when to use it (for lightweight status checks) and when not (for operations requiring real API calls).
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?
Description adds context beyond annotations: 'Read-only; sends nothing and charges nothing' and explains the return format (isAvailable and reason). This aligns with readOnlyHint, idempotentHint, and destructiveHint, and provides practical behavior details.
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: purpose, read-only nature, return format, usage order, disambiguation. Every sentence adds value; no wasted words. Front-loaded with the core action.
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?
For a simple check tool with one parameter and rich annotations, the description fully covers what the tool does, how to use it (first in a sequence), what it returns, and how it differs from siblings. No output schema needed.
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 already describes itemIds as 'List of listing IDs' with constraints. The description adds that it checks for 'a list of listings' and that each itemId gets a result, providing extra context. Baseline is 3 due to 100% coverage; +1 for useful elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Checks' and the resource 'whether a discount/special-offer messenger campaign is available for a list of listings'. It distinguishes itself from sibling tools by naming them and explaining their different purposes.
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?
Explicit guidance: 'Run this FIRST, before msg_discounts_open_api_multi_create' and 'Do not confuse it with ..._tariff_info or ..._stats'. This tells the agent exactly when to use this tool and what alternatives to consider.
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?
Discloses irreversible and public nature, message sending, money deduction, and insufficient funds error. Adds context beyond annotations (destructiveHint=true) such as 'IRREVERSIBLE and PUBLIC' and BETA status.
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 single paragraph, front-loaded with essential warning and action. Every sentence provides necessary information without 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?
Given the tool's irreversible payment nature, the description covers prerequisites (used after multi_create), side effects, error condition, user confirmation requirement, and contrasts with siblings. Complete for a complex 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?
All parameters are documented in schema (100% coverage). Description adds practical context: dryRun for preview, idempotencyKey for duplicate protection, and clarifies that dispatches come from multi_create response. Adds value 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 it is the final step to confirm and pay for a discount campaign created via multi_create. It uses specific verbs 'confirms and PAYS' and distinguishes from read-only sibling tools like _available, _tariff_info, and _stats.
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?
Provides explicit guidance: 'Always confirm the action with the user before calling.' and indicates it is the second step after multi_create. Also contrasts with read-only alternatives.
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?
Adds important context beyond annotations: 'sends nothing and charges nothing' and behavior when no active plan (empty response). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then usage details. No wasted words. 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 low complexity, annotations present, and no output schema, the description covers purpose, behavior, edge cases, and disambiguation. Complete for this 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?
No parameters in schema. Description explicitly states 'no parameters', which is sufficient and aligns with baseline of 4 for zero-parameter tools.
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?
Clearly states it returns info about discount campaign plan with specific fields (sendsLeft, totalSends). Distinguishes from sibling tools _available and _stats.
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 says read-only, no parameters, no side effects (sends nothing, charges nothing), and tells when response is empty. Advises not to confuse with other related tools.
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?
Disclosures beyond annotations: 'Read-only, changes nothing' (matches readOnlyHint and destructiveHint). Describes response format {mimeType, sizeBytes, base64} and error condition (404). Adds context that annotations do not cover.
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 sentences, front-loaded with the main action, no unnecessary words. Efficient and to the point.
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 low complexity (1 param, no output schema, rich annotations), the description covers purpose, usage, response format, and error condition comprehensively.
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 100% with a good description for taskID. The description reinforces that taskID comes from orders_generate_labels(_extended) response, adding slight value. Baseline 3, improved to 4 by clarifying the source.
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 purpose: 'Downloads the generated PDF file with labels by taskID (download_label).' It specifies the resource (labels) and action (download), and distinguishes it from sibling tools like orders_generate_labels by noting it is called after generation.
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?
Provides explicit usage guidance: 'Call it AFTER orders_generate_labels or orders_generate_labels_extended, once the generation task is complete — the taskID comes from their response.' It also warns when not to use (if task not ready or wrong taskID returns 404).
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?
Description aligns with annotations (destructiveHint=true, readOnlyHint=false). It adds behavioral details: 'PAID ACTION (money)', 'CHARGES the budget', 'order is created only if no errors across all listings', and explains dryRun and idempotencyKey behavior beyond annotations.
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 dense paragraph, front-loaded with warning, purpose, then procedural steps. Every sentence adds value. No 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?
Covers prerequisites, parallel tools, error handling, return value (orderId). Minor gap: could mention other potential error responses beyond 402. Still very complete given complexity.
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 100%, but description adds meaning: for 'items' it specifies the source (suggests) and formula; for 'dryRun' it explains preview; for 'idempotencyKey' it explains duplicate protection. All parameters are enriched 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 verb 'creates', the resource 'BBIP order', and the action 'CHARGES the budget'. It distinguishes from sibling tools by referencing estimation and status-checking tools (promotion_get_bbip_suggests_by_items_v1, promotion_get_bbip_forecasts_by_items_v1).
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?
Explicit guidance: 'FIRST estimate the cost and return for free... Then for each listing pass an option...' It also describes error conditions (402 for insufficient funds) and prerequisites (use suggests). Alternatives are named for estimation and status checking.
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?
Description adds 'Read-only, spends no money', which aligns with annotations (readOnlyHint, destructiveHint) but provides additional context. Rate limit is also disclosed. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with purpose, then deprecation and alternatives, then rate limit. No unnecessary words.
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?
For a simple read-only deprecated tool with thorough annotations and schema, the description covers all necessary aspects: purpose, deprecation, alternatives, rate limit. Output is implicitly the audio recording, which is sufficient.
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 only parameter (call_id) is described in the description with source information ('obtained from cpa_get_calls_by_time_v2 or from a chat/action'), adding value beyond the schema's type and constraints. Schema coverage is 100%.
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 'Returns the recording (audio) of a CPA call by its identifier (v1, deprecated)'. It distinguishes from siblings by naming alternatives (cpa_get_call_by_id_v2, calltracking_get_record_by_call_id) and specifying that v1 is deprecated.
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 deprecation and advises to prefer v2 or calltracking versions. Also notes rate limit (1 req/min). Provides clear when-to-use and when-not-to-use guidance.
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?
Adds context beyond annotations: specifies read-only (confirms readOnlyHint=true), does not mark chat as read, and describes pagination and sorting. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loading key information—purpose, read-only note, prerequisites, pagination, and related tool. No superfluous content.
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?
Despite no output schema, description covers return content and sorting, and provides links to related tools. Completely informs agent selection and invocation.
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 100% with descriptions; description adds value by explaining chat_id origin, pagination parameters, and default user_id.
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 messages of a specific chat, sorted newest to oldest, and lists content types (text, images, voice, links, date, author). It distinguishes from sibling tools like messenger_get_chats_v2 and messenger_chat_read.
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 notes read-only behavior, does not mark as read (suggests messenger_chat_read), requires chat_id from messenger_get_chats_v2, pagination via limit/offset, and directs to messenger_get_voice_files for voice downloads.
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?
Description confirms read-only nature ('does not start anything or charge any fee'), aligning with annotations. Adds critical non-standard HTTP detail: 'GET with a request body', which annotations do not cover. No contradiction.
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 sentences, each earning its place. Front-loaded with purpose, no redundant words.
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?
For a read-only query tool with one parameter, description provides usage order, return format, behavioral nuance (non-standard HTTP), and sibling references. Complete despite absence of output schema.
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 covers parameter with description, but description adds output context: 'returns promoAvailable flag and settings: minimum/maximum/step of the commission in hundredths of a percent (100 = 1%)', which goes 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?
Description clearly states verb 'checks' and resource 'transactional promo availability and allowed commission range for listings'. Differentiates from siblings trxpromo_apply and trxpromo_cancel by naming them.
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 says 'Use before trxpromo_apply to learn the commission limits' and names start/cancel tools as alternatives, providing clear when-to-use guidance.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/elchin92/avito-mcp'

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