AI-native property MCP for Northern Cyprus (KKTC/TRNC): listings, prices, districts, yields.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 15 of 15 tools scored.
Several tools overlap: fetch, get_listing_detail, and get_listing_by_number all return full listing details; get_market_overview, get_price_index, and compare_cities all provide city-level price aggregates. The 'Don't use for' guidance helps distinguish them, but the boundaries require careful reading.
Most tools follow a verb_noun pattern (get_*, search_*, compare_*, list_*), but payment_plan and student_housing are noun-only names, and fetch is a bare verb. The pattern is readable but not fully consistent.
15 tools is at the upper boundary of a well-scoped set for a property analytics server. The count is justified by the broad domain, though fetch and search are connector-specific duplicates that slightly inflate the number.
The server covers the full pipeline from listing search and detail retrieval to market stats, district profiles, neighborhood suggestions, yield estimates, and payment planning. Minor gaps like direct agent contact or saved-listings management exist, but they are outside the stated read-only analytics scope.
compare_citiesCompare Northern Cyprus Cities Side-by-SideACompare 2-4 Northern Cyprus cities side-by-side with aggregated prices (avg, median, min, max), listing counts, and top districts. Use when: comparing 2-4 named cities. Don't use for: a single city — use get_price_index.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Sale or rent (default: sale) | |
| cities | Yes | Cities to compare (2-4) |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| cities | Yes | |
| 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 adds value by disclosing the aggregation outputs (avg, median, min, max, listing counts, top districts). It doesn't mention any limitations or data caveats, but given the strong annotation coverage, this is adequate.
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 the core function and outputs, followed by concise usage guidelines. Zero 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?
The tool is simple with 2 params, an output schema exists, and annotations cover safety. The description provides purpose, usage boundaries, and alternative routing. Nothing essential is missing.
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% (both 'type' and 'cities' have clear descriptions, including enums and default). The description repeats the 2-4 range but adds no new parameter semantics. 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 tool compares 2-4 Northern Cyprus cities side-by-side, with specific outputs (avg, median, min, max prices, listing counts, top districts). This distinguishes it from siblings like get_price_index, which is explicitly mentioned as the single-city alternative.
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 explicit when-to-use instructions ('Use when: comparing 2-4 named cities') and when-not-to-use ('Don't use for: a single city — use get_price_index'). This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_propertiesCompare Evlek Property Listings Side-by-SideACompare 2-4 active Evlek property listings side-by-side. Returns price, area, bedrooms, price-per-m², location for each, plus an automatic value insight. Pass UUIDs from search_listings results. Use when: comparing specific known listings. Don't use for: finding candidates — use search_listings first.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_ids | Yes | Evlek listing UUIDs (2-4) |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| missing | No | |
| listings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the safety profile. The description adds valuable behavioral context beyond this: it returns specific fields (price, area, bedrooms, price-per-m², location) plus an automatic value insight, and restricts to 'active listings'. This enriches the agent's understanding without contradicting annotations, though it doesn't cover error handling or edge cases.
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 concise, consisting of three sentences that each serve a distinct purpose: stating the action and scope, listing the returned fields, and providing usage guidance. There is no redundant information, and the most important information is front-loaded.
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 (1 parameter, no nested objects, output schema present, annotations covering safety), the description is complete. It covers the core action, return fields, input source, constraints (2-4 active listings), and usage guidelines. The only potential omission is error handling, but that is not expected at this level of tool description.
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 100% coverage with listing_ids documented as 'Evlek listing UUIDs (2-4)'. The description adds critical semantic context: the UUIDs should come from search_listings results, and the comparison operates on active listings. This helps the agent source and validate inputs beyond what the schema alone provides, justifying a score above the baseline of 3.
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 a specific verb 'Compare' and resource 'Evlek property listings' with a clear scope of '2-4 active listings side-by-side'. It explicitly distinguishes itself from sibling tools like search_listings by stating to pass UUIDs from search_listings results and not to use it for finding candidates. This is a model example of purpose clarity.
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 'Use when: comparing specific known listings' and 'Don't use for: finding candidates — use search_listings first', providing clear when-to-use and when-not-to-use guidance. It also names the alternative tool (search_listings) and implies the prerequisite of having UUIDs from search_listings results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchFetch full Evlek listing detailAFetch the full detail of one Evlek listing by id (from search): title, description, GBP-normalized price, location, size, amenities. Same data as get_listing_detail — this fixed id-only form exists for the ChatGPT/OpenAI connector contract. Use when: an id from search is known. Don't use for: discovery — use search first.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Evlek listing id (UUID) from search |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| photos | No | |
| metadata | No | |
| coverImageUrl | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with that. Beyond annotations, it adds meaningful context: the data is identical to get_listing_detail and this fixed id-only form exists for the ChatGPT/OpenAI connector contract. This helps the agent understand why this tool exists and what to expect behaviorally.
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, each earning its place: the first states the purpose, the second explains the relationship to get_listing_detail and the connector contract, and the third provides explicit usage guidance. No filler or 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?
For a single-parameter read-only tool with an output schema present, the description covers purpose, usage boundaries, relationship to a sibling, and the reason for its existence. There are no significant gaps, and the combination of annotations, schema, and descriptions is sufficient for the agent to select and invoke it 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 coverage is 100%—the only parameter 'id' is already described as 'Evlek listing id (UUID) from search.' The description repeats 'by id (from search)' but adds no extra syntax, format, or constraints beyond the schema, so the baseline of 3 applies.
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 starts with 'Fetch the full detail of one Evlek listing by id'—a specific verb and resource—and enumerates the included fields. It also distinguishes itself from the sibling get_listing_detail by explaining this is a fixed id-only form, so it is immediately clear how it differs.
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 when: an id from search is known' and 'Don't use for: discovery — use search first.' It also names the sibling get_listing_detail as providing the same data, effectively guiding the agent toward the correct alternative when applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_district_profileGet 360° Profile for a Northern Cyprus DistrictAReturns a comprehensive profile for a single district: active listing counts (sale & rent), average/median prices, £/m², bedroom breakdown, estimated gross yield, and matching buyer personas. Use when: after compare_cities narrows the city. Don't use for: comparing multiple cities at once.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| district | Yes | District name (2-60 chars) |
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| rent | No | |
| sale | No | |
| district | Yes | |
| personas | No | |
| totalActive | Yes | |
| grossYieldPct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only/non-destructive behavior. The description adds valuable detail about the profile contents (yield, bedroom breakdown, personas) and the single-district scope. No contradiction, but it doesn't disclose caveats like data freshness or calculation methodology.
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 sentence lists output contents, second gives usage rules. No filler, well front-loaded, every sentence earns its place.
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 profile tool with an output schema and clear annotations, the description fully covers purpose, scope, and usage. Given the sibling list, the agent can easily distinguish this from compare_cities and other listing tools.
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 covers 50% of parameters with descriptions (district), and city has an enum. The description reinforces that city/district are needed and the flow ('after compare_cities narrows the city'), but could more explicitly map to parameters. It adds context but doesn't fully compensate for the missing city 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?
The description states a specific verb 'Returns' and a clear resource: a comprehensive profile for a single district. It lists concrete data points (listing counts, prices, yield, personas) and explicitly contrasts with comparing multiple cities, distinguishing it from siblings like 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 explicitly says 'Use when: after compare_cities narrows the city' and 'Don't use for: comparing multiple cities at once', naming the alternative tool and providing clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_listing_by_numberGet Evlek Listing by NumberALook up a single Evlek listing by its public listing number (e.g. "EVL-123456", "123456", or a bare number) and return its full detail — same shape as get_listing_detail. Use when: a listing number is known. Don't use for: UUID lookups — use get_listing_detail.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_number | Yes | Evlek listing number, e.g. "EVL-123456", "123456", or the bare number 123456. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| city | No | |
| type | No | |
| found | Yes | |
| price | No | |
| title | No | |
| photos | No | |
| areaSqm | No | |
| fxRates | No | |
| bedrooms | No | |
| currency | No | |
| district | No | |
| features | No | |
| listedAt | No | |
| priceGbp | No | |
| amenities | No | |
| bathrooms | No | |
| furnished | No | |
| photoCount | No | |
| dataQuality | No | |
| photosShown | No | |
| coverImageUrl | No | |
| listingNumber | No | |
| pricePerSqmGBP | No | |
| virtualStaging | No | |
| photosTruncated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive. The description adds behavioral context: accepts multiple formats of listing numbers and returns the same shape as get_listing_detail, which goes 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 concise sentences that front-load purpose and immediately provide usage guidance. No waste.
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 tool (one parameter, output schema present, strong annotations), the description fully covers purpose, usage, parameter variants, and the alternative path.
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 detailed parameter description. The description reinforces the format examples but does not add substantial new 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 the tool looks up a single Evlek listing by public listing number and returns full detail. It explicitly distinguishes from get_listing_detail which is for UUID 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?
Provides explicit use case ('when a listing number is known') and exclusion ('Don't use for: UUID lookups') with an alternative named (get_listing_detail).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_listing_detailGet Full Detail for a Single Evlek ListingAReturn a 360° profile of one active Evlek listing by UUID: title, description, price, location, size, amenities, features, cover image, per-photo captions/tags, and AI virtual-staging before/after pairs (always AI-disclosed). Contact details omitted. Use when: a UUID is already known. Don't use for: discovery — use search_listings first.
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes | Evlek listing UUID |
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| city | No | |
| type | No | |
| found | Yes | |
| price | No | |
| title | No | |
| photos | No | |
| areaSqm | No | |
| fxRates | No | |
| bedrooms | No | |
| currency | No | |
| district | No | |
| features | No | |
| listedAt | No | |
| priceGbp | No | |
| amenities | No | |
| bathrooms | No | |
| furnished | No | |
| photoCount | No | |
| dataQuality | No | |
| photosShown | No | |
| coverImageUrl | No | |
| listingNumber | No | |
| pricePerSqmGBP | No | |
| virtualStaging | No | |
| photosTruncated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive. The description adds valuable behavioral context: only 'active' listings are returned, contact details are omitted, and AI virtual-staging pairs are 'always AI-disclosed'. This goes beyond the structured metadata without contradicting it.
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 the purpose and a compact field list, followed by crisp usage directives. Every sentence earns its place; no filler or 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?
With only one parameter, full schema coverage, an output schema present, and annotations covering safety, the description provides sufficient context: purpose, contents, exclusions, and alternative tool guidance. It is complete for a lookup tool.
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 already provides 100% coverage with property_id described as 'Evlek listing UUID'. The description reiterates the UUID usage but adds no new syntax, constraints, or format details. Baseline 3 is appropriate since the schema carries the full burden for this single 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 states a specific verb+resource: 'Return a 360° profile of one active Evlek listing by UUID' and lists the exact contents (title, price, amenities, AI staging pairs). It also explicitly differentiates from siblings by noting it's for lookup, not discovery, contrasting with search_listings.
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 explicit when-to-use ('Use when: a UUID is already known') and when-not-to-use ('Don't use for: discovery — use search_listings first'). Also mentions the omitted contact details, which informs expectations about result completeness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_overviewGet Northern Cyprus Market OverviewAReturns a live, high-level market overview for Northern Cyprus property: active listing counts and average/median sale & rent prices per city (same live data as get_price_index/compare_cities), estimated gross rental yield where sample size allows, and investment-tool routing. Use when: a cross-city snapshot before drilling into one city. Don't use for: buyer cost / tax-rate answers — route to /vergi-hesaplayici.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| cities | Yes | |
| generatedAt | Yes | |
| totalActiveListings | Yes | |
| investmentHighlights | 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 valuable behavioral context beyond that: it notes the data is 'live', that rental yield is 'estimated' and only available 'where sample size allows', and that the tool performs 'investment-tool routing'. These nuances help set expectations without contradicting the read-only hint.
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 tightly written in two sentences: the first delivers the core function and data elements, the second delivers usage boundaries. No filler or redundancy; all information is front-loaded and easy to scan.
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 zero parameters and an output schema present, the description provides sufficient context: it lists what the overview includes (counts, prices, yields, routing), gives usage guidance, and references sibling tools for data consistency. It is complete for a read-only overview tool and does not need to explain return values given the output schema.
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 tool has zero parameters, so schema coverage is effectively 100%. The description does not need to explain parameters, and none are mentioned. A baseline of 4 is appropriate for a no-arg tool; the description doesn't need to compensate for missing schema details.
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 a specific verb ('Returns') and a specific resource ('live, high-level market overview for Northern Cyprus property'), enumerating concrete components: active listing counts, average/median prices, rental yields, and investment-tool routing. It also distinguishes from sibling tools by explicitly referencing get_price_index/compare_cities and framing itself as a cross-city snapshot.
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 explicit 'Use when' and 'Don't use for' clauses, including a direct routing to /vergi-hesaplayici for tax-related queries. This gives an agent clear decision criteria for selecting this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_price_indexGet Northern Cyprus Price IndexAReturns the live Evlek Price Index: aggregated average, median, min, max prices per city and top districts. Based on all active listings on evlek.app. Use when: aggregated market stats for one/all cities. Don't use for: a single listing's price — use get_listing_detail.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| type | No | Sale or rent (default: sale) |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| cities | Yes | |
| generatedAt | No | |
| totalListings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, so the description does not need to restate safety. It adds behavioral context by noting the data is 'live' and 'based on all active listings on evlek.app', which indicates the data source and freshness. No contradictions with 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 three sentences, with the main action in the first sentence and usage conditions in the next. It is front-loaded and contains 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?
With a rich output schema and annotations covering safety, the description adds necessary context about the data source, live nature, and proper use cases. It even names the sibling tool for exclusion, making it highly complete for such a simple tool.
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 documents the 'type' parameter with a default, and both parameters have enums. The description clarifies that 'city' can be used for 'one/all cities', which implies it is optional and that omission returns all cities. However, it doesn't enumerate the cities or provide format details, so value added is moderate.
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 specific metrics (average, median, min, max) aggregated by city and district. It also explicitly differentiates from get_listing_detail, stating when not to use it.
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 explicit use cases: 'Use when: aggregated market stats for one/all cities' and 'Don't use for: a single listing's price — use get_listing_detail.' This directly names the alternative tool and excludes the misuse case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_yield_estimateEstimate Rental Yield for a Northern Cyprus PropertyACalculate estimated gross and net annual rental yield for a property given its purchase price and city. Returns breakeven years and comparison to city averages. Use when: modelling one hypothetical purchase. Don't use for: a real listing's live comps — use get_district_profile.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| bedrooms | No | Bedroom count (integer 0-10) | |
| purchasePrice | Yes | Purchase price in GBP |
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| dataSource | Yes | modelled — not derived from live rental listings |
| netYieldPct | No | |
| netAnnualGBP | No | |
| cityBenchmark | No | |
| grossYieldPct | Yes | |
| breakevenYears | No | |
| grossAnnualGBP | No | |
| monthlyRentGBP | Yes | |
| purchasePriceGBP | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavior context by stating it 'Returns breakeven years and comparison to city averages' and positions the tool as an estimator. No contradiction with 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 action, and integrates usage guidance efficiently. Every sentence serves a purpose with no 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 the output schema exists, the description adequately covers return values, use cases, and exclusions. It is complete for a read-only estimation tool, with annotations covering safety aspects.
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 67%, with purchasePrice and bedrooms already documented. The description reinforces the significance of 'purchase price and city' but adds little beyond the schema. It does not elaborate on the optional bedrooms parameter, though the schema covers it adequately.
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's function: 'Calculate estimated gross and net annual rental yield for a property given its purchase price and city.' It uses specific verbs and resources, and distinguishes itself from siblings by explicitly referencing get_district_profile as the alternative for real listings.
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 explicit usage guidance: 'Use when: modelling one hypothetical purchase' and 'Don't use for: a real listing's live comps — use get_district_profile.' This clearly specifies when to use the tool and when not to, with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_locationsList Valid Evlek Cities and DistrictsAReturn the canonical list of valid KKTC city slugs plus the districts that currently have active Evlek listings. Use when: unsure about exact city/district spelling — call this FIRST. Don't use for: listing data itself — see search_listings.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional — limit districts to a single city slug. |
| Name | Required | Description |
|---|---|---|
| cities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful context: the list is 'canonical' and based on 'currently active Evlek listings', implying it is a dynamic reference list. It also frames it as a first-step prerequisite. This goes beyond what annotations provide, though it doesn't delve into openWorldHint or output formatting.
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 compact and front-loaded with the verb 'Return'. It packs purpose, usage, and exclusion into two sentences with no wasted words. Every part serves a distinct function.
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 reference tool with one optional parameter and an output schema present, the description fully covers what the tool does, when to use it, and when not to. It also conveys the dynamic nature of the data. With annotations clarifying safety and an output schema handling return structure, nothing essential is missing.
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% (the only parameter is fully described in the schema). The description does not add parameter-specific details, but the schema already explains the optional city parameter and its enum. Per the rubric, high schema coverage warrants a baseline of 3.
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 canonical list of valid KKTC city slugs and active districts, using the specific verb 'Return'. It also distinguishes itself from siblings by explicitly saying not to use it for listing data and pointing to search_listings, so it avoids confusion with similar tools.
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 explicit when-to-use guidance ('Use when: unsure about exact city/district spelling — call this FIRST.') and when-not-to-use guidance with a named alternative ('Don't use for: listing data itself — see search_listings.'). This is model usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payment_planKKTC Property Payment & Currency BreakdownAConvert a Northern Cyprus property price across GBP/EUR/USD/TRY using live exchange rates, and surface off-plan staged-payment risk warnings. General information only — confirm with an independent KKTC lawyer. Use when: currency conversion + off-plan risk. Don't use for: live listing prices.
| 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 | Yes | |
| offPlan | No | |
| priceGBP | Yes | |
| warnings | No | |
| inputCurrency | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds meaningful context: live exchange rates, off-plan risk warnings, and a disclaimer about general information. This goes beyond the annotations without contradicting them.
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 front-loaded with the primary action, uses a clear structure with usage boundaries, and every sentence earns its place. No redundant information or fluff.
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, return values need no explanation. The description covers scope, disclaimers, and usage boundaries, making it complete for a tool of this complexity. It effectively differentiates from 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?
Schema description coverage is 100%, so baseline is 3. The description adds extra semantics by linking 'off-plan staged-payment risk' to the offPlan parameter and 'live exchange rates' to the currency/price parameters, clarifying their role beyond the schema's basic descriptions.
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 a specific verb ('Convert') with a resource ('Northern Cyprus property price') and explicit scope ('across GBP/EUR/USD/TRY', 'off-plan staged-payment risk warnings'). It distinguishes this tool from siblings like get_listing_by_number or compare_properties by focusing on currency conversion and risk warnings.
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 provides 'Use when: currency conversion + off-plan risk' and 'Don't use for: live listing prices', giving clear when-to-use and when-not-to-use guidance. It also warns that it's general information only, directing users to confirm with a lawyer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch Evlek property listingsASearch live Northern Cyprus (KKTC/TRNC) property listings on Evlek with a free-text query. Returns matching listings as id/title/url for the fetch tool. Same data as search_listings — this fixed form exists for the ChatGPT/OpenAI connector contract. Use when: the caller only has a free-text query. Don't use for: structured filters — use search_listings.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text property search query |
| Name | Required | Description |
|---|---|---|
| fxRates | No | |
| results | Yes | |
| listings | No | |
| outOfScope | No | |
| unresolved | No | |
| appliedFilters | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by explaining the return format ('id/title/url for the fetch tool') and the purpose of this fixed form (connector contract), providing context beyond the annotations. It does not cover all possible behaviors but is adequate for a simple search tool.
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 four sentences, each serving a purpose: what it does, return format, relationship to sibling, and when to use. It is front-loaded with the core function and avoids unnecessary fluff. Every sentence earns its place.
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 tool with a clear output schema and helpful annotations, the description is complete. It explains the free-text nature, return structure, relationship to the alternative tool, and the contract context. No critical information is missing for correct invocation.
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 the query parameter described as 'Free-text property search query.' The description reinforces the semantic by emphasizing 'free-text query' and contrasting it with 'structured filters,' which adds clarity about the intended input style beyond the schema's terse 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?
The description clearly states the tool's function: 'Search live Northern Cyprus (KKTC/TRNC) property listings on Evlek with a free-text query.' It specifies the verb (search), resource (property listings), and geographic scope. It also distinguishes from the sibling tool search_listings by noting it is a fixed form for the ChatGPT/OpenAI 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?
The description provides explicit usage guidance: 'Use when: the caller only has a free-text query. Don't use for: structured filters — use search_listings.' This clearly states when to use this tool, when not to use it, and names the alternative (search_listings), making it easy for an agent to select correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_listingsSearch Northern Cyprus Property ListingsASearch live property listings on Evlek. Filter by city, type, property type, bedrooms, price range; sort with sortBy (default: newest, NOT best-match). limit caps returned rows (max 10); totalMatched is the full match count, which may be larger. Price outliers and data-entry-error sale prices are excluded before sorting. Use when: structured filters (price, bedrooms, type). Don't use for: free-text queries — use search.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City to filter | |
| type | No | Listing type | |
| limit | No | Result count (integer 1-10, default 5) | |
| sortBy | No | Sort order (default: newest) | |
| bedrooms | No | Bedroom count (integer 0-10) | |
| maxPrice | No | Max price in GBP | |
| minPrice | No | Min price in GBP | |
| propertyType | No | Property type filter |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| fxRates | No | |
| listings | Yes | |
| sortApplied | Yes | |
| totalMatched | Yes | |
| appliedFilters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly and openWorld hints; description adds key behavioral details: sortBy defaults to newest (not best-match), limit caps rows at 10, totalMatched may be larger, and price outliers/errors are pre-filtered. This goes beyond structured 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?
Four sentences pack purpose, behavior, and usage direction without redundancy. Front-loaded with main action.
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 an 8-parameter read-only search tool with output schema and annotations, the description covers when to use, sorting behavior, result limits, and data filtering. No obvious 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 covers all parameters with descriptions (100%), so baseline 3. The description adds behavioral context for sortBy (default and NOT best-match) and limit (max 10, totalMatched larger), enriching parameter understanding.
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, enumerates filter dimensions, and explicitly distinguishes from sibling `search` tool by saying free-text queries should use `search`. This is specific and differentiates.
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 provides 'Use when: structured filters' and 'Don't use for: free-text queries — use `search`', giving clear when/when-not guidance and naming the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
student_housingStudent-Housing Rental Outlook near a KKTC UniversityAGiven a Northern Cyprus university, estimate student-rental monthly rent and academic-year vs year-round gross income/yield, with the city yield band and a link to nearby listings. Estimates only. Use when: modelling one university's rental economics. Don't use for: live listing search.
| 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 | Yes | |
| cityBand | No | |
| dataSource | Yes | modelled — not derived from live rental listings |
| university | Yes | |
| monthlyRentGBP | Yes | |
| 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, so the agent knows it's a safe read operation. The description adds meaningful behavioral context: it states "Estimates only" (clarifying the tool does not return live data) and describes the dual calculation modes (academic-year vs year-round) and the inclusion of a city yield band and listing link. These traits go beyond the annotations, although it doesn't detail data limitations such as data freshness or error bounds.
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 concise and front-loaded: it opens with the primary action and key outputs, adds a critical qualifier ("Estimates only"), then provides explicit usage guidance. Every sentence earns its place, and the whole text is only three sentences with no filler or 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?
The tool has moderate complexity (three parameters, one required, and an output schema) and the description covers purpose, outputs, and usage constraints. Since an output schema exists, the description need not explain return values. The description could mention currency or data source briefly, but the schema covers asset type and the "Estimates only" caveat provides necessary context. Overall, it's sufficiently complete for an agent to invoke it 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% (all three parameters have descriptions, including units and defaults), so the baseline is 3. The description does not add any additional parameter meaning beyond what the schema already provides—it focuses on outputs instead. No further parameter clarification is necessary, but also not contributed.
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 a specific verb "estimate" and clearly specifies the resource: student-rental monthly rent and academic-year vs year-round gross income/yield for a Northern Cyprus university. It also mentions the city yield band and a link to nearby listings, which distinguishes it from sibling tools like get_yield_estimate or search_listings. The scope is well-defined, making it unambiguous what the tool does.
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 explicit usage guidance: "Use when: modelling one university's rental economics" and "Don't use for: live listing search." This clearly tells the agent when to invoke this tool and when to avoid it, effectively differentiating it from search-related siblings. It offers a exclusion without naming alternatives, but the guidance is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_neighborhoodSuggest Best Northern Cyprus Neighborhoods for a Buyer PersonaAGiven a buyer persona (retiree, investor, student, family, digital_nomad, vacation) and optional budget/preferences, return 2-3 best-matched neighborhoods with rationale. Use when: matching a persona to areas. Don't use for: browsing actual listings — use search_listings.
| Name | Required | Description | Default |
|---|---|---|---|
| persona | Yes | ||
| budgetGBP | No | ||
| preferences | No |
| Name | Required | Description |
|---|---|---|
| persona | Yes | |
| budgetGBP | No | |
| preferences | No | |
| suggestions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior. The description adds useful context: returns a fixed number (2-3) of results and includes rationale. This goes beyond the safety profile provided 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, front-loaded with the core action, followed by crisp usage guidance. Every word earns its place; no 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?
For a tool with only 1 required parameter and an output schema present, the description covers purpose, inputs, and usage scope. It doesn't need to explain return format because the output schema exists.
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 0%, so the description must compensate. It does so by listing the persona enum values and indicating budget/preferences are optional. However, it doesn't elaborate on preference enum semantics, relying on the schema for those details.
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's function: given a buyer persona and optional criteria, return 2-3 best-matched neighborhoods with rationale. It distinguishes itself from siblings by explicitly contrasting with search_listings, which handles actual listings.
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 explicit when-to-use and when-not-to-use guidance: 'Use when: matching a persona to areas. Don't use for: browsing actual listings — use search_listings.' This directly addresses the primary alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.