RentalHunter

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds genuinely useful context beyond that: the miss case 'returns found false and does not substitute another home,' which tells the agent not to expect a sibling listing fallback. It stops short of describing pagination or response shape details, but for a single-item read this is solid.

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 front-loaded sentences with no filler: the returned-field inventory comes first, the edge-case behavior second. Every clause earns its place given there is no output schema to carry the field list.

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 no output schema, the description compensates by enumerating return fields and documenting the not-found behavior, which is the key completeness risk for this tool. Minor omission: it does not explain how stay_nights changes the 'stay fit' signal, though the schema covers the parameter's allowed values and purpose.

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 both parameters carry their own descriptions (listing_id sourced from search_rentals, stay_nights scoped to the fit check). The description does not add syntax or format detail beyond the schema, so the 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 and resource ('Returns one RentalHunter listing by id') and then enumerates exactly what comes back (rent in local currency, locality, stay fit, furnishing, deposit, lock-in, verification badges, freshness, link). An agent can distinguish this single-item fetch from the sibling search_rentals list tool without opening either 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?

Usage is implied rather than stated: retrieving one listing by id, with the id obtainable from search_rentals (which the schema notes, not the description). There is no explicit 'use this after search_rentals when you need full detail' routing, and no when-not guidance. Adequate but with a clear gap.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is largely covered. The description adds conditional dispatch logic (search only fires when three fields are present) and explicit no-side-effect guarantees about alerts and emails, which is real value 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?

Three short sentences, no waste, with the primary function stated first and the conditional behavior second. 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 21-parameter, two-mode tool with no output schema, the description omits what the agent actually gets back — the shape of the missing-field report and the search results. The dispatch condition is covered, but the response contract is left entirely to inference.

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 95% across 21 parameters, so the schema already carries the parameter semantics in detail. The description adds no field-level meaning and does not clarify how the questionnaire branch prioritizes the missing fields it reports. 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?

Names a specific verb+resource relationship: it reports missing hunt fields, and conditionally searches inventory. It also carves itself out from siblings by declaring it does not save an alert or collect an email, which separates it from save_hunt_alert. 'Hunt fields' remains slightly jargon-y, but the behavior is 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 gives a clear trigger for the search branch (city, stay length, and budget present) and an explicit exclusion ('Does not save an alert or collect an email'), which implicitly routes the agent to save_hunt_alert for that job. It stops short of naming the alternative tool outright, so it is not a full 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful data context by noting the rates are 'live USD rates,' implying dynamic values, but says nothing about result size or ordering.

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 resource and its returned fields with no filler. Every clause carries information an agent would otherwise have to discover by calling the tool.

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 no output schema, the description must carry the return-value burden, and it does name the four reported fields. It stops short of describing the shape (one entry per city?) or ordering, which leaves a small gap for a list 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 tool takes zero parameters, which is the baseline-4 case; there is nothing parameter-wise for the description to explain. The enumerated return fields are the only meaningful content and they are covered in the purpose statement.

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 pairs a specific verb (Lists) with a concrete resource (cities on RentalHunter) and enumerates the returned fields (budget currency, stay lengths, live USD rates). It is clearly distinct from siblings like get_listing or search_rentals, though it never explicitly contrasts itself against them.

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 only implied: an agent can infer this is a reference/discovery call for city metadata, but the description gives no explicit when-to-use, prerequisites, or alternatives. No guidance is offered on whether to call this before search_rentals or how often to refresh 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 cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lowered. The description still earns credit for disclosing the negative case — a home owned by someone else is reported as 'not in your inventory' rather than erroring, which tells the agent how to interpret a miss.

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 the return payload front-loaded and the edge-case behavior trailing. No filler, no repetition of the title or schema text.

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

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

With no output schema, the description enumerates the returned fields and covers the ownership-miss case, which is enough for an agent to call and interpret it. Minor gap: '7- and 30-day counts' never says counts of what (views, leads, inquiries), leaving one term slightly ambiguous.

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 listing_id is already documented as 'Id of one of this partner's homes'. The description adds meaning beyond that by defining the ownership boundary and what happens when the id falls outside it, which is real semantic value for the single parameter.

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 plus the exact payload (status, verified flag, 7- and 30-day counts) for a single owned home, which separates it from generic listing-detail siblings like get_listing. It does not explicitly name an alternative tool, so sibling differentiation is implied rather than stated.

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 'for one home this partner owns' implies the applicable scope, and search/list tools are implicitly excluded since only one listing_id is accepted. However, there is no explicit when-to-use vs get_listing or my_listings, and no stated prerequisites.

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 value beyond them by disclosing data-minimization behavior: seeker identity is withheld until acceptance and phone numbers are never returned, which shapes how the agent should interpret results. It does not, however, mention ordering, result limits, or pagination.

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 with no filler; the core operation is front-loaded and the two privacy constraints follow. Every sentence carries information the 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?

For a zero-parameter read tool with no output schema, the description covers scope and the key privacy semantics an agent must understand. It omits any indication of return shape beyond restrictions (fields returned, volume, ordering), a minor gap given the tool's simplicity.

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 tool takes zero parameters, so the baseline is 4 and there is nothing in the description that could mislead about inputs. No parameter meaning is added or needed.

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 concrete verb and resource: "Lists recent hunts that match this partner's homes," which an agent can distinguish from my_listings (own inventory) and search_rentals (broader search). The term "hunts" is domain jargon and the link between the tool name "leads" and hunts is only implicit, but the operation is clear.

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 guidance on when to use this versus siblings such as search_rentals or my_listings, and no stated prerequisites. The scope (this partner's leads) implies context but there is no explicit when/when-not instruction.

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 genuinely new behavioral context: an auth requirement (partner API token), strict ownership scoping, and that metrics are windowed at 7 and 30 days.

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: the payload/scope statement first, then the access constraint. No filler, no restating of the title, and every clause carries information an agent can act on.

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 parameterless read-only listing tool with no output schema, the description covers scope, auth, and return fields adequately. Only minor gaps remain, such as result count limits or ordering of the returned homes.

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 tool takes zero parameters, so the baseline is 4. The description correctly implies a no-argument call scoped implicitly to the authenticated partner, and no parameter semantics are needed.

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 (lists) and resource (this partner's own homes), plus the exact fields returned (status, verified flag, view/save/matched-hunt/accepted-hunt counts). The scoping clause 'other partners' homes are never included' separates it from search_rentals and get_listing, though it doesn't explicitly name those siblings.

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

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

The prerequisite 'Requires a partner API token' is a useful usage condition, and the read-only scope is implied. However, there is no explicit statement of when to choose this over listing_performance, my_leads, or search_rentals, and no exclusions beyond the ownership scope.

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 behavior, so the safety profile is covered. The description adds real value beyond them by enumerating the response payload (ok flag, public hunt URL, privacy/terms/support links), which tells the agent what a successful probe yields and that a URL is exposed.

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 short sentences with no filler, the action front-loaded and the return contents following. Every clause 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 zero-parameter health check with no output schema, the description supplies everything needed: what is tested and what comes back, including the URL and legal/support links.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 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 ('Checks that ... can reach its inventory') and a specific resource (the RentalHunter connector). It is unmistakably distinct from every sibling tool, all of which operate on listings, cities, or leads rather than connectivity.

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 purpose implies a connectivity/health-check use case, but the description never says when to call it (e.g., before a batch of rental searches, or when another tool fails) or when it is unnecessary. Usage is inferable 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?

The description discloses substantial behavior beyond the annotations: it creates a seeker account when the email is new, leaves the hunt pending when an account already exists, sends emails on matches, and defers phone sharing to the website. It does not, however, address the destructiveHint=true annotation — nothing explains what is overwritten or destroyed on a save — nor does it confirm the idempotentHint 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 action is front-loaded, which is good, but the passage runs five sentences and wanders into account-lifecycle detail. The final sentence — 'Verify your phone so matching partners can reach you' — is user-facing marketing copy addressed to the seeker, not guidance for an agent invoking the tool, and does not earn 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 25-parameter mutation with no output schema, the description covers the critical non-obvious behavior: consent prerequisite, phone exclusion, account creation and the pending state. Missing pieces are the destructive semantics flagged by annotations and any indication of what the call returns, but overall it is complete enough to call safely.

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 96%, so the schema already documents nearly every parameter. The description's nod to consent ('This is not consent to share a phone number' is already in the schema) and the no-phone rule add little that the schema lacks, so the baseline 3 for high-coverage schemas 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 opening sentence states a specific verb and resource ('Saves a hunt alert for this query') and goes further to describe the full flow — email sharing, matching notifications, account creation. However, it never names or contrasts with the closest alternative path (e.g., guided_rental_questionnaire or search_rentals), so an agent gets a clear purpose but no sibling routing.

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 states preconditions ('Requires consent true', 'Does not accept a phone number') and describes what happens to an email that already has an account, which implies when the tool is and isn't applicable. But there is no explicit when-to-use-vs-alternative guidance and no stated exclusions relative to sibling tools, so usage is inferred rather than directed.

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?

Goes well beyond the readOnly/idempotent annotations by disclosing the return shape (rent in local currency, stay fit, furnishing, deposit, lock-in, verification, freshness, listing link), the semantics of an empty result ('nothing matched,' not an error), the conditional behavior of the summary, and an explicit exclusion ('Does not return image bytes'). These are exactly the operational details annotations cannot express.

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?

Front-loaded with purpose, then constraints, then return behavior; each sentence carries content and none is filler. Minor redundancy: the furnished rule and locality-exactness warning appear verbatim in the schema, so those sentences duplicate rather than add.

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 21-parameter tool with no output schema, the description usefully compensates by enumerating returned fields and defining the empty-result case. What remains unaddressed is result volume — no indication of pagination, result caps, or ordering, which an agent would need when a city-wide search runs broad.

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 95%, so the schema already documents nearly every parameter, including the furnished rule and locality exactness that the description repeats. The description adds only the framing that filters map to 'must-haves the seeker named' — marginal value over the structured fields. 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?

States a specific verb (Searches) and resource (RentalHunter inventory) and enumerates the filterable dimensions (city, locality, stay length, budget, must-haves), which cleanly separates it from get_listing (single listing detail), list_cities (city enumeration), and save_hunt_alert (alert persistence). An agent can distinguish it from all named siblings without opening a 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 when/when-not guidance for a genuinely ambiguous boolean: 'Set furnished true only when the seeker explicitly asks for furnished. Omit it for any furnishing.' It also warns about exact locality matching (Baner does not include Hinjewadi), which prevents a common false-negative. It does not, however, route the agent to alternatives such as get_listing for detail or save_hunt_alert for persistence.

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 usefully adds that the analysis is scoped to the calling partner's own inventory and that results are listing-quality heuristics, but says nothing about scope of evaluation, latency, or what the response contains.

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 the core action first and examples second, and no filler. It is slightly long as a run-on, but every clause adds information about what kind of suggestions to expect.

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 read-only tool the description is nearly sufficient, but with no output schema the description is the only source for the return shape, and it offers only two illustrative examples rather than the categories, structured fields, or volume of suggestions returned.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No argument semantics are needed or expected.

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: it 'suggests improvements' for 'this partner's homes,' and the examples (missing photos, rent far above local median) make the nature of the output concrete. It is distinguishable from search/listing siblings, though it never names a sibling or scope boundary explicitly.

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?

There is no guidance on when to call this versus alternatives like listing_performance or my_listings, nor any prerequisite or trigger condition. The agent must infer from the name alone whether this is a diagnostic tool it should reach for.

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