Dar — free real-estate tools

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

Annotations already declare readOnlyHint=true and openWorldHint=false, consistent with a pure local calculation, so the description needn't restate safety. It adds real value beyond that by clarifying the VAT base (on the commission, not the property) and by declaring currency-agnostic behavior, which an agent could otherwise get wrong.

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 names the computation first and then the outputs, closed with a short scope note on currency. No filler, no repetition of the title, and 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?

There is no output schema, so the description correctly carries the burden of describing what is returned by naming all four computed values, and it covers the two optional percentage inputs implicitly through the split/agent-share framing. Minor gaps remain around rounding/precision behavior and what happens when optional inputs are omitted, but 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 description coverage is 100% and each parameter already carries its own description, including the VAT example and the '100 if no co-broker' default for share. The description reinforces the conceptual relationship (VAT on commission; split with co-broker office; agent's share) but introduces no new syntax, defaults, or constraints beyond the schema, 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 and resource (computes a broker's commission on a deal) and enumerates exactly what is produced: commission, VAT on the commission, co-broker split, and agent share. None of the siblings (fal_license_check, lease_agreement, property_listing_writer, publish_listing_page) overlap with a pure calculation, so no differentiation is needed.

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 the domain framing — an agent can infer this is for calculating deal commissions — but there is no explicit when-to-use, when-not-to-use, or routing guidance relative to any alternative. No prerequisites or edge-case conditions (e.g. missing co-broker, zero VAT) are 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; 'ready to print' adds a useful hint that the output is a finished document rather than persisted state. However it never says what form the result takes (plain text, Markdown, file), what happens when optional fields are omitted, or whether defaults are applied — notable gaps for a 16-parameter generator.

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 core sentence is front-loaded and economical. The trailing fragment 'A guide template.' is vague filler that spends words without adding actionable information, and the field list is compressed into a single clause.

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, zero-required document generator with no output schema and no per-parameter documentation, the description is far too thin: it does not state that all inputs are optional, which fields are required in practice, or what the returned document looks like. Annotations only cover the read-only/no-network side.

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 only 13%, so the description must carry the burden, and it only glosses landlord, tenant, premises, rent and term plus the language and use enums. Nine parameters (bills, every, notice, deposit, activity, date, months, type, start) receive no meaning from either the schema or the description, leaving an agent to guess at things like whether 'months' is a duration or a count.

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 and artifact ('Writes a ... lease agreement') and scopes it to residential or commercial, Arabic or English. It is clearest of the sibling set, though it does not explicitly contrast itself with property_listing_writer or publish_listing_page.

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 when-to-use guidance, no prerequisites, and no naming of alternatives among the four siblings. The trailing phrase 'A guide template' hints the output is non-binding but does not state when an agent should pick this versus drafting a listing.

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 openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral guarantee — it will not fabricate a feature, number or landmark — but says nothing about output length, tone, or how missing fields (only city is required) are handled in the generated text.

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 grounding constraint is placed where it will be read first. It is efficient, though for a 10-parameter tool the extreme brevity is arguably under-specification rather than conciseness.

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?

Ten parameters with zero schema descriptions and no output schema means the definition should explain what each input contributes and what shape the generated listing takes. Neither is addressed, leaving an agent to guess at the semantics of most fields and the format of the returned copy.

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% across 10 parameters, so the description carries the full explanatory burden. It only incidentally covers 'lang' by listing Arabic, English or French, and gestures at facts broadly; area, beds, baths, price, purpose, type, district and features all go unexplained in both schema and description.

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

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

States a specific verb and resource ('Writes a property listing description') plus the three supported languages, so the agent knows exactly what artifact is produced. It does not differentiate itself from siblings like publish_listing_page, which handles distribution rather than copy generation.

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 or when-not-to-use guidance and no named alternative. The agent must infer that this is the copy-generation step before publishing, rather than being told to use property_listing_writer first and publish_listing_page afterwards.

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 annotations that only say readOnly=false, openWorld=true, idempotent=false, destructive=false: it discloses that no account is needed, that the draft expires in 7 days, that ownership requires opening a trial, and that the run takes about a minute. What it omits is what a repeat call does to an existing draft (regeneration vs. overwrite) and whether calls consume quota, which matters for a non-idempotent generative tool.

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

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

Front-loads the verb and what gets built, then closes with the practical facts an agent needs (returned link, 7-day retention, no account, ~1 minute). Slightly promotional phrasing ('on Dar') and a long opening clause cost it a point, but nearly every sentence carries usable 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 9-parameter generative tool with no output schema, the description still tells the agent what comes back (a viewable link) and how long it lives, which is the critical missing piece. Remaining gaps are secondary behaviors such as repeat-call semantics and what the draft looks like before the owner claims 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 89%, so the schema already explains name, city, kind, lang, from, phone, country, license, and about. The description only restates the core trio ('its name, city and services') and the 'in any language' hint for lang, adding essentially nothing beyond the structured fields. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Designs and writes the complete multi-page website of a real-estate office or property developer') and enumerates the output's scope (home with 3D hero, listings with search, services, about, contact with WhatsApp). This clearly separates it from the sibling real_estate_website_check, which audits rather than generates, and from property_listing_writer, which produces a single listing.

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?

Implies when to use it via the inputs it consumes ('from its name, city and services') and the 'No account' / trial framing, but never states when an agent should not call it or which sibling to prefer instead. There is no explicit alternative or exclusion, so an agent must infer routing from the distinctive output (a full site link).

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 openWorldHint, but the description adds meaningful behavior beyond them: the single-page read scope (no crawling), the 0–100 scoring range, and the exact factors the score is composed of. It does not mention failure modes for unreachable pages or rate/robots constraints, which keeps it below 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?

The scoring verb and scale are front-loaded, followed by a compact factor list and a one-line routing hint — no filler sentences. The factor enumeration is slightly run-on and some terms ("phone screens", "share picture") are terse, but nothing is genuinely wasteful.

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 no output schema, the description carries the needed weight: it explains the score range, the factors evaluated, and the read scope. The only gap is whether the response is a single number or a per-factor breakdown, which an agent might want to know before formatting results.

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 one parameter and 100% schema description coverage, the schema already explains that 'url' is the website address with an example. The description's only added nuance is that this URL should be the single public page to be read, which is a modest clarification rather than new syntax or format guidance.

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 precise verb+resource pair ("Scores a real-estate office's or developer's current website") and states the output scale (0–100), then enumerates the concrete factors scored. This clearly separates it from the sibling real_estate_website_builder, which is named as the complementary action rather than a substitute.

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 operating context ("Reads only the one public page given") and explicitly names the follow-up tool with the condition for pairing it ("Pair it with real_estate_website_builder to show the owner a better site"). It stops short of explicit exclusions — e.g. what to do for login-gated sites or multi-page audits — so it is strong but not fully routable guidance.

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