List WooCommerce products at or below a low-stock threshold, optionally only managed stock, to support inventory monitoring via paginated catalogue scans and an item cap.
List products at or below low_stock_threshold units.
Scans the published catalogue via pagination, capped at max_items.
| Name | Required | Description | Default |
|---|---|---|---|
| max_items | No | ||
| only_managed | No | ||
| low_stock_threshold | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that the tool scans the published catalogue via pagination and caps results at max_items, which is real behavioral context. However, it says nothing about read-only safety profile, sort order, or what happens when the cap is hit (truncation vs error).
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 tight sentences with the core filter condition front-loaded and no filler. Every phrase carries information, though the trailing pagination clause reads slightly like an afterthought.
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 list tool with no output schema, the description covers the core selection logic and the result cap. It is incomplete on the only_managed parameter and on return ordering/truncation semantics, gaps that neither the schema nor annotations fill.
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 all three parameters. It explains low_stock_threshold and max_items in prose, but only_managed is never mentioned, leaving a parameter that materially changes the result set entirely undocumented.
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 (List) and resource (products) with an explicit filter condition (at or below low_stock_threshold units). An agent can identify the purpose immediately, though it doesn't distinguish itself from the sibling search_products, which could also return products.
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 statement of when to use this tool versus search_products or get_product, and no prerequisites or exclusions. The stock-threshold framing implies an inventory-monitoring scenario, but that must be inferred rather than read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.