This server provides read-only access to Swedish property data from Booli.se, routing requests through your browser to bypass bot protection. It supports the following tools:
booli_search_areas: Resolve a place name (e.g. "Nacka", "Södermalm") to Booli area IDs for use in other tools.
booli_search_listings: Search active for-sale listings filtered by area, price (SEK), rooms, living area (m²), plot size, property type, construction year, and new construction status.
booli_get_listing: Retrieve full details for a specific property (active or sold) using its Booli residence ID.
booli_search_sold: Look up sold properties (slutpriser) with final achieved prices, over/under-asking percentages, and filters for sold date, price, size, and property type.
booli_market_stats: Compute aggregate market statistics for an area, including median/average sold price, price per m², and average over/under-asking percentage.
booli_healthcheck: Verify connectivity to Booli's data path (direct or via browser bridge) and measure response time.
All monetary values are in SEK and areas in m². Queries can be scoped by Booli area ID or free-text location.
Click on "Install 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., "@booli-mcp Show me sold prices in Göteborg"
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.
An MCP server for Booli, the Swedish property portal — search active for-sale listings, sold prices (slutpriser), resolve areas, and compute market statistics, all from Claude.
Developed and maintained by AI (Claude Code). Use at your own discretion and within booli.se's terms of use.
Booli fronts www.booli.se — including its GraphQL API — with a Cloudflare bot wall that blocks server-side clients. booli-mcp therefore reads Booli's consumer GraphQL API by routing each query through your own signed-in www.booli.se browser tab via the fetchproxy bridge (the Transporter extension), reusing your Cloudflare-cleared session. No Booli login is required — just a normal page view. All tools are read-only.
BOOLI_TRANSPORT selects the path: auto (default — direct fetch first,
browser-bridge fallback when walled), fetchproxy (always the bridge), or
direct. The fetchproxy fleet shares WS port 37149 (BOOLI_WS_PORT).
Related MCP server: Idealista7 MCP Server
Install the Transporter (fetchproxy) browser extension and keep a www.booli.se tab open.
On the first request, approve the one-time pairing prompt in Transporter.
Run booli_healthcheck to confirm the path is working. Its transport
field says which leg served the probe (direct or fetchproxy) and,
once the bridge exists, bridge.session_state says whether the
Transporter extension is linked, pair_pending (approve the pair code
it names), or extension_disconnected.
// mcp config
{
"mcpServers": {
"booli": {
"command": "npx",
"args": ["-y", "@chrischall/booli-mcp"]
}
}
}Tool | What it does |
| Resolve a place name to Booli area ids |
| Search active for-sale listings by area + filters |
| Full detail for one property (active or sold) by residence id |
| Search sold listings (slutpriser) with final prices |
| Median/average sold-price statistics for an area |
| Probe the data path and report |
Searches scope by area_id (from booli_search_areas) or a free-text
location. Money is SEK, areas m². See
docs/BOOLI-API.md for the underlying GraphQL API.
npm install
npm test # vitest, no network
npm run build # tsc + esbuild bundleMIT
Full detail for one property by its Booli residence id — the number in a booli.se/bostad/ URL, or the residence_id from a search result. Works for both active and sold properties. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| compact | No | Return a slim summary instead of the full raw record (default false). | |
| residence_id | Yes | The property's residence id (e.g. "4370936" from /bostad/4370936). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states read-only, consistent with annotations. Adds that it works for active and sold properties. No contradictions. Annotations already cover readOnlyHint, openWorldHint, idempotentHint.
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 essential: purpose, ID source, and scope/safety. No redundancy, perfectly front-loaded.
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 2-param tool with no output schema, the description covers input derivation, read-only nature, and applicability to both active and sold properties. Slightly ambiguous on what 'full detail' includes, but adequate.
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%, description adds value by explaining how to obtain residence_id (from URL or search result) and clarifying the compact parameter's purpose.
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?
Description clearly states the tool returns full detail for one property by residence ID, including how to find the ID. Distinguishes from siblings (search returns lists, this returns individual detail).
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?
Explicitly tells when to use (when you have a residence ID from URL or search result) and that it works for both active and sold. Lacks explicit mention of alternatives but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Round-trips a small public www.booli.se URL (/graphql) through the fetchproxy bridge and returns diagnostics: the bridge's role (host/peer/null), port, version, the extension link (linked / pair pending / not attached / never answered), the elapsed round-trip time, and a plain-English hint distinguishing 'bridge never came up' from 'extension not connected' from 'real www.booli.se-side problem'. Call this when a real tool fails and you want to know which hop broke. Read-only, no auth required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds value beyond that by disclosing the network round-trip, the exact diagnostic fields returned (bridge role, port, version, extension link status, elapsed time), and the failure-mode classification into three distinct causes. The 'no auth required' note is additional context not present in the annotations.
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 dense but front-loaded with the core action ('Round-trips a small public www.booli.se URL through the fetchproxy bridge'). Every clause earns its place — the diagnostic field list, the failure-mode triage, the trigger condition, and the auth note are all decision-relevant. The middle enumeration is slightly long and run-on, which marginally hurts scannability, but there is 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?
With no output schema present, the description carries the full burden of explaining return values — and it does so thoroughly, enumerating each diagnostic field and the three plain-English failure interpretations. For a 0-parameter tool, it also covers when to invoke it and that no authentication is required. Nothing an agent needs to decide whether to call this tool is missing.
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 100% schema coverage, so per the rubric the baseline is 4. The description correctly adds no parameter documentation because none is needed. Nothing is left ambiguous about the invocation surface.
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 verb and resource: it round-trips a small public www.booli.se /graphql URL through the fetchproxy bridge and returns diagnostics. It is immediately distinguishable from the sibling search/data tools (booli_search_*, booli_get_listing), which all retrieve Booli data rather than probe infrastructure. The title 'Verify the fetchproxy bridge end-to-end' reinforces the diagnostic 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?
The description gives an explicit trigger condition: 'Call this when a real tool fails and you want to know which hop broke.' This clearly communicates when the tool is appropriate. It does not explicitly name alternatives or state when-not-to-use, but the contrast with the search siblings is strongly implied by the diagnostic nature of the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate sold-price statistics (median/average final price, price per m², average over/under-asking %) for an area on booli.se. Takes the same scope and filters as booli_search_sold, over one page of sold results. Check sample_size before trusting a thin median. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page (default 1). | |
| sort | No | Sort key (default: newest published). | |
| area_id | No | Booli area id from booli_search_areas. Provide this OR `location`. | |
| compact | No | Return slim summary records (default true). Set false for full raw fields. | |
| location | No | Free-text place name (e.g. "Nacka", "Södermalm") resolved to its top Booli area. Ignored when `area_id` is set. | |
| ascending | No | Sort ascending (default false). | |
| max_rooms | No | ||
| min_rooms | No | ||
| object_type | No | Property type(s), comma-separated, from: Lägenhet, Villa, Kedjehus-Parhus-Radhus, Fritidshus, Gård, Tomt/Mark. | |
| max_plot_area | No | m² | |
| max_sold_date | No | Latest sold date, YYYYMMDD. | |
| min_plot_area | No | m² | |
| min_sold_date | No | Earliest sold date, YYYYMMDD (e.g. "20240101"). | |
| max_sold_price | No | SEK | |
| min_sold_price | No | SEK | |
| max_living_area | No | m² | |
| min_living_area | No | m² | |
| max_sold_sqm_price | No | SEK/m² | |
| min_sold_sqm_price | No | SEK/m² | |
| is_new_construction | No | true = only new production; false = exclude new production. | |
| max_construction_year | No | ||
| min_construction_year | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and openWorldHint are true; description confirms 'Read-only' and warns about thin medians via sample_size. It also clarifies it aggregates over one page, a key behavioral trait. No contradiction with annotations.
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 sentences, front-loading the purpose and immediately providing scope and usage context. Every sentence adds value without redundancy.
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?
Given 22 parameters, no required ones, and no output schema, the description provides adequate context for an agent to use the tool, referencing a sibling tool for filter details and suggesting sample_size checks. However, it lacks details on response structure or pagination behavior.
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 high (82%), so baseline is 3. The description does not add additional parameter semantics beyond referencing that filters match booli_search_sold. No new meaning beyond 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?
The description clearly states the tool aggregates sold-price statistics (median/average price, price per m², over/under-asking %) for an area. It distinguishes itself from sibling tool booli_search_sold by specifying it operates over one page of sold results.
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 explicitly says it uses the same scope and filters as booli_search_sold, guiding when to use it over individual listings. It also provides a caveat to check sample_size, but does not exhaustively list when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a place name to Booli areas — municipalities, districts, streets — each with its area_id to pass as area_id into booli_search_listings / booli_search_sold. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10). | |
| query | Yes | Place-name search string (e.g. "Nacka", "Södermalm"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context about the types of areas returned (municipalities, districts, streets) and the area_id output, which complements the annotations without contradicting them.
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?
Two sentences, zero waste, front-loaded with the main action and resource. Efficiently communicates purpose, output, and consumption pattern.
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 2-parameter lookup tool with strong annotations, the description fully explains the tool's purpose, output (areas with area_id), and how it feeds into sibling tools. No output schema needed given the context provided.
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% (both parameters described with clear descriptions). The description adds little extra meaning beyond what is in the schema, as the schema already covers the parameter semantics adequately.
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 verb ('Resolve'), a clear resource ('place names to Booli areas'), and explicitly distinguishes from siblings by naming booli_search_listings and booli_search_sold as consumers of the area_id.
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 clearly implies usage when needing area IDs for Booli search tools ('to pass as area_id into booli_search_listings / booli_search_sold'), but does not elaborate on when not to use or alternatives beyond the sibling mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search active for-sale property listings on booli.se. Scope by area_id (from booli_search_areas) or a free-text location, and filter by price, rooms, living area, plot, object type, construction year. Paginated by page; check total_count/pages. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page (default 1). | |
| sort | No | Sort key (default: newest published). | |
| area_id | No | Booli area id from booli_search_areas. Provide this OR `location`. | |
| compact | No | Return slim summary records (default true). Set false for full raw fields. | |
| location | No | Free-text place name (e.g. "Nacka", "Södermalm") resolved to its top Booli area. Ignored when `area_id` is set. | |
| ascending | No | Sort ascending (default false). | |
| max_rooms | No | ||
| min_rooms | No | ||
| object_type | No | Property type(s), comma-separated, from: Lägenhet, Villa, Kedjehus-Parhus-Radhus, Fritidshus, Gård, Tomt/Mark. | |
| max_plot_area | No | m² | |
| min_plot_area | No | m² | |
| max_list_price | No | SEK | |
| min_list_price | No | SEK | |
| max_living_area | No | m² | |
| min_living_area | No | m² | |
| max_list_sqm_price | No | SEK/m² | |
| min_list_sqm_price | No | SEK/m² | |
| is_new_construction | No | true = only new production; false = exclude new production. | |
| max_construction_year | No | ||
| min_construction_year | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the tool is read-only, paginated (via page param, check total_count/pages), and only returns active listings. This extra context about pagination behavior and listing status goes beyond what annotations provide, though it doesn't elaborate on rate limits or data freshness.
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?
Two sentences, no wasted words. First sentence conveys purpose and key scope/filter options; second covers pagination and read-only nature. Information is front-loaded and efficient.
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?
Given 20 parameters and no output schema, the description adequately covers input usage and pagination hints (total_count/pages). However, it does not describe the output structure (e.g., each listing includes id, address, etc.), leaving a gap for an agent. Annotations (openWorldHint) partially compensate, but more detail on return format would improve completeness.
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 80% (16 of 20 parameters have descriptions). The description summarizes filter categories (price, rooms, living area, etc.) but adds no detailed semantics beyond what the schema already provides. Baseline of 3 is appropriate as the schema does the heavy lifting.
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 tool searches 'active for-sale property listings' on booli.se, specifying the verb 'search' and resource 'listings'. It distinguishes from siblings like booli_search_sold (sold listings) and booli_get_listing (single listing) by focusing on active for-sale properties and referencing booli_search_areas for area IDs.
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?
Basic usage is provided: scope by area_id or location, filter by various criteria, and pagination. However, no explicit guidance on when to use this tool versus siblings (e.g., sold listings via booli_search_sold) or when not to use it. The description is functional but lacks comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search sold properties (slutpriser) on booli.se with the achieved final price and over/under-asking % — the comparables for valuation. Scope by area_id or free-text location, filter by sold price, sold date, rooms, area, object type. Paginated by page. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page (default 1). | |
| sort | No | Sort key (default: newest published). | |
| area_id | No | Booli area id from booli_search_areas. Provide this OR `location`. | |
| compact | No | Return slim summary records (default true). Set false for full raw fields. | |
| location | No | Free-text place name (e.g. "Nacka", "Södermalm") resolved to its top Booli area. Ignored when `area_id` is set. | |
| ascending | No | Sort ascending (default false). | |
| max_rooms | No | ||
| min_rooms | No | ||
| object_type | No | Property type(s), comma-separated, from: Lägenhet, Villa, Kedjehus-Parhus-Radhus, Fritidshus, Gård, Tomt/Mark. | |
| max_plot_area | No | m² | |
| max_sold_date | No | Latest sold date, YYYYMMDD. | |
| min_plot_area | No | m² | |
| min_sold_date | No | Earliest sold date, YYYYMMDD (e.g. "20240101"). | |
| max_sold_price | No | SEK | |
| min_sold_price | No | SEK | |
| max_living_area | No | m² | |
| min_living_area | No | m² | |
| max_sold_sqm_price | No | SEK/m² | |
| min_sold_sqm_price | No | SEK/m² | |
| is_new_construction | No | true = only new production; false = exclude new production. | |
| max_construction_year | No | ||
| min_construction_year | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds that tool is 'Read-only', paginated, and returns achieved price and over/under-asking %. Provides useful behavioral context beyond annotations.
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?
Two sentences, front-loaded with purpose, then key parameter categories. No unnecessary words. 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?
Given 22 parameters and no output schema, description covers purpose, key filters, pagination, and read-only nature. Could mention sorting options and compact mode, but schema descriptions fill those details. Generally complete for a search tool.
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 82%, so most parameters are described in schema. Description groups key dimensions (price, date, rooms, area, object type) but does not add significant meaning beyond what schema already provides. Baseline 3 is appropriate.
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?
Description clearly states it searches sold properties with final price and over/under-asking %. The term 'slutpriser' and 'comparables for valuation' distinguish this from sibling booli_search_listings (likely active) and other tools. Specific verb+resource.
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?
Implicitly suggests use for valuation (comparables), and describes scope options (area_id vs location) and filters. No explicit alternatives named, but context makes intended use clear.
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. Dates show when Glama detected each change.
v1.0.0booli_get_listing3 fields changedInput schema / properties / booli_idRemoved value: -{
- "description": "The listing's Booli id (e.g. \"1579812\").",
- "type": "string"
-}Input schema / properties / residence_idAdded value: +{
+ "description": "The property's residence id (e.g. \"4370936\" from /bostad/4370936).",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "booli_id"
-]New value: +[
+ "residence_id"
+]booli_get_soldbooli_market_stats13 fields changedInput schema / properties / area_id / descriptionPrevious value: -"Booli area id(s) from booli_search_areas, comma-separated for several (e.g. \"76,16\")."New value: +"Booli area id from booli_search_areas. Provide this OR `location`."Input schema / properties / ascendingAdded value: +{
+ "description": "Sort ascending (default false).",
+ "type": "boolean"
+}Input schema / properties / bboxRemoved value: -{
- "description": "Bounding box \"lat_lo,lng_lo,lat_hi,lng_hi\" (SW then NE corner).",
- "type": "string"
-}Input schema / properties / centerRemoved value: -{
- "description": "Coordinate \"lat,lng\" (e.g. \"59.34674,18.0603\"); use with `dim`.",
- "type": "string"
-}Input schema / properties / dimRemoved value: -{
- "description": "Rectangle size in metres \"w,h\" (e.g. \"400,500\"), used with `center`.",
- "type": "string"
-}Input schema / properties / limitRemoved value: -{
- "description": "Default 30, max 100.",
- "maximum": 100,
- "minimum": 1,
- "type": "integer"
-}Input schema / properties / locationAdded value: +{
+ "description": "Free-text place name (e.g. \"Nacka\", \"Södermalm\") resolved to its top Booli area. Ignored when `area_id` is set.",
+ "type": "string"
+}Input schema / properties / max_rentRemoved value: -{
- "description": "SEK/month",
- "minimum": 0,
- "type": "number"
-}Input schema / properties / object_type / descriptionPrevious value: -"Property type(s), comma-separated, from: villa, lägenhet, gård, tomt-mark, fritidshus, parhus, radhus, kedjehus."New value: +"Property type(s), comma-separated, from: Lägenhet, Villa, Kedjehus-Parhus-Radhus, Fritidshus, Gård, Tomt/Mark."Input schema / properties / offsetRemoved value: -{
- "description": "Pagination offset.",
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
-}Input schema / properties / pageAdded value: +{
+ "description": "1-based page (default 1).",
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / qRemoved value: -{
- "description": "Free-text area search (e.g. \"Nacka\", \"Södermalm\"). One of q / area_id / center / bbox scopes the search.",
- "type": "string"
-}Input schema / properties / sortAdded value: +{
+ "description": "Sort key (default: newest published).",
+ "enum": [
+ "published",
+ "listPrice",
+ "listSqmPrice",
+ "rooms",
+ "livingArea",
+ "rent",
+ "plotArea"
+ ],
+ "type": "string"
+}booli_search_areas8 fields changedInput schema / properties / latRemoved value: -{
- "description": "Latitude; use together with `lng`.",
- "type": "number"
-}Input schema / properties / limit / descriptionPrevious value: -"Default 10, max 50."New value: +"Max results (default 10)."Input schema / properties / lngRemoved value: -{
- "description": "Longitude; use together with `lat`.",
- "type": "number"
-}Input schema / properties / only_with_listingsRemoved value: -{
- "description": "Only return areas that currently have listings for sale.",
- "type": "boolean"
-}Input schema / properties / only_with_soldRemoved value: -{
- "description": "Only return areas that have sold listings.",
- "type": "boolean"
-}Input schema / properties / qRemoved value: -{
- "description": "Place-name search string (e.g. \"Nacka\").",
- "type": "string"
-}Input schema / properties / queryAdded value: +{
+ "description": "Place-name search string (e.g. \"Nacka\", \"Södermalm\").",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "query"
+]booli_search_listings13 fields changedInput schema / properties / area_id / descriptionPrevious value: -"Booli area id(s) from booli_search_areas, comma-separated for several (e.g. \"76,16\")."New value: +"Booli area id from booli_search_areas. Provide this OR `location`."Input schema / properties / ascendingAdded value: +{
+ "description": "Sort ascending (default false).",
+ "type": "boolean"
+}Input schema / properties / bboxRemoved value: -{
- "description": "Bounding box \"lat_lo,lng_lo,lat_hi,lng_hi\" (SW then NE corner).",
- "type": "string"
-}Input schema / properties / centerRemoved value: -{
- "description": "Coordinate \"lat,lng\" (e.g. \"59.34674,18.0603\"); use with `dim`.",
- "type": "string"
-}Input schema / properties / dimRemoved value: -{
- "description": "Rectangle size in metres \"w,h\" (e.g. \"400,500\"), used with `center`.",
- "type": "string"
-}Input schema / properties / limitRemoved value: -{
- "description": "Default 30, max 100.",
- "maximum": 100,
- "minimum": 1,
- "type": "integer"
-}Input schema / properties / locationAdded value: +{
+ "description": "Free-text place name (e.g. \"Nacka\", \"Södermalm\") resolved to its top Booli area. Ignored when `area_id` is set.",
+ "type": "string"
+}Input schema / properties / max_rentRemoved value: -{
- "description": "SEK/month",
- "minimum": 0,
- "type": "number"
-}Input schema / properties / object_type / descriptionPrevious value: -"Property type(s), comma-separated, from: villa, lägenhet, gård, tomt-mark, fritidshus, parhus, radhus, kedjehus."New value: +"Property type(s), comma-separated, from: Lägenhet, Villa, Kedjehus-Parhus-Radhus, Fritidshus, Gård, Tomt/Mark."Input schema / properties / offsetRemoved value: -{
- "description": "Pagination offset.",
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
-}Input schema / properties / pageAdded value: +{
+ "description": "1-based page (default 1).",
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / qRemoved value: -{
- "description": "Free-text area search (e.g. \"Nacka\", \"Södermalm\"). One of q / area_id / center / bbox scopes the search.",
- "type": "string"
-}Input schema / properties / sortAdded value: +{
+ "description": "Sort key (default: newest published).",
+ "enum": [
+ "published",
+ "listPrice",
+ "listSqmPrice",
+ "rooms",
+ "livingArea",
+ "rent",
+ "plotArea"
+ ],
+ "type": "string"
+}booli_search_sold13 fields changedInput schema / properties / area_id / descriptionPrevious value: -"Booli area id(s) from booli_search_areas, comma-separated for several (e.g. \"76,16\")."New value: +"Booli area id from booli_search_areas. Provide this OR `location`."Input schema / properties / ascendingAdded value: +{
+ "description": "Sort ascending (default false).",
+ "type": "boolean"
+}Input schema / properties / bboxRemoved value: -{
- "description": "Bounding box \"lat_lo,lng_lo,lat_hi,lng_hi\" (SW then NE corner).",
- "type": "string"
-}Input schema / properties / centerRemoved value: -{
- "description": "Coordinate \"lat,lng\" (e.g. \"59.34674,18.0603\"); use with `dim`.",
- "type": "string"
-}Input schema / properties / dimRemoved value: -{
- "description": "Rectangle size in metres \"w,h\" (e.g. \"400,500\"), used with `center`.",
- "type": "string"
-}Input schema / properties / limitRemoved value: -{
- "description": "Default 30, max 100.",
- "maximum": 100,
- "minimum": 1,
- "type": "integer"
-}Input schema / properties / locationAdded value: +{
+ "description": "Free-text place name (e.g. \"Nacka\", \"Södermalm\") resolved to its top Booli area. Ignored when `area_id` is set.",
+ "type": "string"
+}Input schema / properties / max_rentRemoved value: -{
- "description": "SEK/month",
- "minimum": 0,
- "type": "number"
-}Input schema / properties / object_type / descriptionPrevious value: -"Property type(s), comma-separated, from: villa, lägenhet, gård, tomt-mark, fritidshus, parhus, radhus, kedjehus."New value: +"Property type(s), comma-separated, from: Lägenhet, Villa, Kedjehus-Parhus-Radhus, Fritidshus, Gård, Tomt/Mark."Input schema / properties / offsetRemoved value: -{
- "description": "Pagination offset.",
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
-}Input schema / properties / pageAdded value: +{
+ "description": "1-based page (default 1).",
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / qRemoved value: -{
- "description": "Free-text area search (e.g. \"Nacka\", \"Södermalm\"). One of q / area_id / center / bbox scopes the search.",
- "type": "string"
-}Input schema / properties / sortAdded value: +{
+ "description": "Sort key (default: newest published).",
+ "enum": [
+ "published",
+ "listPrice",
+ "listSqmPrice",
+ "rooms",
+ "livingArea",
+ "rent",
+ "plotArea"
+ ],
+ "type": "string"
+}v0.0.0booli_get_listingbooli_get_soldbooli_healthcheckbooli_market_statsbooli_search_areasbooli_search_listingsbooli_search_soldEach tool has a clearly distinct role: area resolution, active listing search, single listing detail, sold search, aggregate stats, and diagnostics. Even booli_search_sold and booli_market_stats are cleanly separated by record-level vs aggregate output.
The booli_ prefix and snake_case convention are consistent, and most tools use a search/get verb plus noun. booli_market_stats and booli_healthcheck break the verb_noun pattern slightly, but the names remain predictable and readable.
Six tools is a tight, well-scoped set for a read-only property data server. There is no redundancy and no bloat; each tool earns its place in the workflow.
The set covers the full read-only workflow: resolving areas, searching active listings, fetching listing details, searching sold comparables, and getting market aggregates. The healthcheck tool also covers operational failure diagnosis, so there are no obvious dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Redfin listings, sale-comps, and neighborhood market data via natural-language queries.
Booking.com stays by destination and dates, and full property details, as structured JSON.
Zillow for-sale, for-rent and sold listings, and full property details, as structured JSON.
Search real-estate deals, rank top areas, run rental/BRRRR/flip analysis, pull sold comps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/booli-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
