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., "@ss-ge-mcp Find apartments for rent in Vake under $1000"
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.
MCP-сервер над home.ss.ge
Прозрачный stateless-прокси: один вызов инструмента = один-несколько живых запросов. Между вызовами не хранится ничего, кроме токена (TTL 1 час) и гео-справочника.
У ss.ge нет публичного API. Контракт восстановлен реверс-инжинирингом и проверен живыми запросами -- разбор в docs/API.md.
claude mcp add ss-ge --scope user -- npx -y ss-ge-mcp@1Нужен Node >= 20. Клонировать и ставить вручную ничего не надо: npx сам скачает пакет
из npm и закеширует. @1 фиксирует мажорную версию -- обновления внутри неё приезжают
сами, ломающий релиз молча не подменит сервер.
Для клиентов с JSON-конфигом (Claude Desktop, Cursor, Windsurf):
{
"mcpServers": {
"ss-ge": {
"command": "npx",
"args": ["-y", "ss-ge-mcp@1"]
}
}
}git clone https://github.com/nosuchip/ss-ge-mcp && cd ss-ge-mcp && npm install
claude mcp add ss-ge --scope user -- node "$PWD/src/index.mjs"
npm test # смоук-тест, ходит в сеть по-настоящемуRelated MCP server: naver-land-mcp
Инструмент | Что делает |
| Инструкции: |
| Счётчики по фильтру, без выкачивания. Один дешёвый запрос |
| Поиск. |
| Полная карточка: удобства, координаты, кадастр, просмотры, контакт |
| Районы и микрорайоны города с id |
| Города и курс USD/GEL |
Фильтр принимает человеческие названия: subdistricts: ["Ваке", "Сабуртало"], и название района раскрывается во все его микрорайоны.
Свежесть. Настоящая дата публикации приходит только в mode="paged". В mode="fast" и в listing API отдаёт незаполненную дату, поэтому published там честно null -- это "неизвестно", а не "свежее". Поле bumped -- дата платного поднятия, у топовых объявлений почти всегда "сегодня"; признаком свежести не является.
Счётчики. Их три, и они не совпадают. Для одного фильтра: cards 15 046,
applications 50 197, mapped 23 337. Это карточки после схлопывания дублей,
сырые объявления и объекты с координатами соответственно. Ни одно не равно
"числу уникальных квартир" -- одно жильё часто висит несколькими объявлениями. Сервер отдаёт все три с пояснением и не выбирает "главное".
Молчаливые фильтры. API игнорирует неизвестные поля без ошибки, а ценовой фильтр
без priceType -- тоже без ошибки. Опечатка давала бы не ошибку, а полную выдачу
под видом отфильтрованной. Поэтому имена полей валидируются на входе, а priceType
подставляется автоматически.
Отдельно: фильтра по району в API нет вообще (districtIds сайт кладёт в URL,
но сервер его игнорирует), поэтому район разворачивается в список микрорайонов.
Темп 1 запрос/сек глобально, честный User-Agent -- сервер не выдаёт себя за браузер
(проверено: ss.ge отдаёт данные и без маскировки). На 403 или 429 размыкается
предохранитель и остаётся разомкнутым: это осознанно, повторять запросы нельзя.
Токен берётся оттуда же, откуда его берёт браузер: ss.ge кладёт готовый анонимный
JWT в __NEXT_DATA__ каждой страницы. Никаких чужих секретов в конфиге не хранится.
api-gateway.ss.ge/robots.txt содержит User-agent: * / Disallow: / -- шлюз запрещает
автоматический доступ целиком. Этот сервер его не соблюдает.
Обоснование: robots.txt -- протокол исключения для краулеров, а здесь клиент выполняет конкретный запрос конкретного пользователя, не обходит и не индексирует сайт. Но это именно интерпретация, а не разрешение: оператор явно выразил нежелание видеть автоматический доступ. Соблюдай темп, не выкачивай базу целиком и понимай, что формальных прав на это у тебя нет.
Публичного контракта у API тоже нет: buildId фронта меняется с каждым деплоем,
структура может поехать в любой момент. Для личного поиска -- приемлемо;
как на стабильный источник данных закладываться не стоит.
Переменная | По умолчанию | Смысл |
|
|
|
|
| Минимальный интервал между запросами |
MIT — см. LICENSE.
Города, по которым ss.ge ведёт выдачу, и текущий курс USD/GEL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose the returned data points. However, it omits any note on read-only safety, data freshness, currency source, caching, or authentication needs for what appears to be a simple reference lookup.
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. It efficiently communicates both returned values and earns every word.
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?
Because there is no output schema, the description must state what is returned, and it names both the city list and the USD/GEL rate. For a zero-parameter reference tool this is nearly complete, though missing update frequency or currency source leaves a small gap.
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 takes zero parameters, so there is nothing for the schema or description to document. The baseline for a parameterless tool 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?
The description clearly states the two things returned: cities where ss.ge has listings and the current USD/GEL rate. It is specific enough to distinguish from most siblings, though it does not explicitly contrast itself with the overlapping 'geo' tool.
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 on when to use this tool versus alternatives such as 'geo' or 'listing'. The description only states what the tool returns, leaving usage conditions entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Считает результаты по фильтру, не выкачивая их — один дешёвый запрос. Годится, чтобы проверить осмысленность критериев и сравнить варианты фильтра. Возвращает два несовпадающих счётчика; сообщай их раздельно.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | название или id города, напр. «Тбилиси» или 95 | Тбилиси |
| deal | Yes | тип сделки | |
| rooms | No | число комнат, напр. [2,3] | |
| estate | No | тип недвижимости | flat |
| area_max | No | площадь до, м² | |
| area_min | No | площадь от, м² | |
| currency | No | валюта цены в фильтре | USD |
| features | No | булевы удобства: elevator, furniture, heating, balcony, garage, withImageOnly и др. | |
| price_max | No | верхняя граница цены | |
| price_min | No | нижняя граница цены | |
| price_per_m2 | No | цена задана за м², а не целиком | |
| subdistricts | No | микрорайоны или районы по названию/id. Название района раскрывается во все его микрорайоны — отдельного фильтра по району в API нет |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It usefully discloses that this is a single cheap request that does not fetch listings and that it returns two non-matching counters to be reported separately — non-obvious behavior. However it never explains why the two counters differ or what each represents, and says nothing about read-only nature, limits, or auth.
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?
Three tight sentences, front-loaded with what the tool does and the cheapness rationale, with no filler. The final sentence carries a critical, non-obvious output caveat rather than padding.
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?
With 12 parameters and no output schema, the description must carry return-value meaning, and it only partially does: it names 'two non-matching counters' without explaining what distinguishes them. Parameter meaning is fully covered by the schema, so the gap is confined to the ambiguous return semantics.
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% across 12 well-documented parameters, so the schema does the heavy lifting and the baseline is 3. The description adds no parameter-level 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?
States a specific verb and resource ('считает результаты по фильтру') and clarifies scope ('не выкачивая их'), which implicitly contrasts it with the download-heavy sibling 'search'. It does not name a sibling explicitly, so it stops 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?
Gives concrete when-to-use guidance: validating that criteria are meaningful and comparing filter variants. No explicit when-not-to-use or named alternative, but the use case is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Районы города и их микрорайоны с id. Нужен потому, что фильтровать по району через API нельзя — только перечислением микрорайонов. search() принимает названия и резолвит их сам; этот инструмент — посмотреть доступное или снять неоднозначность.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | название или id города | Тбилиси |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It helpfully reveals the non-obvious API constraint about district filtering, but says nothing about whether the call is read-only, what the response shape is, or whether results are static/cacheable. Adequate but incomplete for an annotation-free tool.
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?
Three sentences, each carrying distinct load: the resource, the reason the tool is needed, and the routing rule versus search(). The resource is front-loaded and there is no filler.
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 one-parameter directory with no output schema and no annotations, the description covers purpose, usage, and the key API constraint. What is missing is only a brief note on the return structure and its read-only nature, which are minor given the tool's simplicity.
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 city parameter is documented there (name or id, with a default). The description mentions districts/microdistricts but adds no parameter-specific semantics, so it neither compensates nor detracts. Baseline 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?
The description states a concrete resource — city districts and their microdistricts with ids — which immediately distinguishes the tool from search(). It does not, however, differentiate itself from the sibling cities, another directory-style location tool, so the agent must infer the split.
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 gives explicit when-to-use guidance: view what is available, or disambiguate names. It also states the reason the tool exists (the API cannot filter by district, only by enumerating microdistricts) and clarifies that search() resolves names on its own, so the routing decision is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает инструкцию. 'apartment-search' — как разложить критерии пользователя по инструментам и в каком порядке идти. 'criteria-coverage' — на что ss.ge отвечает, на что отвечает приблизительно, и чего не знает вовсе. Вызывай перед сборкой многокритериального поиска.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | имя инструкции |
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 says it returns an instruction, but doesn't disclose behavioral traits like whether the instruction is static/cached, whether it changes over time, or the return format/size. For a read-only reference tool this is a moderate gap, not catastrophic, but the description adds little beyond the name and title.
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?
Front-loaded with the core verb and resource, then efficiently enumerates the two enum values with their meanings, and closes with the usage trigger. Every sentence earns its place. Slightly dense but no waste.
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 1-param read tool with no output schema and no annotations, the description covers the essential purpose, the enum semantics, and the usage trigger. It lacks disclosure of what the returned instruction looks like (text, structured, etc.), which would help an agent know how to consume it. Adequate but with a clear gap.
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 schema has 100% description coverage and an enum, so the parameter is fully documented structurally. The description does add semantic meaning by explaining what each enum value ('apartment-search', 'criteria-coverage') actually signifies, which goes beyond the schema's generic 'имя инструкции'. However, it doesn't explain formatting or constraints, so it's not a strong 4.
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 and resource ('Возвращает инструкцию' — returns an instruction) and enumerates the two instruction types with what each contains. It does not explicitly distinguish itself from siblings (search, count, listing, etc.), but the enumerations give enough specificity that an agent can tell it's a guidance/reference tool rather than a query tool.
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?
Provides a clear when-to-use trigger: 'Вызывай перед сборкой многокритериального поиска' (call before assembling a multi-criteria search). This ties this tool to a specific workflow moment. It doesn't name siblings as alternatives or say when NOT to call it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Полная карточка: удобства, координаты, этажность, состояние ремонта, кадастровый код, просмотры, контакт. Настоящей даты публикации здесь нет — API её в этом ответе не отдаёт; bumped и expires относятся к платному размещению.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | валюта, в которой считать цену | USD |
| application_id | Yes | id объявления (поле id из search) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral load. It does disclose one genuinely useful trait: the publication date is absent because the API does not return it in this response, and bumped/expires refer only to paid placement. However, it says nothing about permissions, error behavior for an invalid id, or how currency affects the response.
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?
One dense sentence listing the returned fields, followed by a sharply scoped caveat about the missing publication date. Every clause carries information and the caveat is clearly separated, though the field enumeration is a little packed.
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 two-parameter read tool with no output schema, the description does well to preview the returned fields and to preempt a likely question about the publication date and paid-placement fields. It stops short of covering failure modes or the effect of the currency parameter.
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 both parameters and the currency enum are already documented in the schema, making 3 the baseline. The description adds no syntax, format, or behavioral detail about application_id or currency beyond what the schema 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 resource (the full listing card) and enumerates the fields it carries — amenities, coordinates, floors, renovation state, cadastral code, views, contact. An agent can tell it is a detail-retrieval tool rather than a search/count tool, though it never states a verb or explicitly contrasts with the sibling 'search'.
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?
There is no explicit when-to-use or when-not-to-use guidance. The link back to 'search' exists only in the schema ('поле id из search'), and the description never says to use this after search or instead of any sibling. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ищет объявления на home.ss.ge. Возвращает частичную выдачу — сравнивай returned со счётчиком cards. mode='paged' даёт published (реальную дату публикации), mode='fast' — нет (published=null, это НЕИЗВЕСТНО, а не «свежее»). Цены отдаются сразу в USD и GEL.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | название или id города, напр. «Тбилиси» или 95 | Тбилиси |
| deal | Yes | тип сделки | |
| mode | No | paged — с датами публикации, ~30 объектов на запрос. fast — в разы быстрее (весь набор одним запросом), но БЕЗ дат публикации | paged |
| limit | No | сколько объектов вернуть | |
| order | No | сортировка; по умолчанию — релевантность/VIP самого сайта | |
| rooms | No | число комнат, напр. [2,3] | |
| estate | No | тип недвижимости | flat |
| area_max | No | площадь до, м² | |
| area_min | No | площадь от, м² | |
| currency | No | валюта цены в фильтре | USD |
| features | No | булевы удобства: elevator, furniture, heating, balcony, garage, withImageOnly и др. | |
| price_max | No | верхняя граница цены | |
| price_min | No | нижняя граница цены | |
| price_per_m2 | No | цена задана за м², а не целиком | |
| subdistricts | No | микрорайоны или районы по названию/id. Название района раскрывается во все его микрорайоны — отдельного фильтра по району в API нет |
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 does disclose that output is partial and that mode='fast' yields published=null meaning 'unknown, not fresh' – valuable warnings. However, it says nothing about auth requirements, rate limits, or failure modes, which is a real gap for a 15-param scraping tool.
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?
Four dense sentences, front-loaded with what the tool does and immediately followed by the two most consequential caveats (partial results, unknown dates). No filler, though the embedded guidance is packed tightly.
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?
With 15 parameters, no annotations, and no output schema, the description must work hard, and it covers the most dangerous behavioral traps (partial results, null dates, dual currency). It still omits the shape of the returned objects and any per-mode limits, leaving the agent to infer return structure.
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 baseline is 3, but the description adds genuine interpretation: mode='fast' returns published=null and that null must not be read as freshness, plus the fact that prices come back in both USD and GEL. That is meaning beyond the schema text.
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+resource: searches listings on home.ss.ge. It even hints at the relationship to the count tool ('сравнивай returned со счётчиком cards'). It does not explicitly differentiate from siblings like listing or geo, so it falls 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?
Gives useful guidance on the paged-vs-fast tradeoff and instructs the agent to compare the returned count against the cards counter, but never says when to pick this tool over listing, count, or geo. The only explicit routing is parameter-level, not tool-level.
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.0citiescountgeoget_skilllistingsearchScored across 6 tools
Each tool maps to a distinct operation: search returns listings, count returns only counts, listing returns a full detail card, cities/geo are reference data, and get_skill is meta-guidance. The only mild overlap is search and count, which both accept the same filter object, but the descriptions clearly separate the cheap count-only path from a full search.
All names are lowercase single tokens, which is superficially tidy, but grammatical patterns are mixed: get_skill is verb_noun while search/count are verbs and listing/cities/geo are bare nouns. Readable but not a predictable pattern an agent can anticipate.
Six tools is well-scoped for a read-only real-estate search wrapper: query (search/count), detail (listing), reference data (cities/geo), and guidance (get_skill). Each earns its place without redundancy or bloat.
The surface covers the full search workflow — discovery, counting, detail retrieval, and geographic/currency reference data — plus upfront guidance. Since it is read-only by design, create/update/delete do not apply; only minor gaps like sorting or export exist.
Live Estonia real estate listings with search, geo filters, and property metadata.
MCP server for SmartAgent CRM: leads, tasks, sales pipelines, property listings
RealEstateAPI MCP — property search, detail, and skip-trace (realestateapi.com)
Live Latvia real estate listings with search, geo filters, and property metadata.
