otthon & üzlet

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=true, so the bar is lower. The description still adds two things the annotations do not: "for good" reinforces permanence, and "Needs the seller's sign-in" plus "Ask the seller first" disclose an authorization and human-confirmation requirement that is not encoded anywhere in the structured fields. It stops short of saying what happens to the draft record afterward or how failures surface.

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, front-loaded with the action and its permanence, then the confirmation and auth caveats. No filler and nothing repeated from 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?

For a one-parameter, non-read-only tool with no output schema, the description covers action, permanence, confirmation, and auth. The only meaningful gap is provenance of draft_id, which an agent must guess at since neither the schema nor the description explains it.

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%, so draft_id is documented nowhere; the description only implies it identifies "one of the seller's drafts" and gives no hint about its format (maxLength 64) or how to obtain it (e.g., from list_drafts). With a single required parameter the ambiguity is limited, but the description does not fully compensate for the empty schema 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?

"Discard one of the seller's drafts, for good" names a specific verb (discard) and a specific resource (a draft belonging to the seller), and "one of" makes the single-item scope explicit. It is clearly separable from sibling tools like list_drafts and save_draft 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?

"Ask the seller first" gives a confirmation precondition and "Needs the seller's sign-in" gives an auth precondition, which is real usage guidance. However, it never contrasts this with alternatives (e.g., versus save_draft or leaving the draft in place) or states when a draft should be discarded, so an agent still has to infer the selection context.

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, closed-world behavior, so the bar is lower. The description adds genuinely non-derivable context: "Needs the seller's sign-in," an auth precondition the agent cannot infer from any structured field, plus a summary of what the payload 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?

Three tight sentences with no filler, and the core purpose plus return contents are front-loaded. The middle clause ("with its type, options, bounds and when it applies") is dense but each item earns its place as a description of the returned spec.

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 carries the burden of describing the return value, and it does so at a reasonable level (fields, types, options, bounds, applicability). No required params, three optional enum filters, and the auth caveat is disclosed — only the meaning of the individual filters is thin.

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 only 33% — only "deal" is documented in the schema. The description gestures at the other two by naming "kinds" and "building types" as the subject matter being filtered, but it never states that kind and building are optional narrowing filters or what distinguishes home/shop or the five building values.

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 makes clear this returns the specification a listing draft requires — the kinds, building types, general fields, and per-fact type/options/bounds/applicability. That is a concrete resource description, though the verb is implicit ("What a listing draft asks") and no sibling is named for contrast.

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?

"Call it before asking the seller" is an explicit sequencing instruction, and "narrow it with kind, building and deal" tells the agent how to scope the call. It lacks an explicit when-not-to-use or a mention of the draft siblings (save_draft, discard_draft), so it falls short of a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is low. The description still adds real behavioral context beyond them: offers happen on the page and require a Google sign-in, and ended listings are explicitly flagged rather than erroring. It does not discuss the return format or pagination, which keeps it from a 5.

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 dense sentence that front-loads the core content list and closes with two practical caveats (sign-in for offers, ended listings). It is slightly list-heavy but every clause carries information; nothing is redundant with the name 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?

With no output schema, the description must carry the return-value burden, and it does: it enumerates the page sections an agent will receive and notes the ended-listing state. For a one-parameter read-only lookup, nothing an agent needs in order 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 coverage is 100% and the single parameter already documents that it accepts either the listing code or its full otthonesuzlet.hu URL. The description adds nothing about the code format or normalization. Baseline 3 is appropriate when the schema carries the parameter semantics entirely.

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 makes clear this retrieves a single listing's public page and enumerates its contents (facts, prices, deadline, neighbourhood, floor plan, photos, offer flow). It is clearly distinct from a bulk search, though it never names ingatlan_search_listings as the alternative. A verb is only implicit ('One listing's public page'), but the resource and scope are 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?

Usage is only implied: an agent can infer this is the tool for drilling into one listing once it has a code from a search. There is no explicit when-to-use statement, no mention of prerequisites, and no pointer to ingatlan_search_listings for discovery. Minimum viable, with a clear gap around routing.

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 the safety profile is covered. The description adds that the content is a link the user opens and signs in to, which hints the tool returns instructions/references rather than performing the action. It does not say the response is static or what sections it contains, so added value is modest.

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, and the parenthetical clarifies the ambiguous phrase 'where'. The list of covered topics (kinds, building types, nearby filters) is useful scoping, though the sentence is slightly convoluted and could be split for readability.

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 help tool with annotations covering safety, the description is close to sufficient. However, with no output schema it should say more about what comes back (step-by-step instructions, a URL, a list of posting sites) so the agent knows how to relay the result to the user.

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 per the baseline this scores 4. The description correctly implies no input is needed — it is a pure knowledge lookup — and nothing in it suggests parameters that do not exist.

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 concretely names the subject matter: where and how a seller posts a listing, plus the taxonomy of kinds, building types and nearby filters. That is clearly distinct from the sibling tools (draft, list, search, get), which are all operational rather than explanatory. It loses a point because no verb states what the tool actually does (retrieve instructions? return a URL?) — the agent must infer that it is an informational lookup.

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 explicit when-to-use guidance: nothing says to call this before ingatlan_save_draft / ingatlan_draft_fields, nor that it answers seller-facing 'how do I post' questions. Usage is only implied by the tool name. No exclusions or alternatives are named.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine context beyond them: it discloses the auth requirement ('Needs the seller's sign-in') and the fact that each record carries an activate_url the seller opens to post, which is a behavioral detail not derivable from any structured field. It stops short of pagination, ordering, or behavior when no drafts exist.

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 compact sentence with the resource front-loaded, followed by the return fields and the auth caveat. No filler and nothing redundant with annotations 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?

With no output schema present, the description usefully enumerates the returned fields and adds the sign-in prerequisite, which is enough for an agent to invoke a zero-parameter read correctly. Minor gaps remain around result volume/ordering and the empty-drafts case.

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; there is nothing for the description to clarify beyond the implicit seller scoping, which it does convey ('the seller's drafts').

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 the specific resource ('The seller's drafts') and enumerates the returned fields (id, title, last saved, activate_url), so an agent knows exactly what it retrieves. It does not, however, distinguish itself from the adjacent ingatlan_draft_fields or ingatlan_how_to_post siblings, which an agent could plausibly confuse with a drafts-listing call.

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: the phrase 'the seller's drafts' and the activate_url mention suggest the pre-publish workflow, and the sign-in note establishes a prerequisite. There is no explicit statement of when to call this versus ingatlan_draft_fields or ingatlan_search_listings, and no exclusions.

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 declare it is a non-read-only, non-destructive, non-idempotent write, but the description adds the parts annotations cannot: authentication is required ("Needs the seller's sign-in"), there is a hard quota of 3 drafts, updates are keyed by draft_id rather than creating duplicates, and validation is all-or-nothing ("nothing is saved and the message says what to ask"). Nothing here conflicts with the supplied hints.

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

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

The critical constraint (DRAFT, never live) is front-loaded, and each subsequent sentence adds a distinct operational fact rather than restating the schema. The pricing sentence is dense and its "in millions with at most one decimal (42900000)" phrasing takes a second read, and the phrase "says what to ask" is slightly clumsy, but no sentence is wasted.

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 13-parameter, nested-object write tool with no output schema, the definition covers the workflow end-to-end: creation, the validate-then-fail behavior, the draft quota, the update path, and the activate_url handoff. Remaining gaps are the sale/rent selection rule and the return payload (draft_id), which an agent must infer from 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?

Schema coverage is only 31% across 13 parameters, so the description must carry weight, and it does for the two most error-prone fields: the price encoding (whole amounts, one decimal million granularity, example 42900000) and the draft_id update path. However, it says nothing about how sale versus rent is chosen, what belongs in facts, or how lat/lng and address interact with the map-pin step, so a meaningful share of the parameter surface stays undocumented.

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?

"Save the seller's listing as a DRAFT — never live" names a specific verb and resource and immediately fixes the scope boundary against any live-posting sibling. The follow-on sentence describing the activate_url handoff makes the tool's role in the workflow 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?

It gives clear conditions for use: create when no draft_id is supplied, pass draft_id to update an existing draft, and stay within the 3-draft cap. It also implies the next step happens outside the tool. What it does not do is name an alternative sibling (e.g. ingatlan_discard_draft for cleanup, or a search/list tool for checking existing drafts), so the routing guidance is contextual rather 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 declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine value beyond that by stating the tool queries live data and by enumerating the returned record fields (code, url, title, address, asking prices, deadline, summary) plus catalogue_url; it stops short of describing pagination costs or result-total 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?

Two tight sentences: the first front-loads what is searched and where, the second lists the return payload. No filler, no repetition of schema details.

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

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

For a 10-parameter search with a nested object and no output schema, the description supplies the crucial missing piece by describing the return shape and the catalogue_url. What is absent is routing guidance relative to ingatlan_get_listing and any note on paging through results, though page/page_size are documented in the schema.

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 90%, so the schema carries nearly all parameter meaning, including the elaborate 'near' object and the 'text' matching rules. The description only reinforces deal type ('for sale or rent') and adds the catalogue_url return, which is baseline-level added 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 gives a specific verb and resource ('Search the live listings of otthon & üzlet'), names the site, and scopes it to Hungarian homes and shops for sale or rent with sealed offers. It clearly reads as a search tool rather than a single-record or draft tool, but it never names a sibling (e.g. ingatlan_get_listing) to contrast against.

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 by 'live listings' and the sale/rent framing, which distinguishes it from the draft-management siblings, but there is no explicit 'use this when' statement, no exclusion, and no named alternative. An agent can infer the case but must read sibling names to be sure.

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