How do I use cian-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cian-mcp find 2-room flats in Moscow under 15 million" 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.

cian-mcp

by pom6ac

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

cian-mcp

Локальный MCP-сервер (Python, stdio) для поиска квартир на cian.ru через живой авторизованный браузерный контекст. Подключается к opencode (или любому другому MCP-клиенту) и предоставляет инструменты:

auth_login — ручной вход в видимом браузере (телефон + SMS), сессия сохраняется.
auth_status — проверка валидности сессии.
search_offers — поиск объявлений о продаже квартир по фильтрам.
get_offer — детальная карточка лота с историей цены.

Почему так

У Циана нет покупательского API, а веб защищён агрессивной анти-бот системой (Qrator, JS-challenge, капчи). Основной путь — реальная навигация браузера (page.goto), исполняющая JS и выставляющая нужные куки. context.request используется как ускорение в уже «прогретой» сессии. Подробности — в openspec/changes/cian-search-mcp/design.md.

Related MCP server: HH MCP Server

Требования

Python 3.12+
Десктоп с графическим дисплеем (для auth_login нужен видимый браузер; на headless-сервере или чистом SSH без проброса дисплея вход не сработает).

Установка

make build           # pip install -e . (устанавливает пакет и зависимости)
playwright install chromium   # скачать браузер Playwright

Или вручную:

python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
playwright install chromium

Запуск тестов и линтера

make test     # pytest
make cover    # pytest + coverage (порог 80%)
make lint     # ruff check
make fmt      # ruff format

Запуск сервера

make run      # python -m cian_mcp

Конфигурация opencode

Сервер работает по stdio. Добавьте его в конфиг opencode как локальный stdio MCP-сервер, например:

// opencode.json (или .opencode/config)
{
  "mcp": {
    "cian-search": {
      "type": "local",
      "command": ["python", "-m", "cian_mcp"],
      "cwd": "/path/to/cian"
    }
  }
}

Укажите cwd в корне проекта, чтобы data/ (профиль браузера и БД) создавалась рядом с репозиторием.

Первый вход

Агент вызывает auth_login.
Открывается видимое окно браузера на странице входа Циана.
Вы входите вручную (телефон + SMS-код).
После успешного входа сервер фиксирует сессию; профиль сохраняется в локальную директорию data/browser_profile/.
При последующих запусках авторизованный контекст восстанавливается из профиля.

auth_login идемпотентен: при уже валидной сессии он вернёт сообщение, что вход не требуется.

Примеры вызовов инструментов

auth_login()
  -> { "status": "ok", "message": "Вход выполнен, сессия сохранена ..." }

auth_status()
  -> { "status": "authorized", "message": "Сессия валидна." }

search_offers(city_id=1, rooms=[2], price_min=8000000, price_max=15000000, limit=20, page=1)
  -> { "status": "ok", "page": 1, "limit": 20, "next_page": 2,
       "offers": [ { "offer_id": "...", "url": "...", "price": ..., "price_per_m2": ... }, ... ] }

get_offer(url="https://www.cian.ru/sale/flat/287001234/")
  -> { "status": "ok", "source": "network", "offer_id": "...", "price": ...,
       "price_history": [ {"price": ..., "seen_at": "..."} ], ... }

get_offer поддерживает force_refresh: true — всегда идёт в сеть в обход кэша.

Локальные данные и приватность

Профиль браузера (куки, localStorage) и SQLite-кэш хранятся строго в локальной директории data/, которая добавлена в .gitignore. Значения кук и заголовков авторизации никогда не логируются и не передаются никаким внешним сервисам, кроме самого cian.ru в ходе запросов.

Дисклеймер (ToS Циана)

Использование автоматизированных запросов к cian.ru может противоречить пользовательскому соглашению (Terms of Service) Циана. Этот проект предназначен исключительно для личного использования под собственным аккаунтом, в низком («человеческом») темпе, для помощи в поиске квартиры. Проект не предназначен для массового скрапинга, коммерческого использования или обхода защит. Ответственность за соблюдение применимых правил и законов несёт пользователь.

Available Tools

4 tools

auth_loginA

Открывает видимый браузер для ручного входа на cian.ru (телефон + SMS). Сессия сохраняется в локальный профиль.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries full transparency. It discloses that the browser is visible (not headless), requires manual user interaction (phone and SMS), and persists the session to a local profile. It does not mention error handling or failure modes, but the core behavior is clearly conveyed.

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 concise and well-structured, using only two sentences to convey the action, method, and outcome. There is no unnecessary detail or ambiguity.

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?

The description provides sufficient context for a login action, including the interaction model and session persistence. It does not mention the output schema, but that is likely defined elsewhere; overall, it is complete for the tool's simplicity.

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?

The tool has zero parameters, so there is nothing to elaborate on. The schema coverage is effectively 100%, meriting a neutral baseline score. The description appropriately omits parameter details since none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: opening a visible browser for manual login to cian.ru via phone and SMS. It distinguishes itself from sibling tools (auth_status, search_offers, get_offer) by being the explicit authentication action, while the others focus on status or searching.

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

Usage Guidelines3/5

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

The description implies when to use the tool—when manual login is needed—but it does not explicitly contrast with alternatives such as auth_status for checking existing sessions. The usage context is inferable from the name and sibling set, but not stated directly.

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

auth_statusA

Сообщает, авторизована ли текущая сессия Циана.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that this is a read-only status check and does not suggest mutation, but it does not state that there are no side effects, whether authentication is required to call it, or how errors are handled. The output schema likely covers the return shape.

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 a single, front-loaded sentence that conveys the full purpose without wasted words. It is appropriately sized for a simple zero-parameter status endpoint.

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?

For a zero-parameter tool with an output schema, the description is nearly complete. It could additionally point to auth_login for the login flow or explicitly state that it can be called before other Cian tools, but nothing essential is missing for invoking the tool.

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 parameter semantics are trivially satisfied. The baseline of 4 applies, and the description correctly implies no input is required beyond the current session context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('reports') and resource ('whether the current Cian session is authorized'). It is easy to distinguish from siblings like auth_login, search_offers, and get_offer because it identifies the exact piece of information being returned.

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

Usage Guidelines3/5

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

The intended use is implied: check whether the current session is authenticated, likely before working with offers. However, there is no explicit guidance about when to prefer this tool over auth_login or when to call it relative to other tools.

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

get_offerB

Детальная карточка лота по URL: цена, площади, этаж, метро, тип дома, год, описание, фото и история цены.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`force_refresh`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavior on its own. It does list returned fields, but it does not state whether the operation is read-only, whether authentication is required, what force_refresh does, or what errors or limitations may occur. This is a significant gap for a tool with zero annotation support.

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 one compact, front-loaded sentence that names the operation first and then enumerates the returned data. There is no filler, redundancy, or wasted wording.

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

Completeness2/5

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

An output schema exists, so return values are partly covered, but the description still omits force_refresh semantics, any relationship to search_offers, and behavioral requirements such as authentication. For a tool with no annotations, this is not enough for an agent to reliably select and invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description only restates that the lot is looked up by URL. It says nothing about force_refresh, which is left to be inferred solely from its name and default value. The description fails to compensate for the undocumented parameter.

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 clearly identifies a specific action and resource: retrieving a detailed offer card by URL, and lists the concrete fields returned (price, area, floor, metro, house type, year, description, photos, price history). It does not explicitly contrast it with search_offers, so it stops short of full sibling differentiation.

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

Usage Guidelines3/5

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

The description implies the tool should be used when you already have a URL for a specific lot, but it gives no explicit guidance about when to use it versus search_offers and no prerequisites such as authentication. The usage context is present but implicit.

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

search_offersB

Поиск объявлений о продаже квартир на Циане по фильтрам. Возвращает список лотов с URL и ключевыми фактами.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`limit`	No
`rooms`	No
`city_id`	No
`area_max`	No
`area_min`	No
`metro_ids`	No
`price_max`	No
`price_min`	No
`region_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries the full burden; it discloses only the basic return type (list with URL and key facts) but omits behaviors such as pagination, sorting, data freshness, or 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?

Two short sentences, front-loaded with the action and resource, no redundant wording.

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?

The output schema covers return structure, but the description does not address pagination behavior, filter semantics, or whether authentication is required, leaving some gaps for a 10-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and none of the ten parameters are explained; while names like price_min and area_max are self-explanatory, the description adds no semantics, units, or validation details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states a specific action (search) on a specific resource (apartment sale listings on Cian) and notes that it returns a list of lots with URL and key facts, distinguishing it from single-offer retrieval.

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

Usage Guidelines3/5

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

The description implies usage for filtered list searches through the verb 'search' and 'returns a list', but it does not explicitly state when to use this tool versus get_offer or mention any exclusions.

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. Dates show when Glama detected each change.

4 tool updatesv0.1.0Sep 8, 2026
- First observedauth_login
- First observedauth_status
- First observedget_offer
- First observedsearch_offers

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool maps to a distinct concern: authentication (login/status) versus listing retrieval (search/detail). There is no overlap or confusion between list-level and item-level operations.

Naming Consistency5/5

Tool names follow a clear snake_case verb_noun pattern: auth_login/auth_status share an auth_ prefix, and search_offers/get_offer share the offers resource. The pattern is predictable and easy to navigate.

Tool Count5/5

Four tools is well-scoped for a focused Cian real estate browsing server: two for session management and two for offer discovery/detail. No tool feels redundant.

Completeness5/5

The surface covers the full read-only workflow: authenticate, verify session, search listings, and retrieve full offer details. No critical missing operation exists for the apparent purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

срезAI — Search API for AI agents A
ru.srezai
Web search, page reading and structured extraction for AI agents, with strong RU coverage
Browser Automation Web Scraping Search
101
Aginx Browser A
net.aginx
Stealth web browser for agents: search, fetch, click, download and type in persistent MCP sessions.
Browser Automation Agent Orchestration
28114
scrapeless-mcp-server
io.github.scrapeless-ai
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
1168
agent-web-actions
com.trycloudflare.plates-spread-materials-optimum
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Browser Automation Agent Orchestration
2

Related MCP Servers

mcp-amazon
E-commerce & Retail Browser Automation
markswendsen-code
A
license
Not graded
quality
D
maintenance
Enables AI agents to search products, manage cart, place orders, and track shipments on Amazon via browser automation.
Updated 6 months ago (2026-03-16 04:07 UTC)
27
1
MIT
HH MCP Server
Browser Automation Web Scraping
iraguzov
F
license
A
quality
D
maintenance
Enables to interact with hh.ru (a Russian job platform) through browser automation, allowing users to search for jobs, manage resumes, apply to vacancies with cover letters, and track application statuses via natural language.
Updated 5 months ago (2026-04-09 12:39 UTC)
9
3
-
zillow-mcp
Real Estate Search
chrischall
A
license
A
quality
A
maintenance
Enables natural-language access to Zillow real-estate data, including property search, details, Zestimate history, saved searches/homes, and market reports, by routing requests through the user's authenticated browser session.
Updated 3 days ago (2026-09-05 12:53 UTC)
5
20
612
MIT
redfin-mcp
Real Estate Search Web Scraping
chrischall
A
license
A
quality
A
maintenance
Enables natural language access to Redfin real estate data, including property search, details, photos, market reports, price history, climate risk, and saved homes/searches, by routing requests through your own signed-in browser session.
Updated 3 days ago (2026-09-05 12:23 UTC)
21
592
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pom6ac/cian-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server