Muscat Properties catalogue

Find new-build projects in Oman

search_projects

Read-onlyIdempotent

Projects in the catalogue, filtered by area, developer, bedrooms, maximum starting price in OMR, status or free text. Returns each project with its area, developer, status, starting price in OMR, bedrooms, handover and page URL. Sold-out projects are left out unless include_sold_out is true.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "search_projects"
  }
}

Input Schema

Name	Required	Description
`area`	No	Area name or slug, e.g. "Al Mouj Muscat", "Jebel Sifah", "Hawana Salalah"
`lang`	No	Language of names and URLs. Default en.
`limit`	No	At most this many projects, default 10
`query`	No	Free text matched against project, area and developer names
`status`	No	Project status
`bedrooms`	No	A home with this many bedrooms (0 = studio) must be in the project
`developer`	No	Developer name or slug, e.g. "Dar Global", "Muriya"
`residency`	No	Only projects where a purchase can qualify for Oman residency
`max_price_omr`	No	Highest starting price in Omani rial
`include_sold_out`	No	Include sold-out projects. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent, so the description's added value is the default sold-out exclusion and an explicit inventory of returned fields (area, developer, status, starting price, bedrooms, handover, page URL). That is meaningful context a caller cannot get from the annotations; it does not mention ordering or what happens when limit is hit, hence not a 5.

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 sentences, zero filler: the filter surface is front-loaded and the return shape follows. Every clause carries information the agent needs to call and interpret the tool.

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?

With 10 optional parameters and no output schema, the description does the right thing by declaring the returned fields and the sold-out default. The remaining gaps are minor: no note on ordering or how the residency and lang filters interact with results, which the schema covers only partially.

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%, so the schema already documents every parameter, including examples for area and developer and the 0=studio convention for bedrooms. The description only restates the filter names and the OMR unit, adding essentially no meaning beyond the structured fields.

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?

Opens with "Projects in the catalogue, filtered by..." and enumerates the dimensions (area, developer, bedrooms, max price, status, free text), which is specific enough to separate it from get_project's single-record lookup. The verb is implicit rather than stated ("filtered by"), and no sibling is named, so it stops short of a 5.

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

Usage Guidelines3/5

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

Usage is implied by the filter list, and one exclusion rule is stated ("Sold-out projects are left out unless include_sold_out is true"). But there is no explicit guidance on when to use this versus get_project for detail, list_areas, or list_developers to resolve slugs before filtering.

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

All Muscat Properties catalogue tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?