mcp-ozon-seller

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action, with no overlap. For example, product tools are separated from order tools, and within products, there are separate tools for prices, stocks, and attributes.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case, such as get_product, list_products, update_prices, get_fbo_order. The naming is predictable and easy to understand.
Tool Count4/5
With 26 tools, the server covers a comprehensive set of operations for an e-commerce platform. While slightly on the higher side, each tool serves a clear purpose within the domain, making the count appropriate.
Completeness5/5
The tools cover all major aspects of Ozon seller management: products (CRUD, pricing, stock), orders (FBO/FBS, returns), finances (reports, transactions), analytics, and seller rating. Few gaps are apparent for the stated purpose.
Average 4.1/5 across 26 of 26 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Inno Setup License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the output as a 'detailed list' and date format requirements, but omits important traits such as pagination behavior (page, page_size parameters exist but not explained), sorting, result limits, or any side effects (though likely read-only). This leaves significant behavioral uncertainty.
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 two sentences, front-loading the purpose and types of transactions. It is concise and avoids unnecessary words, while still conveying key constraints like required date range and optional filters. Some additional context (e.g., pagination) could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description covers core purpose and required parameters but lacks details on pagination, output structure, and differentiation from similar tools. It is minimally adequate but incomplete for complex usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 7 parameters have descriptions), so baseline is 3. The description adds value by noting that date range is required and providing ISO 8601 examples. It also lists optional filters by name. However, it does not elaborate on parameter semantics beyond what the schema already provides, such as details on operation_type or posting_number.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists financial transactions and enumerates types (sales accruals, commissions, etc.). It specifies the verb 'Get a detailed list' and the resource 'financial transactions', making the purpose clear. However, it does not differentiate from sibling tools like get_finance_report or get_transactions_totals, which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates that date range filtering is required and optional filters are available, but provides no guidance on when to use this tool versus alternatives (e.g., get_finance_report for aggregated totals). No exclusion criteria or usage conditions are mentioned, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns details but does not disclose behavioral traits such as read-only nature, permissions required, rate limits, or any potential side effects. This is a significant gap for a retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and resource. It is concise yet informative. Minor improvement could be breaking into two sentences for better 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 the tool has one parameter, no output schema, and no annotations, the description covers the key output aspects (products, quantities, prices, analytics, financial breakdown) adequately. It lacks prerequisites or error handling details but is sufficient for a 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 one parameter 'posting_number' that is well-described in the schema. The description adds value by specifying 'by posting number' and listing returned fields (products, quantities, etc.), but does not enhance parameter semantics 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 ('Get full details') and the resource ('single FBO order') with the required identifier ('by posting number'). It distinguishes itself from siblings (e.g., list_fbo_orders, get_fbs_order) by specifically mentioning 'FBO order' and 'posting number'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (what the tool does and how to use it) but lacks explicit guidance on when to use this tool versus alternatives (e.g., list_fbo_orders for multiple orders, get_fbs_order for FBS orders). No exclusions or when-not scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description is the sole source. It mentions the batch limit and string format but omits error handling, idempotency, response behavior, or authentication needs.
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 well-structured sentences that front-load the core action and limit, with no redundant 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?
Lacks response structure details and prerequisites; for a mutation tool, this is a gap given absence of output schema and 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 coverage is 100%, and the description adds value by explaining the role of old_price and min_price and emphasizing string formatting, going 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?
Clearly states 'Update prices for one or more products' with a specific limit, distinguishing from sibling tools like get_prices or update_product.
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?
Provides constraints on what to provide (offer_id/product_id plus new price) and optional fields, but does not explicitly compare with alternatives or state 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'update stock quantities' but does not disclose behavioral traits like whether updates are absolute or incremental, idempotency, error handling, or required permissions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences with no waste. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given lack of output schema and annotations, description omits return behavior (success/error handling), partial update support, and batch atomicity. Adequate for basic use but incomplete for a complex update 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 baseline is 3. Description adds value by summarizing required fields and referencing list_warehouses, but it largely restates schema descriptions. No extra syntax or constraints 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 updates stock quantities for FBS warehouses, specifying required identifiers (offer_id or product_id) and distinguishing FBS from FBO. This provides a specific verb+resource and differentiates from sibling tools like get_stocks.
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 guides users: use list_warehouses for warehouse IDs, provide per-item identifiers and stock, and notes FBS vs FBO distinction. However, it lacks an explicit alternative for FBO stock updates, which could be inferred but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It states the tool returns quantities and supports pagination, but does not explicitly indicate read-only behavior, rate limits, or authentication needs. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding distinct value: purpose, returned data, filters/pagination. No fluff, front-loaded, and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description mentions returned quantities. It lacks explicit default values (limit=100, visibility=ALL) and response structure details, but covers essential aspects adequately. Could elaborate more on return format given no 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%, with all parameters already described. The description reinforces optional filtering and pagination but adds no new 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?
The description clearly states the tool retrieves stock levels across all warehouses, specifies returned data (available and reserved quantities), and mentions optional filters and pagination. This distinguishes it from siblings like get_warehouse_stocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for general stock queries with optional filters and pagination, but does not explicitly state when to use this tool versus alternatives like get_warehouse_stocks or get_product. No exclusions or when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides basic behavioral context: products become visible to buyers after unarchiving. However, it lacks details on error handling, idempotency, permissions, or side effects when products are already unarchived.
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 action, and contains no extraneous information. Every word serves a 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 simple tool with one parameter and no output schema, the description provides sufficient information for an AI agent to understand the core functionality. Minor gaps remain (e.g., handling of invalid IDs), but it is largely 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% and the description adds little beyond the schema's parameter description ('Array of Ozon product IDs to unarchive'). The description states to provide an array of product_ids, which is redundant.
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 (restore/unarchive), the resource (products on Ozon), and the effect (visible to buyers). It distinguishes from siblings like archive_product and get_product by specifying the opposite operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for unarchiving archived products but does not explicitly state when to use versus alternatives (e.g., archive_product for archiving). No exclusion criteria or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns multiple data categories (products, buyer details, etc.), which is transparent about output. However, it does not explicitly state that the operation is read-only or that it requires the posting number to exist. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, lists key return types, and contains zero waste. It is optimally concise for a simple retrieval tool.
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 tool has no output schema, so the description must compensate. It enumerates all major return components (products, buyer details, delivery address, shipment deadline, analytics data, financial breakdown), providing a clear picture of what to expect. However, it omits error cases or field-level details, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single parameter (posting_number) described as 'FBS posting number, e.g. "57308553-0009-1"'. The description adds no further semantic value 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 retrieves full details of a single FBS order by posting number, listing what is returned (products, buyer details, etc.). It distinguishes from sibling tools like list_fbs_orders and get_fbo_order by specifying 'FBS order' and 'single order'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need detailed information about one specific order by providing the posting number. However, it does not explicitly state when not to use it (e.g., for listing many orders) or mention alternatives like list_fbs_orders. The context is clear but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that returns include product name, SKU, reason, status, and amounts, and that filtering is supported. However, it does not mention pagination behavior (last_id), default ordering, or rate limits, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a note. It front-loads the purpose and key details, with 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 8 parameters and no output schema or annotations, the description covers the main aspects: domain (FBO), filterable fields, and usage constraint. It lacks details on pagination, default sorting, or response structure, but is adequate for a monitoring 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 baseline is 3. The description adds value by summarizing filter options and providing the usage note about one time filter, but does not explain individual parameters 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?
The description clearly states it retrieves a list of product returns for FBO orders, specifies included fields (product name, SKU, reason, status, amounts), and explains its utility for monitoring return rates and identifying problematic products. This distinguishes it from sibling tools like list_fbs_returns for FBS orders.
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 lists filter options (logistic return date range, posting number, offer_id, product name) and includes an important usage note: 'use only one time filter field at a time.' It lacks explicit guidance on when not to use this tool or alternatives, but the context of monitoring returns 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?
With no annotations, the description must fully disclose behavior. It states it returns order details including buyer info, delivery method, and products. It does not mention pagination behavior, rate limits, authentication needs, or that it's read-only. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines purpose and required/optional filters, second lists statuses and return info. Front-loaded with key information, 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?
For a tool with 7 parameters, 2 required, and no output schema, the description covers the purpose, required filters, status options, and general return content. However, it omits details on pagination (offset/limit), sorting (dir), and warehouse filtering, which are important for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by emphasizing that date range is required, listing possible status values, and summarizing return content. This goes beyond the schema's individual 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 'Get a list of FBS orders (fulfilled from seller warehouse)', with a specific verb ('list') and resource ('FBS orders'), and distinguishes from sibling FBO tools by mentioning 'FBS' and 'seller warehouse'.
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 specifies that a date range is required and optional status filtering, including listing possible statuses. However, it does not explicitly guide when to use this tool vs alternatives (e.g., get_fbs_order for single order, list_fbo_orders for FBO), nor does it provide 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?
Discloses the return format (warehouse IDs and names) and the read-only nature. With no annotations, it adds basic behavioral context but omits details like data freshness, authorization requirements, or whether results are paginated.
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 short sentences, each serving a distinct purpose: purpose, output, and usage. No redundancy, no fluff. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description adequately covers what the tool returns and how it relates to other tasks (stock updates). Minor omission: could clarify if all warehouses or only active ones are returned.
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 no properties; description adds 'No parameters required' which only reiterates the schema. No additional semantic value beyond confirming parameter absence.
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?
Uses specific verb 'Get the list of seller warehouses', clearly identifies resource and scope (FBS warehouses). Distinguishes from sibling tools like get_warehouse_stocks which returns stock data, not warehouse list.
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 the tool requires no parameters and explains a primary use case (get IDs for update_stocks). However, lacks explicit conditions when not to use or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns a task_id for asynchronous processing, which is useful behavioral context. It also notes that attributes depend on the category, hinting at complexity. However, without annotations, it does not cover rate limits, authentication requirements, or potential side effects beyond creation. The mutation aspect is obvious, so a score of 3 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two main sentences and a note. It starts with the purpose, then lists requirements and return value. Every sentence adds useful information. It could be slightly more structured, but it is 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?
Given the tool's complexity (creating up to 100 items with many fields) and the lack of an output schema, the description is fairly complete. It explains the required fields, the batch size limit, the asynchronous nature via task_id, and the need to look up category-specific attributes. It does not cover error codes or response details, but for a tool that returns a task ID, 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?
The input schema covers 100% of parameters, so baseline is 3. The description adds value by explaining that attributes list depends on the category and referencing external documentation. It also clarifies that images are URLs and the first is main. This extra context improves 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 tool creates one or more new products on Ozon, with a maximum of 100 per request. It lists all required fields and distinguishes itself from update, archive, and other product tools. The action, resource, and constraints are 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 create new products) and provides a follow-up action (check import status with another endpoint). However, it does not explicitly state when not to use it or mention alternatives like update_product for existing items. The context from sibling tools helps, but explicit guidance would be better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It indicates a read operation ('Get full information') which is safe, but omits details like authentication needs, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no wasted words, clearly front-loaded with the action and then listing return fields and identifiers.
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 no output schema, the description covers what is returned (fields list) and how to identify the product, making it complete for its purpose.
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 value by explaining the relationship: 'Provide either product_id, offer_id, or sku'—clarifying that these are alternative identifiers and at least one is needed, which is not explicit 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 'Get full information about a single product' with a specific verb and resource, and distinguishes from sibling tools like list_products, create_product, etc. The phrase 'Provide either product_id, offer_id, or sku' further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (use for single product details, not for listing), but there is no explicit guidance on when to use this versus alternatives like list_products or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses stricter rate limits as a behavioral trait, which is valuable. However, it does not explicitly state that the operation is read-only, have no side effects, or describe authentication requirements. The rate limit warning partially compensates for missing 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 three sentences that cover purpose, rate limits, and parameter usage. It is generally concise, though the last sentence could be slightly tightened. The critical information is front-loaded in the first sentence, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 parameters, no output schema, no annotations), the description provides necessary context: purpose, rate limits, parameter defaults, and source of SKUs. It does not describe response structure or pagination details, but the schema covers limit/offset. Overall, it is adequately complete for an API tool in a known context.
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%, giving a baseline of 3. The description adds value by explaining the warehouse_type default, specifying how to obtain SKUs (from get_stocks or list_products), and clarifying that skus is required with at least one item. This extra context improves understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed stock information for products in Ozon warehouses (FBO) and lists specific data points (free-to-sell, reserved, promised quantities, turnover data). This specific verb+resource combination effectively distinguishes it from sibling tools like get_stocks or list_products.
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 sparingly due to stricter rate limits and directs the agent to use get_stocks or list_products to obtain SKUs before calling this endpoint. It also clarifies the warehouse_type parameter with default value. While it doesn't explicitly state when not to use this tool versus alternatives, the guidance 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?
No annotations are provided, so the description must explain behavior. It describes the output but does not state whether the tool is read-only or has side effects. Since it's a report, read-only is implied, but explicit disclosure would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, concise, and front-loaded with the main purpose. Every sentence adds value: the first explains what the tool does, and the second provides context and a date format reminder. No redundant or missing 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 simple tool with no output schema, the description lists the key fields in the output (total orders, returns, commission, etc.), which is sufficient for an agent to understand what it returns. It does not describe pagination or error cases, but these are not critical for a basic report 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% with descriptions for all parameters. The description adds value by specifying the date format ('YYYY-MM-DD'), which is not in the parameter descriptions. This helps the agent use the correct format. The 'with_details' parameter is not mentioned in the description, but that is covered by 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 retrieves a cash flow statement for a period, listing specific metrics like total orders, returns, commission, etc. It also gives an example usage ('how much did I earn this month') and distinguishes itself from sibling tools which are for products, orders, and other non-finance operations.
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 'Great for quick financial overview' and provides a usage example, indicating when to use this tool. However, it does not mention when not to use it or suggest alternatives, though no alternative finance report tools exist among siblings.
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 return fields and filtering/pagination behavior, implying a read-only operation. However, with no annotations, it could be more explicit about non-destructive 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?
Two sentences, first lists what prices are returned, second covers filtering and pagination. No extraneous text, 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?
Covers purpose, return data, filtering, and pagination. Missing details like default sorting or error conditions, but sufficient for a getter tool with 5 params 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?
Adds context beyond schema by listing returned price fields and explaining price index concept. Schema already covers all parameter descriptions, so baseline 3 plus value from response context.
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 gets current prices for products and lists specific price fields (selling price, old price, marketing price, etc.), distinguishing it from sibling tools like update_prices or get_product.
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?
Implies usage for price retrieval but does not explicitly say when to use this tool vs alternatives like update_prices or get_product. No exclusions or alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explains parameter defaults and key meanings, but does not mention pagination, time range, rate limits, or return structure, which are relevant for a history tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4-5 sentences), front-loaded with purpose, and includes a structured list of keys. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description lacks details on the return format (e.g., time granularity, fields). It adequately covers the parameter but leaves uncertainty about the history structure.
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?
Despite 100% schema coverage, the description adds significant value by listing all rating keys with human-readable explanations (e.g., 'product reviews', 'shipment delays'), improving understanding beyond the enum values.
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 retrieves 'history of seller rating (quality index) changes over time', distinguishing it from get_seller_rating which likely provides current rating. The purpose is 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use ('tracking rating trends and diagnosing drops') and explains default vs. filtered behavior. It does not explicitly exclude use cases or name 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?
Describes that it returns order details including products, quantities, and financial data. No annotations provided, so description carries burden; it adequately conveys a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences covering purpose, filters, and output. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose and filters. Could mention pagination behavior but schema already handles limit/offset. No output schema, so description gives a good overview.
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 description adds little beyond schema. Lists statuses and notes date range is required, which is helpful but not extensive new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists FBO orders fulfilled by Ozon warehouse, with date range filtering and optional status filter. Distinguishes from siblings like list_fbs_orders and get_fbo_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies required date range and optional status filter. Does not explicitly state when not to use or name alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description partially covers behavior (what is returned, filtering), but omits pagination, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, then filtering details and constraint; 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 main purpose, returned fields, filtering options, and constraint. Lacks explicit pagination explanation but adequate for 8-param tool without 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 covers all params (baseline 3); description adds context on what each filter is for ('logistic return date range') and constraint on time filters, plus explains returned fields.
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 action (list) and resource (product returns for FBS orders), distinguishing from list_fbo_returns for FBO orders.
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 filtering options and constraint on time filters, but does not explicitly compare to siblings like list_fbo_returns.
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 archived products are not visible to buyers but preserved and restorable. Without annotations, it covers the key behavioral trait. Could mention if it affects existing orders or listings, but not critical for this action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with core action, no fluff. 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?
Tool is simple (one param, no output schema). Description covers main functionality, restoration pointer, and usage. Minor gap: no mention of rate limits or auth, but not essential for this straightforward 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% for the single parameter. Description restates the schema's purpose ('array of product_ids') without adding new semantic detail. 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?
Clearly states it hides/archives products from Ozon storefront, distinguishing from unarchive_product. Verb 'archive' is specific and resource-oriented.
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 (to hide products) and when not (use unarchive_product to restore). Also provides instruction to provide an array of product_ids.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses date format requirements, lists available metrics and dimensions, and notes the 1:1 index correspondence in the response. It does not mention authentication or rate limits, but these are not critical for a read-only analytics tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive: a clear purpose sentence, example questions, enumerated lists of options, date format note, and response structure note. Every sentence earns its place 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?
The tool has 8 parameters (4 required) and no output schema. The description covers the main functionality, response format, and parameter options well. It could mention sorting/pagination defaults, but these are documented in the schema. Overall it is thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value by enumerating and contextualizing metrics and dimensions (e.g., explaining 'hits_view_search' as search impressions) and specifying date format. This goes beyond the schema's enum lists.
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 'Get sales analytics for a date range' and provides specific example questions (e.g., 'show revenue for last week', 'top 10 products by orders'). It distinguishes this tool from sibling tools which are mostly CRUD operations on products/orders/warehouses, making the analytics purpose unique.
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 it: 'use it to answer questions like ...' and implies it is for analytics queries. It does not explicitly exclude scenarios or mention alternatives, but the context is clear given the 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?
No annotations, so description carries full burden. Discloses that it returns orders in 'awaiting_packaging' or similar states, and defaults cutoff to current calendar month. Could mention read-only nature, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main purpose. Every sentence adds distinct 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 key aspects: states, filters, defaults. No output schema, so description adequately informs what the tool returns. Minor gaps like sort default not mentioned, but 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% (baseline 3). Description adds value by explaining filter options and default behavior for cutoff dates, going 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 'Get the list of FBS orders that are waiting to be processed and shipped' – specific verb, resource, and scope. Distinguishes from siblings like 'list_fbs_orders' by focusing on awaiting orders.
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 this to see what needs to be packed and dispatched today' – clear context. Optional filters mentioned but no explicit when-not-to-use or alternatives listed, though 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?
No annotations, so description bears full burden. It discloses performance characteristic (faster) and date format requirement. Does not mention authorization or side effects, but the tool is read-only aggregation. Lacks details on error handling or data scope.
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 output, second provides usage context and date format. No redundancy, every word 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?
No output schema, but description lists returned fields (orders amount, returns, etc.). Also covers date format requirement. Could mention that result is a single aggregate, but not essential. Complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions. Description reinforces ISO 8601 for dates but adds no new meaning beyond schema. Baseline 3 is appropriate as schema is rich.
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 gets summary totals for transactions in a period, listing specific metrics (orders, returns, etc.). Distinguishes from sibling 'list_transactions' by noting it's faster and for bottom-line needs.
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 over list_transactions ('when you only need the bottom line') and provides date format requirement (ISO 8601). Implicitly says not for detailed transaction listing.
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 key behavioral traits: returns product_id and offer_id, supports pagination via last_id, and allows filtering by visibility. Since no annotations are provided, the description carries the full burden, and it does so adequately for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences. The first sentence captures the primary purpose, and the second adds essential details on filters and pagination. 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 has 5 parameters, no output schema, and no annotations, the description adequately covers the main functionality: listing, filtering, pagination, and return fields. It is complete enough 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 description coverage, the baseline is 3. The description adds value by explaining the visibility enum values and the role of last_id for pagination, which goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (products in Ozon seller account). It distinguishes from sibling tools like get_product, archive_product, etc., as it covers a general listing with optional filters.
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 it (listing products with optional visibility filters and pagination). While it doesn't explicitly say when not to use it, the context from sibling tools (e.g., get_product for a single product) provides implicit 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?
With no annotations, description carries full burden. It discloses return values (overall score, status, breakdown) and confirms no parameters. Could mention data freshness or update frequency but adequate for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. Front-loads purpose and return details, followed by usage guidance. Perfectly concise.
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, no output schema, and low complexity, the description covers all essential aspects: what it does, what it returns, when to use it.
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 coverage is 100%. Description correctly states 'No parameters required.' Baseline 4 for zero 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?
Description clearly states verb 'Get' and resource 'seller quality index (rating)' on Ozon. It distinguishes from siblings like get_seller_rating_history (historical data) and get_seller_info (profile info).
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 this for monitoring — alert when rating drops below a threshold.' Provides a clear use case; does not explicitly exclude alternatives but sufficient given no ambiguity.
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?
Despite no annotations, the description discloses key behavioral traits: it updates only attributes (not price/stock), existing attributes cannot be deleted, the update is asynchronous (returns task_id), and identification can be via product_id or offer_id. No contradictions with annotations since none are provided.
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 core purpose, followed by important caveats and async behavior. It is concise, with only necessary details. Could be slightly more streamlined, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value (task_id) and async nature. It covers identification methods and constraints. However, it does not address error cases or behavior when both product_id and offer_id are provided or omitted (no required params). Still, it provides sufficient context for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description adds meaning by explaining that 'attributes' are for product characteristics, that product identification options are flexible, and that the return is a task_id for async processing. This adds context 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 updates product attributes/characteristics, using specific verbs and resources. It distinguishes from siblings by noting that price and stock updates are handled by separate tools (update_prices, update_stocks).
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 advises against using this tool for price/stock updates, directing to alternatives. It also mentions that existing attributes cannot be deleted, only added or changed. However, it does not explicitly state when to use this tool over other product-related siblings like get_product or create_product.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It adequately indicates a non-destructive read operation ('Get information') and implies authentication context, though it doesn't detail rate limits or specific error behaviors.
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 succinct sentences: first states function, second adds verification purpose, third advises order of operations. No superfluous text.
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 parameters and no output schema, the description sufficiently covers purpose, usage, and behavioral context for a simple status/verification tool, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema provides no information beyond their absence. The description adds meaningful context about what the tool returns and its purpose, fully compensating for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves seller account info (shop name, company ID, account status) and distinguishes it from sibling tools by focusing on account verification rather than product or order management.
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 verify credentials) and recommends calling it first to confirm connection, providing clear guidance on its role as an initialization step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![mcp-ozon-seller MCP server](https://glama.ai/mcp/servers/woyaxnini/mcp-ozon-seller/badges/card.svg)](https://glama.ai/mcp/servers/woyaxnini/mcp-ozon-seller)

Score Badge

Copy to your README.md:

[![mcp-ozon-seller MCP server](https://glama.ai/mcp/servers/woyaxnini/mcp-ozon-seller/badges/score.svg)](https://glama.ai/mcp/servers/woyaxnini/mcp-ozon-seller)

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/woyaxnini/mcp-ozon-seller'

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