WB Readonly MCP

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation5/5
Each tool has a clearly distinct purpose: discovery (catalog/schema), execution (read), result handling (result/aggregate), product-specific (find_product/product_profile), analytics (sales_funnel/ads_audit), and local calculations (stock_plan/unit_economics). Descriptions are explicit about boundaries and dependencies, so misselection is unlikely.
Naming Consistency4/5
All tools share the wb_ prefix and use snake_case, but the suffix pattern mixes nouns (status, catalog, schema, result) and verbs (read, find_product). This is consistent in style but not strictly verb_noun; the naming is predictable and readable.
Tool Count5/5
With 12 tools, the server is well-scoped for a read-only Wildberries API wrapper. Each tool serves a distinct function, and the count is within the ideal 3–15 range without being redundant.
Completeness5/5
The tool set covers the full read lifecycle: discovering operations (wb_catalog), understanding schemas (wb_schema), executing reads (wb_read), retrieving full results (wb_result), and performing local analysis (wb_aggregate, wb_stock_plan, wb_unit_economics). Product discovery, profile, and analytics are also covered. No critical gaps for the stated read-only purpose.
Average 3.7/5 across 12 of 12 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful context about data delays and recalculations, which is beneficial. However, it references non-existent parameters (selectedPeriod, pastPeriod) that conflict with the actual schema, muddying the behavioral picture without directly 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but it contains misleading information about parameters. Conciseness is not valuable if the content is inaccurate; the structure is flat with no prioritization of key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description is grossly incomplete. It omits pagination details, filtering semantics, and response expectations. The erroneous parameter reference further undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain start, end, limit, offset, nmIds, or subjectIds. Instead, it mentions parameters that don't exist in the schema, providing no meaningful semantics for the actual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists concrete data types (transitions, carts, orders, redemptions) for specified products, making the tool's purpose clear. It doesn't explicitly differentiate from siblings like wb_aggregate, but the focus on funnel metrics is distinctive. The mention of 'selectedPeriod' and 'pastPeriod' introduces confusion, but the core intent remains understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as wb_aggregate or wb_read. The description lacks any conditional context or exclusions, leaving the agent to infer applicability from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds useful context: access is restricted to one's own catalog and category is derived from the found card. It does not disclose error behavior, rate limits, or return format, but given the annotation coverage, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and free of fluff. The list of data fields is front-loaded, making the core purpose immediately visible. It is efficient, though the second sentence adds a procedural detail without much structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and zero parameter descriptions, the description must carry the full burden. It explains what data is returned but fails to link the input (nmId) to the output, does not specify the output format, and omits any caveats about missing products or catalog scope beyond a passing mention. An agent would struggle to call it correctly without external context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the only parameter nmId, and the description does not mention nmId at all. The tool name implies product context, but the parameter's meaning and usage are not explained, leaving the agent to infer from the name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists the data fields returned (card, item, parent category, characteristic requirements, prices) and explains that category is determined by the found card, clearly indicating a product-profile retrieval tool. However, it lacks an explicit verb like 'get' or 'retrieve' and does not differentiate from sibling tools by name or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The only usage-related note is the access restriction ('Access only to your own catalog'), which is a constraint but not selection guidance. With many sibling tools, an agent has no basis for choosing this one over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context: all amounts must be in one currency, tax and commission are monetary sums, and the output is not a final financial report. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The main purpose is front-loaded, and the caveat is concise. Every word contributes to understanding or constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 0% parameter coverage, the description fails to describe what the calculation returns or how to interpret the result. The parameter semantics are too vague for an agent to correctly assemble inputs, and the output is undefined. The caveat about not being a final report is helpful but insufficient for full correctness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only clarifies that tax and commission are monetary amounts and that all sums share a currency. It does not explain the meaning of revenue, cost, logistics, storage, advertising, or other, leaving the agent to infer their roles for 8 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a scenario calculation for one redeemed unit from input costs. It also specifies it is not a final financial report, which sets expectations. However, it does not explicitly differentiate from sibling tools, though the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies scenario analysis but does not mention any sibling tools or exclusions beyond the caveat that it is not a final report. This leaves the agent without routing context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds valuable behavior: 'Gaps do not become zeros' and 'calculation concerns only the saved WB page'. These go beyond annotations and help the agent understand edge-case handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying distinct information: the core operation, the field specification mechanism, and two behavioral constraints. Front-loaded and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested objects and no output schema, the description provides general purpose and key behaviors but omits details about required parameters like `arrayPointer` and `resultId`, and the semantics of filter operators and metric ops are left to the schema. Adequate for a simple tool but incomplete for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the five parameters. It explains that fields are specified by JSON Pointer, which clarifies `field` values, but it does not explain `arrayPointer`, `resultId`, or the structure of the `metrics` array and `filter` object. The compensation is inadequate for a nested schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes local sums, averages, grouping, and filtering on a saved result. The verb 'aggregate' is implied through these operations, and the resource (saved WB page) is identified. However, it does not explicitly contrast with siblings like wb_read or wb_result, so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for aggregation on a saved WB page and notes the constraint 'only saved page' but offers no explicit guidance on when to use this tool versus alternatives like wb_read or wb_result. There are no 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by confirming in domain terms that the tool 'does not order anything or create a supply', and by framing the result as a 'local forecast'. It does not disclose calculation details or output behavior, but the safety profile is well covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: core purpose, input instruction, and safety constraint. The description is front-loaded with the most important information and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a calculation tool with 7 parameters, no output schema, and no parameter descriptions, the description is too thin. It does not explain the formula, units, semantics of safety/lead time/availability/inbound, or the shape of the returned result. An agent would need substantial external knowledge to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It loosely maps to parameters via 'balances, demand, and timeframes' (stock, orders, periodDays), but it leaves inbound, leadTimeDays, safetyDays, and availabilityDays unexplained. With 7 parameters and no schema descriptions, this is insufficient for reliable parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a local replenishment/forecast calculation based on explicit stock, demand, and timeframes, and explicitly states it does not order or create supply. It lacks a direct action verb like 'calculates', but the title and content convey the purpose. It partially distinguishes itself from siblings by emphasizing 'local' and 'does not order/create supply'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives actionable usage guidance: pass values from WB with consistent periods. This tells the agent the expected inputs and their alignment requirement. It does not explicitly name sibling alternatives or state when not to use the tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral details: reading is done in parts, nested previews are limited, and nextOffset refers only to the saved result, not to the WB API.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. The core action is front-loaded, and each sentence adds useful information about paging, pointers, and preview limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key behavioral caveats such as preview limits and offset scoping, but because there is no output schema it should more fully describe pagination semantics and the remaining parameters. It is adequate but leaves several gaps an agent would need to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains arrayPointer and textOffset meaningfully, but it leaves resultId, limit, offset, and textLimit undocumented in prose. With six parameters and zero schema descriptions, covering only two is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Читает' - reads) and a specific resource ('сохранённый ответ' - saved response), and further clarifies it reads in parts. This distinguishes it from siblings like wb_read or wb_status, which relate to live API operations rather than saved results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical guidance for using parameters (arrayPointer, textOffset) and warns about preview limits, but it does not explicitly state when to use this tool versus alternatives or when not to use it. Usage context is implied rather than explicitly compared with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description adds behavioral details: it clarifies the basis of calculations (attributed orders), excludes profit and redemption-based DRR, and notes statistical limitations. These are valuable context for interpreting results and avoiding misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core function, and then adds essential clarifications and limitations. Every sentence carries meaning without redundancy, making it efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately focuses on input constraints and metric definitions. It addresses what the tool computes and its limitations, providing enough context for an agent to decide when to invoke it, though it could mention expected output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implicitly covers parameter limits (max 50 campaigns, 31-day window) that align with the schema, but does not explain the meaning of campaignIds, the date format, or the relationship between start and end. The parameter names are intuitive, yet explicit semantics are lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool calculates CTR, CPC, and DRR based on attributed orders, and explicitly notes what it is not (profit or DRR by redemptions). This specificity distinguishes it from generic analytics tools and leaves little ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical constraints (up to 50 campaigns, 31 days per call, small samples do not prove inefficiency) but does not explicitly compare with sibling tools like wb_sales_funnel or wb_aggregate. This leaves some inference needed to decide when this tool is the best choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds practical context: pagination behavior and the workflow of retrieving an ID for subsequent calls. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words, front-loading the core purpose and then providing workflow context. Structure is excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key workflow, pagination, and the fact that it returns IDs. With no output schema, it gives enough to use the tool correctly, though more detail on the return structure would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions 'Russian words or group' (mapping to query and group) and implies pagination (offset/limit), but does not explicitly define each parameter. It adds some meaning but not exhaustive detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: finding operations by Russian words or group, and explicitly explains the workflow (obtain ID, then call wb_schema and wb_read). This distinguishes it from siblings and gives the agent a concrete purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use it to search by Russian words or group, and notes that an empty search lists capabilities page by page. It also specifies follow-up calls, but does not explicitly exclude alternatives or state when not to use it. Still, the guidance is substantial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, idempotent, non-destructive behavior. The description additionally discloses that the tool provides authoritative schema details (including source and date) and warns against fabricating parameters, adding useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the first front-loads the exact deliverable, the second gives actionable usage guidance. No filler, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only metadata tool, the description covers what is returned (path/query/body, constraints, source, date) and when to call it. It doesn't detail error cases, but annotations and the tool's simple nature keep that risk low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, operationId, has 0% schema description coverage. The description and title imply that operationId identifies the operation whose schema is returned, but neither explicitly defines valid values or format. This adds some inferable meaning but leaves a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific deliverable: 'exact schema of path/query/body, constraints, source and date'. This clearly identifies the tool as an operation-schema metadata lookup and is distinguishable from siblings like wb_status or wb_read, which perform other functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: 'Read before the first call of the operation', and instructs the agent not to invent parameters. It doesn't name alternative tools or exclusions, but the meta-tool purpose makes the when-to-use context reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description adds non-obvious behavioral details beyond those annotations: name searches are paginated and limited, results may be partial, a nextCursor is returned, and multiple candidates are possible. This is exactly the kind of runtime behavior that helps an agent avoid incorrect silent selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no filler: first sentence states the purpose and accepted inputs, second sentence describes pagination behavior, third sentence gives an actionable warning. It is front-loaded with the most important information and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, a nested cursor object, and no output schema, the description covers the core search semantics and pagination caveat, but it leaves important context unstated: what partial results look like, how to provide cursor, brand, or subjectId, and how nextCursor should be fed back in. It is adequate for a first invocation but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the burden of explaining parameters. It does clarify that query can be an nmId, seller article, barcode, or name, and it hints at cursor semantics via 'nextCursor.' However, brand, subjectId, maxPages, and the cursor object structure are left unexplained, so the description only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('поиск своего товара' - search for your product) against a clear resource, and enumerates the search keys: nmId, seller article, barcode, or name. This differentiates it from siblings like wb_read or wb_product_profile, which are about reading or viewing profiles rather than finding a product by multiple lookup methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use this tool to find a product by identifier or name, and it explains that name searches scan only limited pages. It also provides a concrete decision rule: do not silently pick a product when multiple candidates exist. It does not explicitly name sibling tools or state when not to use it, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, open-world, and non-destructive. The description adds important context beyond that: arbitrary URL/method/header are forbidden, the result is only a preview with resultId, and pagination is not guaranteed complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each adding distinct information: the restriction, the return shape, the follow-up path, and the pagination caveat. It is front-loaded and has no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, it correctly explains the return value (preview + resultId) and the path to full results via wb_result. However, it leaves parameter semantics (params, maxAgeSeconds) undocumented, so an agent may still be uncertain how to construct a complete call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only hints that operationId must come from a verified catalog. The params object and maxAgeSeconds are not explained at all, leaving the agent without semantics for two of the three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—invoke a verified catalog operation—and clarifies what it returns (a limited preview plus resultId), explicitly distinguishing itself from wb_result. This is far more specific than the generic title and helps separate it 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says to call only operations from the verified catalog and directs users to wb_result for the full response. It also warns that this returns one page, not the whole dataset, so an agent knows when to use an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context by stating that no requests to WB are made and no secrets are returned, going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, front-loaded with the key instruction 'Start here', and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status/configuration check with no parameters and no output schema, the description fully covers what the agent needs: purpose, behavior, and side-effect transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is complete. The baseline for no parameters is 4, and there is no additional parameter information needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: start here and check configuration. It distinguishes itself from sibling tools by focusing on status/config rather than data operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Start here', giving direct usage guidance. It also clarifies that no WB requests are made. However, it does not explicitly name alternative tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![mcp-wb-readonly MCP server](https://glama.ai/mcp/servers/zimuspro156-lab/mcp-wb-readonly/badges/card.svg)](https://glama.ai/mcp/servers/zimuspro156-lab/mcp-wb-readonly)

Score Badge

Copy to your README.md:

[![mcp-wb-readonly MCP server](https://glama.ai/mcp/servers/zimuspro156-lab/mcp-wb-readonly/badges/score.svg)](https://glama.ai/mcp/servers/zimuspro156-lab/mcp-wb-readonly)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zimuspro156-lab/mcp-wb-readonly'

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