korter-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KORTER_MODE | No | Set to 'remote' to run the stdio facade against a deployed korter-mcp service instead of fetching directly. | |
| KORTER_API_TOKEN | No | Required when running in serve mode; authenticates the API endpoints. | |
| KORTER_REMOTE_URL | No | The base URL of the deployed korter-mcp service (required when KORTER_MODE=remote). | |
| KORTER_REMOTE_TOKEN | No | API token for authenticating to the remote korter-mcp service (required when KORTER_MODE=remote). | |
| KORTER_POMERIUM_TOKEN | No | Required when running in serve mode; authenticates the Pomerium gateway. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| consentA | Record or change YOUR consent (authenticated users). Two separate consents: accept_terms — required to use the tools (notice: get_skill 'privacy'); marketing_offers — OPTIONAL opt-in to receive real-estate suggestions matching your searches, never required. Omit a field to leave it unchanged; false revokes. |
| diff_reportA | What changed across all observed projects since a timestamp: price moves (old → new), newly discovered projects, delistings, and listing membership changes. |
| get_projectA | Full card for one project by korter slug: attributes, latest price per currency, coordinates, history summary. Check staleness_days — korter itself displays months-old prices. |
| get_skillA | Fetch usage guidance for this server before composing non-trivial queries. Skills: apartment-search — Map a buyer's criteria onto the search tools; the coarse-to-fine flow; criteria-coverage — What korter exposes vs what this server models — the gap map by buyer persona; freshness-and-history — Reading the staleness envelope; using price_history and diff_report; operating-limits — Rate limits, the breaker, and what this tool refuses to do; privacy — The privacy notice shown to authenticated users (current version). Call with the skill name; call 'apartment-search' before any multi-criteria search. |
| list_districtsA | korter's own district/microdistrict taxonomy for Tbilisi with their average price per m². Names are korter's, as-is — their 'Vake district' swallows Bagebi, Lisi and the Nutsubidze plateau. |
| list_trackedC | The sources in the weekly sweep, and when the last sweep ran. |
| list_usersC | Operator only: registered users, their consents and interest profiles (the opted-in list is the offers feed). |
| my_dataA | Everything this server holds about YOU (authenticated users): profile, consent log, recorded search interests. Your right to know — and the map for what consent(false) erases from use. |
| price_historyC | The accrued price history for one project — every price change and re-dating this tool has observed, from the journal. This is the value korter does not show: how the price moved. |
| refreshA | Fetch one source from korter now (cache-first, 24h TTL; globally paced at 1 req/s; honest UA). source_id is 'project:' or 'listing:'. If korter answers 403/429 the circuit breaker opens and stays open — by design this tool stops instead of evading. |
| search_projectsA | Search observed Tbilisi new-build projects. Criteria: district/city (korter's taxonomy, as-is), price per m² and total budget, rooms and unit area (need per-unit data — see get_skill 'apartment-search'), construction/sales status, building type, developer, free text. Served from the local journal — check staleness_days on every result. Room/area filters only consider projects whose project page has been observed; candidates lacking that data are listed separately so you can refresh them. |
| search_secondaryB | Search the secondary market (resale and rent) from the latest snapshots of tracked secondary sources. Each result links to the korter listing — contact with the seller happens THERE; this server stores property facts only, never seller identities. Per-listing korter freshness is in actualize_staleness_days. If a district has no snapshot, the result says which source to refresh. |
| secondary_trendsC | Secondary-market aggregates per district (korter's own figures: avg price/m², sale and rent ranges) plus the accrued trend from the journal for tracked secondary sources. |
| trackA | Add a source to the weekly sweep (journaled; survives restarts). Seed set: project:tsavkisi-park-tbilisi, project:ambience-avlabari-tbilisi, listing:new-projects-in-avlabari |
| untrackC | Remove a source from the weekly sweep. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Most tools target distinct resources or actions: search_projects vs search_secondary cover different markets, get_project vs price_history differ in scope, and track/untrack/refresh have clear boundaries. Minor potential confusion between diff_report/price_history/secondary_trends (all change-oriented) and between refresh and the track/untrack sweep tools, but descriptions clarify.
Names use consistent snake_case, but conventions are mixed: some are verb_noun (get_project, list_districts, search_projects), others are bare verbs/nouns (track, refresh, consent), and others are noun phrases (diff_report, price_history, my_data). Readable, but not a predictable single pattern.
At 15 tools, the set is at the upper end of the ideal range but each tool maps to a concrete capability (search, track, refresh, history, secondary market, consent/privacy, skills). It is slightly heavy due to auxiliary tools (get_skill, consent, my_data, list_users) but not bloated or mismatched for the domain.
Core lifecycle for the domain is covered: source tracking (track/untrack/list_tracked), manual refresh, project search and detail, history/diff, secondary search and trends, plus consent and user data. Minor gaps exist, such as no explicit bulk source management or a per-source metadata view, but agents can work around them.