Evlek — Northern Cyprus Property MCP Server

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

No annotations are provided, so the description carries full burden. It discloses that results are neutral, general information with disclaimers, and recommends consultation. It does not explicitly state that it is read-only or safe, but the nature implies it. Adequate but could be more explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the purpose and output, and adding a short disclaimer. Every sentence adds value, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, enum) and the presence of an output schema, the description covers purpose, output, and limitations. No gaps remain.

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 parameter is well-documented in the schema. The tool description adds no additional meaning beyond the schema, meeting the baseline of 3.

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

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

The description clearly states the tool's purpose: given a KKTC title-deed type, return a risk band, framing notes, and verification steps. It uses specific verb+resource+output and distinguishes well from sibling tools (e.g., compare_cities, get_legal_info) by focusing on title-deed risk assessment.

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 includes usage context: it is for general information only and not legal advice, with a disclaimer and recommendations. However, it does not explicitly state when to use this tool versus alternatives, or when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It describes what the tool does and its output, but does not disclose behavioral traits such as data freshness, permissions, or any side effects. Since the tool is likely read-only, the description is adequate but not highly transparent.

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 with no wasted words. The first sentence explains the functionality, and the second provides context for use. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the presence of an output schema, the description covers the essential elements: what is compared (cities), the number of cities (2-4), and the output structure (aggregated prices, counts, districts). No critical gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for both parameters (cities and type). The description adds no additional meaning beyond what the schema already provides (e.g., the output details but not parameter specifics). Baseline is 3.

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

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

The description clearly states the verb 'compare' and the resource '2-4 Northern Cyprus cities', and specifies the output: aggregated prices (avg, median, min, max), listing counts, and top districts. This distinguishes it from sibling tools like compare_properties and get_market_overview.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes 'Useful for deciding between investment locations', which provides clear context for when to use the tool. However, it does not explicitly mention when not to use it or compare it to alternatives like compare_properties or get_market_overview, so it lacks exclusion 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?

With no annotations, the description carries full burden. It discloses that the tool returns specific attributes and an automatic value insight (e.g., cheapest £/m²). It does not mention side effects, but as a comparison tool, it is likely read-only. The description adequately conveys expected behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no redundancy. It front-loads the core purpose, then lists outputs and provides a usage tip. Every sentence contributes meaningfully.

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?

Although an output schema exists (not shown), the description already explains the returned attributes and insights. It covers input sources and constraints. Slight gap: does not mention that listings must be 'active', but that is in the first sentence.

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 parameter 'listing_ids' is fully described in the schema with 100% coverage. The description adds value by stating 'Pass UUIDs from search_listings results', providing context on where to obtain valid UUIDs, which goes 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 compares 2-4 active Evlek property listings side-by-side, listing the specific attributes returned. This distinguishes it from sibling tools like 'search_listings' (which returns results) and 'get_listing_detail' (single listing), making its purpose 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?

The description instructs users to pass UUIDs from 'search_listings' results, providing a clear precondition. However, it does not explicitly state when not to use this tool versus alternatives like 'get_listing_detail', but the context of comparing multiple listings is implied.

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?

With no annotations, the description carries full burden and explicitly states 'Read-only' and that contact details are intentionally omitted. This clearly discloses behavioral traits beyond the 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?

Single sentence with no wasted words; information is front-loaded and structured effectively.

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 one parameter and an output schema present, the description is sufficient—it lists fields returned, notes read-only nature, and mentions omission of contact details.

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 describes the 'id' parameter as 'Evlek listing id (UUID) from search' (100% coverage). The description adds context that the id comes from search, matching the schema, but does not add new meaning beyond it.

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

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

The description clearly states it fetches full detail of one Evlek listing by ID, listing specific fields returned. It distinguishes from siblings like 'search' but does not explicitly differentiate from '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 mentions 'by id (from search)', implying it should be used after a search, but provides no explicit guidance on when to use versus alternatives like 'get_listing_detail', and no 'when not to use' instructions.

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?

With no annotations provided, the description takes full responsibility for behavioral disclosure. It honestly states its limitations (general info, not legal advice) and recommends external verification, providing transparency about what the tool does and does not guarantee.

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. It packs essential information: purpose, scope, and disclaimers, with no wasted words. Front-loaded with the roadmap purpose.

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 no parameters and the presence of an output schema, the description is largely complete. It covers the tool's purpose, scope, and necessary caveats. Minor improvement could include mentioning the output format or step categories, but it is sufficient for an informational overview tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so schema description coverage is 100% vacuously. The description adds no parameter-specific details, but the tool requires none; baseline for no-parameter tools is 4, and the description adds overall value.

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

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

The description clearly states it provides a step-by-step roadmap for foreign nationals buying property in KKTC, including the Permission to Purchase process. It distinguishes itself from sibling tools (e.g., assess_title_risk, get_legal_info) which cover specific aspects, making its purpose unique and well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly notes that it is general information only, not legal advice, and advises confirming with a KKTC lawyer. This gives clear context for usage, though it does not explicitly contrast with sibling tools or specify when not to use it.

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

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

No annotations present, so description carries full burden. Describes return data thoroughly and implies a read-only operation. Does not cover error conditions but sufficient for a profile 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?

Single sentence with no wasted words, front-loaded with purpose. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With output schema present, description lists all major return fields. Usage sequencing is provided. Completeness is high for a profile retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema already covers city with enum and district with length constraint (50% coverage). Description adds context about the tool's purpose but no new parameter details, which is acceptable given schema adequacy.

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

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

Description specifies a comprehensive profile for a single district with detailed data points, and distinguishes from siblings by indicating usage after compare_cities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Use after compare_cities narrows the city,' providing clear usage context. Does not include explicit exclusions but the guidance is strong.

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?

No annotations are provided, so the description carries the full burden. It does not disclose any behavioral traits such as being read-only, requiring authentication, or having rate limits. The only behavioral hint is the recommendation to consult a lawyer, which is not a tool behavior.

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 with no wasted words. It front-loads the purpose and then adds the important usage caveat. 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?

Given the tool has a single parameter with an enum and an output schema exists (not shown but mentioned), the description is fairly complete. It covers the scope of topics and provides a usage warning. It does not explain the output structure, but that is not required since an output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters with a single enum parameter 'topic'. The description adds meaning by providing real-world equivalents for each enum value (e.g., 'title deed types (koçan)' for 'kocan_types'), going beyond the schema's brief 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 it is for 'general legal/procedural routing' for Northern Cyprus property topics, listing specific examples like title deed types, foreign purchase rules, taxes, etc. This distinguishes it from sibling tools like 'foreign_buyer_roadmap' which likely focus on a specific process.

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 advises to 'always recommend consulting a lawyer for specific cases,' which provides a when-not-to-use guideline. However, it does not explicitly contrast with sibling tools or provide alternative tool names for more specific tasks.

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?

With no annotations, the description carries full burden. It transparently discloses what is included and what is intentionally omitted (contact details). For a read operation, this provides sufficient behavioral context; no side effects need disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, tightly written sentence that front-loads the action ('Return a 360° profile') and enumerates contents efficiently. Every part contributes value with zero redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (1 parameter, output schema present), the description fully covers input source and output contents. No additional context is needed; the tool is self-contained.

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 already describes property_id as 'Evlek listing UUID', but the description adds that it should be a UUID from search_listings, providing provenance context that enhances meaning beyond the schema alone.

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 ('Return') and resource ('360° profile of one active Evlek listing by UUID'), and lists distinct fields covered. It clearly distinguishes itself from sibling tools like search_listings (which returns a list) and others.

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 instructs to pass a UUID from search_listings, establishing a clear usage context. It also sets expectations by noting contact details are omitted, but does not explicitly state when not to use this tool or compare with similar detail tools.

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?

No annotations provided, so description must cover behavioral traits. It states it returns data with no side effects, but lacks details on data freshness, update frequency, or limitations. Adequate but minimal.

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?

Single, front-loaded sentence that conveys purpose and content efficiently. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with output schema, description is complete enough. It covers what the overview includes and doesn't need to detail return fields further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema, so schema coverage is 100%. Description adds no parameter info beyond schema, but baseline is 4 for zero-param tools.

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

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

Description clearly states it returns a high-level market overview including average rents, sale prices, yields, and key facts. It distinguishes itself from sibling tools like get_district_profile and get_price_index by being broad and multi-city.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage for a top-level market overview, but no explicit when to use vs alternatives or exclusions. With siblings like get_district_profile and get_yield_estimate, the context is clear but not stated.

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?

With no annotations provided, the description carries full burden. It mentions data source (active listings on evlek.app) and aggregation type, but lacks details on update frequency, staleness, or behavior when parameters are omitted. Partial disclosure but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action. No redundant information. Each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, return values are covered. The description lists aggregated metrics. Minor gap: does not specify what happens when no city is provided (presumably all cities). Otherwise adequate for a data retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (only 'type' has description). The description adds 'per city and top districts' which hints at city-level aggregation but does not clarify default behavior when city is omitted or what 'top districts' means. It does not significantly supplement 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?

Description clearly states it returns the live Evlek Price Index with aggregated statistics per city and top districts. It identifies the specific resource and action, and the sibling tools like get_market_overview cover broader market data, so this tool is distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'useful for market analysis and investment decisions' providing a general context, but it does not explicitly state when to use this tool versus alternatives like get_market_overview or get_district_profile. No exclusions or when-not-to-use guidance is given.

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?

With no annotations provided, the description carries full burden. It states 'calculate estimated' but does not disclose assumptions, data sources, accuracy, or any side effects. No information on whether calculations are real-time or static.

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 short sentences, front-loaded with the action verb 'calculate'. Every word adds value; 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 tool's complexity (3 parameters, output schema exists), the description covers the main intent and outputs but lacks detail on optional inputs (bedrooms) and how net vs gross differ. It is minimally complete for a straightforward calculator.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67% (2 of 3 parameters described). The description adds meaning by specifying city and purchase price as key inputs but omits the optional bedrooms parameter. For a baseline of 3 with moderate coverage, this is adequate without being exceptional.

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 gross and net annual rental yield, breakeven years, and city averages from purchase price and city. It distinguishes from sibling tools like get_market_overview or get_price_index by specifying exact outputs.

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 provide guidance on when to use this tool versus alternatives (e.g., compare_cities). It implicitly suggests use for yield estimation but lacks explicit when-not or alternative tool references.

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?

With no annotations, the description carries the full burden. It discloses that rates are 'live' and 'date-stamped', that off-plan triggers 'staged-payment risk warnings', and that output is 'general information only'. However, it does not detail rate sources, update frequency, or any behavioral implications like reliance on external 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 sentences: the first delivers the core functionality ('Convert... and surface...'), and the second provides a legal disclaimer. No fluff, front-loaded, and every sentence serves a purpose.

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 has an output schema (return values are documented), the description covers the main use cases (currency conversion and off-plan warnings). The disclaimer sets appropriate expectations. It could mention the source of exchange rates, but overall it is complete for a tool of this 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 coverage is 100% with descriptions for all three parameters. The description adds that 'offPlan' triggers risk warnings and that base currency is GBP, but does not significantly extend beyond the schema's parameter descriptions (e.g., price description is redundant).

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 'Convert a Northern Cyprus property price across GBP/EUR/USD/TRY using live, date-stamped exchange rates, and surface off-plan staged-payment risk warnings.' It uses specific verbs ('convert', 'surface') and identifies the resources (price, off-plan status), and clearly differentiates from sibling tools, none of which perform currency conversion.

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 ends with 'General information only — confirm escrow, milestones and title transfer with an independent KKTC lawyer,' which sets a disclaimer but does not explicitly state when to use this tool vs alternatives (e.g., for off-plan vs. ready properties). No exclusions or alternative tool names are provided.

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?

With no annotations provided, the description carries the full burden. It clearly states 'Read-only; no contact details,' which are key behavioral traits. However, it does not mention pagination, rate limits, or whether results are limited.

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 main purpose, and every sentence adds value. No wasted words 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?

Given the presence of an output schema and a single parameter, the description provides adequate context: what it searches, what it returns, and that it is read-only. It does not cover edge cases or limits, but it is sufficient for a simple search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% coverage with a brief description of 'query', but the tool description adds valuable context by listing examples (city, sale/rent, bedrooms), which helps an agent formulate better queries.

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 searches live Northern Cyprus property listings on Evlek using free-text query, and specifies what the query can contain (city, sale/rent, bedrooms). It also distinguishes from sibling tools like 'search_listings' by noting the return format (id/title/url for the fetch tool) and that it is read-only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for initial search to get listing IDs for the fetch tool, but does not explicitly state when not to use this tool or mention alternatives like 'search_listings'. It lacks clear guidance on when to prefer other tools.

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?

No annotations are provided, so the description must cover behavioral traits. It mentions 'live property listings' and the returned fields, but does not disclose data freshness, authentication requirements, or whether the query is cached. Adequate but not thorough.

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 provide the essential information without unnecessary detail. The structure is straightforward and front-loaded with the main purpose. Minor improvement could be adding bullet points for filters, but current version is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Considering the tool has 6 parameters, an output schema, and 16 sibling tools, the description covers the core purpose, filters, and result shape. However, it lacks ordering/pagination details and comparative guidance against similar siblings like 'search'. Still adequate for basic use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers all 6 parameters with descriptions (100% coverage). The description adds minimal extra meaning beyond listing the filter types; for example, it doesn't explain that the price range is in GBP or that the limit is inclusive. Baseline 3 applies since schema does the heavy lifting.

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 action ('Search'), the resource ('live property listings on Evlek'), and the available filters (city, type, bedrooms, price range). It distinguishes itself from sibling tools like 'get_listing_detail' or 'get_market_overview' by focusing on multi-property search with filters.

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?

No explicit guidance on when to use this tool versus alternatives such as 'search' or 'compare_properties'. The description only explains what the tool does, not when it is appropriate or what limitations exist.

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?

With no annotations, the description adds some transparency: it uses a live roster, provides estimates only, and is not financial advice. It does not disclose potential side effects or data usage beyond the estimate.

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: two sentences with no fluff. It front-loads the key purpose and includes a necessary disclaimer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description adequately covers input, output, and context. It mentions the live roster, yield bands, and a link to listings. A mention of potential limitations could improve completeness.

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 descriptions for all three parameters. The description adds context about the output (9-month vs 12-month yield) but does not add significant meaning beyond the schema descriptions.

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

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

The description clearly states the verb 'estimate' and the resource: student-rental monthly rent and yield for a university in Northern Cyprus. It differentiates from siblings like get_yield_estimate by specifying the student-housing context and the university focus.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a Northern Cyprus university is given and rent/yield estimates are needed. However, it does not explicitly state when to avoid using this tool or compare with siblings like get_yield_estimate.

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?

No annotations are provided, so the description carries the full burden. It mentions 'expert knowledge' but does not explain the matching algorithm, data sources, or limitations. The return value details are vague (only mentions neighborhoods and rationale, not format or properties).

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 (2 sentences) and front-loaded with the core purpose. Each sentence serves a purpose: defining input and output. However, it could be slightly more structured, e.g., by separating output format details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema, the description does not need to detail return values, but it lacks other contextual completeness: no info on required permissions, data recency, or how 'expert knowledge' is derived. For a recommendation tool, more context about the underlying logic would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must add meaning. It mentions 'buyer persona' and 'optional budget/preferences' but does not detail constraints (e.g., min/max for budget, exact enum values for preferences). The persona enum is fully listed in the description, which adds value, but other parameters lack 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 tool's function: given a buyer persona and optional budget/preferences, return 2-3 best-matched neighborhoods with rationale. It specifies the exact verb ('suggest') and resource ('neighborhoods'), and the persona enumeration distinguishes it from sibling tools like search or get_district_profile.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for persona-based recommendations but does not explicitly state when to use this tool versus alternatives like compare_cities or get_district_profile. No exclusion criteria or when-not-to-use guidance is provided.

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