MRK Dubai Property

Send enquiry to MRK

submit_enquiry

Send a buyer/seller enquiry to MRK Real Estate's advisory team on the user's behalf. Only call with the user's explicit consent. Requires name plus email or phone. Rate limited.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

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

Input Schema

Name	Required	Description
`name`	Yes	Full name
`email`	No	Email address
`phone`	No	Phone with country code, e.g. +44 7700 900000
`message`	No	What the user is looking for
`language`	No	Preferred language code, e.g. 'en', 'ar'
`listingSlug`	No	Related listing slug, if any
`projectSlug`	No	Related project slug, if any

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare openWorldHint=true, readOnlyHint=false and non-idempotent, but the description adds real context beyond them: the action is taken on the user's behalf (external, third-party visible side effect), consent is required, and the endpoint is rate limited. It does not say what the user sees on success or whether a duplicate submission creates a second enquiry, but the non-idempotent hint partly covers that.

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?

Three short sentences, front-loaded with the action and destination, then the consent gate, then the contact requirement and rate limit. No filler and nothing buried.

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 7 parameters, 100% schema coverage and no output schema, the description covers the essential gates (consent, required contact info, rate limiting) an agent needs before calling. It is slightly incomplete in not indicating what the caller gets back on success, which matters for a one-shot external submission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds a genuinely useful constraint not expressed in the schema: contact requires name plus email or phone. That clarifies practical usage of the optional email/phone fields beyond what their individual schema descriptions say.

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?

States a specific verb (send) and resource (buyer/seller enquiry) plus the destination (MRK Real Estate's advisory team) and that it acts on the user's behalf. That is far more specific than a name restatement. It does not explicitly contrast with the sibling 'ask' tool, which is the most plausible alternative for routing a user's question, 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 Guidelines4/5

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

Gives a clear precondition for use: only call with the user's explicit consent, which is a real gating rule an agent must respect. It does not say when to prefer this over 'ask' or what to do if the user is merely browsing rather than enquiring, so exclusions are absent.

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

All MRK Dubai Property 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?