Skip to main content
Glama

DNS-Shop Search

dns_search
Read-onlyIdempotent

Search DNS-Shop for products by query and retrieve matching listings with prices and availability through your Chrome session; price is omitted when unavailable.

Instructions

Search DNS-Shop, rendered in the operator's Chrome.

price_rub is None when the tile states no price — never 0.

Full field list and error codes: guide://dns/dns_search.

Input Schema

NameRequiredDescriptionDefault
queryYesSearch text, e.g. 'ноутбук lenovo'

Output Schema

NameRequiredDescriptionDefault
_metaNo
countNo
itemsNo
queryNo
statusNo
tier_usedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.5.1

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that results are rendered in the operator's Chrome and that price_rub is null rather than 0 when no price is shown, plus a guide link for error codes. This is meaningful behavioral context beyond the annotations, though it does not detail failure modes inline.

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 three short lines, front-loads the search purpose, and each line adds useful information: execution context, price null semantics, and a reference link. There is no wasted wording.

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 one-parameter search tool with rich annotations and an output schema, the description covers purpose, browser rendering, and a notable output caveat. It omits explicit sibling routing, but the store-specific name and guide reference make it largely complete.

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% and the single query parameter is documented in the schema with an example. The description does not add syntax or filtering semantics for query, so it meets the baseline for fully documented schema but adds no extra meaning.

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 states a specific verb 'Search' and a specific resource 'DNS-Shop', so the agent knows it is a store-search tool. It does not explicitly name dns_card or another sibling, but the 'search' vs 'card' naming and store name make the distinction reasonably clear.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no named alternative such as dns_card for product details. The store name and verb imply its use for product discovery on DNS-Shop, so usage is only implied.

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