Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Avito MCP Server найди на Авито iPhone 13 в Москве до 50000 рублей"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Кроссплатформенный Model Context Protocol (MCP) сервер для интеграции AI-ассистентов (Claude, Cursor, Antigravity и др.) с платформой Авито (Avito.ru).
Поддерживает Windows, macOS и Linux.
Позволяет агенту искать объявления, анализировать состояние товаров и продавцов, читать чаты и вести диалог / торговаться от имени вашего аккаунта.
avito_search — поиск по ключевым словам, городу, диапазону цен и сортировке (с превью-фотографиями)
avito_get_item_details — получение полной карточки товара (фотогалерея лота, описание, характеристики, статус бронирования, наличие Авито Доставки, рейтинг продавца)
avito_download_images — выгрузка фотографий объявления на диск для визуального анализа AI-моделью (осмотр состояния, чипов, разъемов, маркировок)
avito_send_message — отправка сообщения продавцу в чат по объявлению (для торга или уточнения деталей)
avito_list_chats — список недавних диалогов в мессенджере с превью и статусом непрочитанных
avito_get_chat_history — чтение истории сообщений в конкретном чате
Related MCP server: cian-mcp
Node.js >= 18
Установленный браузер: Google Chrome, Microsoft Edge или Chromium (на macOS и Windows находится автоматически; на Linux ищутся стандартные пути в /usr/bin/ или задаются через переменную).
Задайте вашему ии-ассистенту этот промт:
Привет моя дорогая нейросеть! Можешь пожалуйста установить MCP сервер авито из этого репозитория : https://github.com/foorsee/avito-mcp-server. Сделай все хорошо, чтоб я даже руками ничего не трогал, потому что я в тебя верю. Спасибо!git clone https://github.com/foorsee/avito-mcp-server.git
cd avito-mcp-server
npm installДля того чтобы сервер мог писать продавцам и читать чаты от вашего имени:
Windows: запустите login_avito.bat или выполните:
npm run loginmacOS / Linux: выполните:
chmod +x login_avito.sh
./login_avito.sh
# или
npm run loginОткроется окно браузера. Войдите в свой профиль на Авито по номеру телефона / СМС и нажмите ENTER в консоли. Сессия сохранится локально в папке avito-data (эта папка находится в .gitignore и никогда не попадает в репозиторий).
Для headless Linux серверов (без дисплея): Авторизуйтесь на компьютере с монитором (Windows или macOS), а затем просто скопируйте созданную папку
avito-dataна ваш Linux-сервер в корень проекта.
Добавьте сервер в ваш файл конфигурации (mcp_config.json или claude_desktop_config.json):
{
"mcpServers": {
"avito": {
"command": "node",
"args": [
"C:/Users/<Username>/Documents/avito-mcp-server/avito_server.mjs"
]
}
}
}{
"mcpServers": {
"avito": {
"command": "node",
"args": [
"/home/<username>/avito-mcp-server/avito_server.mjs"
]
}
}
}Если вы используете Gemini Desktop на macOS, приложение запускает MCP-серверы внутри защищенной песочницы (Seatbelt Sandbox), которая блокирует прямой запуск сторонних процессов через Mach Ports.
Сервер автоматически поддерживает подключение к Chrome через Chrome DevTools Protocol (CDP):
Запуск в фоне (разово в терминале):
npm run cdpЛибо установка фонового демона на macOS (LaunchAgent): Браузер будет автоматически запускаться при входе в систему и работать в фоне:
npm run daemon:install(Для удаления: npm run daemon:uninstall)
Сервер avito_core.mjs автоматически обнаружит запущенный на порту 9222 браузер и подключится к нему через CDP.
Если при частых запросах Авито временно заблокировало доступ («Доступ ограничен: проблема с IP») или запросило решение слайдер-пазла (GeeTest):
npm run solveОткроется окно браузера. Переместите слайдер (сложите пазл), скрипт автоматически определит прохождение капчи, обновит куки и перезапустит фоновый сервис.
AVITO_DATA_DIR — путь к директории хранения сессии (по умолчанию папка ./avito-data в корне проекта).
AVITO_CHROME_PATH (а также CHROME_PATH, PUPPETEER_EXECUTABLE_PATH) — путь к конкретному исполняемому файлу браузера (Chrome/Chromium), если он установлен в нестандартном месте.
AVITO_HEADLESS — принудительно включить (true) или выключить (false) headless-режим. По умолчанию на десктопах с монитором браузер работает в окне за пределами экрана, а на серверах Linux без дисплея — безголовым.
AVITO_CDP_URL — адрес для подключения по CDP (по умолчанию http://127.0.0.1:9222).
AVITO_CDP_PORT — порт отладки для скрипта npm run cdp (по умолчанию 9222).
AVITO_NO_SANDBOX — принудительно включить флаг --no-sandbox (на Linux под root или в Docker включается автоматически).
Все куки, токены авторизации и профиль браузера сохраняются исключительно локально на вашем компьютере в директории avito-data/.
Папка avito-data/ внесена в .gitignore. Никакие персональные данные, телефоны или пароли не передаются третьим лицам и не сохраняются в репозитории.
Сервер запускает системный браузер локально в фоне, обходя детекты автоматизации и проверки безопасности (Qrator).
MIT License.
Download photos from an Avito listing to local disk for visual AI inspection. Returns array of local file paths and image URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Item URL or item ID | |
| limit | No | Max photos to download (default 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that files are written to local disk and that the return value contains local paths and image URLs, but it does not mention permissions, rate limits, overwrite behavior, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences front-load the action and resource, then state the return shape. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter download tool with full schema documentation, the description covers purpose, side effect, and return format adequately. It could optionally mention where files are saved or how failures are handled, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the two parameters are already documented in the input schema. The description adds no additional parameter semantics beyond what the schema provides, making 3 the appropriate baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: download photos from an Avito listing to local disk. It also clarifies the intended use for visual AI inspection, which cleanly distinguishes it from siblings like search, item details, and messaging tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for visual AI inspection' implies when this tool is useful, but there is no explicit guidance on when to choose it over avito_get_item_details or other siblings. No exclusions or preconditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read message history in an active Avito chat to check seller responses.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max messages to return | |
| chat_url | No | URL of the specific chat or empty for active chat |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It clarifies that this is a read operation, but it does not disclose message ordering, pagination behavior, what happens when no active chat exists, authentication requirements, or what the returned payload contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single front-loaded sentence with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with a fully described schema, the description is adequate but thin. Because there is no output schema, it should do more to indicate what the returned message history looks like or how limits affect it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains limit and chat_url. The description adds no parameter-level details beyond implying the active-chat default, which the schema also states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Read message history in an active Avito chat.' It is distinct from siblings like avito_send_message and avito_list_chats, though it does not explicitly name them and 'active chat' slightly conflicts with the chat_url parameter that can point to a specific chat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to check seller responses' implies the use case, but the description gives no explicit when-to-use versus alternatives, no prerequisites, and no exclusions. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of an Avito listing: title, price, description, seller rating/reviews, parameters, delivery status and messaging capability.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL of the listing or item ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It usefully discloses the shape of the returned data (title, price, seller rating, delivery status, messaging capability), which implies a read operation, but says nothing about authentication, rate limits, or error behavior when a listing is unavailable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. Every clause contributes either the action or the set of returned fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read with no output schema, the description does the useful work of enumerating the returned fields and signaling messaging capability. It is nearly complete; only auth and failure-mode context is missing, which is minor here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single 'url' parameter is fully documented as accepting a full URL or an item ID. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('full details of an Avito listing') and enumerates the returned fields, so an agent can tell it is a single-listing fetch. It does not explicitly distinguish itself from the sibling avito_search, which also returns listing data, so it misses the top band.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent would infer it calls this when it has a listing URL or ID and needs full details. There is no explicit statement of when to prefer this over avito_search or of any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent chats from the user's Avito messenger. Requires prior login.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max chats to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the auth prerequisite and implies a read-only listing operation, but it does not describe return shape, ordering, or whether limit affects recency—gaps that matter without annotations or an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core operation and followed by the prerequisite. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description covers purpose and login requirement. But with no annotations and no output schema, it should say more about what a 'chat' summary includes or how results relate to 'avito_get_chat_history'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'limit' parameter is fully documented in the schema. The description adds no further parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List recent chats from the user's Avito messenger'), making the operation immediately clear. It does not, however, distinguish this tool from the sibling 'avito_get_chat_history', which an agent could easily confuse with it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It adds a prerequisite ('Requires prior login'), which is useful usage context. But it gives no explicit guidance on when to choose this over 'avito_get_chat_history' or other siblings, so the usage 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.
Search for listings on Avito by query, location, price range and sort order.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order | default |
| limit | No | Max results to return | |
| query | Yes | Search query, e.g. 'iphone 15 pro', 'rtx 4070' | |
| location | No | City or region, e.g. 'moskva', 'sankt-peterburg', 'all' | all |
| price_max | No | Maximum price in RUB | |
| price_min | No | Minimum price in RUB |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not disclose read-only behavior explicitly, rate limits, pagination, result format, or authentication requirements, leaving key behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single, front-loaded sentence with no redundant or filler content. The core purpose and filter dimensions are immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, including a limit and an enum sort, and no output schema. The description covers the main filters but omits result/return behavior and pagination, leaving some useful context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters with examples and defaults. The description only restates the main filter dimensions and does not add syntax, constraints, or meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('Search') and resource ('listings on Avito') and names the filtering dimensions. It is clearly distinct from siblings such as avito_get_item_details and avito_send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what can be searched but gives no explicit when-to-use guidance, no alternatives, and no workflow context (e.g., use this before avito_get_item_details). Usage is only inferable from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to a seller on Avito to negotiate or ask questions. Requires prior login via npm run login.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Item URL or direct chat URL | |
| message | Yes | Text of the message to send |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It usefully states the auth prerequisite, which is real behavioral context, but says nothing about failure modes when not logged in, rate limits, whether the send is idempotent, or what the call returns on success or error.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the action front-loaded and the prerequisite immediately following. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A mutation tool with no annotations and no output schema needs more than purpose plus an auth note; the description omits post-send behavior and error handling. For a two-parameter tool with fully documented schema it is adequate but leaves behavioral gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters including the item-URL-or-chat-URL flexibility are already documented. The description adds no parameter-level detail beyond the schema, which is the expected baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Send a message to a seller on Avito') and its intent ('to negotiate or ask questions'), which is clearly distinct from the read-oriented siblings like avito_get_chat_history and avito_list_chats. It stops short of naming any sibling explicitly, so it lands at a solid 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a reason to use the tool ('negotiate or ask questions') and a critical prerequisite ('Requires prior login via npm run login'), but offers no explicit guidance on when to prefer it over checking existing chats first or what conditions should block use. Usage is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0avito_download_imagesavito_get_chat_historyavito_get_item_detailsavito_list_chatsavito_searchavito_send_messageScored across 6 tools
Each tool targets a distinct resource+action: search (query listings), get_item_details (single listing), send_message (outbound messaging), list_chats (conversation index), get_chat_history (messages within a chat), download_images (media retrieval). The messaging trio is cleanly separated by scope (send vs. list vs. read), and download_images has no overlap with anything else.
All six tools use the same avito_ prefix followed by a snake_case verb_noun pattern (get_item_details, send_message, list_chats, get_chat_history, download_images). The single bare verb (avito_search) is still read as a domain-scoped action and is consistent with the rest of the set.
Six focused tools cover a marketplace browse-and-message workflow without redundancy; every tool maps to a real step in the search → inspect → contact → follow-up loop. Nothing feels padded or missing from a count perspective.
The core lifecycle (search, listing details, image inspection, send message, list chats, read history) is covered with no dead ends for the main workflow. Minor gaps remain: authentication is pushed to an external 'npm run login' step with no tool to trigger or verify login state, and there is no favorites/watchlist or own-listings retrieval.
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
Hosted browser for agents: open pages, search the web, extract data, read PDFs and take screenshots.
Control a real browser from AI agents: navigate, click, type, screenshot, read the page.
Let your AI agent operate any website through a real, logged-in browser session.