Avito Personal MCP
The server provides a local, read-only-first MCP interface to your own authenticated Avito web session, plus one guarded write tool.
avito_selfcheck: verify the MCP server can reach the user-controlled Chrome session and detect an open Avito tab.avito_me: return the authenticated Avito profile identity.avito_search: search Avito listings.avito_get_listing: fetch details of a specific listing.avito_my_listings: list the authenticated user's own listings.avito_favorites: access the user's favorite listings.avito_chats: list Avito chats/conversations.avito_chat_messages: read messages in a chat.avito_send_message: send a chat message, guarded by a two-step confirmation token to prevent accidental duplicate sends.
It attaches to a dedicated Chrome session over loopback CDP, requires manual Avito sign-in, and never handles passwords, cookies, tokens, or CAPTCHA/anti-bot bypass.
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 Personal MCPshow me my unread chat messages"
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.
Avito Personal MCP
Unofficial, local-first MCP server for personal Avito accounts. It lets an MCP-capable AI client work with your own Avito account through a dedicated browser session — without requiring Avito Developer API credentials.
This project is independent and is not affiliated with, endorsed by, or maintained by Avito.
Why this project exists
Many Avito integrations are built around official developer/business APIs or public listing parsing. Avito Personal MCP is aimed at a different use case: an ordinary user who wants an AI assistant to work with the Avito account they already use in the browser.
The user signs in to Avito manually in a dedicated Chrome profile. The MCP server then attaches to that already authenticated browser over Chrome DevTools Protocol (CDP).
No Avito Developer Client ID or Client Secret is required. The project also does not ask users to provide Avito passwords, SMS/OTP codes, cookies, authorization headers, session tokens, or exported browser storage state.
This makes the project suitable for personal-account workflows such as:
searching Avito and inspecting individual listings;
reviewing your own listings;
reviewing your favorites;
reading your Avito conversations and message history;
preparing and explicitly confirming a message before it is sent.
It is not intended to bypass Avito authentication, CAPTCHA, anti-bot controls, account restrictions, or access controls.
Related MCP server: avito-scraper
What it does
Avito Personal MCP exposes a local-first MCP interface over the user's own Avito web session. Authentication remains in the dedicated browser controlled by the user rather than being copied into MCP configuration.
Current MCP tools
Read-only tools:
avito_selfcheckavito_meavito_searchavito_get_listingavito_my_listingsavito_favoritesavito_chatsavito_chat_messages
Guarded write tools:
avito_send_message
avito_send_message is deliberately two-step. The first call only returns a sanitized preview and a short-lived one-time confirmation token. A second call with the same chat id, the same message text, and that token performs one send attempt. The MCP does not automatically retry a send because a retry could create a duplicate message.
Requirements
Python 3.11, 3.12, 3.13, or 3.14
Google Chrome or another compatible Chromium browser with CDP support
a dedicated browser profile for this project
manual Avito authentication by the user
Installation
Clone the repository and install the package into a virtual environment:
git clone https://github.com/AlexButiev/avito-personal-mcp.git
cd avito-personal-mcp
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install .Run the MCP server over stdio:
avito-personal-mcpThe console entry point is installed by the package and does not require a repository-local PYTHONPATH.
Dedicated Chrome session
Use a separate Chrome profile. Do not reuse a normal browser profile that also contains banking, email, work, or other sensitive accounts.
On macOS:
open -na "Google Chrome" --args \
--user-data-dir="$HOME/.avito-personal-mcp/chrome-profile" \
--remote-debugging-address=127.0.0.1 \
--remote-debugging-port=9222 \
"https://www.avito.ru"Then sign in to Avito manually inside that Chrome window. Do not put Avito credentials, cookies, tokens, or browser storage in MCP client configuration.
CDP security
Keep CDP bound to loopback only (127.0.0.1). Do not expose port 9222 to the LAN, Internet, a public tunnel, or an untrusted container/network namespace. A process that can reach the CDP endpoint can potentially control the attached browser session.
MCP client configuration
The server uses stdio. A generic MCP client configuration looks like this:
{
"mcpServers": {
"avito": {
"command": "/absolute/path/to/.venv/bin/avito-personal-mcp"
}
}
}Use the actual absolute path to the installed console script on your machine. No Avito credentials or session material belong in this configuration.
Chrome and the MCP server are separate processes: start the dedicated Chrome session first, sign in manually if needed, then let the MCP client launch avito-personal-mcp.
Codex and ChatGPT desktop app
On one Mac, the ChatGPT desktop app, Codex CLI, and the Codex IDE extension can
share the same ~/.codex/config.toml MCP configuration. Add the installed
avito-personal-mcp command there and restart the client; /mcp listing
avito verifies that the server can launch. It does not by itself make Avito
available in an ordinary ChatGPT conversation. For that experience, install
the matching local Avito Personal plugin, start a new ordinary chat, and
first confirm a safe avito_selfcheck call before relying on natural-language
requests.
Keep avito_send_message on prompt/approval and leave
avito_chat_messages on prompt unless you accept Avito's normal behaviour that
opening a conversation can mark it read. The configuration and the separate
private Secure MCP Tunnel route for ChatGPT on the web are documented in
docs/CHATGPT_CONNECTION.md.
Terminal fallback: avito-ai
avito-ai is a small terminal client for the same local MCP surface. It is useful
when the AI client cannot yet attach to the MCP server directly, or when you want
to copy a compact, structured result into a chat.
avito-ai selfcheck
avito-ai --compact search "мини ПК для HomeLab" --limit 10
avito-ai --compact search "ноутбук" --min-price 10000 --max-price 100000 --sort price_asc --limit 10
avito-ai listing OWN_LISTING_ID
avito-ai listing '<exact-Avito-URL-copied-from-browser-or-search-result>'
avito-ai messages CHAT_ID --limit 20Search price and sort
avito_search accepts optional min_price, max_price, and sort arguments;
the same options are exposed by avito-ai search as --min-price,
--max-price, and --sort. Price bounds are non-negative integers and the
maximum cannot be below the minimum. Supported sort values are:
default— Avito's normal result order;price_asc/price_desc— lower or higher price first;date_desc— newest first;discount_desc— larger discount first.
The server uses Avito's rendered price inputs and sort menu, then verifies that the visible result set refreshed. It does not construct undocumented search URLs or pass arbitrary filter selectors from a client. Category-specific filters, location, and pagination are intentionally deferred until each has its own stable UI observation and fail-closed acceptance.
A bare numeric ID is deliberately supported only for one of your own
listings: the server first finds its observed URL in the authenticated profile.
For another public listing, pass its exact same-origin Avito URL, copied from the
browser or returned by avito_search. The server never guesses a listing URL
from a numeric ID, because Avito paths include volatile location/category/slug
segments and a guessed path is neither reliable nor safe.
The command launches the installed avito-personal-mcp console entry point from
the same Python environment, not a repository checkout or a private browser
helper. It therefore exercises the packaged MCP path while keeping Chrome, CDP,
and all Avito authentication material outside the CLI configuration. The bridge
currently exposes read-only commands only; guarded message sends remain available
only through the explicit two-phase MCP tool.
To use a different loopback CDP port, set the documented server setting for
the individual command; avito-ai forwards only this setting to its child MCP
server and does not forward other shell environment values:
AVITO_MCP_CDP_URL=http://127.0.0.1:9333 avito-ai selfcheckArchitecture
MCP client
|
v
Avito Personal MCP
|
+-- browser/session layer
+-- profile discovery
+-- search/listings
+-- favorites
+-- chats/messages
+-- guarded confirmations for writes
+-- diagnostics
|
v
Dedicated user-controlled Chrome session (CDP on loopback)
|
v
avito.ruThe implementation prefers browser-visible page state and frontend behavior observed in the user's own authenticated session. It does not guess private endpoints and does not attempt to bypass CAPTCHA or anti-bot controls.
Behavioral caveats
Opening an Avito conversation can cause Avito itself to mark that conversation as read. avito_chat_messages does not intentionally send, edit, delete, react to, or otherwise mutate messages, but normal page navigation can still affect read state.
Browser-driven operations are inherently coupled to Avito's current DOM. The project therefore treats unexpected DOM changes as errors rather than silently pretending an empty result is valid.
Safety principles
Local-first authentication/session state.
No Avito Developer API credentials required for the current browser-session workflow.
No Avito credentials committed to the repository.
No CAPTCHA bypass, stealth circumvention, or automated OTP handling.
CDP stays on loopback only.
Dedicated Chrome profile only; do not use it for unrelated sensitive accounts.
Read operations are separated from write operations.
Write operations require explicit confirmation safeguards.
Message sends are never automatically retried after an irreversible click.
Logs/tests must not contain passwords, cookies, authorization headers, session tokens, browser storage state, or real private-message fixtures.
See SECURITY.md for the security policy.
Troubleshooting
chrome_unreachable
Confirm the dedicated Chrome instance is running with --remote-debugging-address=127.0.0.1 --remote-debugging-port=9222 and that no firewall/container boundary prevents the local MCP process from reaching it.
no_avito_tab
Open https://www.avito.ru in the dedicated Chrome window.
Authentication unavailable / login redirect
Sign in manually in the dedicated Chrome window. Do not paste credentials, cookies, or tokens into MCP configuration.
DOM mismatch / unavailable data
Avito may have changed its frontend. Fail closed and update selectors only after observing the new browser behavior. Do not guess internal APIs or weaken authentication checks.
Development
Install development dependencies:
python -m pip install -e '.[dev]'Run local checks:
pytest
ruff check .GitHub Actions runs sanitized unit tests and Ruff on Python 3.11, 3.12, 3.13, and 3.14 without Avito credentials or a real browser session. Live CDP acceptance is intentionally separate from CI.
Project status
0.1.0rc3 is the current public release candidate. It adds the packaged
avito-ai fallback, data-minimized diagnostics, Gate 12 acceptance fixes, and
the first stable price/sort search controls to the read-only foundation and
guarded message-send path. Browser-driven integrations can still break when
Avito changes its frontend, so treat the release candidate as experimental until
the final release is promoted.
See CHANGELOG.md for release notes and docs/ROADMAP.md for the capability boundary, safety model, and planned development order. See docs/CHATGPT_CONNECTION.md for the local desktop connection and the private-tunnel runbook for ChatGPT on the web.
License
MIT. See LICENSE.
Available Tools
2 toolsavito_meB
Return the authenticated Avito profile identity.
Profile discovery is deliberately not guessed from undocumented endpoints. It will be implemented after observing the user's real authenticated browser session and identifying a stable, minimally privileged source of truth.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does add context beyond the name: it is a read-oriented return of identity and it explicitly discloses that profile discovery is not guessed from undocumented endpoints and will be implemented later. However, it does not state what happens on an unauthicated call or whether the tool currently returns data or an 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?
The essential purpose is front-loaded in the first sentence. The following two sentences explain a deliberate implementation decision, which is useful context for an agent deciding whether the tool is reliable. It is slightly verbose for the point being made, but still compact and readable.
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 zero-input tool with an output schema, the description covers the main need: it identifies the resource and warns that implementation is pending. However, the contradiction between 'Return' and 'will be implemented' leaves ambiguity about whether the tool is currently callable, and no guidance is given about what to do instead.
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?
The tool has zero parameters and the schema coverage is vacuously 100%, so parameter semantics are not at issue. The baseline for a zero-parameter tool is 4, and the description does not need to explain parameter meanings.
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 first sentence, 'Return the authenticated Avito profile identity,' names a specific verb, resource, and scope. It does not explicitly distinguish from the sibling avito_selfcheck, but the resource ('profile identity') is clear. The later implementation caveat slightly muddies current functionality but does not obscure the intended purpose.
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?
No guidance is given for when to use this tool versus avito_selfcheck or any alternative. The description notes that discovery 'will be implemented after observing the user's real authenticated browser session,' implying unavailability, but it never states when to call it or what conditions should route an agent elsewhere.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
avito_selfcheckA
Check whether the MCP server can reach the user-controlled Chrome session.
This diagnostic is intentionally non-invasive. It only enumerates open page URLs/titles and reports whether an Avito tab is currently visible.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly says the check is 'intentionally non-invasive' and describes exactly what it does: enumerate open page URLs/titles and report whether an Avito tab is visible. This is transparent and sets appropriate expectations for side effects.
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?
The description is two concise sentences. The primary purpose is front-loaded, and the second sentence adds valuable non-invasive context without unnecessary detail. Every sentence earns its place.
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 zero-parameter diagnostic tool with an output schema available, the description is complete. It defines the purpose, scope, non-invasive nature, and the specific signal it reports. An agent has enough information to decide whether and when to invoke 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?
The tool has zero parameters, so the baseline is 4. There are no parameter semantics to explain, and the description appropriately focuses on behavior rather than inputs.
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 action and resource: 'Check whether the MCP server can reach the user-controlled Chrome session.' It also clarifies the exact scope by saying it only enumerates open page URLs/titles and reports whether an Avito tab is visible. It does not explicitly differentiate from the sibling tool avito_me, so it falls just short of 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?
The description gives clear context for use: this is a non-invasive connectivity diagnostic for verifying access to the Chrome session. It does not state when to prefer avito_me instead, nor does it name any alternatives, but the diagnostic purpose is sufficiently clear for an agent to know when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
avito_me - First observed
avito_selfcheck
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one checks whether the MCP server can reach the user's Chrome session, and the other returns the authenticated Avito profile identity. There is no overlap or risk of choosing the wrong tool for a task.
Both tool names share the 'avito_' prefix and use snake_case, which provides some consistency. However, 'selfcheck' and 'me' follow different naming conventions, and neither follows the more common verb_noun pattern, making the naming schema somewhat mixed but still readable.
With only two tools, the server feels thin and leaves the impression of an early-stage or deliberately minimal implementation. The count is borderline appropriate given the diagnostic-first positioning, but it does not yet feel like a substantive toolset.
For a server branded as 'Avito Personal MCP', the surface is incomplete: there are no operations for managing listings, messages, favorites, or other common personal account activities. The current tools only cover session reachability and profile identity, leaving significant gaps for most real workflows.
Maintenance
Related MCP Connectors
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
Read-only MCP for Copart and IAA/IAAI search, history, filters, locations, shipping, and usage.
Agent social posting via your logged-in Chrome. Remote MCP + OAuth. Not clawpost.dev.
1Search, organize, and chat with your saved Reddit posts from Claude, Cursor, and any MCP client.
Related MCP Servers
- AlicenseAqualityAmaintenanceUniversal MCP server for the Avito API (Russia's largest classifieds marketplace), built for autonomous AI agents to operate an account hands-free — 145 tools across 18 domains (listings, messenger, orders, delivery, promotion, autoload, reviews, analytics). Safe-by-default: dry-run, idempotency, structured errors, confirmation flow.144155 npm17MIT
- FlicenseNot gradedqualityDmaintenanceMCP server for searching and retrieving details from Avito listings, enabling integration with Claude Desktop.43-
- AlicenseNot gradedqualityAmaintenanceЛокальный MCP-сервер, дающий ИИ-агенту read-only доступ к задачам, проектам и чатам Bitrix24 в объёме прав пользователя — через браузерное расширение, переиспользующее живую сессию. Без прав администратора и без официального REST-вебхука.6 npmMIT
- AlicenseAqualityAmaintenanceMCP server that reads product data from Russian and Chinese marketplaces (Wildberries, Ozon, Yandex Market, Avito, etc.) — prices, availability, ratings, reviews, and seller details — with price comparison across sources. Requires no API keys; some sources use your Chrome session for anti-bot access.40107MIT