Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses important behavior: the key enters the chat transcript, persistence location (~/.marketplace-mcp/cabinets.json), file permissions (chmod 600), the 'never echoed' guarantee, and the default-name fallback behavior. This is rich, non-obvious context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the tool's purpose and critical safety caveat, then organized into clear argument definitions. The formatting is scannable and every sentence adds information needed to invoke the tool correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a credential-storing operation, the description covers purpose, safety risks, parameters, storage location, and side effects. The output schema exists separately, so return values need not be described here. Nothing essential is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full parameter burden. It explains the expected credentials dict format for both Ozon and WB, the optional name behavior, and the required safety flag. This goes well beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Add or update a cabinet') and clarifies the resource: a named set of API credentials. The 'from chat' context and the credential examples make the tool's role unmistakable even among many sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly explains when this tool is appropriate ('from chat') and warns that the key becomes part of the conversation. It also names the safer alternative (install.py / double-click installer) for cases where the key should not enter chat.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's 'Reads only: nothing here changes data, so it runs without confirmation' reinforces but also adds the operational consequence (no confirmation). It also discloses the return envelope shape ('Returns JSON: {"ok": true, "status", "data"} or the error envelope'), which is useful beyond the annotations. Minor gap: no mention of rate limits or auth requirements, but the read-only safety profile is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: the core action and target API come first, then the read-only safety note, then sibling routing, then parameter explanations, then return format. Every sentence earns its place with no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 params, 0% schema coverage, no enums) and the presence of an output schema, the description covers the essential usage context: what the tool does, how to find operation_ids, how to route to write/delete alternatives, and what the return envelope looks like. It could mention auth prerequisites or rate limits, but the read-only nature and clear parameter guidance make it largely complete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains operation_id as 'id from the catalog (see ozon_search_methods)', path_values as 'values for {placeholders} in the path', query as 'query-string parameters', and body as 'JSON request body (a few read endpoints take one)'. This adds meaning beyond the bare schema titles, though it could be more detailed about the exact format of path_values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Execute') and resource ('one READ endpoint from the catalog by operation_id'), and explicitly contrasts with write/delete siblings. It also names the target API. This clearly distinguishes it from the many sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool ('Reads only') and when not to ('To change data use ozon_write_method, to delete use ozon_delete_method'). It also points to ozon_search_methods for finding operation_ids, giving clear routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, but the description adds valuable safety context beyond that: it explicitly states that secret values are NOT revealed and only variable presence is reported. This helps the agent avoid mishandling sensitive data and matches the read-only annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, purposeful sentences: the core purpose, a critical safety caveat, and the exact return shape. No filler or repetition; information is front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity—no parameters, read-only annotations, and explicit return JSON in the description—the definition fully covers what the agent needs to call and interpret the tool. Nothing important is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is nothing for the description to clarify. The schema is effectively complete at 100% coverage, and the description's mention of the missing/required arrays provides useful context for interpreting results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: 'Check whether the required credentials are present in the environment.' This clearly differentiates it from sibling tools that perform data operations or key management, since no other sibling is an auth-check diagnostic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is implied: call this tool to verify credential presence before attempting authenticated Ozon operations. However, the description never explicitly says 'use before other Ozon tools' and does not mention alternatives or exclusions, leaving the timing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (destructiveHint=true, readOnlyHint=false), the description discloses irreversibility, the hard requirement that nothing is sent unless both confirm flags are true, and the return envelope. This is meaningful behavioral safety context. It doesn't cover auth/rate limits but annotations already cover the 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and the critical safety constraint before the args list. There is a small redundancy between the early warning about required flags and their repeated 'must be true' in Args, but no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a dynamic destructive endpoint tool, the description provides enough to call it: target API, source of operation_id, required confirmations, parameter meanings, and response shape. It references an output schema and API docs, so remaining endpoint-specific details are discoverable via the catalog.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by assigning a meaning to every parameter: operation_id from catalog, path_values for placeholders, query as query-string params, body as JSON, and the two booleans must be true. It could go deeper on body construction, but it adds value over the schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a destructive executor for catalog endpoints ('Execute one DESTRUCTIVE endpoint: deletes or irreversibly changes data') and points to the Ozon seller API. It does not explicitly contrast with sibling tools such as ozon_delete_raw or ozon_call_method, so not a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies usage for destructive endpoints and instructs the agent to get operation_id from ozon_search_methods, and it states the two confirmation flags are mandatory. It gives no explicit when-not-to-use or alternative-tool guidance, so it falls between clear context and implied usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's warning about modifying data is consistent. The description adds valuable context beyond annotations: it warns that paths not in the catalog can be deleted, requires explicit confirmation flags, and specifies the return envelope. It could go further by noting irreversibility or auth requirements, but it is already transparent about the 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the most important warning ('Delete data at ANY path'). The Args list is terse and useful. It loses one point because the return-format line is slightly vague ('or the error envelope') and could be more explicit, but overall every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive raw HTTP tool with 7 parameters and no schema descriptions, the description covers the critical context: what it deletes, the required confirmations, the target API, and the return shape. It doesn't mention authentication prerequisites or rate limits, but the sibling context (ozon_check_auth, ozon_use_cabinet) implies auth is handled elsewhere. This is nearly complete for the tool's purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 does: it explains path ('full path beginning with '/''), method ('DELETE'), host ('host override'), query, body, and the two confirmation booleans. It doesn't detail the error envelope structure, but it names it. This is strong compensation for a schema with no descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Delete') and resource ('data at ANY path, including paths not in the catalog'), which clearly distinguishes it from sibling tools like ozon_delete_method or ozon_get_raw. It also names the target API and the HTTP method, leaving no ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'DELETE only' and states that both confirm_write=true and i_understand_this_modifies_data=true are required. It also implies this is the raw/destructive variant among siblings, and the 'ANY path' warning tells the agent when to use it (low-level deletion) versus safer alternatives. This is strong usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already establishes that this is a safe read operation, and the description is consistent with it. The description adds useful behavioral context by specifying exactly what the catalog record contains, including safety level, pagination style, and rate limit. No contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that starts with the action and object, then compactly lists the returned fields. Every word earns its place, and there is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one required parameter, a readOnlyHint annotation, and an output schema, the description is nearly complete. The only meaningful gap is that it does not point the agent to a source for valid operation_id values, but this is a minor omission for such a simple metadata lookup tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 for the operation_id parameter. It only says 'one endpoint,' which loosely implies that operation_id selects an endpoint, but it does not explain the parameter's format, valid values, or that the ID comes from catalog tools like ozon_map or ozon_search_methods.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Return') and a clear resource ('the full catalog record for one endpoint'), then enumerates the record contents: method, host, path, scope, safety level, pagination style, rate limit, params, and doc URL. This sharply distinguishes it from sibling tools like search_methods, map, and call_method.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance about when to use this tool versus ozon_search_methods, ozon_map, ozon_call_method, or the describe_method equivalents for other markets. Usage is only implied by the word 'describe,' and there are no when-not-to-use or alternative conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=true, so the safety profile is covered. The description adds substantial behavioral detail: it handles multiple pagination styles, automatically detects the array path, manages cursor fields, enforces a max_items cap to protect context, and returns a structured result with a 'truncated' flag. This gives the agent a clear model of what will happen during execution.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: a one-sentence purpose, a brief pagination-support note, then a clean Args list and return shape. There is no filler, and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 7 parameters, the description provides enough operational detail to invoke it correctly: purpose, pagination behavior, parameter roles, defaults, and return envelope. Since an output schema exists, return values are even less burdensome. It omits explicit error-handling and rate-limit expectations, but these are outweighed by the strong parameter and behavior coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden for clarifying parameters. The Args section meaningfully explains operation_id, query/body/path_values as base parameters with cursor fields managed, items_path as an override, limit as page size, and max_items as a hard cap. It covers all parameters, though query/body/path_values are grouped and could be more granular about how each is used.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Auto-paginate a read endpoint and return every row in one response,' which names a specific action, resource, and scope. It clearly distinguishes itself from sibling single-call tools like ozon_call_method by emphasizing automatic pagination across all rows and by listing supported pagination styles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the use case clear: use this when you need all rows from a read endpoint, rather than making manual paginated calls. It also states that cursor fields are managed, so callers should not pass them. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of fully explicit routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and openWorldHint=true, so the description's claim of listing data is consistent)Skip. The description does not add much beyond the annotation: it notes the 'new/unprocessed' status and the response format, but doesn't detail auth requirements or quirks. With annotations covering safety, a 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the purpose. It includes a brief Args section and a one-line return format. Some redundancy exists with schema (e.g., limit/offset names), but the docstring format is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Has an output schema which reduces need to explain return values, but parameter semantics are incomplete. For a data-retrieval tool, missing pagination details (like limit range) and lack of prerequisites (e.g., auth) mean the agent may not invoke correctly. Overall, moderate completeness for a read-only, simple listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain parameters. It explains cutoff_from/to as datetime bounds but does not describe limit and offset beyond names. It suggests pagination but lacks details on defaults or ranges. This is inadequate given 4 parameters and zero schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists new/unprocessed FBS shipments awaiting assembly, which is specific and distinct from siblings like wb_get_new_orders or ym_get_orders. It uses a specific verb (list) and resource (FBS shipments).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for filtering unfulfilled FBS orders by date range, but does not explicitly state when to use this versus other tools, nor when not to use it. It provides no alternatives or conditions for choosing a different tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds useful behavioral detail: it returns a JSON payload with specific fields (price, marketing_seller_price, commissions) and states that the cursor is for pagination from a previous response. No side effects or failure modes are disclosed, but those are largely covered by the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely compact and well-ordered: core purpose with endpoint first, then parameter list, then return payload. Zero filler, zero repetition, and the pagination cursor note is meaningfully placed near the parameter it describes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only paginated endpoint, the description is nearly complete: it specifies the resource, the three parameters, and the return shape. The presence of an output schema reduces the need to enumerate response fields further. Minor gap: it doesn't explain when pagination would be necessary or how many results come back per page, but that's not critical for a simple read operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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, and it does: all three parameters (visibility, limit, cursor) get one-line meanings, including defaults ('ALL') and the max page size (1000). It doesn't specify allowed visibility values or the exact cursor format, but it adds real semantic value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and a clear resource ('prices, commissions and price indexes per product') plus the exact API endpoint (v5/product/info/prices). This distinguishes it from platform-level siblings like ym_get_prices or wb_get_pricesable, and from write operations like ozon_set_price. It doesn't explicitly contrast with ozon_get_products, though the resource is clearly different, so it stops just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to choose this tool over alternatives. It does not mention uzation, pagination strategy, or why an agent would call this instead of ozon_get_products or a fetch-all wrapper. The endpoint is stated, but usage context is absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint and openWorldHint. Description adds pagination behavior (cursor-based via last_id) and return structure (JSON with ok, data, items, last_id). No contradiction. Could mention rate limits or error cases but sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: one-line purpose, then succinct parameter descriptions, return format, and cross-page guidance. No redundant sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers essential aspects: purpose, parameters, return format, and pagination. Output schema exists and description complements it. No mention of error handling or rate limits, but acceptable for a read-only list tool. Could add default visibility hint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description carries full burden. It explains all three parameters: visibility with examples, limit with max constraint, and last_id as cursor. Adds meaning beyond schema types and defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List Ozon products (one page)'. The verb 'List' and resource 'Ozon products' are specific, and it distinguishes from siblings by mentioning pagination and cross-page usage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states this tool returns one page, and for multiple pages it recommends using ozon_fetch_all with ozon_product_list. This provides clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, and the description complements this by enforcing safe verbs, explaining the default method, host override, and the JSON response envelope. It adds meaningful context beyond the annotations, though it does not mention authentication prerequisites 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise but complete, front-loading the core purpose and then enumerating each parameter with defaults and examples. Every sentence earns its place. The structured block format is easy to scan and use.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low schema coverage and the tool's generic raw-access nature, the description covers the essential invocation details: endpoint, method, host, query, body, and response envelope. It also names sibling tools for mutation, making the overall context complete for correct selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It clearly describes path with an example, method default, host override, query parameters, and body behavior. This fully compensates for the sparse schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Read ANY endpoint by path,' and explicitly differentiates itself from the write/delete raw siblings. It also clarifies its scope as general raw reads, including catalog-missing endpoints. This makes the tool's purpose unambiguous and distinct from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage rules: 'Safe verbs only (GET, HEAD, OPTIONS)' and directly names alternatives: 'To change data use ozon_write_raw, to delete use ozon_delete_raw.' It also provides the target API URL, so an agent knows exactly where and when this tool applies.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, covering the read-only safety profile. The description adds that the tool returns a JSON list with operation_id, method, path, safety, and summary, but it does not describe edge cases or pagination behavior; this is modest value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a one-line purpose, an Args section, and a Returns section. Every sentence contributes value, and the pointer to ozon_list_sections plus the return shape list are useful without filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read-only lookup, the description covers the required parameter, how to obtain valid section names, and the output shape; an output schema also exists. It could be stronger by explicitly routing against search/describe siblings, but nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single section parameter has 0% schema description coverage, but the description compensates by explaining it is a section name, pointing to ozon_list_sections for valid values, and providing the concrete example 'statistics.' This gives an agent actionable parameter guidance without needing an enum.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description leads with the specific behavior 'List all endpoints in one section,' naming the action and resource precisely. It also separates this from section-listing tools like ozon_list_sections by focusing on endpoints within one section.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage as a section-endpoint enumerator and tells the agent to refer to ozon_list_sections for valid section names, with the example 'statistics.' It does not explicitly compare this tool with alternatives like ozon_search_methods or ozon_describe_method, so exclusion guidance is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnlyHint=true and openWorldHint=true, and the description does not contradict them. It adds useful behavioral context beyond the annotations: the endpoint, the returned per-product and per-warehouse-type breakdown, pagination via last_id, and the limit cap of <=1000.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose, followed by an efficient Args block. Every sentence contributes either the operation, endpoint, parameter semantics, or return shape, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with three optional parameters, an output schema, and read-only annotations, the description covers the endpoint, parameter meanings, constraints, and return shape. It is complete enough to invoke correctly, though it leaves usage-alternative guidance to inference and does not document visibility value options.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates meaningfully by explaining each parameter: visibility is a product visibility filter defaulting to ALL, limit is page size capped at 1000, and last_id is the pagination cursor. It does not enumerate possible visibility values, but it adds real meaning beyond the bare schema names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Get available + reserved stock per product' and names the underlying endpoint v4/product/info/stocks. It clearly differs from product-listing siblings like ozon_get_products, though it does not explicitly name or contrast any sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives such as ozon_get_products or wb_get_stocks. The use case is inferable from the name and purpose, but no when-to-use or when-not-to-use conditions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, so the read-only nature is already disclosed. The description adds no behavior that would surprise an agent (it is a simple retrieval). It does not mention output structure, but the existence of an output schema reduces the need. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus an args listing, all essential. The main purpose is stated upfront, and the parameter reference is placed at the end. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only retrieval tool with an output schema and annotations covering safety, the description is nearly complete. The only minor gap is that it doesn't explicitly state the returned plan is in a structured format, but the output schema covers that. It provides enough for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only one parameter and 0% schema coverage, the description references '{svc}_list_workflows' to indicate where valid values come from, which is helpful but minimal. It does not explain the format or constraints beyond the schema's type string. Baseline 3 is appropriate given the low complexity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action (return the full plan) and resource (one workflow), and describes precisely what the plan contains (ordered steps, interpretation guidance, mistakes). It is easily distinguished from siblings like ozon_list_workflows (which likely lists workflows) and ozon_get_section (which gets a section).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for retrieving a workflow plan, and references its companion list tool for discovering workflow names. It does not explicitly state when not to use it versus, say, ozon_describe_method, but the context is clear that this is for workflow plans, not individual operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds value by specifying the exact return format and a security guarantee ('Secret values are never returned'), which is beyond the annotation's safety profile. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no waste. The purpose is front-loaded, followed by the return shape and a security note. Every sentence contributes essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists (per context signals), the description need not explain return values in detail, but it does anyway, reinforcing clarity. It covers the purpose, scope ('for this marketplace'), and a security guarantee. For a read-only list tool with no parameters, this is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the schema fully covers them (100% coverage). The baseline for zero params is 4. The description adds return format details, which are not parameter semantics but are useful context. No param explanations needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('List') and resource ('configured cabinets') and clearly identifies what is returned (active cabinet and list). It distinguishes itself from sibling tools like ozon_add_cabinet and ozon_remove_cabinet by focusing purely on listing, with no ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The context is clear: this tool is for viewing configured cabinets and the active one. It does not explicitly mention when not to use it or name alternatives, but the read-only nature and purpose are obvious from the description and annotations. No exclusions are stated, but the guidance is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that the tool returns counts, which is a mild behavioral detail, but it does not disclose any limits, pagination, or other execution traits. With annotations carrying the main burden, this is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence, front-loaded with the verb and object, and no filler. Every word contributes to the meaning. This is exemplary conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is sufficient for a simple read-only list tool with no parameters and an output schema present. It states what is listed and the key metric (count of endpoints). It does not explain what 'sections' are or how to interpret counts, but for this tool's simplicity, that is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema description coverage is effectively 100% (vacuous). The description does not need to explain parameters, and it adds no unnecessary parameter-related information. The baseline of 4 applies for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('List') and resource ('API sections'), and adds detail that it returns the count of catalog endpoints per section. This clearly identifies the tool's function and distinguishes it from other provider-specific list tools, though it does not explicitly differentiate from siblings like ozon_perf_list_sections.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as ozon_map or ozon_search_methods. It only describes what it does, leaving the agent to infer that it is for getting an overview of sections, but no explicit conditions or exclusions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already conveys that this is a safe read operation. The description adds the output shape ('JSON: [{name, category, when_to_use}]') and the follow-up tool, which helps, but it does not disclose other behavioral details such as pagination, filtering, or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action, and every sentence adds useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Fully sufficient for a zero-parameter, read-only listing tool: it states what is returned alert and directs the agent to the companion tool for detail. The output schema plus readOnlyHint cover the remaining context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the empty input schema already covers the parameter surface. The description adds no parameter-specific meaning, which is acceptable but not an extra contribution beyond the schema baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Starts with a specific verb ('List') and identifies the resource ('ready-made analytical workflows (recipes) for this marketplace'). The parenthetical 'recipes' and the contrast with the sibling fetch tool make the purpose immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly tells the agent to use this tool to list available workflows and points to '{svc}_get_workflow' when the full step-by-step plan for one recipe is needed. It gives the key routing hint, though it does not spell out explicit exclusion cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description adds that calling with no args returns the full map while passing an entity narrows to that entity's methods. This is useful behavioral context beyond the annotation, with no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences front-load the purpose and immediately explain the two calling modes. Every clause earns its place; no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, read-only map tool with one optional param and an output schema, the description covers purpose, usage, parameter semantics, and orientation guidance. Nothing an agent needs to decide whether to call it and what to pass is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has no description for the 'entity' parameter (0% coverage), so the description carries the burden. It explains the default (no arg = whole map) and provides examples ('reviews' or stocks/prices/orders/…) that make the parameter's semantics clear, warranting a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific purpose: a map of API entities and go-to methods. It clearly distinguishes itself from sibling tools like ozon_search_methods by framing itself as the orientation tool ('Use this before guessing'). Gives examples of entities to reinforce scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use guidance: 'Use this before guessing — it orients you fast.' It also instructs how to invoke for whole map vs specific entity, but does not explicitly name alternative tools or when not to use it, so not a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds meaningful context beyond annotations: if the removed cabinet was active, another becomes active. This is a valuable side-effect disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded: the primary action is stated first, followed by a useful behavioral note and the argument explanation. There is minor redundancy between 'Delete' and 'remove,' but no wasted content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter destructive operation with annotations and an output schema, this description is largely complete: it identifies the target, the side effect, and the argument. It does not discuss error behavior or prerequisites, but those are not essential here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explicitly defines `name` as 'the cabinet to remove,' fully clarifying the single required parameter. No further format or constraint details are needed for this simple string parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Delete a stored cabinet.' This clearly distinguishes the tool from sibling operations like add, list, or use cabinets. The additional active-cabinet behavior clarifies the exact scope of the operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied by the verb 'Delete' and the reference to a stored cabinet, but the description does not explicitly state when to prefer this tool over alternatives or mention exclusions. It gives no direct comparison to siblings like ozon_add_cabinet or ozon_use_cabinet.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The readOnlyHint annotation already declares this as read-only. The description adds behavior beyond that: it works in Russian and English, returns results 'best first', and specifies a limit range (1-50). This enriches the agent's understanding of expected behavior without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded. The main purpose is stated in the first sentence, followed by a clear Args list and a one-line return description. There is no redundant or filler content; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description needn't detail the return structure—it only says 'JSON list of matching endpoints (best first)', which is sufficient. The description covers the purpose, arguments (with examples and limits), language support, and return type. For a search tool of this simplicity, nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must fully compensate. It does: 'query: free text' with concrete examples ('остатки', 'stocks', 'update price') clarifies the expected input, and 'limit: max results (1-50)' adds range constraints. This is exactly the kind of semantic enrichment the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Search'), the resource ('endpoint catalog'), and the scope ('by keyword'). It also notes language support (Russian and English), which further clarifies its purpose. This distinguishes it from sibling tools like ozon_describe_method (which presumably describes a specific endpoint) and ozon_map, making it unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly conveys when to use it: when you need to find endpoints by keyword. It doesn't explicitly mention alternatives or exclusions, but the context of sibling tools (e.g., ozon_describe_method, ozon_get_section) makes it obvious that this is the discovery tool. The language support note adds a useful usage constraint.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, the description discloses the key is sent into the chat transcript, requires an explicit acknowledgment flag, is saved locally with chmod 600, is never echoed back, and is validated against the marketplace on success. This is rich, security-relevant behavioral context that annotations alone do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured: a short purpose, a prominent security warning, an alternative recommendation, then concise per-parameter guidance, followed by success behavior. Every sentence adds necessary information, and the most critical caveat is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's security sensitivity, the description covers the trigger, the prerequisites, the confirmation requirement, the default behavior, the failure-avoidance alternative, and post-success validation. Since an output schema exists, it does not need to exhaustively document return values. Nothing essential to calling the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries the full burden. It explains credentials as a dict with required fields, cabinet selection including defaults and fallback naming, and the confirmation flag's meaning. However, the exact required fields for credentials are left as a placeholder ('{fields}'), so it does not fully specify how to build a valid credentials object.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Change / rotate the API key from chat', a specific verb with a clear resource and intent. The examples ('expired or leaked') and the reference to the installer alternative make it easy to distinguish from all sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use the tool (key expired or leaked), and explicitly contrasts it with the safer installer alternative where the key never enters chat. It also adds practical guidance to use a scoped key and rotate it in the seller cabinet if exposed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses WRITE semantics, confirm_write requirement, Ozon's rate limit, string price typing, old_price='0' clearing behavior, and response shape beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence carries distinct operational value; formatted with endpoint, caveats, parameter list, and response shape without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, endpoint, confirmation requirement, rate limit, parameter semantics, and return shape. An agent can call this tool correctly without external lookups.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description adds meaning for every parameter, including units, defaults, and the special old_price sentinel.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Set'), the exact resource ('price for ONE product'), the identifier ('offer_id') and the endpoint. The scope is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational context: requires confirm_write=true, has a rate limit, and is scoped to one product. It does not explicitly name an alternative for bulk updates, though 'ONE product' implies the boundary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=false (mutation) and idempotentHint=true. The description adds that it affects subsequent calls and uses credentials, providing useful behavioral context beyond the annotations. It does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a parameter note, with the core action front-loaded. No redundant words or filler. It is concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no nested objects, and an output schema present), the description covers the essential behavior and parameter semantics. It does not mention error conditions or prerequisites, but these are not critical for a straightforward switch action and are implied by the reference to list_cabinets.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must clarify the parameter. It states that 'name' is 'the cabinet to activate' and points to ozon_list_cabinets for available options, adding meaning beyond the bare schema field. It could offer more format details, but for a single parameter this is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Switch' with a clear resource 'active cabinet' and explicitly states the consequence: 'Subsequent API calls use its credentials.' This distinguishes it from siblings like list/add/remove cabinets, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context that this tool changes the active cabinet for subsequent calls, but it does not explicitly state when not to use it or mention alternatives beyond the parameter reference to list_cabinets. There are no exclusions or alternate tools named, but the purpose is self-evident enough for a simple state-switching tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only provide basic read-only/destructive hints. The description adds meaningful behavioral context: the confirmation gate, the fact that no request is sent without confirm_write=true, the target API, and the response envelope format. This goes beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: purpose first, then safety requirement and sibling routing, then argument definitions, then return format. Every line adds necessary information without filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a dynamic catalog-driven tool, the description covers what an agent needs: which API it targets, how to find operation IDs, how to fill path/query/body, the mandatory confirmation setting, expected return shape, and when to use sibling tools. The presence of an output schema further reduces the need to explain return values in detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden. It provides concise but useful meanings for all five parameters: operation_id as the catalog id, path_values as placeholder substitutions, query as query-string params, body as JSON body, and confirm_write as the required safety flag. The body and query entries are somewhat generic, so it is not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Execute one WRITE endpoint from the catalog: create or update data') and identifies the resource as a catalog write endpoint. It also distinguishes itself from sibling tools by naming ozon_call_method for reads and ozon_delete_method for irreversible operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage guidance is explicit: 'Requires confirm_write=true; nothing is sent without it' and 'Irreversible operations live in ozon_delete_method, reads in ozon_call_method.' This tells the agent exactly when to use this tool and which alternative to select for other operation classes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds valuable behavior: it only accepts POST/PUT/PATCH, requires confirm_write, documents host defaulting, and specifies the return envelope. It does not discuss error cases or rate limits, but nothing contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two opening sentences plus a tight Args list, with the most important scope statement front-loaded. Every line adds information, there is no filler, and the return format is included compactly at the end.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a raw-path write tool with six parameters, the description supplies the target API, method limitations, parameter semantics, confirmation requirement, and response envelope. An agent has enough to construct a valid call, including knowledge of the required confirm_write override, without needing the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden for six parameters. It adds concrete constraints: method values, path format, host defaulting, query-string semantics, JSON body type, and the mandatory confirm_write flag. Every parameter receives meaning beyond its bare title.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action ('Create or update data') and resource ('at ANY path'), and immediately differentiates it from catalog-based siblings by noting paths not in the catalog. The POST/PUT/PATCH restriction and target API anchor it as a raw write tool, so an agent can distinguish it from ozon_get_raw, ozon_delete_raw, and ozon_write_method.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly states when the tool applies: any raw write via POST/PUT/PATCH, and requires confirm_write=true. It does not name sibling alternatives or an explicit when-not-to-use, but the 'paths not in the catalog' wording gives a usable decision boundary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.