Skip to main content
Glama
chrischall

booli-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get a Booli property

booli_get_listing
Read-onlyIdempotent

Fetch full details for a single Swedish property by its Booli residence ID, covering active and sold listings for read-only lookup and analysis.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact returns the slim PropertySummary/detail projection; "full" returns Booli's whole GraphQL node.
residence_idYesThe property's residence id (e.g. "4370936" from /bostad/4370936).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed2 schema fields changedv1.3.1
    • removedInput schema / properties / compact
      Removed value: -{
-  "description": "Return a slim summary instead of the full raw record (default false).",
-  "type": "boolean"
-}
    • addedInput schema / properties / view
      Added value: +{
+  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact returns the slim PropertySummary/detail projection; \"full\" returns Booli's whole GraphQL node.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  3. Changed3 schema fields changedv1.0.0
    • removedInput schema / properties / booli_id
      Removed value: -{
-  "description": "The listing's Booli id (e.g. \"1579812\").",
-  "type": "string"
-}
    • addedInput schema / properties / residence_id
      Added value: +{
+  "description": "The property's residence id (e.g. \"4370936\" from /bostad/4370936).",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "booli_id"
-]New value: +[
+  "residence_id"
+]
  4. First observedv0.0.0

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety and repeatability profile is fully covered and "Read-only" in the description is largely redundant. The one genuinely additive behavioral fact is the active/sold scope; nothing is said about missing-id errors, rate limits, or data freshness. With annotations carrying the burden, a 3 is appropriate.

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 tight sentences, front-loaded with what is returned, zero filler; the final "Read-only" is the only slightly redundant clause and costs almost nothing.

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?

No output schema exists, but the description plus the schema's `view` documentation adequately convey the returned shape (compact projection vs full GraphQL node). Naming the id source (URL or search result) closes the main integration gap; only error behavior for an unknown id is left uncovered.

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?

Schema coverage is 100% and both parameters are documented in the schema, including the compact/full enum and id example. The description's id guidance (booli.se/bostad/<id>, residence_id from search) largely restates the schema example, and it says nothing about the `view` parameter. Baseline 3 when the schema does the work.

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?

"Full detail for one property by its Booli residence id" is a specific verb+resource plus the identifier, and the contrast with the search siblings (one vs many) is implicit in the phrasing. An agent can tell this is the single-record lookup rather than a search.

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

Usage Guidelines4/5

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

It states when this applies: it accepts an id from a URL or a search result, and "works for both active and sold properties" removes the ambiguity of whether a separate sold-property lookup is needed. It stops short of naming alternatives or stating prerequisites (e.g. needing an id in hand rather than a query).

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

Deploy Server

Other Tools