This server gives AI agents structured, real-time access to Northern Cyprus property data for comprehensive research, investment analysis, and legal guidance. Key capabilities include:
Property Search & Discovery: Search active listings by city, type, bedrooms, and price; free-text search; fetch full details by UUID or listing number; compare properties side-by-side.
Market Analysis & Price Intelligence: Obtain aggregated price indexes per city, market overviews, rental yield estimates (gross/net), city comparisons, and breakeven calculations.
Location & Neighborhood Insights: List all valid cities and districts; access 360° district profiles with buyer persona matching (retiree, investor, student, family, digital nomad, vacation); get tailored neighborhood suggestions.
Legal & Procedural Guidance: Learn about title deed types (koçan), foreign purchase rules, taxes, residency, and the Permission to Purchase (PTP) process; assess title-deed risk bands; step-by-step foreign-buyer roadmap.
Investment & Financial Tools: Estimate student housing rental outlooks near specific universities; convert prices across GBP/EUR/USD/TRY with live rates; receive warnings for off-plan staged payments.
Additional Features: Pre-built resources and prompts for investment analysis and legal checks; simplified search/fetch tools for OpenAI-compatible clients; covers 6 cities and 100+ districts; all prices normalized to GBP; read-only with no contact details exposed; max 10 results per query; outputs carry appropriate disclaimers.
Exposes OpenAI-compatible search and fetch tools for property data, enabling integration with ChatGPT and other OpenAI-based agents.
AI-native property discovery for North Cyprus (KKTC). Built on the Model Context Protocol — works in Claude, ChatGPT, Gemini, Cursor, and any MCP-compatible client.
The Evlek MCP server gives AI agents structured, real-time access to North Cyprus property data — search active listings, compare cities and districts, track the price index, and estimate rental yield. All data is sourced live from evlek.app. Title-deed (koçan) and legal-procedure tools are deliberately not part of the surface: that taxonomy has not passed an independent KKTC legal audit.
This repository is MIT-licensed for the public manifest, documentation, examples, and reference clients contained here. The hosted Evlek service, evlek.app web app, mobile apps, listing database, AI prompts, business logic, brand assets, name, logo, and trade dress remain proprietary and are not licensed under MIT. See LICENSE for details.
Related MCP server: UK Property Data
AI-first. Built for agentic workflows from day one — not retrofitted on a legacy listing API.
Multilingual. Property data in TR, EN, RU, DE, AR (currently exposed via tool descriptions in EN).
Verification-aware listings. Evlek surfaces listing and account verification context where available, and the MCP omits contact fields to preserve Evlek's reveal/contact funnel.
Built for the region. Optimized for the 6 cities of North Cyprus (Lefkoşa, Girne, Gazimağusa, İskele, Güzelyurt, Lefke) and 100+ districts.
Production-grade. OWASP MCP Top 10 aligned — Zod input validation, output sanitization, rate limiting (60/min/IP, 500/min global), Sentry observability.
Most modern MCP clients (Claude, Cursor, VS Code) connect directly to the Streamable HTTP endpoint — no local bridge needed:
{
"mcpServers": {
"evlek": {
"url": "https://evlek.app/api/mcp"
}
}
}Add https://evlek.app/api/mcp as a custom connector. Evlek exposes OpenAI-compatible search and fetch tools, so it works in ChatGPT connectors and Deep Research in addition to developer mode.
If your client only supports stdio servers, use the pinned mcp-remote bridge. Add this to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"evlek": {
"command": "npx",
"args": ["-y", "mcp-remote@0.1.16", "https://evlek.app/api/mcp"]
}
}
}Restart Claude Desktop. The "evlek" server appears in the tools list.
npx @modelcontextprotocol/inspector https://evlek.app/api/mcpcurl -X POST https://evlek.app/api/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'More configs: examples/
This repo is also a runnable MCP server. It answers initialize / tools/list entirely locally from the embedded tool contract (tools.json) and fetches live data from the Evlek data API when a tool is called:
npx github:Evlek/evlek-mcp # or: npm install && npm start{
"mcpServers": {
"evlek": {
"command": "npx",
"args": ["-y", "github:Evlek/evlek-mcp"]
}
}
}Smoke-test it (spawns the server and speaks real MCP over stdio):
npm test # live: initialize + tools/list + a real tools/call
OFFLINE=1 npm test # offline: introspection works with zero network# | Tool | What it does |
1 |
| Search active listings by city, type (sale/rent/daily), bedrooms, and GBP price range (normalized server-side). Up to 10 results with title, price, location, direct link. |
2 |
| Aggregated avg/median/min/max prices per city + top districts (Evlek Price Index), with IQR outlier exclusion and a minimum-sample floor. |
3 |
| High-level market overview — indicative city rent/sale levels, yield ranges, and routing to Evlek's calculators. |
4 |
| Compare 2-4 cities side-by-side with prices, listing counts, top districts, automatic verdict. |
5 |
| Estimate gross/net annual rental yield + breakeven years. Cities without sufficient data return a clear unsupported message. |
6 |
| Match a buyer persona (retiree, investor, student, family, digital_nomad, vacation) to neighborhoods. |
7 |
| Compare 2-4 active listing UUIDs side-by-side with GBP price-per-m², area, bedrooms, value insight. Mixed sale/rent/daily IDs are rejected — those prices are not comparable. |
8 |
| 360° district profile — sale/rent stats, £/m², bedroom breakdown, estimated yield, persona match. Same outlier filter and sample floor as the price index. |
9 |
| Student-housing rental outlook near a KKTC university, academic-year vs year-round. |
10 |
| Convert a price across GBP/EUR/USD/TRY using live date-stamped rates; off-plan staged-payment context. |
11 |
| 360° profile of one active listing by UUID, including GBP-normalized price-per-m². |
12 |
| (ChatGPT-compatible) Free-text search returning listings as |
13 |
| (ChatGPT-compatible) Fetch full listing detail by id from |
14 |
| Valid city + district dictionary — call first when unsure of location names. |
15 |
| Look up a listing by its |
Three tools additionally ship a sandboxed HTML view that MCP Apps-capable hosts (Claude web/desktop) render inline in the conversation:
Tool | Widget | What you get |
|
| Horizontal carousel of cards (cover photo, price, location) — the whole card is the link, no separate CTA button; opening one drills into the SAME detail view as |
|
| Photo gallery with AI captions, spec sheet, and a before/after AI virtual-staging comparison slider |
|
| Per-city summary rows inline (avg/median, capped to a few cities to stay compact); the full district breakdown and city-comparison table open in fullscreen, not inline |
Views are static, self-contained HTML — no bundler, no third-party JS. Listing
data reaches them only at runtime over postMessage and is written with
textContent, never innerHTML. CSP is declared per resource
(_meta.ui.csp) and limited to the public listing-photo origin.
See TOOLS.md for full input schemas, parameter details, and response examples.
Read-only evlek:// data via resources/list / resources/read, plus parameterized templates via resources/templates/list:
Templates: evlek://price-index/{city} · evlek://district/{city}/{district}
Instances: per-city price indexes (girne, iskele, lefkosa, gazimagusa, guzelyurt, lefke) and a sample district profile.
investment_analysis · student_rental_outlook
"Find 2-bedroom flats for rent in Girne under £500/month."
"What's the median sale price per square meter in Lefkoşa?"
"Compare İskele and Famagusta for investment — which has higher rental yield?"
"Estimate the rental yield on a £150,000 2+1 in Girne."
"Show me apartments in Girne under £150,000."
"What does a district profile for Alsancak look like?"
Cities: 6 (Girne, İskele, Lefkoşa, Gazimağusa, Güzelyurt, Lefke)
Districts: 100+
Currency: GBP primary; TRY/USD/EUR normalized to GBP server-side using live daily exchange rates
Tool descriptions: EN · Listing data fields: TR + EN
The Evlek MCP server runs as a hosted endpoint at https://evlek.app/api/mcp. It speaks the Model Context Protocol over Streamable HTTP (JSON-RPC 2.0), protocolVersion 2026-07-28, and exposes tools, resources, resource templates, and prompts. Discovery metadata is published at /.well-known/mcp.json.
This repository contains:
server.json — MCP Registry manifest
TOOLS.md — Full tool reference (JSON schemas + examples)
examples/ — Configuration files for Claude Desktop, Cursor, VS Code
CONTRIBUTING.md — How to file issues and propose docs improvements
The full server implementation (database schemas, API routes, AI prompt engineering, listing pipeline) is hosted at evlek.app and remains proprietary.
Per OWASP MCP Top 10: per-IP rate limit 60/min, global 500/min, 30s hard timeout, Zod input validation, output sanitization (prompt-injection defense), max 10 results per query, Supabase anon key + RLS, no stack traces leaked, Sentry observability.
To report a security issue, email hello@evlek.app.
MCP version: 1.9.0 (live)
Protocol: 2026-07-28
Primitives: 15 tools · 7 data resources + 3 interactive widget resources · 2 resource templates · 2 prompts
Auth: none (public read-only)
Endpoint: https://evlek.app/api/mcp
MCP Registry: app.evlek/mcp-server
MIT — see LICENSE. MIT covers the public manifest, documentation, examples, and reference clients in this repository only (see License scope above). The hosted Evlek service (web app, mobile apps, listing data, AI prompts, database schemas, business logic) is proprietary.
Trademark notice: "Evlek" is a trademark of Onur Dokuzoğlu. The MIT license does not grant rights to use the "Evlek" name, logo, or branding except as described in this README. To request brand usage permission, contact hello@evlek.app.
Web: evlek.app
iOS: App Store
Android: Google Play
MCP endpoint: https://evlek.app/api/mcp
MCP documentation: evlek.app/mcp
MCP Registry: app.evlek/mcp-server
Model Context Protocol: modelcontextprotocol.io
Contact: hello@evlek.app
Built in North Cyprus by an architect, not a software firm. Powered by Anthropic Claude, Supabase, Vercel, and the Model Context Protocol.
Given a KKTC title-deed (koçan) type, return a neutral risk BAND, framing notes, and verification steps. General information only — every result carries a disclaimer and recommends an independent KKTC lawyer plus a Land Registry title check. Not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| title_deed_type | Yes | KKTC koçan type: turk_kocan, esdeger_kocan, tahsis, foreign_title, kat_irtifak, or unknown (legacy turkish/equivalent/allocation/foreign accepted). |
| Name | Required | Description |
|---|---|---|
| band | No | |
| label | No | |
| framing | No | |
| kocanType | No | |
| disclaimer | No | |
| verifySteps | No | |
| bandDescription | No | |
| legalAuditStatus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint, destructiveHint), the description adds that results are neutral, carry a disclaimer, and are not legal advice, fully disclosing behavioral traits.
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, no fluff; the first sentence clearly states the action and output, the second adds disclaimers. Highly efficient.
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 the presence of an output schema, the description adequately covers input, output, and limitations, making it complete for the tool's role.
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% with enum descriptions. The description only restates 'Given a KKTC title-deed type', adding no new parameter semantics beyond what schema provides.
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 uses specific verb 'return' and resource 'risk band', and clearly distinguishes from sibling tools which are about properties, districts, prices, etc.
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 explicitly states it is for general information only, not legal advice, and recommends consulting a lawyer and Land Registry, providing clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2-4 Northern Cyprus cities side-by-side with aggregated prices (avg, median, min, max), listing counts, and top districts. Useful for deciding between investment locations.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Sale or rent (default: sale) | |
| cities | Yes | Cities to compare (2-4) |
| Name | Required | Description |
|---|---|---|
| type | No | |
| cities | No | |
| generatedAt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to reiterate safety. The description adds no further behavioral traits (e.g., rate limits, data freshness), but it does not contradict 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?
The description is two sentences, front-loading the action and output. Every word adds value; no unnecessary details.
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 the simple parameter set (2 params, 1 required), existing annotations, and presence of an output schema, the description is complete and sufficient for an agent to understand usage.
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 the schema fully documents both parameters and their enums. The description does not add extra meaning beyond the schema, which is adequate.
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 specifically states 'Compare 2-4 Northern Cyprus cities side-by-side' with clear output details (aggregated prices, listing counts, top districts). This clearly distinguishes it from siblings like 'get_district_profile' or 'compare_properties'.
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 mentions 'Useful for deciding between investment locations,' providing clear context. It does not explicitly state when not to use it or name alternatives, but the purpose is evident, and siblings are available for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2-4 active Evlek property listings side-by-side. Returns price, area, bedrooms, price-per-m², location for each, plus an automatic value insight (cheapest £/m², largest area, same-city grouping). Pass UUIDs from search_listings results.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_ids | Yes | Evlek listing UUIDs (2-4) |
| Name | Required | Description |
|---|---|---|
| count | No | |
| missing | No | |
| listings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that it returns a side-by-side comparison with automatic value insights, providing useful behavioral context beyond 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?
The description is two sentences, front-loaded with the core purpose, and every sentence adds essential information without redundancy.
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 that an output schema exists (so return values need not be detailed), the description covers purpose, prerequisites, and what it returns, making it complete for the tool's complexity.
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 100% schema coverage, the schema already documents the 'listing_ids' parameter. The description adds value by telling users to pass UUIDs from search_listings results, clarifying the source.
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 'Compare 2-4 active Evlek property listings side-by-side' and lists specific return fields (price, area, bedrooms, etc.), distinguishing it from sibling tools like search_listings and get_listing_detail.
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 explicitly states 'Pass UUIDs from search_listings results', indicating the prerequisite step. While it doesn't mention when not to use, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full detail of one Evlek listing by id (from search): title, description, GBP-normalized price, location, size, amenities. Read-only; contact details intentionally omitted. Same underlying data as get_listing_detail — this fixed id-only form exists for the ChatGPT/OpenAI connector contract; prefer get_listing_detail directly outside that connector.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Evlek listing id (UUID) from search |
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| text | No | |
| title | No | |
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint. Description adds useful context beyond annotations: contact details are intentionally omitted, and it shares the same data as get_listing_detail. No contradiction.
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 well-structured sentences that front-load the purpose and add necessary context. No redundant 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?
Given output schema exists, return values are not needed. Tool is simple with one parameter; description covers purpose, usage guidelines, and behavioral traits completely, including its relationship to get_listing_detail.
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% for the single parameter 'id'. Description adds that the id comes from search and is a UUID, providing extra context beyond the schema description.
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?
Description clearly states it fetches full detail of one Evlek listing by id, listing specific fields returned. It explicitly distinguishes itself from the sibling tool get_listing_detail by explaining this is a fixed id-only form for a connector contract.
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?
States 'prefer get_listing_detail directly outside that connector', giving explicit guidance on when to use this tool vs the alternative. Also mentions contact details are omitted, setting expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DEPRECATED — alias of get_legal_info(topic: 'ptp_process'); will be removed after 2027-07-30, use get_legal_info directly. Step-by-step roadmap for a foreign national buying property in Northern Cyprus (KKTC), including the Permission to Purchase (PTP) process. General information only — confirm current rules with an independent KKTC lawyer. Not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| topic | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes deprecation status, alias relationship, and that it provides only general information. Annotations already indicate read-only and open-world, but the description adds context that is not present in annotations (deprecation timeline, alias).
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?
Description is concise with three sentences, front-loads the deprecation warning, and every sentence adds value. No wasted words.
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 deprecated alias tool with no parameters and existing annotations and output schema, the description provides all necessary context: purpose, alias, deprecation, and disclaimer. Complete and sufficient.
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?
Input schema has no parameters, so parameter semantics are not applicable. Baseline for 0 parameters is 4. Description does not need to add parameter info.
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?
Clearly states it is a step-by-step roadmap for foreign nationals buying property in Northern Cyprus, including the PTP process. Also explicitly says it is an alias of get_legal_info and deprecated, distinguishing it from siblings.
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?
Explicitly advises to use get_legal_info directly instead, and warns that it is general information only, not legal advice, and to confirm with a lawyer. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a comprehensive profile for a single district: active listing counts (sale & rent), average/median prices, £/m², bedroom breakdown, estimated gross yield (rent/sale ratio), and matching buyer personas (retiree, investor, student, family, digital_nomad, vacation). Use after compare_cities narrows the city.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| district | Yes | District name (2-60 chars) |
| Name | Required | Description |
|---|---|---|
| city | No | |
| rent | No | |
| sale | No | |
| district | No | |
| personas | No | |
| totalActive | No | |
| grossYieldPct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds context about returned metrics (active listings, prices, yields, personas) without contradicting annotations. It does not disclose additional behavioral traits like rate limits or data freshness, but the annotations cover the safety profile adequately.
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 sentences front-loaded with the tool's purpose and contents, followed by a clear usage recommendation. No redundant words, every sentence adds value.
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 an existing output schema, the description does not need to detail return values. The description is sufficient given the tool's complexity and annotations. It could mention that the output is open-world (per annotation) but overall is complete enough.
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 50% (district has a description, city does not). The description does not explain either parameter further, relying on the schema. Since coverage is low, the description should compensate but it does not, leaving ambiguity about city values (list in schema) and district format.
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 uses the specific verb 'Returns' and clearly names the resource 'comprehensive profile for a single district', listing exact metrics. It also distinguishes itself from the sibling 'compare_cities' by advising to use it after that tool narrows the city.
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?
Explicitly states 'Use after compare_cities narrows the city.' which provides clear context for when to invoke this tool. However, it does not include when-not-to-use or alternative tools for similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
General legal/procedural routing for Northern Cyprus property topics: title deed types (koçan), foreign purchase rules, taxes, residency context, and PTP (Permission to Purchase) process. Always recommend consulting a lawyer for specific cases.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Legal topic to retrieve |
| Name | Required | Description |
|---|---|---|
| topic | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds important context: it is a general routing tool, not a definitive legal resource, and recommends lawyer consultation. This clarifies its non-definitive nature beyond what annotations provide.
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 concise sentences, front-loaded with main purpose. No filler or redundant information. Every sentence adds value.
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 simple read-only tool with one parameter and an output schema, the description covers purpose, topics, and a crucial disclaimer. It is nearly complete; only missing fine-grained usage guidance relative to siblings.
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?
The input schema only labels topic as 'Legal topic to retrieve' with no enum descriptions. The description lists the actual topics (kocan_types, foreign_purchase, etc.) with brief context (e.g., 'title deed types (koçan)'), adding significant 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 clearly states it provides general legal/procedural routing for Northern Cyprus property topics, listing key areas. It distinguishes from siblings like foreign_buyer_roadmap by emphasizing its routing nature, though not explicitly differentiating from all.
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 implies use for informational routing and advises consulting a lawyer for specific cases, but does not explicitly state when not to use it or how it compares to related tools like foreign_buyer_roadmap or assess_title_risk.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a single Evlek listing by its public listing number (e.g. "EVL-123456" or "123456") and return its full detail — same shape as get_listing_detail. Use this when a listing number is known (site/card reference) instead of a UUID.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_number | Yes | Evlek listing number, e.g. "EVL-123456" or "123456". |
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| city | No | |
| type | No | |
| found | No | |
| price | No | |
| title | No | |
| photos | No | |
| areaSqm | No | |
| bedrooms | No | |
| currency | No | |
| district | No | |
| features | No | |
| listedAt | No | |
| priceGbp | No | |
| amenities | No | |
| bathrooms | No | |
| furnished | No | |
| photoCount | No | |
| coverImageUrl | No | |
| listingNumber | No | |
| titleDeedBand | No | |
| titleDeedType | No | |
| pricePerSqmGBP | No | |
| titleDeedLabel | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds that the output shape matches get_listing_detail, which is useful context beyond 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 concise sentences, front-loaded with purpose and usage guidance. No unnecessary words.
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 single-parameter lookup tool with an output schema, the description provides sufficient context: it explains the input, output shape, and when to use it. No gaps.
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 the parameter is already well-documented. The description reiterates the format (e.g., 'EVL-123456' or '123456'), adding minimal extra meaning. Baseline 3 is appropriate.
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 the verb 'Look up', the resource 'Evlek listing', and the input method (by listing number). It also differentiates from get_listing_detail by noting the same shape and alternative identifier (UUID vs number).
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?
Explicitly instructs when to use: 'when a listing number is known (site/card reference) instead of a UUID.' This provides clear guidance on choosing this tool over alternatives like get_listing_detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a 360° profile of one active Evlek listing by UUID: title, description, price, location, size, amenities, features, cover image, per-photo captions and tags, and title-deed (koçan) type with its risk band. Contact details are intentionally omitted. Pass a UUID from search_listings.
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes | Evlek listing UUID |
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| city | No | |
| type | No | |
| found | No | |
| price | No | |
| title | No | |
| photos | No | |
| areaSqm | No | |
| bedrooms | No | |
| currency | No | |
| district | No | |
| features | No | |
| listedAt | No | |
| priceGbp | No | |
| amenities | No | |
| bathrooms | No | |
| furnished | No | |
| photoCount | No | |
| coverImageUrl | No | |
| listingNumber | No | |
| titleDeedBand | No | |
| titleDeedType | No | |
| pricePerSqmGBP | No | |
| titleDeedLabel | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the description adds context beyond them by specifying omitted fields (contact details) and the breadth of data returned. No contradictions.
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 a single sentence that front-loads the purpose and enumerates fields concisely. Every phrase adds value with no wasted words.
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 the presence of output schema, the description need not detail return format. It enumerates many included fields and explicitly notes omitted contact details. For a single-parameter detail retrieval tool, it is complete.
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?
The schema has 100% coverage for property_id with a basic description. The tool description adds value by specifying the parameter should come from search_listings, providing origin context 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 clearly states the tool returns a '360° profile' of an active listing by UUID, listing many fields. It implies differentiation from siblings like 'get_listing_by_number' by specifying UUID input, but does not explicitly distinguish.
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 says 'Pass a UUID from search_listings', indicating when to use this tool after searching. It mentions 'Contact details are intentionally omitted', giving insight into limitations, but no explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a high-level market overview for Northern Cyprus property: average rents and sale prices by major city, rental yields, investment highlights, and key facts (taxes, foreign ownership rules).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| source | No | |
| indexes | No | |
| lastUpdated | No | |
| investmentHighlights | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, destructiveHint) already indicate safe read-only behavior. The description adds value by detailing the output contents (rents, sales, yields, investment highlights, key facts) without contradicting 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?
A single sentence that efficiently conveys the tool's purpose and output details without redundant words. Every clause adds value: 'high-level market overview', 'average rents and sale prices by major city', 'rental yields', 'investment highlights', 'key facts'.
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 zero-parameter tool with an output schema, the description fully explains what the tool returns, covering all relevant aspects (prices, yields, highlights, facts). No gaps.
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?
No parameters exist (schema coverage 100%), so the description need not add param info. Baseline for zero params is 4. The description focuses on output, which is appropriate.
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 the tool returns a 'high-level market overview for Northern Cyprus property' and lists specific data points (average rents, sale prices, rental yields). This verb+resource combination is specific and distinguishes it from sibling tools like get_district_profile or compare_cities.
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 implies the tool is for broad market context but does not explicitly state when to use alternatives like get_district_profile or compare_cities. The context is clear, yet no exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the live Evlek Price Index: aggregated average, median, min, max prices per city and top districts. Based on all active listings on evlek.app. Useful for market analysis and investment decisions.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| type | No | Sale or rent (default: sale) |
| Name | Required | Description |
|---|---|---|
| type | No | |
| cities | No | |
| generatedAt | No | |
| totalListings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it is 'live' and 'based on all active listings on evlek.app,' which goes beyond the annotations and clarifies data freshness and source. No contradictions.
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 sentences long, front-loaded with the key action and result, and contains no filler. Every sentence adds value.
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 the tool's simplicity (2 optional enum parameters, read-only, with an output schema), the description adequately explains what is returned and its source. It covers the main use case without needing extensive detail.
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?
The input schema has two parameters with enums, and the 'type' parameter includes a description. The description mentions 'per city' referencing the city parameter but does not detail the 'type' parameter or any other semantics. With 50% schema description coverage, the description provides partial compensation but not full clarity.
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 the tool returns the 'live Evlek Price Index' with aggregated statistics per city and top districts. The verb 'returns' and resource 'Price Index' are explicit. However, it does not differentiate from sibling tools like 'get_market_overview' or 'compare_cities', which could have overlapping purposes.
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 mentions 'useful for market analysis and investment decisions,' providing a reasonable context. However, it offers no explicit guidance on when not to use this tool or which alternative sibling tool might be better suited for a given scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate estimated gross and net annual rental yield for a property given its purchase price and city. Returns breakeven years and comparison to city averages.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| bedrooms | No | Bedroom count (integer 0-10) | |
| purchasePrice | Yes | Purchase price in GBP |
| Name | Required | Description |
|---|---|---|
| city | No | |
| dataSource | No | modelled — not derived from live rental listings |
| netYieldPct | No | |
| netAnnualGBP | No | |
| cityBenchmark | No | |
| grossYieldPct | No | |
| breakevenYears | No | |
| grossAnnualGBP | No | |
| monthlyRentGBP | No | |
| purchasePriceGBP | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, which are consistent with the description. The description adds that it returns breakeven years and city comparison, but does not disclose any additional behaviors beyond what annotations and schema imply.
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 a single, clear sentence with no wasted words, front-loading the core action of calculating estimated rental yield.
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 an output schema present and annotations covering safety, the description adequately explains return values (breakeven years, city comparison). Could be considered complete for a straightforward estimation tool, though it lacks differentiation from sibling tools in usage guidance.
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 67% (two of three parameters have descriptions). The description adds context for purchasePrice and city but does not explain the optional bedrooms parameter beyond the schema's existing description. Baseline 3 is appropriate given moderate 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?
The description clearly states it calculates gross and net annual rental yield for a property given purchase price and city, distinguishing it from sibling tools like get_market_overview or get_price_index by focusing specifically on yield estimation.
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 implies usage when needing rental yield estimates but does not explicitly state when to use or not use this tool versus alternatives, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the canonical list of valid KKTC city slugs plus the districts that currently have active Evlek listings. Call this first when unsure about exact city/district spelling — search_listings, compare_cities, and get_district_profile all reject unrecognized city values.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional — limit districts to a single city slug. |
| Name | Required | Description |
|---|---|---|
| cities | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds context about returning only active listings and being a validation step, which is useful but not extensive. No contradictions.
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, no waste. First sentence states the core functionality, second provides usage guidance. Ideal structure for efficient parsing.
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 the simple one-parameter schema and presence of an output schema, the description fully covers what the agent needs: purpose, usage timing, and relation to siblings. No gaps.
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% with a clear enum and description. The description does not add new parameter info beyond schema, so baseline 3 is appropriate.
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 the verb 'Return', the resource 'canonical list of valid KKTC city slugs plus districts', and the scope 'active Evlek listings'. It distinguishes from sibling tools by noting that they reject unrecognized city values, making it the go-to for spelling validation.
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?
Explicitly advises to 'Call this first when unsure about exact city/district spelling' and lists sibling tools that reject unrecognized values, providing clear when-to-use and contextual alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a Northern Cyprus property price across GBP/EUR/USD/TRY using live, date-stamped exchange rates (base GBP), and surface off-plan staged-payment risk warnings. General information only — confirm escrow, milestones and title transfer with an independent KKTC lawyer.
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | Property price. | |
| offPlan | No | True if off-plan (under construction). | |
| currency | No | Currency of the price (default GBP). |
| Name | Required | Description |
|---|---|---|
| fx | No | |
| amounts | No | |
| offPlan | No | |
| priceGBP | No | |
| warnings | No | |
| inputCurrency | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it specifies 'live, date-stamped exchange rates (base GBP)' and mentions surfacing off-plan risk warnings. The annotations (readOnlyHint, openWorldHint, destructiveHint) are consistent and the description enhances transparency about the tool's mechanics.
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 sentences: the first states the core action, the second provides essential legal context. It is front-loaded with actionable information and contains no wasteful words.
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?
The description fully explains the tool's output (currency conversion results and off-plan risk warnings), and the presence of an output schema covers return values. For a moderately complex tool with parameters and annotations, the description is complete and leaves no ambiguity.
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 100% schema description coverage, the description still adds value by explaining the role of parameters: price is the property price in the given currency, offPlan triggers risk warnings, and currency defaults to GBP. This clearly ties parameters to the tool's conversion and warning functionality.
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 explicitly states the tool converts a Northern Cyprus property price across four currencies using live exchange rates and surfaces off-plan payment risk warnings, which is a specific verb+resource combination. This clearly distinguishes it from sibling tools like get_price_index or get_yield_estimate.
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 provides clear usage context (currency conversion and off-plan risk warnings) and a strong disclaimer ('general information only — confirm with a lawyer'). However, it does not explicitly name alternative tools or state when not to use this tool, slightly reducing its guidance value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live Northern Cyprus (KKTC/TRNC) property listings on Evlek with a free-text query (city, sale/rent, bedrooms). Returns matching listings as id/title/url for the fetch tool. Read-only; no contact details. Same underlying data as search_listings — this fixed single-query-string form exists for the ChatGPT/OpenAI connector contract; prefer search_listings directly for structured filters (price range, exact bedroom count).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text property search query |
| Name | Required | Description |
|---|---|---|
| results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint. Description adds that it returns listings as id/title/url for the fetch tool and no contact details, beyond what annotations provide.
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?
Description is a single paragraph with clear sentences, each serving a purpose. It could be slightly shorter but remains focused and informative.
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 that output schema exists and annotations provide safety info, the description covers purpose, usage, and return format adequately for a tool with one parameter.
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 has 100% coverage with one parameter described as free-text. Description adds examples of what to include in query (city, sale/rent, bedrooms), enhancing meaning beyond 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?
Description clearly states the tool searches live property listings with free-text query. It distinguishes itself from sibling search_listings by noting this is a fixed single-query-string form for a specific connector contract.
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?
Explicitly says when to use this tool (ChatGPT/OpenAI connector) and when to prefer search_listings for structured filters. Also notes read-only nature and no contact details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live property listings on Evlek. Filter by city, type (sale/rent/daily), bedrooms, and price range. Returns up to 10 matching properties with title, price, location, and direct link.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City to filter | |
| type | No | Listing type | |
| limit | No | Result count (integer 1-10, default 5) | |
| bedrooms | No | Bedroom count (integer 0-10) | |
| maxPrice | No | Max price in GBP | |
| minPrice | No | Min price in GBP |
| Name | Required | Description |
|---|---|---|
| count | No | |
| listings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by specifying return fields (title, price, location, link) and result limit. No contradictions.
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, front-loaded with action and key details. No unnecessary words. Efficient and clear.
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?
Covers essential aspects: filtering, limit, return format. With an output schema (not shown) and annotations, this is adequate. Missing details like sorting or empty results, but not critical.
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% with detailed descriptions for each parameter. Description summarizes filters but adds no new meaning beyond the schema. Baseline score of 3 is appropriate.
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?
Clearly states it searches live property listings on Evlek with specific filters (city, type, bedrooms, price range) and returns matching properties. Distinguishes from sibling tools like get_district_profile or get_market_overview.
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?
Provides context of when to use (search listings with filters) but lacks explicit guidance on when to prefer sibling tools like compare_properties or get_price_index. Implied usage, but no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a Northern Cyprus university (resolved from the live Evlek roster), estimate student-rental monthly rent and academic-year (9-month) vs year-round (12-month) gross income/yield, with the city yield band and a link to nearby listings. Estimates only — not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| bedrooms | No | Bedroom count (0=studio). | |
| university | Yes | University name, short code, or known alias, matched against the canonical Evlek university catalog. | |
| purchasePrice | No | Optional purchase price in GBP (enables yield). |
| Name | Required | Description |
|---|---|---|
| city | No | |
| cityBand | No | |
| dataSource | No | modelled — not derived from live rental listings |
| university | No | |
| monthlyRentGBP | No | |
| academicYieldPct | No | |
| academicAnnualGBP | No | |
| yearRoundYieldPct | No | |
| yearRoundAnnualGBP | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that outputs are estimates only and not financial advice, covering additional behavioral context beyond structured fields.
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, front-loaded with core action, no redundant words. Every sentence contributes meaning.
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 the presence of an output schema (not shown but indicated), the description covers key outputs (rent, yield, band, link) and is complete for the tool's complexity.
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%, baseline 3. The description adds value by noting the university is resolved from the Evlek roster, enhancing understanding of that parameter.
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 the tool estimates student-rental monthly rent and income/yield for a Northern Cyprus university, distinguishing it from siblings like 'get_yield_estimate' which may be more general.
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 implies usage when estimating student-housing near a university but lacks explicit guidance on when to use this tool over siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a buyer persona (retiree, investor, student, family, digital_nomad, vacation) and optional budget/preferences, return 2-3 best-matched neighborhoods with rationale. Based on Evlek expert knowledge of KKTC regional characteristics.
| Name | Required | Description | Default |
|---|---|---|---|
| persona | Yes | ||
| budgetGBP | No | ||
| preferences | No |
| Name | Required | Description |
|---|---|---|
| persona | No | |
| budgetGBP | No | |
| preferences | No | |
| suggestions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, destructiveHint false) are consistent and describe safety. The description adds context about expert knowledge (Evlek) but does not detail edge cases like no matches found or behavior with invalid personas. Overall adds value beyond 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: first covers purpose, input, and output; second adds credibility. No wasted words, front-loaded with key info.
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 the presence of an output schema (not shown but signaled) and sibling tools covering related topics, the description adequately covers what the tool does. It specifies input, output count, and basis (expert knowledge). Could mention handling of missing matches but sufficient.
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 0%, but the description enumerates the possible personas and notes that budget and preferences are optional. It adds meaning beyond the schema by explaining how parameters are used together to generate recommendations.
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 the verb (suggest), the resource (neighborhoods), the input (buyer persona with optional budget/preferences), and output (2-3 best-matched neighborhoods with rationale). It distinguishes itself from siblings by focusing on persona-based recommendation.
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 implies usage for matching neighborhoods to buyer personas but does not explicitly state when to use this tool versus siblings like 'get_district_profile' or 'search'. No when-not-to-use or alternative guidance.
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.
v1.6.0assess_title_riskcompare_citiescompare_propertiesfetchforeign_buyer_roadmapget_district_profileget_legal_infoget_listing_by_numberget_listing_detailget_market_overviewget_price_indexget_yield_estimatelist_locationspayment_plansearchsearch_listingsstudent_housingsuggest_neighborhoodThere are clear duplicate tools: 'search' vs 'search_listings' and 'fetch' vs 'get_listing_detail' with nearly identical purposes. Descriptions warn to prefer one over the other, which adds confusion. Also, several market analysis tools overlap partially, making it hard for an agent to pick the right one.
Most tools follow a verb_noun pattern (e.g., get_district_profile, search_listings). However, 'student_housing' and 'payment_plan' are noun phrases, and 'foreign_buyer_roadmap' is also noun-heavy, breaking the pattern slightly. Overall, the convention is mostly consistent.
18 tools is well-scoped for a property domain covering search, detail, comparisons, market analysis, legal info, and specialized calculators. Each tool has a clear role despite some overlap, and the count is neither too few nor too many.
The toolset covers core workflows: listing search and retrieval, comparisons, market overviews, legal guidance, and specialized estimates (yield, student housing, payment plans). Minor gaps exist (e.g., no amenity-based filtering), but the surface is largely complete for a read-only property data server.
AI-native real estate discovery with structured property search and market intelligence.
Property Records MCP — address-level US property records (sales history,
Real estate MCP server for Morocco — search, valuation, market analysis, 17 tools.
GDPR-clean property listings, rents, price stats, yields and below-market deals. UK, EU.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Evlek/evlek-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server