Skip to main content
Glama

Birinchi Shop — Uzbekistan store

Search products

search_products
Read-onlyIdempotent

Search the store catalog. Returns title, price (UZS), delivery fee, availability, url and image. Product names are in Uzbek or Russian; short keywords in either language match best.

Input Schema

NameRequiredDescriptionDefault
sortNo
limitNoDefault 10.
queryNoKeywords, e.g. "karcher", "soat", "наушники". Empty = popular products.
max_priceNoMaximum product price in UZS.
min_priceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds something the annotations cannot: the exact return payload (title, price in UZS, delivery fee, availability, url, image), which is important with no output schema. It omits ordering/pagination behavior beyond limit and any rate-limit or truncation notes.

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, front-loaded with purpose, then return payload, then the one non-obvious usage tip. No filler and nothing an agent must skim past.

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 zero-required-parameter read-only search with no output schema, the description covers purpose, return shape and query strategy, which is most of what an agent needs. The remaining gap is the undocumented sort and min_price parameters and any result-cap behavior.

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?

With schema coverage at 60%, the schema documents query, limit and max_price but leaves sort and min_price bare. The description reinforces the currency for price and adds a real tip about keyword length and language that goes beyond the schema examples, but it never explains what the sort enum values imply or how min_price/max_price interact. Baseline 3 is appropriate.

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 opens with a specific verb and resource ("Search the store catalog") and then enumerates the returned fields, so an agent knows exactly what the tool produces. It does not explicitly distinguish itself from the sibling get_product (single-item lookup), leaving that routing to inference.

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 language note ("Product names are in Uzbek or Russian; short keywords in either language match best") is useful guidance on how to query, and "Empty = popular products" in the schema covers the browse case. However there is no explicit when-to-use or when-not-to-use versus get_product or the other siblings, so selection guidance is only implied.

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.

Resources