Skip to main content
Glama

kapruka_search_products

Read-onlyIdempotent

Search for products on Kapruka.com by keyword, with optional category filter and pagination.

Returns a ranked list of matching products with prices, stock status, images, and URLs.
Supports cursor-based pagination — pass next_cursor from one response into the next call.
Pagination is capped at 3 pages per query to discourage catalog enumeration; for broader
discovery, refine the query or filter by category instead.

Queries must be at least 3 characters and contain specific terms — pure stopword queries
(e.g. "the", "a an") are rejected.

By default, category landing pages (CATSYM entries with price=0) are filtered out so results
contain only purchasable products. Set include_stubs=true to include them.

Args:
    params (SearchProductsInput):
        - q (str): Search query (e.g. 'birthday cake', 'roses', 'tea gift'). Min 3 chars.
        - category (Optional[str]): Category filter (e.g. 'Birthday', 'Flowers')
        - limit (int): Results per page, 1–50 (default 10)
        - cursor (Optional[str]): Pagination cursor from previous response
        - currency (str): LKR (default), USD, GBP, AUD, CAD, EUR
        - min_price (Optional[float]): Min price (inclusive) in the requested currency
        - max_price (Optional[float]): Max price (inclusive) in the requested currency
        - in_stock_only (bool): Restrict to in-stock items (default false)
        - sort (str): 'relevance' | 'price_asc' | 'price_desc' | 'newest' | 'bestseller'
        - include_stubs (bool): Include category landing pages (default false)
        - response_format (str): 'markdown' (default) or 'json'

Returns:
    str: Search results in the requested format.

    JSON schema:
    {
      "results": [
        {
          "id": str,
          "name": str,
          "summary": str,
          "price": {"amount": float | null, "currency": str},
          "compare_at_price": {"amount": float, "currency": str} | null,
          "in_stock": bool,
          "stock_level": str,
          "image_url": str | null,
          "category": {"id": str, "name": str, "slug": str},
          "rating": null,
          "ships_internationally": bool,
          "url": str
        }
      ],
      "next_cursor": str | null,    # null after page 3 even if upstream has more
      "applied_filters": {"q": str, "limit": int, "in_stock_only": bool}
    }

    Error: "Error: <message>" or "No products found for '<query>'" on failure.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds substantial behavioral context: pagination is capped at 3 pages, queries must be ≥3 chars and reject stopwords, category landing pages (price=0) are filtered by default, and error formats are specified. This goes well 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 long but every section earns its place: purpose first, then pagination and query rules, then a structured Args list, then the return JSON schema and error messages. It is front-loaded with the most important info and contains no fluff.

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?

The description fully covers the complexity of this search tool: pagination behavior and cap, query constraints, stub filtering, parameter meanings, and the complete output schema. It also documents error strings and the special meaning of next_cursor. Nothing important is left unexplained.

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

Parameters5/5

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

Schema description coverage at the top level is 0% (the 'params' property has no description), so the description must compensate. It does so thoroughly: the Args section lists all 11 parameters with types, defaults, allowed values, and examples (e.g., sort options, currency list, min price). This adds critical meaning beyond the bare schema.

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 opens with 'Search for products on Kapruka.com by keyword, with optional category filter and pagination,' using a specific verb+resource+scope. This clearly distinguishes it from sibling tools like kapruka_get_product (single product) and kapruka_list_categories.

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?

Provides clear context for usage: keyword search, cursor-based pagination, pagination cap of 3 pages, and advice to 'refine the query or filter by category instead' for broader discovery. However, it does not explicitly name alternative tools or state when not to use this 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a clearly distinct operation: delivery checking vs city listing, product search vs product fetch, order creation vs tracking, plus an auxiliary card renderer. Even the two delivery-related tools have non-overlapping purposes, and descriptions reinforce the boundary.

Naming Consistency5/5

All tools follow a consistent `kapruka_<verb>_<noun>` snake_case pattern (e.g., check_delivery, create_order, search_products). The verb-noun structure is uniform, making it easy to predict tool names.

Tool Count5/5

8 tools is well-scoped for an e-commerce MCP server, covering catalog browsing, delivery feasibility, order placement, and order tracking without unnecessary bloat. Each tool serves a distinct step in the shopping workflow.

Completeness5/5

The tool surface covers the full agent-visible lifecycle: discover products (search/get/categories), check delivery, create a guest order, and track post-payment status. There are no obvious dead ends for common shopping scenarios.