Skip to main content
Glama

search_products

Search the WooCommerce product catalog by text query or SKU to retrieve normalized products with pricing, stock quantity, stock status, and pagination details.

Instructions

Search the WooCommerce product catalog by text query or SKU. Returns normalized products including pricing, stock quantity, stock status, and pagination metadata.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number for pagination.
limitNoMaximum number of products to return (1-100).
queryNoOptional search keyword or text to match against product titles, descriptions, or SKUs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It does disclose the return payload (pricing, stock quantity, stock status, pagination metadata), which usefully signals a read-only, paginated operation. It says nothing about permissions, rate limits, or what happens when the optional query is omitted, so key behavioral context is missing.

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 tightly written sentences: purpose first, return payload second. Zero filler and the most decision-relevant information is front-loaded.

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 read-only search tool with three optional, well-documented parameters and no output schema, the description covers purpose, lookup modes, and returned fields adequately. The one gap is that it does not clarify behavior when the optional query is absent, which matters for callers deciding whether to pass a query at all.

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 100%, so page, limit, and query are already fully documented with ranges and defaults; baseline is 3. The description reinforces the query semantics (titles, descriptions, SKUs) and pagination, but adds no syntax or format detail beyond the 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?

States a specific verb and resource (search the WooCommerce product catalog) plus the lookup modes (text query or SKU), which clearly separates it from a single-item getter like get_product. It does not explicitly name a sibling or contrast its role against search_orders, so it falls short of full sibling 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?

Usage is implied by 'search … by text query or SKU', which signals the retrieval scenario, but the description never states when to prefer this over get_product or get_inventory, nor any exclusions or prerequisites. No explicit when/when-not guidance is present.

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