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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by specifying that it returns source-dated live active-listing asking-price aggregates and descriptive listing facts only, which clarifies the nature and limitations of the data beyond the 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 a single, tightly written sentence that front-loads the action and resource, then adds the important exclusions. Every element earns its place; there is 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?

With annotations covering the read-only/destructive profile, a fully described input schema, an output schema present, and a description that states scope, data type, and exclusions, the description is complete for an agent to correctly select and invoke this tool. Return format is not needed because 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?

Schema description coverage is 100%, so the input schema already documents both parameters. The description reinforces the 2-4 city constraint and the sale/rent context, but it does not add substantial meaning beyond what the schema already provides. Baseline 3 is appropriate here.

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 clear verb ('Compare') and a specific resource ('source-dated live active-listing asking-price aggregates across 2-4 Northern Cyprus cities'). It also distinguishes itself from valuation, forecast, and investment tools by explicitly excluding those categories, making it easy for an agent to identify what this tool does.

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

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

The description provides clear context for when to use the tool: comparing city-level asking-price aggregates for 2-4 Northern Cyprus cities, for sale or rent. It also gives exclusions (not transaction prices, valuation, forecast, ranking, or investment advice). However, it does not explicitly name alternative sibling tools such as compare_properties or get_price_index, so the when-not-to-use guidance is present but not fully explicit.

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, so the safety profile is covered. The description adds meaningful behavioral context: it only compares factual listing data and avoids subjective judgments, shows specific outputs (price, size, £/m²), and documents that the legacy alias `listing_ids` is accepted. This goes beyond the structured annotations.

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

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

Three sentences, each carrying distinct value: core function, output scope and non-judgment boundary, and alias note. The most important constraints are front-loaded, and there is 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 tool with one parameter, a complete output schema, and annotations covering safety, the description covers all needed guidance: input count and type constraints, active and same-type prerequisites, what it returns, what it avoids, and legacy compatibility. Nothing critical 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 baseline is 3. The description adds extra meaning by clarifying that only listings of the same type and active listings should be compared, and by revealing the legacy `listing_ids` alias. These details are not present in the schema itself, raising the value 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 uses the specific verb 'Compare' with a clear resource: descriptive facts from 2-4 active Evlek sale or long-term-rent listings of the same type. It distinguishes itself from sibling tools like compare_cities by focusing on property listings, and from listing lookups by emphasizing side-by-side comparison of facts.

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 scopes when to use the tool: comparing descriptive facts from 2-4 active listings of the same type. It also provides an explicit when-not by stating it makes no value, suitability, appraisal, or investment judgment. It does not name alternative sibling tools, but the use case is well-defined enough to guide an agent.

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 mark the tool as read-only and non-destructive, and the description adds valuable behavior beyond that: it requires fresh date-stamped rates and fails closed without amounts if conditions are unmet. This gives the agent a clear expectation of success and failure modes.

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 deliver the purpose, scope, preconditions, and failure mode with no filler. The core action and limitations are front-loaded, making the tool easy to scan and understand.

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, together with the schema and annotations, gives a solid picture of when and how the tool behaves. An output schema exists so return details are not the description's responsibility. It could be slightly more explicit about whether all four currencies are returned at once, but the current wording is sufficient for selection and 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 description coverage is 100%, so the schema already documents the price amount and currency well. The description reinforces that the input is a property asking-price amount and not a deposit or installment, but it does not add new parameter-level detail 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 states a specific verb and resource: converting an entered property asking-price amount across GBP/EUR/USD/TRY. It also clearly delimits the tool's scope by excluding payment plans, deposit schedules, and other related calculations, distinguishing it from sibling tools like payment_plan.

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 clear context: this is only for currency conversion of an asking price, not for payment schedules or cost advice. It also states a precondition (complete, valid, fresh, date-stamped FX rates) and the failure behavior. It does not explicitly name alternative tools for the excluded use cases, but the exclusion itself provides practical routing 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, so the safety profile is covered. The description adds useful behavioral context: it is id-only, returns GBP-normalized price, and mirrors get_listing_detail's data. 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 well-structured and front-loaded: it opens with the action and resource, then narrows to contract context and explicit usage rules. Every sentence contributes useful information without unnecessary 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?

For a one-parameter read-only tool with a rich output schema and annotations already present, the description covers what the tool does, what data it returns, when to use it, and when not to. Nothing critical 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?

The schema has 100% coverage for its single required parameter, including the UUID-from-search meaning. The description reinforces 'by id (from search)' but adds no meaning beyond the schema, 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 states a specific verb and resource: 'Fetch the full detail of one Evlek listing by id', and enumerates the exact data fields returned. It also distinguishes this tool from get_listing_detail by explaining it is the fixed id-only connector-contract form.

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?

It explicitly gives a use condition ('Use when: an id from search is known'), a don't-use condition ('Don't use for: discovery'), and names the alternative ('use search first'). However, because get_listing_detail is described as returning the same data, the description doesn't fully clarify when to choose fetch over get_listing_detail for non-connector use.

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. The description adds valuable behavioral context: data is source-dated, reflecting active listings, and any rent-to-price percentage is a derived ratio rather than observed income, yield, valuation, forecast, ranking, or recommendation. This prevents misinterpretation of results.

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 filler. The first sentence front-loads the core behavior, and the second sentence adds an essential caveat about how rent-to-price percentages should be interpreted.

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 full schema coverage, annotations, and an output schema, the description is nearly complete. It adds the right disclaimers and scope. A small gap is the absence of any explicit pointer to sibling tools for multi-district comparisons, though this is not required for invoking 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 description coverage is 100%, so both city and district parameters are fully documented there. The description adds no parameter-specific details beyond the single-district scope, so it does not need to compensate for any 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?

Description states a specific verb and resource: 'Returns source-dated active sale/long-term-rent listing counts and asking-price aggregates for one district.' It clearly identifies a single-district profile tool and distinguishes it from siblings like compare_cities or 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 gives clear context: use this tool when you need asking-price and listing-count aggregates for one district. It does not explicitly name alternatives or exclusions, but the single-district scope and output type make the intended usage reasonably obvious.

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, so the safety profile is known. The description adds useful behavior beyond that: it returns 'full detail — same shape as get_listing_detail' and documents the accepted legacy `listing_number` alias. 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?

Three sentences pack purpose, boundary conditions, return shape, and alias information without any filler. Key scoping information is front-loaded before the alternatives and alias notes.

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 lookup with a single required parameter and an output schema, the description fully covers what the tool does, when to use it, what not to use it for, and the parameter alias. Nothing material 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%, so the schema already documents listingNumber with examples. The description adds the legacy alias `listing_number` and clarifies the acceptable formats ('EVL-123456', '123456', or bare number), which goes beyond the schema's already-good 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 opens with a specific verb and object: 'Look up a single Evlek listing by its public listing number.' It immediately differentiates itself from get_listing_detail by contrasting public-number lookups with UUID lookups, so an agent can distinguish the two tools without inspecting schemas.

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 guidance: 'Use when: a listing number is known. Don't use for: UUID lookups — use get_listing_detail.' It also covers the legacy parameter alias, which helps agents handle older call patterns 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, destructiveHint=false), the description discloses meaningful behaviors: contact details are omitted, AI virtual-staging is always disclosed, and only active listings are returned. These details inform an agent about content boundaries and policy compliance beyond what the annotations or schema state.

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 information-dense but every clause earns its place: main behavior, field list, exclusions, usage guidance, and alias note. It is front-loaded with the core purpose and avoids redundant restatement of the title.

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 everything an agent needs: what is returned, what is omitted, when to use it, and how to identify the listing. No critical 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 schema already documents the parameter well. The description adds value by clarifying that the propertyId can be a UUID or listing number and by noting the legacy 'property_id' alias is still accepted, which the schema does not mention.

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: 'Return a 360° profile of one active Evlek listing by UUID or listing number,' followed by a concrete list of included fields. It clearly distinguishes itself from discovery-oriented tools by naming search_listings as the alternative, making its role 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?

Explicit guidance is provided: 'Use when: a UUID or listing number is already known. Don't use for: discovery — use search_listings first.' This gives both positive and negative usage conditions and names the exact alternative, leaving no inference required.

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, so the safety profile is clear. The description adds meaningful context beyond that: data is 'source-dated', 'live active', and based on 'asking prices' only, and it clarifies that output is descriptive facts rather than investment advice. This helps the agent interpret results correctly.

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 tight sentences with zero waste. The first states the action and key qualifiers; the second draws a clear boundary of what the data is not. Every phrase contributes to understanding.

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 lightweight read-only tool with two optional, fully documented parameters and an output schema, the description covers the essential semantics, scope, and limitations. An agent can safely invoke it and know what kind of output to expect without missing critical context.

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% parameter description coverage, so the description does not need to compensate. It echoes the 'sale or rent' distinction from the type parameter but adds no meaning beyond what the schema already provides. 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?

Description names a specific verb ('Returns'), a clear resource ('source-dated aggregates of live active Evlek sale or long-term-rent asking prices'), and explicitly scopes away from completed transactions, valuations, forecasts, and recommendations. This distinguishes it from sibling listing/search tools, which target individual properties 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 use for market-level asking-price analytics and explicitly lists exclusions ('not completed transactions, a valuation, a forecast, or an investment recommendation'). However, it does not explicitly name an alternative tool or state a direct routing condition such as 'use this for aggregates, use search for listings', so the guidance is more implied than explicit.

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 mark the tool as read-only and non-destructive; the description adds that results are live inventory-location facts only and that holiday-home inventory is unavailable. This usefully discloses the data-source behavior and a meaningful limitation beyond what annotations state.

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 at two sentences, front-loads the core purpose, and every sentence carries meaningful scope information. No filler or redundant restatement of the title or schema.

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 optional parameter, an output schema, and clear annotations, the description covers purpose, scope, live-inventory behavior, and an explicit exclusion. Nothing essential is missing for an 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?

The input schema already provides 100% coverage for the single optional city parameter, including accepted forms like slug, Turkish name, or exonym. The description adds no additional parameter-level detail, so the baseline score 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 states a specific verb and resource: it returns canonical KKTC city slugs plus districts represented by active Evlek sale or long-term-rent listings. It clearly scopes the result set and distinguishes itself from broader search or comparison tools by emphasizing live inventory-location facts.

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 makes clear that this is for canonical city/district data derived from active sale or long-term-rent listings and explicitly excludes holiday-home inventory. It does not name a specific sibling alternative, but the exclusion and live-inventory framing give the agent clear contextual guidance on when 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?

Annotations already declare readOnlyHint and non-destructive behavior. The description adds meaningful context by revealing that this is a temporary placeholder that only returns currency conversion, going beyond what the annotations convey and preventing false expectations about payment-plan outputs.

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 concise sentences. The first front-loads the actual current behavior, and the second prevents misuse by listing what the tool does not do and explaining the placeholder situation. 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 simple two-parameter tool with an output schema and safety annotations, the description covers the essential caveat that the tool name is misleading. It could have pointed explicitly to convert_currency as the canonical sibling, but nothing critical is missing for correctly invoking a basic currency conversion.

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 itself adds no parameter-specific detail; the schema already explains that price is the asking price and not a deposit or installment, and currency is the price currency.

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 currently performs currency conversion only, and explicitly disclaims payment-plan, deposit, and acquisition-cost outputs. This distinguishes it from the misleading name, though it does not explicitly differentiate it from the sibling convert_currency.

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

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

The description implies the tool should be used for currency conversion and warns against using it for payment plans or related estimates. However, it never explicitly says when to prefer this tool over the sibling convert_currency, and it lacks clear when-to-use versus when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds that results are returned as id/title/url for the fetch tool and that it shares data with search_listings. It enriches the behavioral context without contradicting annotations.

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

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

The description is clear and front-loaded with the core action and resource, then return format, then usage routing. It is slightly longer than the minimum but every sentence carries distinct 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?

For a one-parameter, read-only search tool with an output schema and annotations, the description covers what the tool does, why it exists, when to use it, and which sibling covers the excluded case. Nothing required 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 'query' is already fully described in the schema as 'Free-text property search query'. The description reinforces the free-text nature and contrasts with structured filters, but adds no new details such as format, length, or language constraints.

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 action (search), a concrete resource (live Northern Cyprus property listings on Evlek), and the free-text query mode. It also explicitly distinguishes itself from search_listings by noting the shared data and the fixed connector contract, 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 'Use when' and 'Don't use for' instructions, naming search_listings as the alternative for structured filters. This is unambiguous routing guidance that leaves no doubt about when this tool should be selected.

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, destructiveHint=false), the description discloses default ordering, that limit caps returned rows, that totalMatched reports the full match count, and explicitly states what the tool does NOT return (valuation, verification, forecast, ranking, recommendation). This is rich, non-contradictory context that meaningfully shapes agent 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?

Three compact sentences: the first states the action, the second explains ordering and count semantics, and the third lists explicit exclusions. No filler or repetition, and key facts are 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?

For a 16-parameter tool with 100% schema coverage and an output schema, the description covers all necessary operational context: purpose, default order, pagination semantics, and explicit disclaimers about result scope. An agent can select and invoke it correctly without needing additional 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?

Schema coverage is 100%, so the schema documents all 16 parameters. The description adds value by defining 'limit' as capping rows, introducing 'totalMatched' as the full match count, and clarifying that the search targets sale and long-term-rent listing types. This goes slightly 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 identifies a specific verb ('Search') and resource ('live active sale and long-term-rent listings on Evlek'), with the title adding 'Northern Cyprus Property Listings'. It does not explicitly contrast with sibling 'search', but the scope and platform-specific wording make the tool's purpose distinguishable.

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 is clear: use this tool to find active sale and long-term rent listings, with default newest-first ordering and pagination. However, it does not name any alternatives or state when to prefer get_listing_by_number, compare_cities, or search instead.

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