Evlek — Northern Cyprus Property MCP Server

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, which covers the safety profile. The description adds useful behavioral context about accepted listing-number formats ('EVL-123456', '123456', or bare number) and that the returned shape matches get_listing_detail. 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 compact, front-loads the core action, and uses the 'Use when / Don't use for' structure to pack routing guidance into a few words. Every sentence earns its place, and it remains highly scannable.

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 lookup tool with an output schema and clear annotations, this description is complete. It covers input formats, return shape, and the alternative for UUID lookups. No important contextual gap remains 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% and the property description already lists the same accepted formats. The tool description repeats those examples but adds no new parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate because the schema fully carries the parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (look up), the resource (a single Evlek listing by public listing number), and the result (full detail). It explicitly distinguishes this tool from get_listing_detail by noting the UUID lookup case, so an agent can tell them apart.

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 gives explicit guidance: 'Use when: a listing number is known. Don't use for: UUID lookups — use get_listing_detail.' This is a clear when/when-not statement with a named alternative, which is exactly what an agent needs.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, while the description adds extra behavioral context beyond that: it only returns active listings, omits contact details, and clarifies that AI virtual-staging pairs are always AI-disclosed. This meaningfully enriches the structured annotation data.

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 dense sentences front-load the core behavior and field list, then add exclusions and routing guidance. Every clause earns its place with no filler or repetition of schema content.

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 tool with an output schema, the description covers what is returned, what is explicitly omitted, when to use it, and which sibling to use instead. Combined with the annotations and existing schema, nothing needed for correct invocation 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 single parameter property_id is already fully documented in the schema as an 'Evlek listing UUID' (100% coverage). The description adds useful nuance by specifying that the UUID must refer to an active listing and is the lookup key, slightly extending the schema's bare definition.

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 names a specific verb ('Return') and a specific resource ('a 360° profile of one active Evlek listing by UUID'), and enumerates the fields returned. It clearly differentiates this lookup-from-UUID tool from discovery tools like 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?

Explicit 'Use when' and 'Don't use for' guidance is given, including naming the alternative discovery tool 'search_listings'. This leaves no ambiguity about when the tool is appropriate.

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

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.

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.

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.

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.

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.

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

Beyond the annotations (readOnlyHint=true, openWorldHint=true, destructiveHint=false), the description discloses that results are newest-first by default, that `limit` caps returned rows while `totalMatched` reports the full match count, and that output is limited to advertised listing facts. This adds meaningful behavioral detail about ordering, result sizing, and content boundaries that the annotations do not 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?

Three sentences, each earning its place: the first identifies the resource and scope, the second covers ordering and result-count semantics, and the third clarifies exclusions. The most important information is front-loaded and there is no 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?

The description covers the resource scope, default ordering, limit/totalMatched behavior, and what is excluded, while the output schema handles return values. Given the annotations covering safety and the rich input schema, nothing critical is missing for an agent to invoke this 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 description coverage is 100%, so the baseline is 3. The description adds value by explaining the relationship between `limit` and `totalMatched`: limit caps only the returned rows, while totalMatched exposes the full match count. This pagination semantics is not present in the schema, justifying a score above baseline.

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 the specific verb ('Search'), the resource ('live active sale and long-term-rent listings on Evlek'), and the scope of output ('advertised asking-price and listing facts only'). It explicitly excludes valuation, verification, forecast, ranking, and recommendation, which clearly distinguishes it from siblings like get_yield_estimate and get_price_index.

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 does not name sibling tools, but the clause 'not valuation, verification of property-specific claims, forecast, ranking, or recommendation' gives clear implicit guidance on when not to use this tool. It establishes context for selecting alternatives, though it stops short of explicitly directing the agent to a specific sibling.

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

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.

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.