The dld-mcp server provides a single tool, query_dld, to query Dubai real estate data — property sales transactions and rental contracts — through the OfferBrief API.
Search by location: area or building name (e.g., Marina, Palm Jumeirah).
Retrieve data types: sales transactions (DLD) or rental contracts (Ejari).
Filter results: by property type (apartment, villa, townhouse — sales only), bedrooms (studio, 1-5+), and date range.
Aggregated metrics (stats): median, average, min, max prices, transaction count, total volume.
Count only (count): number of matching records.
List records (list): individual transactions/contracts (limit 1-50, default 10).
Compare areas: run multiple queries to compare prices across locations.
Integration: easily added to Claude Code or Claude Desktop for natural language queries.
Robust handling: input validation rejects invalid parameters; clear error messages for API failures, rate limits, timeouts.
Privacy-conscious: no credentials needed; query parameters and response bodies are not logged.
Example queries: "How many villas sold in Palm Jumeirah in 2024?" or "Average rent for 2BR in Marina."
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., "@dld-mcp What's the median price in Marina?"
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.
Local stdio MCP server for querying Dubai property sales transactions and rental contracts through OfferBrief.
The server uses MCP Python SDK v2 and supports the MCP 2026-07-28 protocol.
Run the published package directly:
uvx dld-mcpRelated MCP server: MOLIT Real Estate Transactions MCP Server
Claude Code:
claude mcp add dld -- uvx dld-mcpClaude Desktop:
{
"mcpServers": {
"dld": {
"command": "uvx",
"args": ["dld-mcp"]
}
}
}Add that entry to ~/Library/Application Support/Claude/claude_desktop_config.json on macOS.
query_dld accepts:
Parameter | Allowed values | Default |
| Area or building name, at least 2 non-whitespace characters | Required |
|
|
|
|
|
|
|
|
|
| A real date in | OfferBrief default |
| A real date in | OfferBrief default |
|
|
|
| Integer from 1 through 50 |
|
property_type is supported only for sales. date_from cannot be later than date_to.
Examples:
query_dld(area="Marina")
query_dld(area="Palm", property_type="villa", date_from="2024-01-01", metric="count")
query_dld(area="Downtown", type="rentals", bedrooms="2")
query_dld(area="JBR", metric="list", limit=10)Invalid arguments fail before an API request. OfferBrief HTTP, rate limit, timeout, connection, and malformed response failures return structured errors with a message and status code.
Each tool call sends its query parameters to https://offerbrief.com/api/query. No credentials are used. The package does not log query parameters or response bodies.
Results reflect the data available from OfferBrief when the call is made. This package does not claim a refresh schedule or transaction count.
git clone https://github.com/level09/dld-mcp
cd dld-mcp
uv sync --group dev
uv run pytest
uv run ruff check
uv buildMIT, OfferBrief
Query Dubai property data - sales transactions or rental contracts.
Args: area: Location to search (e.g., "Marina", "JBR", "Downtown", "Palm Jumeirah", or building name) type: "sales" for DLD transactions, "rentals" for Ejari contracts property_type: "all", "apartment", "villa", or "townhouse" (sales only) bedrooms: "all", "studio", "1", "2", "3", "4", "5+" date_from: Start date YYYY-MM-DD (default: last 12 months for sales, 24 for rentals) date_to: End date YYYY-MM-DD (default: today) metric: "stats" (aggregated statistics), "count" (just count), "list" (individual records) limit: Max records for list mode (1-50, default 10)
Returns: For stats: median/avg/min/max prices, transaction count, total volume For count: just the count of matching records For list: individual transaction/contract records
Examples: - "How many villas sold in Palm Jumeirah in 2024?" query_dld(area="Palm", property_type="villa", date_from="2024-01-01", metric="count")
- "Average rent for 2BR in Marina"
query_dld(area="Marina", type="rentals", bedrooms="2")
- "Recent sales in Downtown"
query_dld(area="Downtown", metric="list", limit=10)
- "Compare JBR vs Marina prices"
Call twice with different areas
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | ||
| type | No | sales | |
| property_type | No | all | |
| bedrooms | No | all | |
| date_from | No | ||
| date_to | No | ||
| metric | No | stats | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of transparency. It states it returns data but does not explicitly declare read-only behavior, auth requirements, or side effects. As a query tool, it is implied to be non-destructive, but explicit mention would improve transparency.
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 well-structured with clear sections for Args, Returns, and Examples. Every sentence adds value, and the examples are concise yet informative. No unnecessary repetition.
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 no output schema, the description adequately explains return formats for each metric type. It covers all parameters and provides examples. Minor gap: does not specify behavior when incompatible parameters (e.g., rentals with property_type) are used.
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?
With 0% schema coverage, the description fully explains all 8 parameters, including defaults, allowed values (e.g., 'sales' or 'rentals'), and constraints (e.g., 'property_type' only for sales). Examples demonstrate usage effectively.
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 'Query Dubai property data - sales transactions or rental contracts', specifying the verb, resource, and the two data types. This is precise and distinguishes any potential confusion between sales and rentals.
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 includes usage examples and explains when to use each parameter, such as 'property_type' being for sales only. However, it lacks explicit guidance on when not to use the tool or alternatives, but since no sibling tools exist, it remains clear enough.
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.
v0.2.0query_dldOnly one tool exists, so there is no possibility of confusion between tools.
With a single tool, naming consistency is not applicable; the tool name is clear and descriptive.
A single tool for querying Dubai property data is too few for comprehensive coverage. The tool is powerful but would benefit from additional tools for different operations or data types.
The tool covers a wide range of queries with flexible parameters, but lacks operations for retrieving metadata like available areas or property types, and does not support updates or deletions.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Registered Dubai apartment prices, rents, gross yields and returns, by building and by area.
Official Dubai real estate data: live prices and rental yields by area, from the DLD.
Manage your real-estate stock on Propick (Dubai): bulk listing sync, lookups and run reports.
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/level09/dld-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
