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.4/5 across 14 of 14 tools scored.
Several tools have overlapping purposes: fetch and get_listing_detail both return full listing details (differing only by ID type), and search and search_listings both perform listing searches (differing by query style). The payment_plan tool is misleadingly named as it only converts currency, not plan payments.
Most tools follow a verb_noun pattern (compare_cities, get_listing_detail, search_listings), but exceptions like fetch, search, payment_plan, and student_housing break the pattern. The mix is readable but not fully consistent.
14 tools is within the typical well-scoped range, but the set includes redundant pairs (fetch/get_listing_detail and search/search_listings) that could be consolidated, making it feel slightly inflated for the actual functionality.
The server covers core discovery (search, get detail), aggregate pricing (index, district, city comparisons), and specialized calculations (yield, student housing). As a read-only property search server it is fairly complete, though it lacks explicit filter/list-by-type tools beyond search_listings.
compare_citiesCompare Northern Cyprus Cities Side-by-SideACompare source-dated live active-listing asking-price aggregates across 2-4 Northern Cyprus cities. Descriptive listing facts only; not transaction prices, valuation, forecast, ranking, or investment advice.
| 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 | |
| dataSource | No | |
| isEstimate | No | |
| metricType | No | |
| generatedAt | 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 meaningful context beyond these hints: 'source-dated live active-listing' clarifies data recency and source, while 'descriptive listing facts only' and the list of exclusions disclose what the output does not represent. 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?
Two concise sentences, front-loaded with the core purpose and followed by clear exclusions. Every word earns its place, with no fluff or repetition of schema 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?
The tool has an output schema (not shown) and comprehensive annotations. The description fully covers the tool's scope and limitations for a read-only comparison tool. It does not need to explain return values (output schema exists) and provides sufficient context for an agent to select it appropriately.
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 descriptions for both parameters ('type' with default and enum, 'cities' with 2-4 constraint and enum values). The description adds no parameter-specific detail beyond what the schema already provides, so the 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?
The description uses a specific verb ('compare') and resource ('Northern Cyprus cities') with a clear scope: 'asking-price aggregates across 2-4 cities.' It also explicitly states what it is not ('not transaction prices, valuation, forecast, ranking, or investment advice'), which 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 implies when to use the tool: when needing city-level asking-price aggregates. It also provides when-not guidance through exclusions ('not transaction prices, valuation, forecast, ranking, or investment advice'). However, it does not explicitly name alternatives or contrast with sibling tools like compare_properties, so it falls short of a 5.
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 descriptive facts from 2-4 active Evlek sale or long-term-rent listings of the same type. Shows advertised asking price, size and £/m² differences without making a value, suitability, appraisal, or investment judgment.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_ids | Yes | Evlek listing UUIDs (2-4) |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| missing | No | |
| listings | Yes | |
| dataSource | No | |
| isEstimate | No | |
| metricType | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds valuable context by explicitly stating it shows only descriptive facts (price, size, £/m²) and refrains from making judgments. This clarifies the tool's scope and limitations beyond the annotation hints, though it doesn't discuss failure modes or return format (covered by output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the primary purpose. Every sentence adds value: the first defines the action and constraints, the second details the specific outputs and explicitly excludes subjective analysis. There is no redundancy or unnecessary wording.
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, combined with the annotations and output schema, provides complete context. It covers what the tool compares, the constraints (2-4, same type, active), and explicitly states what it does not do. Since an output schema exists, the description doesn't need to explain return values. All critical usage aspects are addressed.
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 fully describes the only parameter, listing_ids, including its type, format, and count (2-4). The description does not add additional semantic meaning to the parameter itself; it only reiterates the count requirement. Since schema coverage is 100%, 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 clearly states the tool's function: comparing descriptive facts from 2-4 active Evlek listings. It specifies the resource (listings), the action (compare), the scope (same type, sale or long-term rent), and the specific outputs (price, size, £/m²). This distinguishes it from siblings like compare_cities 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 provides clear when-to-use context: comparing 2-4 listings of the same type. It also implies boundaries by stating it does not make value or investment judgments, which is a useful guideline. However, it does not explicitly mention alternatives for single listing details or city comparisons, so it lacks full exclusionary guidance.
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 Live Asking-Price Context for a Northern Cyprus DistrictAReturns source-dated active sale/long-term-rent listing counts and asking-price aggregates for one district. Any rent-to-price percentage is a derived asking-price ratio, not observed income, net yield, valuation, forecast, ranking, or recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | ||
| district | Yes | District name (2-60 chars) |
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| rent | No | |
| sale | No | |
| district | Yes | |
| dataSource | No | |
| metricType | No | |
| totalActive | Yes | |
| isObservedYield | No | |
| personaContexts | No | |
| yieldMetricType | No | |
| indicativeGrossRentToPricePct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and non-destructive behavior. The description adds valuable context by noting data is 'source-dated,' 'active,' and that rent-to-price is a 'derived asking-price ratio, not observed income, net yield, valuation, forecast, ranking, or recommendation.' This prevents misinterpretation 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?
The description is two sentences, front-loaded with the core function and followed by an essential caveat. Every word earns its place, with no redundancy or filler.
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 and annotations cover safety, the description sufficiently covers purpose, scope ('one district'), and important disclaimers. It could be slightly more explicit about sibling differentiation, but overall it is complete for a simple read-only tool with structured output.
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%, with district described as 'District name (2-60 chars)' and city as an enum. The description does not elaborate on parameter meaning beyond identifying 'one district,' but the city enum values are self-explanatory. It adds no additional semantics 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 'source-dated active sale/long-term-rent listing counts and asking-price aggregates for one district,' with a specific verb and resource. This distinguishes it from siblings like get_price_index or compare_cities by focusing on asking-price context at the district level.
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 a single district's aggregate asking-price data, but does not explicitly state when to use this versus alternatives such as compare_cities or get_yield_estimate. No exclusions or alternative guidance is provided, leaving usage to be inferred from the tool's purpose.
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 | |
| bedrooms | No | |
| currency | No | |
| district | No | |
| factType | No | |
| features | No | |
| listedAt | No | |
| priceGbp | No | |
| amenities | No | |
| bathrooms | No | |
| furnished | No | |
| dataSource | No | |
| isEstimate | No | |
| photoCount | 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 readOnly and non-destructive behavior; the description adds useful context about the return shape ('same shape as get_listing_detail') and accepted input variants. 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?
Two main sentences plus compact usage hints. Every sentence adds value, and the structure is front-loaded with the primary 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 a simple read-only tool with one parameter, an output schema, and strong annotations, this description is complete. It addresses purpose, alternatives, and return shape without redundancy.
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 100% of parameter documentation and includes examples. The description adds semantic distinction by specifying 'public listing number' (vs. UUID), which improves understanding beyond the schema's basic type 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 uses a specific verb and resource: 'Look up a single Evlek listing by its public listing number' and clarifies it returns full detail. It explicitly distinguishes from get_listing_detail, making the tool's scope unambiguous.
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 listing number is known') and when-not-to-use ('Don't use for: UUID lookups — use get_listing_detail'), naming the alternative tool. This is exemplary guidance.
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 | |
| bedrooms | No | |
| currency | No | |
| district | No | |
| factType | No | |
| features | No | |
| listedAt | No | |
| priceGbp | No | |
| amenities | No | |
| bathrooms | No | |
| furnished | No | |
| dataSource | No | |
| isEstimate | No | |
| photoCount | 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?
The description adds value beyond annotations by disclosing that AI virtual-staging is 'always AI-disclosed', that contact details are omitted, and that only active listings are returned. These are specific behavioral traits not covered by readOnlyHint/openWorldHint/destructiveHint. 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 concise and front-loaded, with two sentences: the first lists return contents efficiently, the second gives usage guidance. Every phrase adds value (e.g., 'always AI-disclosed', 'Contact details omitted'), with 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?
Despite having an output schema, the description enriches context by enumerating the returned fields and specifying omissions and constraints (active listing, AI disclosure, contact details omitted). For a single-parameter read tool, this provides sufficient context for an agent to invoke it correctly and anticipate results.
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% as the only parameter, property_id, is already described as 'Evlek listing UUID'. The description adds no further parameter meaning beyond repeating 'by UUID'. Baseline for high coverage is 3, and there is no extra semantic detail.
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' and the resource 'a 360° profile of one active Evlek listing by UUID', listing concrete fields. It distinguishes from discovery tools by noting 'Don't use for: discovery' and explicitly names search_listings as the alternative. The title also reinforces the tool's role for a single listing by UUID.
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 usage conditions: 'Use when: a UUID is already known' and 'Don't use for: discovery — use search_listings first.' This gives clear context for when to select this tool over the sibling search_listings and implies when not to use it. The UUID-specific nature also hints at differentiation from get_listing_by_number, though not named.
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 source-dated aggregates of live active Evlek sale or long-term-rent asking prices. Descriptive listing facts only: not completed transactions, a valuation, a forecast, or an investment recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| type | No | Sale or rent (default: sale) |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| cities | Yes | |
| dataSource | No | |
| isEstimate | No | |
| metricType | No | |
| generatedAt | No | |
| totalListings | No |
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 meaningful behavioral context: data is source-dated, reflects live active listings only, and is descriptive rather than analytical. This goes beyond the annotations by clarifying the nature and limitations of the returned data, which is valuable for correct interpretation.
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 followed by a concise exclusion list. Every word earns its place; there is no fluff or redundant information. Perfectly sized for an agent to quickly parse.
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 an output schema, so return-value details need not be in the description. The description covers the data source, aggregation type, property type, and explicit exclusions, which is comprehensive for a read-only aggregate tool. It doesn't detail the index computation method, but that is likely covered by the output schema or supplemental documentation. Given the simplicity and existing annotations, this is nearly 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?
Schema coverage is 50% (only 'type' has a description, 'city' does not). The description adds some semantic meaning by connecting 'sale or long-term-rent' to the type parameter and implying the aggregation scope, but it does not explain the city parameter or clarify default behavior when parameters are omitted. The enums are self-explanatory, but the description does not fully compensate for the schema gap.
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 resource ('source-dated aggregates of live active Evlek sale or long-term-rent asking prices'). It clearly distinguishes itself from individual listing tools by emphasizing it provides aggregate asking-price data, and it further differentiates itself from valuation/forecast tools by explicitly stating what it is NOT. This is more than sufficient to set it apart from the listed 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?
The description provides clear context on what data is included (live active asking prices) and explicitly excludes completed transactions, valuations, forecasts, and investment recommendations. While it does not name sibling tools like get_yield_estimate or search_listings as alternatives, the exclusions strongly imply when this tool should and shouldn't be used. Lacks explicit 'when to use' guidance but has effective 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_yield_estimateBuild an Illustrative Long-Term Rental ScenarioACalculate an illustrative long-term-rent scenario only from caller-supplied purchase price, monthly rent, occupied months, and annual operating costs. No Evlek market baseline or occupancy assumption is used; outputs are not observed income, forecasts, guarantees, or advice.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| monthlyRentGBP | Yes | User-supplied monthly long-term rent assumption in GBP | |
| occupiedMonths | Yes | User-supplied number of occupied and paid months in the 12-month scenario period | |
| purchasePriceGBP | Yes | User-supplied purchase price in GBP | |
| annualOperatingCostsGBP | Yes | User-supplied annual operating-cost assumption in GBP |
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| dataSource | Yes | |
| assumptions | No | |
| netYieldPct | No | |
| estimateType | No | |
| netAnnualGBP | No | |
| grossYieldPct | Yes | |
| breakevenYears | No | |
| grossAnnualGBP | No | |
| monthlyRentGBP | Yes | |
| occupiedMonths | No | |
| purchasePriceGBP | Yes | |
| usesLiveListingData | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds valuable disclosure that outputs are illustrative, not observed income, forecasts, guarantees, or advice. Also clarifies no external data is used, which goes beyond annotation hints.
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 function then limitations. No redundant information. Every sentence contributes to understanding the tool's scope and caveats.
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, combined with the output schema and annotations, provides a complete picture. It covers inputs, computation scope, exclusions, and important disclaimers. The presence of an output schema means return value documentation is handled externally.
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 80% of parameters with descriptions. The description mentions the four key inputs but does not add per-parameter semantics beyond what schema already provides. It also omits the optional city parameter. 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 calculates an illustrative long-term-rent scenario using specific caller-supplied inputs. It distinguishes itself from market-data tools by explicitly stating no market baseline or occupancy assumption is used.
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 when to use this tool: when the user has their own assumptions and wants an illustrative calculation. It explicitly excludes market baselines and occupancy assumptions, which signals not to use it for market-based estimates. However, it does not name alternative sibling tools explicitly, so it falls short of a 5.
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 canonical KKTC city slugs plus districts represented by active Evlek sale or long-term-rent listings. Live inventory-location facts only; holiday-home inventory remains unavailable.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional — limit districts to a single city slug. |
| Name | Required | Description |
|---|---|---|
| cities | Yes | |
| dataSource | No | |
| isEstimate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint), the description adds valuable context: data is derived from live Evlek sale and long-term-rent listings, and holiday-home inventory is explicitly excluded. This clarifies the tool's data coverage and currentness.
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 action verb 'Return', and each sentence earns its place: the first defines the output, the second adds a necessary data-scope qualifier. There is no redundant or extraneous text.
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 tool with zero required parameters, one optional parameter, strong annotations, and an output schema, the description covers the key facts: what is returned, the data source, and exclusions. It lacks explicit use-case guidance but is otherwise complete for its scope.
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 fully documents the only parameter 'city' with an enum and description. The tool description reiterates the concept of city slugs but does not add material semantics beyond the schema, so a 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?
The description clearly states the tool returns 'canonical KKTC city slugs plus districts' from active Evlek listings, using a specific verb and resource. This distinguishes it from sibling tools like get_district_profile or suggest_neighborhood by emphasizing its role as a source of valid slug data.
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 this tool is used to obtain canonical location slugs for querying other tools, but it does not explicitly state when to use it over alternatives or exclude inappropriate cases. No sibling tool is referenced, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
payment_planCurrency Conversion Only (legacy payment_plan name)AThe payment_plan identifier is retained only for compatibility. This tool converts an entered property asking-price amount across GBP/EUR/USD/TRY when complete, valid, fresh, date-stamped stored FX rates are available; otherwise it fails closed without amounts. It does not produce a payment plan, deposit schedule, installment schedule, acquisition-cost estimate, or advice.
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | Entered property asking-price amount; not a deposit or installment. | |
| currency | No | Currency of the price (default GBP). |
| Name | Required | Description |
|---|---|---|
| fx | No | |
| amounts | Yes | |
| priceGBP | Yes | |
| dataSource | No | |
| inputCurrency | Yes | |
| usesStoredRate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, the description adds critical behavioral details: it fails closed without amounts if rates are not complete/valid/fresh/date-stamped, and it explicitly disclaims generating any payment-plan-related outputs. This goes 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?
The description is three sentences: first disarms the legacy name, second states the core function and condition, third eliminates common misconceptions. Every sentence earns its place, and the main purpose 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 (two parameters, full schema descriptions, output schema present, and strong annotations), the description adequately covers what the tool does, under what conditions it works, and what it does not do. No critical selection-relevant information 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?
The input schema has 100% description coverage, including clear descriptions for both 'price' and 'currency.' The tool description restates the scope (asking-price amount, not deposit) but adds no new parameter-level information beyond the schema. The schema already carries the burden, so a baseline 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?
The description explicitly states that the tool converts an entered property asking-price amount across GBP/EUR/USD/TRY, with the title reinforcing 'Currency Conversion Only.' It also distinguishes itself by listing what it does not do (payment plan, deposit schedule, etc.), making its purpose unmistakable.
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 clearly presents the tool's use case (currency conversion of an asking price) and even clarifies that the legacy name is retained only for compatibility. However, it does not explicitly name alternative tools for related tasks or provide exclusion criteria, so it stops short of a full 5.
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 active sale and long-term-rent listings on Evlek. Results are newest-first by default; limit caps returned rows and totalMatched reports the full match count. Returns advertised asking-price and listing facts only; not valuation, verification of property-specific claims, forecast, ranking, or recommendation.
| 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 | |
| factType | No | |
| listings | Yes | |
| dataSource | No | |
| isEstimate | No | |
| sortApplied | Yes | |
| totalMatched | Yes | |
| appliedFilters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive. The description adds valuable context: results are newest-first by default, limit caps returned rows, totalMatched reports full count, and only advertised facts are returned. This goes beyond schema and annotations, providing clear behavioral expectations.
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 primary purpose, then efficiently adds key behavioral details and exclusions. Every clause earns its place with no repetition of schema 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 the 8-parameter schema, full annotation coverage, and presence of an output schema, the description is complete. It covers purpose, default behavior, pagination/limit semantics, and explicit limitations, giving an agent all necessary context to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description supplements this by explaining the effect of limit (caps rows) and introducing totalMatched as a result field, plus the default sort order. This adds meaningful semantics that the schema alone does not convey.
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 purpose: 'Search live active sale and long-term-rent listings on Evlek.' It specifies the resource (Evlek listings), scope (Northern Cyprus property), and action (search). This distinguishes it from sibling tools like get_listing_detail or compare_properties, which focus on details or comparisons.
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 primary use for searching listings and explicitly states what it does not return ('not valuation, verification of property-specific claims, forecast, ranking, or recommendation'), which guides users toward alternatives when needed. However, it does not explicitly name sibling tools or state 'when not to use' directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
student_housingIllustrative Student-Housing Rental ScenarioACalculate one illustrative student-rent scenario from caller-supplied monthly rent and occupied months. The university only supplies location context; no Evlek rent or occupancy baseline, observed demand/income, forecast, guarantee, or advice is used.
| Name | Required | Description | Default |
|---|---|---|---|
| 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). | |
| monthlyRentGBP | Yes | User-supplied monthly long-term rent assumption in GBP. | |
| occupiedMonths | Yes | User-supplied number of occupied and paid months in the 12-month scenario period. |
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| dataSource | Yes | |
| university | Yes | |
| assumptions | No | |
| estimateType | No | |
| monthlyRentGBP | Yes | |
| occupiedMonths | No | |
| grossRentToPricePct | No | |
| usesLiveListingData | No | |
| modelledGrossRentGBP | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, which the description does not contradict. It adds value by clarifying that the output is illustrative and that the tool does not use or imply any baseline data, forecast, or advice, setting expectations about the limited scope and nature of the calculation.
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, two sentences long, with the primary action and key inputs in the first sentence. It front-loads the core purpose and adds a clarifying limitation in the second, 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 tool's simplicity, the presence of an output schema, and annotations, the description sufficiently covers the essential context. It explains the illustrative nature and what inputs are used, while the schema and output schema handle parameter and return details. No critical information 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%, so the schema already documents all parameters. The description mentions 'caller-supplied monthly rent and occupied months' but adds no additional meaning beyond what the schema provides. It does not discuss the optional purchasePrice, leaving the schema to carry that information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Calculate one illustrative student-rent scenario from caller-supplied monthly rent and occupied months.' This clearly distinguishes it from sibling tools that retrieve listings or price indices, as it is a calculation tool with a specific, narrow purpose.
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 context: this tool is for an illustrative scenario, not a forecast, and explicitly states that no Evlek baseline, demand/income, guarantee, or advice is used. However, it does not explicitly name alternative tools for when a forecast or more detailed analysis is needed, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_neighborhoodCurated Neighborhood Context by PersonaAReturn static editorial orientation context for a persona and optional preferences. It contains no price or yield figures and is not live listing data, a ranking, suitability finding, valuation, or recommendation.
| Name | Required | Description | Default |
|---|---|---|---|
| persona | Yes | ||
| preferences | No |
| Name | Required | Description |
|---|---|---|
| persona | Yes | |
| dataSource | No | |
| preferences | No | |
| suggestions | Yes | |
| notRecommendation | 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 the content is 'static editorial orientation context,' indicating no live computation or dynamic data. This adds context 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 extremely concise, with two sentences that front-load the primary purpose and immediately follow with clarifying exclusions. No wasted words or 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 the presence of an output schema and read-only annotations, the description covers the essential aspects. However, it lacks a positive explanation of what the tool returns and how the context is useful, relying heavily on negative claims. This is adequate but not fully comprehensive for a tool with this level of 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 0%, and the description only mentions 'persona and optional preferences' without explaining the meaning or effect of each enum value. While the schema provides enums, the description does not add sufficient detail to clarify how preferences influence the orientation context, leaving the agent with limited semantic 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?
The description clearly states the tool's function: returning static editorial orientation context for a persona and optional preferences. It further distinguishes itself by explicitly listing what it does not contain (price/yield figures, live listings, rankings, etc.), which helps differentiate it from sibling tools like get_yield_estimate and 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?
The description provides clear exclusions (not live data, not a recommendation) that implicitly guide when not to use this tool, but it does not explicitly name alternative tools or provide positive use-case scenarios. The context is clear but lacks explicit when-to-use guidance.
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.