NC Keys — Northern Cyprus property

Search property listings

search_listings

Read-onlyIdempotent

Search current property listings in Northern Cyprus. All filters are optional and accept English, Russian or Turkish spellings (e.g. region 'Kyrenia' or 'Гирне'). Returns up to limit listings (featured first, then newest by default) with a one-line summary, url and contact_url. Example: long-term rent of a 2+1 in Iskele up to £700 → deal='Rent', region='iskele', layout='2+1', price_max=700, price_period='month'.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`deal`	No	Sale or Rent
`kind`	No	Property type(s), e.g. ['villa', 'house']
`sort`	No	recommended = featured first, then newest	recommended
`type`	No	Property type
`limit`	No	How many listings to return, 1–10
`cursor`	No	next_cursor from a previous call, for more results
`layout`	No	'studio', '1+1', '2+1', '3+1', or '4+' for 4 or more bedrooms
`poster`	No	Only listings where the author says they are the owner / an agent / the developer
`region`	No	girne (Kyrenia), iskele, famagusta, lefkosha (Nicosia), guzelyurt, lefke
`area_min`	No	Minimum area in m²
`currency`	No	Currency of price_min/max, default GBP
`features`	No	Amenities mentioned in the listing; all must match
`has_photo`	No	Only listings with photos
`price_max`	No	Maximum price in `currency`
`price_min`	No	Minimum price in `currency`
`sub_region`	No	Area within a region, e.g. 'Long Beach', 'Bogaz', 'Esentepe', 'Alsancak' (see list_regions)
`deposit_max`	No	Rent: max number of deposits; 0 = no deposit only
`price_period`	No	month = monthly rent, day = daily/holiday rent, total = sale price

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 11, 2026

addedInput schema / properties / deposit_max

Added value: +{
+  "anyOf": [
+    {
+      "minimum": 0,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Rent: max number of deposits; 0 = no deposit only",
+  "title": "Deposit Max"
+}

addedInput schema / properties / features

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "enum": [
+          "pool",
+          "private_pool",
+          "sea_view",
+          "beach",
+          "garden",
+          "pets",
+          "furnished",
+          "land"
+        ],
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Amenities mentioned in the listing; all must match",
+  "title": "Features"
+}

addedInput schema / properties / kind

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "enum": [
+          "apartment",
+          "villa",
+          "house",
+          "townhouse",
+          "penthouse"
+        ],
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Property type(s), e.g. ['villa', 'house']",
+  "title": "Kind"
+}

addedInput schema / properties / poster

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "owner",
+        "agent",
+        "developer"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only listings where the author says they are the owner / an agent / the developer",
+  "title": "Poster"
+}

First observedOct 1, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, safe, non-open-world semantics, so the description only needs to add what annotations cannot. It does: multilingual query normalization, the default ordering ('featured first, then newest'), and the limit cap behavior are all disclosed. Pagination via cursor is only implied by the schema, not narrated.

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?

Four compact sentences: purpose first, then language/filter behavior, then return shape and ordering, then a concrete example. Nothing is redundant and every sentence carries information an agent needs given 18 optional parameters.

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 a full output schema and complete annotation coverage, the description only needs to frame the call, and it does so well. It does not explain pagination flow (cursor/next_cursor) or the distinction between region and sub_region resolution, both of which would help given the parameter count.

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 a 3, but the description genuinely adds meaning beyond the schema: filters accept English/Russian/Turkish spellings ('Kyrenia' or 'Гирне') and sort='recommended' is explained as featured-first. The example maps natural-language intent onto concrete parameter values (deal, region, layout, price_max, price_period).

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+resource ('Search current property listings in Northern Cyprus') and the filtering/return behavior, so it is clearly a multi-result search rather than a by-id fetch. It never names the siblings get_listing or list_regions, so the differentiation from them is left to inference.

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?

Says all filters are optional and gives a full worked query example, which conveys when this tool is the right call. It stops short of explicit routing guidance (e.g. 'use list_regions to resolve a sub_region name, use get_listing for details on one result'), so no exclusions or alternatives are stated.

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

All NC Keys — Northern Cyprus 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?