new.estate

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only that the response is the listing's full text with a citable URL; it says nothing about failure modes for a bad id or content limits.

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 front-loaded sentence with no filler. It is tight, though arguably too terse given the naming collision with get_listing that a clause could have resolved.

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?

An output schema exists, so return values need not be explained, and the tool is simple (one required param). What is missing is any statement of how this differs from get_listing/search_listings, which the agent needs to route correctly among five siblings.

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

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

Schema description coverage is 0% and the lone id parameter is documented only as a bounded string. The description partially compensates by telling the agent the id comes from a search result, which is real semantic value, but it omits any id format or example.

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 (fetch) and resource (full text of one listing) plus a scope qualifier ('by id from search'), so the operation is clear. However, it never distinguishes itself from the sibling get_listing, whose name suggests the same resource, leaving overlap the agent must resolve on its own.

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?

'by id from search' implies the id originates from a search call, which is a useful usage cue, but there is no explicit when-to-use statement, no exclusion, and no routing between fetch, get_listing, or search_listings. Usage is only 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral content beyond that: the explicit similarity rules and the notable special case that a development unit returns the other units of that development, which an agent could not infer from 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 tight sentences, zero filler, with the core purpose front-loaded and the edge case (development units) placed second. Every clause carries information.

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

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

With an output schema present, return structure need not be explained, and annotations cover the safety profile. The only minor gap is that result count, ranking or pagination behavior of the similar-listings set is unstated, though this is not essential to invoke the tool correctly.

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

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

Schema description coverage is 100%, with the id and locale parameters fully documented in the schema (including accepted formats and enum values). The description adds no syntax or format detail beyond that, so the baseline 3 is correct.

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?

States a specific verb and resource ('listings ... similar to the given one') and then defines the similarity criteria precisely (same type and transaction, comparable price, area and location), which cleanly separates it from get_listing and search_listings without opening either schema. The development special case further sharpens scope.

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?

Usage is implied — you supply a listing id you already have and want comparable alternatives — but the description never states when to prefer this over search_listings or get_listing, nor any exclusions or prerequisites. Adequate but leaves routing to inference.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real behavior beyond them: the catalog includes listing counts per country and that names are resolved in the requested language, which an agent cannot infer from 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?

A single front-loaded sentence that lists the catalog contents with no filler. Every clause carries information an agent needs.

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

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

With an output schema present, the description needn't explain return shape, and it adequately covers what the catalog contains and how locale affects it. It stops short of saying when this catalog must be consulted, a minor gap for a lookup tool with one optional parameter.

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% and the enum plus per-parameter description already document locale, so baseline is 3. The description slightly exceeds that by confirming the locale governs the language of the returned names, tying the parameter to observable output behavior.

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 resource (the set of values accepted by search_listings) and enumerates its contents (countries with counts, property types, transaction types, features, sort orders, currencies). It implicitly distinguishes itself from search_listings by describing itself as the catalog that feeds it, though the verb is not explicit.

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 phrase 'Values accepted by search_listings' implies this tool is called to discover valid filter inputs before searching, which gives usable context. However, it never states when to call it versus simply calling search_listings, nor any exclusions or prerequisites (e.g., must fetch first).

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 readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: contact details are excluded from the payload and the correct action is to redirect the user to the listing URL to contact the advertiser.

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 tight sentences: the core result is front-loaded, followed by input sourcing and then the contact-details caveat. 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?

An output schema exists, so return values need no explanation, and the description still characterizes the payload. It covers id sourcing and the contact-detail exclusion; only the absence of any sibling routing (fetch vs find_similar_listings vs get_catalog) keeps it short of 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 description coverage is 100%, so both parameters are already documented, including the id/URL duality and the locale enum. The description repeats the id sourcing but adds nothing about locale semantics, so 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?

Names a specific verb and resource ('Full details of one listing published on new.estate') and enumerates what it returns (description, photos, features, facts). It is clearly distinguishable from sibling listing tools like search_listings or find_similar_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?

Tells the agent where the id comes from ('a listing id from search_listings or the URL of a listing page') and sets an explicit limitation: contact details are not returned, so the user must be sent to the listing URL. It does not contrast against siblings like fetch or get_catalog, but the usage context is clear.

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 readOnly, idempotent, non-destructive and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: results are shallow (ids, titles, URLs) and full text requires a follow-up fetch call, which prevents an agent from assuming it already has the listing content. Auth, rate limits and pagination are still unstated.

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 front-loaded sentences, each doing distinct work: what it does, what it returns plus the follow-up tool, and the alternative for filtered search. 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?

With one fully documented parameter and an output schema present, the description only needs purpose, routing and scope. It supplies all three, including the explicit hand-off to fetch, so nothing needed to call it correctly 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% and the query parameter already documents 'city, district or street'. The description's 'by place name' restates the same idea without adding format, syntax or length guidance, so baseline 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?

States a specific verb (Find) and resource (listings on new.estate) plus the driving input (place name), which immediately separates it from search_listings and fetch. An agent can route correctly without opening any schema.

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?

Gives explicit routing: use fetch for full listing text, use search_listings for filters like price, size or property type. The when-to-use-this vs when-to-use-siblings conditions are stated outright rather than 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?

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds useful behavioral context beyond that: what a result contains (price, area, location, listing URL) and the mandatory practice of surfacing the URL to the user. Pagination mechanics (cursor) and rate/limits are left unstated.

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, front-loaded with purpose, then prerequisite, then output obligation. Every sentence carries distinct information and nothing is restated from the schema or annotations.

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?

Output schema exists, so return values need not be detailed, and annotations carry the safety profile. The description covers purpose, the catalog prerequisite and the URL hand-off, which is enough for correct invocation; it could go further on paging via cursor for a 21-parameter 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?

With 21 parameters and only 67% schema description coverage, the description barely touches parameters; its only contribution is steering the agent to get_catalog for valid propertyTypes/country values. Undocumented params such as limit, minPrice/maxPrice, minArea/maxArea, latitude and longitude get no compensating explanation, so it does not rise above the mid-coverage 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?

States a specific verb and resource ('Search real-estate listings') and enumerates the scope (homes, apartments, plots, commercial; sale or rent; many countries), so an agent immediately knows what this returns. It does not differentiate from the generic sibling tool `search` or `find_similar_listings`, which is the only gap.

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?

Gives a concrete prerequisite ('Call get_catalog first when unsure which property type or country values exist') and an output directive ('Always give the user the listing URL'). There are no when-not-to-use notes or comparisons against the sibling search/find_similar_listings tools, so it stops short of full routing guidance.

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