Skip to main content
Glama

avito_search

Search Avito listings by query with city, category, price, page, and sort filters; returns result cards with position, price, seller, reviews, and promotion.

Instructions

Поиск на Авито. city — часть адреса (sankt-peterburg, moskva, rossiya). category — часть адреса раздела, например predlozheniya_uslug. Возвращает карточки выдачи: позиция, цена, продавец, отзывы, продвижение.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNosankt-peterburg
pageNo
sortNodefault
queryYes
categoryNo
price_maxNo
price_minNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It does disclose the returned card fields (position, price, seller, reviews, promotion), which is useful and not available from any structured field since there is no output schema. However, it omits pagination behavior, auth needs, and rate limits, so the coverage is partial.

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?

Three short sentences with the purpose front-loaded, then parameter hints, then return shape. No filler, but the parameter hints are not ordered by importance (the required query is never addressed).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter search tool with no annotations and no output schema, the description covers purpose, two parameters, and the return fields. It still leaves pagination, sorting semantics, price-filter behavior, and the core query parameter undefined, so an agent would need to guess at how several parameters interact.

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 0%, so the description should compensate. It adds real meaning for the two opaque parameters (city as an address fragment, category as a section fragment with a concrete example), but leaves query (the required parameter), page, sort, and both price bounds unexplained — those are inferable from their names, but not documented.

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?

States a specific verb and resource ("Поиск на Авито" = search on Avito), which cleanly separates it from read-oriented siblings like avito_listing or avito_read. It does not explicitly name a contrast tool, so it stops short of a 5, but the intent is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus alternatives such as avito_listing or avito_open, nor any prerequisites. Usage is only inferred from the word "Поиск"; the description provides zero routing guidance.

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