Skip to main content
Glama

kapruka_render_options_card

Read-onlyIdempotent

Render 1-4 products as ONE shareable JPEG "menu" card and return its URL.

The card shows each product's photo with a big numbered badge (the ref you
assign), and its name + price printed under the photo. Built for chat
commerce (WhatsApp): send the image, tell the customer "reply 1, 2 or 3",
and they pick without opening links. No AI is involved — the image is
server-composited from the live catalog data, so prices match what the
product tools return.

Ref numbering contract: refs are yours to assign — use sequential numbers
per conversation and NEVER reuse one (if the first card was 1-3, the next
card starts at 4). A number must keep meaning the same product for the whole
conversation.

Args:
    params (RenderOptionsCardInput):
        - items (list[CardProduct]): 1-4 of {product_id, ref}
        - currency (str): LKR (default), USD, GBP, AUD, CAD, EUR

Returns:
    str: JSON:
    {
      "card_url": str,              # public JPEG URL — send this as the image
      "items": [{"ref": int, "product_id": str, "name": str,
                  "price": {"amount": float, "currency": str}, "url": str}],
      "unavailable": [str]          # product_ids that failed to load (omitted from card)
    }

    Error: "Error: <message>" when no product could be loaded.

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?

Beyond the annotations (readOnlyHint, idempotentHint), the description reveals that the image is server-composited from live catalog data (so prices match product tools), explains the ref-assignment contract (sequential, never reused, stable meaning per conversation), and details the exact JSON return shape and error behavior. These are operational traits the annotations do not cover.

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 longer than average but every part is warranted: it front-loads the purpose, then explains the chat use case, the critical ref contract, and ends with organized Args/Returns sections. It is structured and free of fluff—no sentence is redundant with the annotations or schema.

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 tool's behavior is complex enough that this detail is needed: it specifies the output URL, the item list with product names, prices, and URLs, the absence of unavailable products, and the fallback error string. Together with the WhatsApp scenario and the ref contract, the description provides complete context for an agent to invoke it correctly.

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?

With schema_description_coverage at 0% for the top-level 'params' parameter, the description's Args section compensates fully: it lists 'items' (1-4 of {product_id, ref}) and 'currency' with defaults, clarifies the ref numbering rule, and gives an example of use. This adds practical meaning well beyond the bare schema structure.

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 a precise action and outcome: 'Render 1-4 products as ONE shareable JPEG "menu" card and return its URL.' This clearly differentiates the tool from siblings (search, create_order, delivery) by its output format (a composited image card) and its chat-commerce 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 explicitly targets a WhatsApp chat-commerce use case: 'send the image, tell the customer "reply 1, 2 or 3" and they pick without opening links.' This provides clear when-to-use context, but it does not name alternative tools or state exclusions, so it misses the top score by one.

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.