Skip to main content
Glama
AlexButiev

Avito Personal MCP

by AlexButiev

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.

IMPORTANT

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_selfcheck

  • avito_me

  • avito_search

  • avito_get_listing

  • avito_my_listings

  • avito_favorites

  • avito_chats

  • avito_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-mcp

The 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 20

Search 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 selfcheck

Architecture

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.ru

The 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 tools
avito_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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

  1. 2 tool updatesv0.1.0
    • First observedavito_me
    • First observedavito_selfcheck

TDQS

A3.6/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency3/5

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.

Tool Count3/5

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.

Completeness2/5

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

ActivityMaintained
ResponsivenessUnresponsive

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    A
    maintenance
    Universal 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.
    144
    155 npm
    17
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Локальный MCP-сервер, дающий ИИ-агенту read-only доступ к задачам, проектам и чатам Bitrix24 в объёме прав пользователя — через браузерное расширение, переиспользующее живую сессию. Без прав администратора и без официального REST-вебхука.
    6 npm
    MIT
  • A
    license
    A
    quality
    A
    maintenance
    MCP 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.
    40
    107
    MIT