Skip to main content
Glama

Preview a search

preview_search
Read-onlyIdempotent

Up to 25 sample places of a search (name, city, category, rating, reviews). Contact details are booleans here: email addresses, phone numbers and websites only come with a list (create_list).

Free.

Same call as POST /api/v1/search/preview of the REST API.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "search": "<search>"
    },
    "name": "preview_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoRows returned (default 10, at most 25).
offsetNoRows to skip (default 0).
searchYesThe search, as returned by POST /categories/suggest (field "search"). Send it back as is, edited if needed. The "search" object returned by suggest_categories (target, area, filters, sort), sent as is or edited; its full schema is the "search" input of count_search. An invalid search is refused with invalid_request and the fields to fix.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent and non-destructive, so the added value here is the disclosure that contact data is degraded to booleans in this call and that the call is free — two things the annotations do not say. Return-format/pagination behavior is left implicit, keeping it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Short and front-loaded, with the row cap and the distinguishing create_list note up front. The fragmentary formatting ("Free." as its own line, REST endpoint reference at the end) is slightly choppy but wastes no real space.

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?

With no output schema, the description usefully enumerates the sample fields returned and flags that contact details are booleans, which is the most important caveat for a preview call. A brief note on ordering or what "sample" means (random vs. top-ranked) is the only real omission.

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 coverage is 100% and the nested `search` parameter is documented with its origin (suggest_categories) and validation behavior (invalid_request), so the schema does the heavy lifting. The description restates the 25-row cap but adds no parameter meaning beyond it, making the baseline 3 correct.

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?

"Up to 25 sample places of a search (name, city, category, rating, reviews)" states the resource and the shape of what comes back, and the create_list clause separates it from the full-list sibling. The action verb is nominal ("preview") rather than explicit, but an agent can still tell this is a sampling/read operation.

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?

It clearly signals context via "Free" and the contrast that real contact details only come with create_list, which implicitly routes the agent to preview first and to create_list for real emails/phones/websites. It stops short of an explicit "use this before/unless" statement, so it lands just under 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.