Off-plan projects in Ras Al Khaimah, UAE: search by area, developer, budget and handover year.
Scored across 6 tools
Each tool has a clearly distinct purpose: listing projects, fetching project details, comparing projects, listing areas, listing developers, and broad site search. The only potential overlap between list_projects and search_site is explicitly resolved by the descriptions. An agent can reliably select the right tool.
All tool names use consistent snake_case with a verb_noun pattern (compare_projects, get_project_details, list_areas, list_developers, list_projects, search_site). No mixed conventions or vague names.
Six tools is well-scoped for a read-only RAK real estate catalogue server. Each tool covers a distinct operation and none feels redundant or missing for the core workflows.
The surface covers listing, inspecting, comparing, and searching projects plus area and developer discovery. Minor gaps exist, such as no dedicated get_area_details or get_developer_details tools, but the list tools return URLs and summaries that let agents work around this.
Compare 2-4 projects side by side. Accepts slugs or project names; anything that cannot be resolved is reported in not_found.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the answer. Default en. | |
| slugs | Yes | Array of project slugs or names (2-4 entries) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one useful behavioral detail — unresolvable inputs are reported in not_found rather than failing — but says nothing about what the comparison actually contains or how results are ordered.
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 short sentences, zero filler, with the core comparison behavior front-loaded and the error-handling note second. Nothing could be removed without losing information.
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 read-only tool with full schema coverage this is close to adequate, but with no output schema the agent cannot tell what dimensions the comparison returns or how to interpret an empty versus partial result. One clause on compared fields would close the gap.
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 100%, so both parameters are already documented, including the lang enum. The description only restates that names are accepted alongside slugs and that failures land in not_found, adding marginal meaning beyond the 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?
States a specific verb and resource ('Compare 2-4 projects side by side'), which is clearly distinguishable from the single-project sibling get_project_details. It does not explicitly name that sibling as the alternative, so it stops short of 5.
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?
Usage is only implied: the 2-4 project constraint suggests this is for multi-project comparison rather than single-project lookup. No explicit when-to-use or when-not-to-use guidance versus get_project_details or list_projects is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch every stored fact for one project: developer, area, starting price, handover, ownership, DLD fee, payment plan, unit mix, amenities, distances, FAQ and description. Accepts a slug or a project name.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the answer. Default en. | |
| name | No | Project name e.g. "Radisson Blu by RAK". Used when the slug is unknown. | |
| slug | No | Project slug e.g. "costa-mare" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so safety profile is covered. The description adds the breadth of the returned record via the field list, but says nothing about not-found behavior, whether name matching is fuzzy, or how lang affects the payload.
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, lead sentence front-loads the what and the return contents, second sentence handles lookup input. Nothing redundant.
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, listing the stored fields is the right compensation and it does that well. However, for a lookup tool with zero required parameters, it omits what happens when slug and name disagree, when neither resolves, and how the language parameter influences returned text.
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%, so all three parameters are documented in the schema; the description only restates the slug-or-name lookup option. No additional semantics about precedence when both slug and name are supplied, or default behavior when neither is given.
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?
States a specific verb and resource ('Fetch every stored fact for one project') and enumerates the returned fields, which makes the scope (single, full record) clearly distinct from list_projects or compare_projects. It never names a sibling explicitly, so differentiation is inferred rather than stated.
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?
Usage is only implied: you call it when you need the full record for one known project. There is no guidance on when to prefer search_site or list_projects to resolve a project first, and no note on the slug-vs-name precedence beyond 'Used when the slug is unknown' in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Ras Al Khaimah area guides published on this site, with the guide URL, its on-page summary and how many catalogue projects sit in each area.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the answer. Default en. | |
| query | No | Optional area name filter, e.g. "Marjan" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that it lists only content published on this site and enumerates the returned fields, but says nothing about pagination, result limits, or ordering.
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?
A single front-loaded sentence that states the resource first and the return payload second, with no filler. It is dense but every clause carries information an agent needs.
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, the description usefully enumerates the returned fields (guide URL, on-page summary, project count per area), which is exactly what an agent needs to decide the call is sufficient. Only pagination/coverage of 'all areas' is left unstated.
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 100%, so both the lang enum and the optional query filter are already documented in the schema. The description hints at area-level granularity but adds no detail on how the query filter matches or how lang affects the guide URL/summary.
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 gives a specific verb (List) and a specific resource (Ras Al Khaimah area guides published on this site), plus the fields returned (URL, on-page summary, project count). The resource name 'area guides' is clearly distinct from siblings like list_projects or list_developers, though no sibling is named explicitly.
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?
Usage is implied by the scope (only guides published on this site) and the per-area project counts, which suggests a discovery/orientation role. However, the description never says when to prefer this over search_site, list_projects or compare_projects, and offers no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the developers that have a profile page on this site, with the page URL and how many catalogue projects each one has. Use it for "which developers build in RAK" or to look a developer up before filtering projects.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the answer. Default en. | |
| limit | No | Max results, default 40, hard cap 100 | |
| query | No | Optional developer name filter, e.g. "Aldar" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral scope by saying it returns developers with profile pages and includes page URL plus catalogue project count, which helps an agent understand what the tool surfaces without an output schema.
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 efficient sentences with no wasted language. The core purpose and return fields are front-loaded, followed by concise usage examples.
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, the description appropriately explains the important return values: page URL and project counts. The schema covers parameters and annotations cover safety, so the definition is largely complete, though it could say more about pagination or the optional name filter.
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 100%, so all three parameters are already documented in the schema. The description's phrase "look a developer up" loosely implies the query filter, but it does not add syntax, defaults, or filtering semantics beyond what the schema provides, making 3 the appropriate baseline.
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: list developers with a profile page on the site. It also specifies key return content (page URL and catalogue project count), which clearly distinguishes it from project-focused siblings like list_projects and compare_projects.
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?
It gives concrete usage examples ("which developers build in RAK" and looking a developer up before filtering projects), which clearly indicates when to use it. It does not explicitly name when not to use it or name a sibling alternative, so it falls short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List off-plan projects from the site catalogue. Filter by area, developer, budget, handover year or free text. Returns name, developer, area, starting price, handover, unit types and the page URL. Sold-out projects are excluded unless include_sold_out is true.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | Area name e.g. "Al Marjan Island", "Mina Al Arab", "RAK Central" | |
| lang | No | Language of the answer. Default en. | |
| limit | No | Max results, default 5, hard cap 25. ALWAYS request 5 unless visitor explicitly asks for more. | |
| query | No | Free text matched against project, developer and area names (e.g. "beachfront", "branded residence") | |
| developer | No | Developer name e.g. "RAK Properties", "BNW Developments" | |
| handover_year | No | Year of handover, e.g. 2027 | |
| max_price_aed | No | Maximum starting price in AED | |
| min_price_aed | No | Minimum starting price in AED | |
| include_sold_out | No | Include projects flagged sold out. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, closed-world catalogue lookup. The description adds useful behavior beyond annotations: sold-out projects are excluded by default unless include_sold_out is true, and it lists the fields returned.
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 tightly written sentences cover purpose, filtering, return fields, and the sold-out default. The most important scoping information is front-loaded with no wasted phrasing.
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?
There is no output schema, and the description compensates by naming the returned fields. Given full parameter schema coverage and annotations covering safety, the definition gives an agent enough information to call the tool correctly.
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 100%, so all nine parameters are already documented in the schema. The description restates the main filter categories and include_sold_out behavior but adds little parameter-level meaning beyond the 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 states a clear verb and resource ("List off-plan projects") and scopes it to the site catalogue. It does not explicitly distinguish itself from sibling tools such as get_project_details, compare_projects, or search_site.
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?
It names supported filter dimensions, which implies how to use the tool for discovery. However, it gives no explicit when-to-use guidance versus alternatives like search_site or get_project_details, and no exclusions beyond sold-out handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free-text search across the whole site: projects, developer pages, area guides, informational guide pages and blog articles. Use this for any question the project tools do not answer directly (buying process, freehold ownership, visas, mortgages, fees, market news) and cite the pages it returns.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of the answer. Default en. | |
| limit | No | Max results per group, default 5, hard cap 20 | |
| query | Yes | Search text, e.g. "buying process for foreigners", "freehold ownership", "Wynn casino" | |
| types | No | Optional subset of result groups. Default: all five. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false; the description reinforces the closed corpus ('across the whole site') and adds an agent-facing duty to cite returned pages, which is behavior not encoded anywhere in structured fields. It does not describe result ordering or pagination, but the safety profile is already covered by 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: the first defines scope and result groups, the second gives the routing rule and output duty. Front-loaded and free of 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?
With no output schema, the description still signals that results are pages worth citing, and the schema fully documents the four inputs. Only a note on relevance ranking or result grouping would make it complete for an agent composing an answer.
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 100%, including examples for query and defaults for limit, lang, and types, so the schema carries parameter meaning. The description adds no parameter-level detail beyond implying broad free-text queries, which is the expected baseline at full coverage.
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?
States a specific verb (free-text search) and resource scope (whole site), then enumerates the five result groups returned. This clearly separates it from the sibling tools, which are all structured project/area/developer lookups.
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?
Gives an explicit routing rule: use it for questions the project tools do not answer directly, with concrete example topics (buying process, freehold, visas, mortgages, fees, market news). The agent can decide between this and list_projects/get_project_details without inference.
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.
compare_projectsget_project_detailslist_areaslist_developerslist_projectssearch_siteNew-build and off-plan property in Oman: projects by area, developer, bedrooms and budget in OMR.
Find UAE off-plan developments and registered residential sales.
Off-plan and ready property in the UAE, Oman, Georgia, Cyprus, Bali, Thailand and London.
Official Dubai real estate data: live prices and rental yields by area, from the DLD.
Add one secure layer between your agents and this server.