ozon-mcp

by PCDCK

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.6.0
Disambiguation5/5
Every tool has a distinct, well-defined purpose with no overlap. For example, ozon_call_method executes API calls, ozon_describe_method provides metadata, ozon_fetch_all handles pagination, and ozon_search_methods performs search—each serves a unique function in the API interaction workflow.
Naming Consistency5/5
All tools follow a consistent 'ozon_verb_noun' naming pattern (e.g., ozon_call_method, ozon_describe_method, ozon_fetch_all). The structure is uniform throughout, using snake_case and starting with 'ozon_' as a prefix, making the set predictable and easy to navigate.
Tool Count5/5
With 15 tools, the server is well-scoped for its purpose of interacting with the Ozon API. The tools cover a comprehensive range from core operations (call, describe, fetch) to support functions (error lookup, rate limits, workflows), each adding clear value without redundancy.
Completeness5/5
The toolset provides complete coverage for API interaction, including execution, description, pagination, error handling, rate limits, subscription management, search, and workflow guidance. There are no apparent gaps; agents can perform all necessary tasks from discovery to execution and troubleshooting.
Average 4.4/5 across 15 of 15 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 17, 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?
No annotations are provided, so the description must convey behavioral traits. It states the examples are real, validated, and hand-crafted, but does not explicitly mention that the operation is read-only or discuss side effects, authorization, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema (as per context signals), the description adequately covers the tool's purpose and the nature of the output. Minor gap: no mention of error handling for invalid operation_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, operation_id, is not explained in the description (e.g., its format or how to obtain it). Schema description coverage is 0%, and the description fails 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 the tool retrieves hand-crafted request examples for one method, using a specific verb and resource, and is distinct from sibling tools like ozon_call_method or ozon_describe_method.
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 (copy examples as starting points) but does not explicitly state when to use this tool versus alternatives, nor does it mention 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does not disclose behavioral traits beyond the basic function, such as read-only nature, authentication requirements, pagination, or potential side effects. This is a significant gap for a tool that likely performs 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?
The description is extremely concise: two sentences with an example list under 'Args'. Every sentence adds value, and the most critical information (verb, resource, input) is front-loaded. 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?
The tool is simple (one parameter, no nested objects) and has an output schema, so the description doesn't need to detail return values. However, it lacks usage guidance and behavioral transparency, which slightly reduces completeness. For its complexity, it is mostly adequate.
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 explains the single parameter 'query' as 'section name or tag', providing concrete examples like 'FinanceAPI', 'Финансовые отчёты', 'ProductAPI'. This adds significant meaning beyond the input schema, which only has a type 'string' with no description, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'List all methods inside a section (by section name or tag).' It specifies the verb 'List', the resource 'methods inside a section', and the input mode 'by section name or tag', which distinguishes it from sibling tools like ozon_list_sections that list sections, and ozon_search_methods that search across all methods.
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 that the tool is used when you have a section name or tag to retrieve its methods, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., ozon_search_methods, ozon_describe_method). It lacks 'when-to-use', 'when-not-to-use', or referral to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the search algorithm and language support, which is useful. However, with no annotations provided, it fails to explicitly state that this is a read-only operation with no side effects. It also does not describe the output format or pagination behavior, which are important for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise first paragraph stating purpose and search details, followed by a bullet list for parameters. It is front-loaded with the most important information. Slightly verbose in the first paragraph (algorithm details could be condensed), but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 1 required) and the presence of an output schema, the description covers purpose, search algorithm, and parameter details. It could be enhanced by clarifying the output structure (e.g., returns ranked list of methods with scores), but the output schema likely fills this gap. The description is sufficiently complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It provides clear explanations with examples for each parameter: query (free-text with examples), section (case-insensitive substring match), api (allowed values 'seller'/'performance'), safety (allowed values 'read'/'write'/'destructive'), and limit (default 10). This adds significant meaning beyond the schema's bare names and types.
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 'Full-text search across all Ozon API methods', specifies the fields searched (operation_id, path, summary, description, section, tag), and details the ranking algorithm (BM25 with field boosting) and language support (Russian/English stemming). This distinguishes it from sibling tools that describe single methods or list sections.
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 finding API methods via free-text queries, but it does not explicitly state when to use this tool versus alternatives like ozon_describe_method or ozon_list_sections. No guidance on when not to use it or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses that many limits are conservative guesses (source: 'guess') and advises verification in production. It also explains the override hierarchy. This provides important behavioral context beyond the basic function.
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 five sentences that efficiently convey purpose, default behavior, argument-specific behavior, and a critical caveat. No extraneous 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 low complexity (2 optional parameters, output schema exists), the description adequately covers the key aspects: default behavior, override logic, and data quality warning. It does not mention potential errors or rate limit format, but the output schema likely covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add parameter meaning. It explains that without arguments returns all limits, and with operation_id returns specific limits, implying operation_id's role. However, it does not explicitly describe the 'section' parameter, leaving its purpose somewhat ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Look up rate limits for a method, section, or the whole API.' The verb 'look up' and resource 'rate limits' are specific, and the tool is distinct from siblings like ozon_call_method or ozon_describe_method.
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 behavior without arguments (returns all limits) and with operation_id (returns most specific limit via override hierarchy). It also includes a caution about conservative guesses and advising verification in production, guiding appropriate use. However, it does not explicitly mention when to use section vs operation_id or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the tier filter is auto-extracted and may not match actual 403 sets, which adds transparency. However, it does not mention read-only nature, authentication needs, or rate limits, though these are partially implied by the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs, front-loading the purpose. The docstring-style argument list is clear. Minor redundancy in the example use cases but overall efficient.
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 presence of an output schema and the simplicity of the tool (single parameter), the description is complete. It covers purpose, usage scenario, parameter constraints, and a caveat about accuracy. No further details are 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 description coverage is 0%, so the description must explain the parameter. It lists the five possible values for 'tier', which adds meaning beyond the schema's type definition. It could further explain what each tier represents, but the list is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all Ozon methods that mention a specific subscription tier,' providing a specific verb and resource. It distinguishes from siblings like ozon_get_subscription_status and ozon_search_methods by filtering by tier.
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 explicit use cases ('want to know what extra capabilities do I unlock by upgrading?') and notes the limitation that it's a hint, not a contract. It lacks explicit when-not-to-use or alternatives, but the guidance 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, description carries full burden. It describes output structure and grouping, but lacks details on rate limits, pagination, or any potential side effects. Adequate for a simple read-only list.
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, usage hint, return format. Front-loaded, no wasted words, 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?
Given no parameters and presence of output schema, description fully explains the tool's function and return details. Could mention how to use output with other tools, but not necessary.
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; baseline 4 applies. Description compensates by detailing the output structure beyond the empty 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 'List all Ozon API sections (Seller + Performance) with method counts,' specifying the resource and action. Distinguishes from siblings like ozon_get_section.
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 first to orient yourself in the API,' providing clear context for when to use it. Does not explicitly exclude alternatives but implies initial orientation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It details pagination walking, rate limit enforcement, safety cap, and return format. The reference to an external knowledge file adds context, though the agent may need to resolve it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections (Args, Returns) and essential details. It is slightly dense in the first paragraph but overall efficient and front-loaded with the main 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 the tool's complexity (pagination handling) and the presence of an output schema, the description covers argument semantics, return structure, and safety mechanisms. It could include a simple example but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It thoroughly explains each parameter: operation_id (same as call method), params (without pagination fields), max_items (range), and cabinet_tier (override). This is far beyond the bare 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 fetches all pages of a paginated Ozon endpoint, using a specific verb and resource. It distinguishes from sibling tools like ozon_call_method by explicit mention of pagination walking.
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 this tool (for paginated endpoints) and provides constraints like max_items and ownership of pagination fields. It mentions rate limits but lacks explicit when-not-to-use guidance or alternatives beyond the implied comparison to ozon_call_method.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency. It explains the tool is read-only (lookup) and describes filtering behavior. It does not mention any side effects, rate limits, or authentication needs, but for a pure lookup tool, this is adequate. A 5 would require explicit statement of non-destructiveness or safety.
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 purpose. Each sentence adds essential information without fluff. The structure is clear: purpose first, then argument modes. 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 presence of an output schema (not shown but indicated), the description does not need to detail return values. It covers the main functionality and argument usage. It could mention behavior for invalid codes or empty results, but overall it is sufficiently complete for a lookup 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?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains both parameters: 'code' filters by error code (with examples like '429'), and 'operation_id' returns errors specific to that method plus generic ones. This adds significant meaning beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to look up Ozon API errors and their solutions. It distinguishes itself from sibling tools (e.g., ozon_describe_method, ozon_get_rate_limits) by focusing on error catalog lookup. The verb 'look up' is specific, and the resource is clearly the error catalog.
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 each argument combination: without arguments returns all errors, with code filters by code, with operation_id returns method-specific plus generic errors. However, it does not explicitly mention when not to use this tool or suggest alternative tools (e.g., ozon_describe_method might also show errors), which would elevate it to a 5.
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 caching (per process, refreshable, errors never cached) and credential requirement. No annotations exist so description carries burden. Lacks mention of idempotency or rate limits, but acceptable for a read-only 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?
Four concise sentences, front-loaded with main purpose, no redundant words. Each sentence adds distinct 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 (1 param, no required ones) and has output schema. Description covers purpose, input, caching, prerequisite, and output content. Complete for reliable agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description explains the sole parameter 'refresh': 'pass refresh=True to bypass cache'. Adds practical meaning beyond schema's default.
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 'get' and resource 'subscription tier' from a specific endpoint. Specifies return values (type, is_premium flag, list of methods). Distinguishes from sibling tools like ozon_list_methods_for_subscription.
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: prerequisite (seller credentials), caching behavior, and refresh bypass. Does not explicitly exclude scenarios or compare with alternatives, but sufficient for most 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?
With no annotations, the description carries the burden. It discloses the output (metadata or an error if missing) and implies no side effects. It does not explicitly mention idempotency or rate limits, but for a metadata retrieval tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, followed by bullet-pointed use cases. Every sentence adds 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?
Given zero parameters and a simple output, the description fully covers the tool's behavior, including the error condition. The existence of an output schema further reduces the need to describe return values in detail.
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 no parameters, and the schema coverage is trivially 100%. The description adds no parameter info since none exist. According to the rule, 0 parameters earns a baseline of 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 metadata about bundled Ozon swagger snapshots, specifying what it returns (spec version, method count, timestamp, SHA-256) and the error case. It distinguishes itself from sibling tools that handle method calls, descriptions, 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?
The description provides explicit use cases: for agents checking docs, operators validating refreshes, and bug reports. It gives clear context but does not include when-not-to-use or direct 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?
No annotations provided. Description discloses return structure: ordered steps, operation_ids, pagination/batching/concurrency guidance, DB schema, gotchas, and for analytical workflows additional fields. Does not mention authentication or rate limits, but conveys key behavioral aspects for a read-only 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?
Well-structured: opening statement, bullet-like list of return content, and Args section. Approximately 60 words, front-loaded, no redundant sentences.
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 existence of an output schema (not shown), the description covers return values sufficiently: ordered steps, guidance, DB schema, gotchas, and additional fields for analytical workflows. No apparent 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?
Single parameter 'name' has 0% schema description coverage. Description adds meaning with 'workflow name from ozon_list_workflows' and examples. This guides the agent on valid values, compensating for lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get the full step-by-step plan for one workflow.' Specifies the resource (workflow) and action (get). Differentiates from siblings like ozon_list_workflows and others that handle different resources.
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 an Args section with example workflow names, implying use after listing. Mentions analytical workflows have extra fields. Lacks explicit when-not or alternative tool references, but context from siblings and examples guides 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?
With no annotations, the description details that relations are auto-extracted from doc links and workflows and that both forward and backward links are returned. The max_hops parameter behavior is described. This is good transparency, though no mention of caching or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short paragraphs and an args block. It is front-loaded with the main purpose, uses clear language, and 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 presence of an output schema, the description covers purpose, parameter details, and use case adequately. No additional context is needed for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates. It explains operation_id as 'source method' and max_hops with explicit meaning: '1 = direct neighbours, 2 = neighbours of neighbours', adding significant 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 'Find methods related to a given one' and identifies the resource as methods derived from doc links and workflows. It distinguishes itself from siblings like ozon_search_methods and ozon_describe_method by focusing on relational links.
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 usefulness for integration ('which calls you'll likely need together when integrating a feature'), providing clear context. It does not explicitly state when not to use or name alternatives, but the intent is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that $ref pointers are inlined, combinators preserved, and when knowledge layer is loaded adds rate_limit, quirks, examples, related methods. Effectively communicates behavior and output characteristics.
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?
Seven sentences, front-loaded with purpose. Every sentence adds value, no redundancy. Clear structure with parameter guidance and output details.
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 existence of output schema, description does not need to detail return values but still mentions key content. Covers input, output, and conditional behavior (knowledge layer). Complete for tool discovery and 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?
Schema has 0% description coverage, so description compensates by explaining preferred parameter (operation_id), alternative (path + optional http_method), and that at least one should be provided. Adds meaning beyond schema structure.
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 a complete description of one Ozon API method' with specific details about return content (metadata, resolved JSON Schema, etc.). Distinct from sibling tools like ozon_call_method and ozon_search_methods.
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 guidance on parameter selection: 'Provide either operation_id (preferred) OR path (+ optional http_method).' Lacks explicit 'when not to use' or comparison with alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the tool lists workflows, optionally filtered, and clarifies that categories in response always lists all values present. It's a read operation and no destructive actions are implied, but it doesn't mention auth or rate limits, which is acceptable for this context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main sentence, a context paragraph about workflows, and an Args section. It is concise with about 80 words, though slightly verbose but still efficient.
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 an output schema, the description does not need to explain return values. It adequately covers purpose, usage, parameter semantics, and relationship to sibling tools, making it complete for a lightweight list 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 goes significantly beyond the input schema by explaining the 'category' filter, listing all valid values (catalog, orders, analytics, etc.), and noting that response categories always list every value present. This adds essential meaning that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists curated workflows, optionally filtered by category. It distinguishes itself from the sibling tool ozon_get_workflow, which fetches a full plan for a specific workflow.
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 explicitly tells when to use this tool vs alternative: 'Use ozon_get_workflow to fetch the full plan for a specific workflow.' This provides clear guidance on selecting the right 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?
With no annotations provided, the description carries full burden. It fully discloses the safety model, subscription gate, rate limit handling (retries with Retry-After, semaphore for slow endpoints), and error envelope. This goes well beyond what structured fields would 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 well-structured with clear section headers (SAFETY MODEL, SUBSCRIPTION GATE, RATE LIMITS). It is appropriately sized—each sentence adds value, no fluff. It is front-loaded with the core 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?
Given the tool's complexity (5 parameters, safety flags, subscription, rate limits), the description covers all behavioral aspects comprehensively. It explains what happens on failure (structured OzonError). Since there is an output schema, return value details are not needed. Complete for an execution 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?
Schema coverage is 0%, so description must compensate. It explains confirm_write and i_understand_this_modifies_data in the context of safety classes, cabinet_tier as an override, operation_id with an example, and params as the request body. This adds critical meaning beyond the schema's type/default 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 executes real calls against the Ozon API, using a specific verb ('Execute') and resource ('Ozon API'). It distinguishes itself from sibling tools like ozon_describe_method (which describes methods) by focusing on execution.
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 safety flags (confirm_write, i_understand_this_modifies_data) based on the method's safety class, and mentions subscription gate and rate limits. However, it does not explicitly state when not to use the tool or suggest alternatives, though the context implies that for description or listing, other siblings should be used.
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:

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

Score Badge

Copy to your README.md:

[![ozon-mcp MCP server](https://glama.ai/mcp/servers/PCDCK/ozon-mcp/badges/score.svg)](https://glama.ai/mcp/servers/PCDCK/ozon-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/PCDCK/ozon-mcp'

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