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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds critical context: the key enters the chat transcript, requires explicit acknowledgment, storage path (~/.marketplace-mcp/cabinets.json) with chmod 600, and that it is never echoed. This is substantial additional behavioral disclosure beyond annotations, with no contradictions.

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

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

The description is well-structured: a clear purpose sentence, a prominent security warning, and a compact parameter list. It front-loads the most important info (security) and avoids redundancy. Each sentence adds value.

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 security-sensitive credential-management tool, the description covers purpose, parameters, security implications, storage, and alternatives. Even without seeing the output schema, the description is self-sufficient for an agent to call 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 coverage is 0%, so the description fully compensates. It explains the credentials format for Ozon and WB, the name parameter's fallback behavior, and the i_understand_key_goes_to_chat requirement. Every parameter is meaningfully described.

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 (add/update) and resource (cabinet, a named set of API credentials), and specifies it operates from chat. It distinguishes from installer alternative and implies service scope (Ozon) by giving credential examples. This is specific and unambiguous.

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

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

It explicitly names the safe alternative (install.py / double-click) and the condition for using this tool (accepting that the key goes to chat). This provides clear when-to-use and when-not-to-use guidance, going beyond mere description.

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 indicate destructiveHint=true and readOnlyHint=false. The description expands on this by specifying exactly which flags are required for write vs destructive operations and that 'nothing is sent otherwise' for destructive ones. It also discloses the return format (JSON success envelope or error envelope). This adds behavioral context 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 well-structured with a concise summary sentence, a bullet-like 'Args' list, and a return statement. It front-loads the core behavior and safety requirements. Every sentence contributes to usability; there is no redundancy or 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?

Given that the tool is a generic method caller with an output schema (mentioned in the description) and complex safety logic, the description covers the essential usage: operation_id sourcing, path/query/body parameters, confirmation flags, and return format. It doesn't mention rate limits or error handling specifics, but these are not critical for correct invocation. The description is complete enough for an agent to call it 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 schema description coverage at 0%, the description carries the full burden of explaining parameters. It explains each of the six parameters: operation_id (with pointer to search_methods), path_values (for placeholders), query (query-string parameters), body (JSON request body), and the two safety flags. It could be slightly more explicit about the exact format of path_values (e.g., as a map) but overall it provides meaningful guidance.

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's purpose: 'Execute one catalog endpoint by operation_id.' It identifies the verb (execute), resource (catalog endpoint), and the key identifier (operation_id). This distinguishes it from siblings like ozon_call_raw (which likely calls raw endpoints) and ozon_search_methods (which searches for methods), and from provider-specific variants like wb_call_method. The purpose is unambiguous and specific.

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 clear guidance on when to use this tool and what flags are required: read endpoints run immediately, write endpoints require confirm_write=true, and destructive endpoints require both confirm_write and i_understand_this_modifies_data. It also references {svc}_search_methods for obtaining operation_id. However, it does not explicitly mention that dedicated tools (e.g., ozon_get_products) should be preferred when available, which is a minor gap in routing.

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 description adds significant behavioral context beyond annotations: it maps HTTP verbs to safety levels (GET=read, POST/PUT/PATCH=write, DELETE=destructive) and mentions confirmation rules. It also discloses the return format ('Returns JSON: {"ok": true, "status", "data"} or the error envelope'). Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description enriches rather than contradicts 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 front-loaded with the core purpose and uses a clear bulleted list for parameters. It is efficient with no fluff, but the placeholder '{svc}_call_method' is vague and slightly confusing. The mention of two confirmation parameters could be consolidated, but overall it is well-structured and readable.

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 raw, unrestricted nature and the presence of an output schema, the description covers the essential aspects: purpose, safety inference, parameter semantics, and return format. It omits details like authentication requirements or rate limits, but these are likely common to the service and may be handled elsewhere. The description is sufficient for an agent to correctly invoke the tool for arbitrary endpoints.

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: every parameter is listed with a brief explanation (method, path, host, query, body, confirm_write, i_understand_this_modifies_data). It provides a concrete path example and explains defaults for host. However, it does not clarify the relationship between confirm_write and i_understand_this_modifies_data, and query/body formats could be more detailed.

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's function: 'Execute ANY endpoint, even ones not in the catalog (full API coverage).' It uses a specific verb ('Execute') and resource ('endpoint'), and explicitly contrasts with catalog tools by mentioning 'even ones not in the catalog,' distinguishing it from sibling tools like ozon_call_method. The name 'ozon_call_raw' also reinforces the raw, unrestricted nature.

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 endpoints outside the catalog ('even ones not in the catalog') and references confirmation rules via 'Same confirmation rules as {svc}_call_method,' but it does not explicitly say 'use this instead of call_method for uncatalogued endpoints.' It provides clear guidance on safety based on HTTP verb, which helps the agent decide when confirmations are needed, but it could be more explicit about the alternative 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?

Beyond the readOnlyHint annotation, the description explicitly discloses that secrets are not revealed—only set/unset status is reported—and documents the exact return shape. This is meaningful behavioral information not already in the 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 sentences: purpose first, then a caveat, then the return contract. Every sentence adds information; no fluff or repetition of the schema.

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 zero-parameter read-only check with an output schema already given in the description, the definition is fully self-sufficient. Nothing needed for calling it 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 locked in the schema, so there is nothing the description needs to add. The description properly focuses on behavior and output instead of parameters.

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 and object: 'Check whether the required credentials are present in the environment.' The tool's name and description make its scope (OZON credential presence check) clear, and the 'only reports which variables are set' clause sharpens what it does not do.

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 on when to use this tool versus alternatives such as ozon_perf_check_auth or wb_check_auth. It is implicitly a preflight credential check, but the description never states that or recommends using it before API calls.

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?

The description discloses several behavioral traits: automatic pagination (cursor fields handled), max_items hard cap with truncation result, raw responses returned, and path/depth handling. However, it doesn't reveal whether the tool follows API rate limits, retries, or handles auth issues — but the annotation readOnlyHint=true and openWorldHint=true are consistent (read-only, may hit unknown endpoints). No contradiction. Could mention error behavior on non-paginated endpoints, but solid.

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 organized in a tight paragraph followed by a parameter list. It front-loads the key behavior (auto-paginate, return everything, capped). A couple of phrases are slightly redundant (e.g., 'read endpoint' is repeated, return shape is stated twice), but it's dense and scannable.

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 pagination wrapper tool, the description covers the essential invocation context: which endpoints are valid, what to pass, what comes back, and the truncation behavior. It doesn't exhaustively document every error case or authentication assumptions, but no output schema is provided, so disclosing the return envelope is important and it does. The presence of many sibling fetch_all tools (wb_fetch_all, ym_fetch_all, avito_fetch_all) makes the Ozon-specific read-endpoint framing adequate.

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 explains every parameter's role: operation_id is the read endpoint to target, query/body/path_values are base parameters, cursor_fields are ignored/overwritten, limit and max_items control pagination, items_path is the array location. It adds semantics the raw schema does not convey (e.g., cursor fields are managed; items_path has heuristic default), compensating well for the 0% schema coverage.

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 verb+resource: "fetch all pages" / "list ALL calls in date range" pattern is replaced here with a clear statement that this tool returns every row from a paginated read endpoint in one response. It distinguishes itself from siblings like ozon_call_method, ozon_call_raw, ozon_fetch_all, and wb_fetch_all by saying it is the pagination-encompassing fetch-all variant for Ozon, and its name itself clearly pairs with the Ozon catalog context.

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 states when to use it: for read endpoints from the catalog that return arrays. It mentions that cursor fields are managed automatically them, warns the agent about the max_items cap, and explicitly says the tool returns raw API data — so the agent knows not to use it when processing or transformation is needed.

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=true. The description adds that it returns a JSON list with specific fields (operation_id, method, path, safety, summary), which is useful. It does not mention pagination or potential errors, but given the annotations cover safety, 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?

The description is concise, front-loading the purpose and including the arguments and return format in a well-structured docstring. Every sentence is necessary, 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 has one parameter, a clear return format, and annotations for read-only safety, the description is fairly complete. It lacks details on error handling or enumeration of section names, but it points to where to get them (list_sections). The output schema exists, so return format is well covered.

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 schema only provides the parameter name and type. The description compensates by explaining the section parameter should come from {svc}_list_sections and gives an example. This adds meaning beyond the schema, but it doesn't fully describe the range of valid values, earning a baseline 3.

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 it lists all endpoints in one section, with a specific verb ('List') and resource ('endpoints in one section'). It distinguishes itself from siblings like ozon_list_sections (which lists sections) and ozon_search_methods (which searches methods), and the return format is specified.

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 by requiring a section name from ozon_list_sections and provides an example ('statistics'). However, it does not explicitly state when to use this tool over alternatives like ozon_describe_method or ozon_get_section for other services (e.g., ozon_perf_get_section). The context is clear but lacks explicit exclusions or alternative routing.

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. The description adds useful behavioral context by specifying the JSON return shape and explicitly stating that secret values are never returned, which is valuable security-related behavior beyond the schema.

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

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

The description is short, front-loaded with the core purpose, and each sentence earns its place: what it lists, what it returns, and a security guarantee. 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 zero-parameter read-only tool, the description is nearly complete: it explains purpose, return structure, and secret handling. The only minor gap is that 'fields_needed' is not explicitly described, though the output schema likely covers this.

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 baseline is 4. The description adds no parameter information, but none is needed; input schema coverage is effectively complete.

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 and resource: 'List configured cabinets for this marketplace' plus identifies the active one. This clearly distinguishes the operation from most siblings and is not a tautology.

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 tool's purpose clear enough that an agent can infer when to use it, and the 'this marketplace' phrasing implies scope. However, it does not explicitly contrast with sibling tools like ozon_perf_list_cabinets or state when not to use it.

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

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 provide readOnlyHint=true, so the agent knows this is safe. The description adds that it is a map/orientation tool and can be called with no args, which is useful context beyond the annotation. However, it doesn't discuss the output format or potential size of the map, which could be large, nor does it mention any 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 composed of three sentences, each earning its place: the first frames the tool's purpose, the second gives concrete usage instructions, and the third advises when to use it. It's front-loaded with the 'big picture' concept and avoids any 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 low complexity (1 optional parameter) and the readOnly annotation, the description covers the essential usage guidance. However, because it's a mapping tool, it could benefit from including an example of expected output or what the map contains, but the output schema is provided, which may compensate. Overall, it's quite complete for an overview 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?

The schema provides a single optional 'entity' property with a default empty string, which is ambiguous. The description clarifies that 'entity' can be a specific entity name like 'reviews' or 'stocks/prices/orders', effectively compensating for the 0% schema coverage. Since it adds clear meaning to the parameter, but the schema is minimal, a score of 3 is appropriate.

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 that this tool is a capabilities map for the OZON API, and explains that calling it with no arguments shows the whole map or pass entity='reviews' to list methods for that entity. It effectively distinguishes itself from sibling tools like 'ozon_describe_method' or 'ozon_search_methods' by framing it as a high-level orientation tool.

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 tells the agent when to use this tool: 'Call with no args to see the whole map... Use this before guessing — it orients you fast.' It clearly implies when to prefer this over other tools (before guessing or exploring), and gives concrete examples of how to invoke it (entity='reviews', etc.).

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, so the description's 'Delete' aligns. The description uniquely adds a behavioral consequence: removing the active cabinet automatically activates another. This context goes beyond the annotation's binary safety flag.

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 sentences are concise and front-loaded: the core action and consequence are stated first, and the parameter is described clearly. No waste.

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?

With a single parameter and an output schema present, the description is complete for this simple tool. It conveys the essential action and behavioral consequence, and the output schema likely explains return values. There is no missing information required 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 coverage is 0%, so the description must explain parameters. It does state that 'name' is the cabinet to remove, which adds meaning beyond the schema's 'Name' label. However, it does not specify the format of the name (e.g., a name string versus an identifier) or where it comes from, which would be useful.

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 'Delete' and the resource 'a stored cabinet' and explains the consequence when the active cabinet is removed. It is specific and distinguishable from sibling tools like ozon_add_cabinet, ozon_use_cabinet, and ozon_list_cabinets.

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 when to use: when you need to remove a cabinet mirrors the common pattern among siblings (wb_remove_cabinet, ym_remove_cabinet). It does not explicitly mention alternatives or exclusions, but the pattern is consistent across platforms, so context is clear enough given the sibling list.

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; the description adds that the tool returns a JSON list of matching endpoints sorted by best match, and explains the parameters' roles. No additional behavioral traits need 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?

Two concise paragraphs with bold headers, front-loaded main action, and no extraneous text. Every sentence adds value.

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 search tool with an output schema, the description covers parameter meaning, return format, and language support. No gaps given the tool's simplicity.

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% (no descriptions in schema), but the description fully compensates by detailing 'query' as free text with examples and 'limit' as max results with range 1-50, adding meaningful context.

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 explicitly states the tool searches an endpoint catalog by keyword, works in both Russian and English, and is clearly distinct from siblings ozon_get_products and wb_get_new_orders, which are data retrieval 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 implies usage via example queries and explains the limit parameter, but does not explicitly state when not to use the tool or mention alternative tools. The context is clear enough for a search 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 indicate idempotentHint=true and destructiveHint=false, but the description adds critical behavioral details: the key goes into the chat transcript, requires a specific flag, is validated against the marketplace on success, saved locally with chmod 600, and never echoed back. This goes well beyond the annotations and covers security, persistence, and validation behavior. No contradiction with annotations.

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

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

The description is well-organized with a warning, alternative, and args breakdown. It front-loads the key security concern and flag requirement. It is somewhat long but every sentence adds value for a security-sensitive operation. The structure is clear and readable, though it could be tightened slightly.

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 covers when to use, the risk, the flag, the alternative, argument semantics, and success behavior (validation and shop name reporting). The only notable omission is the specific required fields for the 'credentials' dict, which prevents full completeness for an agent to invoke the tool correctly. Otherwise, the context is thorough.

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 'cabinet' with detailed default behavior and 'i_understand_key_goes_to_chat' clearly. However, 'credentials' is described only as 'dict with the required fields ({fields})' without enumerating the actual fields (e.g., api_key, client_id). This is a significant gap for an agent to know what to provide, so parameter semantics is only partially addressed.

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 changes/rotates the API key from chat, with a specific verb and resource. It distinguishes itself from the safer installer alternative, which is a sibling-like option, and the name already indicates the marketplace. The context (expired or leaked key) makes the purpose unambiguous.

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

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

The description explicitly recommends the installer as the safe alternative when the key should not enter chat, and advises using scoped keys with rotation in the seller cabinet if exposed. It also explains the default cabinet behavior, giving clear when-to-use and when-not-to-use guidance without ambiguity.

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 mark the operation as non-read-only and idempotent, and the description adds the key behavioral detail that this changes the credential context for subsequent API calls. It does not contradict the annotations, and it sufficiently discloses the stateful side effect for such a small tool.

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 focused sentences plus an Args block, with the core behavior first and no filler. Every sentence adds useful information and the structure is easy to scan.

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 single-parameter, state-switching tool with an existing output schema and idempotent annotation, the description is complete enough to call correctly. It explains the action, the parameter, and the effect on subsequent calls without needing extra 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%, but the description compensates by defining name as 'the cabinet to activate' and pointing to list_cabinets for obtaining valid values. This adds meaning beyond the raw schema field, though it stops short of specifying the exact expected format or identifier type.

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: 'Switch the active cabinet' and explains the functional consequence: subsequent API calls use its credentials. This clearly distinguishes it from list/add/remove/set-key cabinet tools and from use_cabinet tools for other providers.

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 conveys the context for use: call this when you need to activate a different cabinet so later API calls authenticate with its credentials. It references {svc}_list_cabinets as the source of valid names, but it does not explicitly state when not to use this tool or name an alternative.

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