Skip to main content
Glama

MatchOffice — Commercial Real Estate Search

search_locations

Read-onlyIdempotent

Search for available commercial real estate locations

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number starting at 1. Returns 20 results per page. Use ceil(total / 20) to calculate total pages.
kindsNoProperty type filter (OR logic). Matches locations where the primary kind OR any secondary kind is in the list — a business_center with secondary_kind 'office' will appear for kinds: ['office']. Lease kinds: office, business_center, warehouse, store, coworking, meeting_room, virtual_office, parking. Sale kinds: housing, office, warehouse, store, lot.
queryNoCity, district, neighborhood, or street name — resolved via autocomplete search. Examples: 'Copenhagen', 'København', 'Østerbro', 'Vesterbro', 'Nørrebro'.
sectionNoProperty section. 'lease' (default) for rentals; 'sale' for properties for sale.
sort_byNoSort order in 'column|direction' format. E.g. 'yearly_rent_per_m2_amount_from|asc', 'area_from|asc', 'created_at|desc'.
area_maxNoMaximum area in m² (inclusive). Must be greater than or equal to area_min when both are provided.
area_minNoMinimum area in m² (inclusive). Uses overlap semantics: a location is included if its available range overlaps [area_min, area_max], e.g. a listing offering 50–500 m² will appear for area_min: 400.
currencyNoCurrency for rent_min/rent_max values, e.g. EUR, DKK, SEK. Defaults to country's native currency.
rent_maxNoMaximum rent (see rent_format and currency).
rent_minNoMinimum rent (see rent_format and currency).
facilitiesNoFacility keys to filter by (OR logic). Common aliases accepted: cctv, wheelchair, 24h, ev_charging, internet, moving.
rent_formatNoLease only. 'monthly' (default) = total rent per month; 'yearly' = rent per m²/year.
suitable_forNoTenant type suitability filter.
energy_ratingNoEnergy rating filter.
country_alpha2YesISO 3166-1 alpha-2 country code (lowercase). Always infer from the city or country name — 'Kyiv' or 'Ukraine' → 'ua', 'Stockholm' or 'Sweden' → 'se', 'Berlin' or 'Germany' → 'de', 'Paris' or 'France' → 'fr'. Uppercase is accepted and normalized. Use 'global' ONLY for country-agnostic searches with no location query (e.g. browsing all available countries). Never combine 'global' with a query — geo resolution requires a country.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile fully. The description adds nothing behavioral on top — no result shape, no pagination behavior, no rate limits — so it contributes no value beyond what the structured fields already convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no waste. It is terse to the point of under-specification rather than bloated, so it is concise but arguably too sparse for a 15-parameter tool.

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?

For a 15-parameter search tool with no output schema, the description is adequate but thin: it says nothing about what results look like, how filtering combines, or how it relates to get_location. The unusually rich schema descriptions compensate for most parameter gaps, keeping this at a minimum-viable 3.

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 description coverage is 100%: all 15 parameters, including complex enum filters, currency handling, and the country_alpha2 inference rules, are documented in the schema itself. The description adds no parameter meaning, so the baseline 3 applies.

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 states a clear verb+resource ('Search for available commercial real estate locations'), which is specific enough to understand the operation. However, it does nothing to distinguish this tool from the sibling get_location, leaving the search-vs-detail boundary to inference from the names alone.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no mention of alternatives like get_location, and no prerequisites or exclusions. An agent must infer entirely from the tool name that this is the broad listing/search entry point.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources