Heffl Free Tools

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, but the description adds genuinely new behavioral facts: it is free, requires no authentication, and is rate limited. The formula semantics (margin as a percentage of selling price versus overhead/riskBuffer as additive percentages) also clarify behavior beyond the numeric bounds in schema.

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?

Four short sentences, front-loaded with the core purpose followed by the semantic clarifications and then the operational facts. No filler, no repetition of schema or annotation 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?

With an output schema present there is no need to describe return values, and annotations carry the safety profile. The description covers formula basis, auth requirements and rate limiting, which is nearly everything an agent needs before calling; only the sibling routing question remains open.

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 the description must compensate, and it does for the ambiguous parameters: it clarifies that margin is a percentage of selling price while overhead and riskBuffer are percentage additions, which the schema's bare min/max bounds cannot express. hours and hourlyCost are left unstated, but their meaning is self-evident from the names and the pricing formula.

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 ('Calculate project price from labor, overhead and risk buffer') with the formula inputs named, so an agent knows exactly what it does. It does not, however, distinguish itself from the pricing-like siblings (freelance_rate, photography_pricing, quotation_generate), leaving that differentiation to inference.

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, when-not-to-use, or alternative-naming guidance. The description never says whether this supersedes freelance_rate or how it relates to quotation_generate; an agent must guess based on the name alone.

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 establish read-only, idempotent, non-destructive, closed-world behavior; the description goes further with UTC-only dates, Monday–Friday definition of a weekday, boundary semantics (start included, end excluded unless includeEnd; offset excludes start), the important caveat that public holidays are NOT excluded, and operational facts (free, no auth, rate limited). That is substantial context beyond the structured fields.

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 core capability front-loaded and boundary caveats packed in; no filler and nothing repeated from 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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. The description supplies the ambiguity-prone rules (UTC, weekday definition, boundary inclusion, holiday exclusion) an agent needs to call and interpret 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 baseline is 3, but the description adds real semantics the schema cannot express: what includeEnd actually changes at the boundary and that the offset count excludes the start date. It does not clarify direction/businessOnly beyond the enum, so it stops short of 5.

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 specific verbs (count, add, subtract) on a specific resource (weekdays/dates) and names both operating modes, so an agent knows exactly what it does. Sibling tools are unrelated (pricing, agreements, VAT), so no differentiation is required.

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 two modes imply when each applies (counting a span vs. shifting a single date), but there is no explicit 'use this when...' guidance or exclusion language. Since no sibling tool overlaps in function, the inference cost is low, keeping this at minimum-viable.

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 readOnly, idempotent, and closed-world behavior, so the bar is lower. The description nonetheless adds real behavioral detail: missing fields become placeholders, output is plain text, no auth is required, and the endpoint is rate limited. These are genuine value-adds an agent can act on.

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 the core purpose and then terse, high-density sentences about placeholders, legal status, auth, and rate limiting. No sentence wanders, though the final fragments are cryptic rather than explanatory.

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 draft/legal, placeholder, auth, and rate-limit notes cover operational concerns. But for an 11-parameter tool with zero schema descriptions, the definition leaves an agent without guidance on the majority of inputs.

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 11 parameters, so the description carries the full burden, yet it only says missing text fields use placeholders. It never explains the three enum parameters (paymentTerms, sessionFormat, cancellationPolicy), the integer sessionLength bounds, or what fee/dates mean, so the parameter semantics gap is largely unfilled.

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 (Generate) and resource (website's coaching agreement) plus the output format (plain text). This clearly distinguishes it from siblings like retainer_agreement and sow_generate, though it does not explicitly call out the alternative it complements.

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 line 'Draft only; legal review may be needed' gives a caveat about intended use, which is useful context. However, it never names when to pick this over the sibling retainer_agreement or other agreement generators, leaving the choice 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?

Goes well beyond the annotations by disclosing that no email is sent, that no login or API key is required, and that the endpoint is rate limited. These are exactly the operational facts an agent needs for an SMTP-probing tool, and none of them are derivable from readOnlyHint/openWorldHint alone.

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 purpose is front-loaded in the first sentence, followed by compact, discrete clauses covering side effects, interpretation caveats, auth, and limits. Every sentence carries information, though the result-interpretation caveats are slightly dense for the space.

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 structure needn't be explained, yet the description proactively clarifies the ambiguous result states ('unknown means inconclusive or mailbox not checked', 'likely_deliverable is evidence, not a delivery guarantee'). Combined with the side-effect, auth, and rate-limit notes, an agent has everything needed to call and interpret this 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 0%, but the single parameter is a self-explanatory 'email' string, and the description confirms the scope is exactly one address ('one email's...'). It adds no format or syntax guidance beyond the name, so the low-coverage baseline is not clearly exceeded.

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 (check) and resource (one email) and enumerates exactly what is tested: syntax, mail routing, disposable/free-provider/role flags, and SMTP recipient acceptance. An agent knows precisely what this tool returns information about, and no sibling tool overlaps with it.

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 the intended use implied (verify one email's deliverability signals) and warns against a common misuse ('DNS alone does not verify a mailbox'), but it never states when to reach for this tool versus not using it, and there is no alternative named. Adequate but leaves usage conditions 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 declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful non-obvious traits on top: no authentication required, rate limiting, a currency-consistency constraint across all money inputs, and how margin is applied. It stops short of describing the returned rate structure, but the output schema covers that.

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?

Four short sentences, front-loaded with the core purpose and immediately followed by the margin definition, which is the least obvious input. 'Matching the website' is filler that does not help an agent, but overall there is very little waste.

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 output schema means return values need not be explained, and the safety profile is carried by annotations. However, for a tool requiring six bare numeric parameters at 0% schema coverage, the description leaves most inputs semantically undefined, which is the main completeness gap.

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 six required parameters, so the description carries the full documentation burden and only discharges part of it. It explains margin's meaning and the shared-currency requirement for money fields, but annualIncome, overhead, billableWeeks, billableHours, and hoursPerDay are left without units or meaning, and the agent must infer that billableHours is per-week from the max of 168.

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+resource ('Calculate sustainable rates') and the margin semantics tie it to a pricing calculation, matching the title's 'Freelance hourly and day rates'. It does not, however, distinguish itself from sibling pricing tools like agency_pricing or photography_pricing, so the agent must infer the freelance context from the name/title alone.

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 choose this tool over agency_pricing, photography_pricing, or the other pricing siblings, nor any stated prerequisites or exclusions. The 'Free, no authentication required' line is an access note, not usage 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 cover the read-only, idempotent, non-destructive profile, and the description adds genuinely new behavioral context: margin is a percentage of selling price, the calculation is currency-neutral with no conversion, no auth is needed, and the endpoint is rate limited. The rate-limit and auth disclosure is exactly the kind of extra context annotations cannot convey.

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 core action and outputs before the calculation rule and operational notes. Every clause adds information with no repetition 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?

An output schema exists, so return values need not be explained, and the description covers the key semantic rule (margin basis), currency behavior, and access/rate constraints. The main residual gap is unit/format guidance for the six undocumented numeric inputs.

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 7 required parameters, so the description carries the full burden, but it only pins down one field's semantics: margin is a percentage of selling price. The remaining six (hoursOnSite, hourlyRate, editingHours, editingRate, gearTravelCost, numPhotos) rely on self-explanatory names with no stated units or format, leaving partial compensation.

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 precise verb (Calculate) and enumerates the four concrete outputs: session price, costs, profit, per-photo price. It is unambiguous what the tool produces, though it does not explicitly differentiate itself from pricing-adjacent siblings like agency_pricing or freelance_rate.

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 no when-to-use guidance and never names an alternative tool. Statements like 'Free, no authentication required' describe operational properties rather than selection criteria, so the agent must infer that a photography-session quote is the right 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 the safe, idempotent, read-only profile, so the bar is lower. The description still adds real context beyond them: no persistence or sending, no PDF rendering, currency treated as a label with no FX conversion, no auth, and a rate limit. It stops short of quantifying the rate limit or describing edge-case 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?

Front-loaded with the core action, then a sequence of short declarative clauses that each deliver a distinct fact (output formats, non-persistence, currency handling, auth, rate limit). Every sentence earns its place; only the slightly clipped fragment style costs a point.

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 needn't be explained. For a stateless read-only generator the description covers what it produces, what it deliberately does not do, currency semantics, and access constraints, which is sufficient for an agent to 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?

Schema coverage is 0%, so the description must carry parameter meaning. It explains that discounts are percentages applied per item and tax is computed on discounted amounts, and that currency is a non-converting label, which clarifies three of the five fields. quotationNumber, sender, and client receive no interpretation at all, leaving part of the gap unfilled.

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 (Generate) and resource (quotation JSON and plain-text draft) with concrete output formats. It does not differentiate itself from the closest sibling (sow_generate or the other *_generate document tools), so an agent must infer the quotation-vs-SOW distinction from the name alone.

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 negative guidance ('Does not save, send, or render PDF; website provides visual export') and operational gating ('Free, no authentication required. Rate limited'), which implies when the tool is usable. However it never names an alternative tool or an explicit condition for choosing this over a sibling generator.

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 read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuinely useful operational context the annotations do not carry: missing text fields fall back to placeholders, output is a draft requiring legal review, and there are no auth requirements but rate limiting applies.

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?

Four short, front-loaded sentences with no filler: purpose first, then placeholder behavior, legal caveat, and access/rate-limit facts. 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?

An output schema exists so return values need not be described, and annotations cover the safety profile. The description supplies placeholder behavior, legal-review caveat, auth, and rate-limit info, which is close to complete; only the parameter semantics gap keeps it from a 5.

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 10 parameters and 0% schema description coverage, the description must carry the burden, but it only vaguely gestures at fields via "Missing text fields use placeholders." None of the enums (paymentDue, contractTerm, noticePeriod) or the specific fields like monthlyFee and includedScope are explained, so an agent gets little semantic guidance beyond the schema's own names and defaults.

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 (generate), a specific resource (the website's monthly retainer agreement), and the output format (plain text). It is clearly distinguishable from the other agreement/pricing siblings, though it does not explicitly name an alternative to contrast with.

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 a caveat ("Draft only; legal review may be needed") but no statement of when to choose this over siblings like coaching_agreement or sow_generate, and no prerequisites or exclusions. The agent must infer the use case from the name alone.

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 establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds genuinely useful operational context beyond that: it is free, requires no authentication, and is rate limited, which an agent needs for retry/batching decisions.

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?

Four short, front-loaded statements with no filler: purpose/algorithm first, then thresholds, then the inference constraint, then cost/auth. 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?

An output schema exists, so return formatting need not be described. Scoring semantics, thresholds, the no-inference constraint, and cost/auth/rate-limit facts are all present. Only batch-size and field-level handling of the risks payload are unaddressed, a minor gap for a one-parameter 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?

Schema description coverage is 0%, so the schema alone does not explain the 1–5 likelihood/impact scale or its meaning. The description supplies the scale semantics and the threshold bands, partially compensating. However, it says nothing about the risks array shape, the optional mitigation field, or the 100-item limit, leaving the single parameter's structure unexplained.

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 (Score) and resource (user-supplied risks) plus the exact algorithm (likelihood × impact on a 1–5 scale). No sibling tool does anything similar, so it is unambiguously identifiable.

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 clause 'Does not infer likelihood or impact' is an effective boundary condition: it tells the agent the caller must supply both values rather than expecting the tool to derive them. It stops short of naming alternatives or explicit when-not-to-use conditions, but no sibling competes for this task.

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, openWorldHint, non-idempotent, non-destructive), the description discloses that output is untrusted HTML, that it is not legal advice, that drafts may hallucinate details requiring verification, that provider configuration is needed server-side, and that the endpoint is free but rate limited. These are exactly the behavioral traits 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?

Six short, front-loaded sentences with no filler: purpose first, then output trust warning, then inference caveat, then operational constraints. 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 generator with an output schema and rich annotations, the description covers trust, safety, and operational constraints well. The one gap is the total absence of parameter guidance for a 0%-coverage schema, which the agent needs to populate six fields 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 0% across six parameters (projectTitle, projectGoals, timeline, clientName, deliverables, serviceCategory), and the description mentions none of them. With zero schema documentation, the description carries the full burden and adds nothing about required fields, lengths, or formats.

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: 'Generate a scope-of-work draft.' That is clearly distinct from sibling generators like quotation_generate or retainer_agreement. It stops short of naming any sibling or contrasting scope, so it earns a 4 rather than a 5.

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 lists operational conditions ('Free, no authentication required. Rate limited.') but never says when an agent should choose this tool over quotation_generate, agency_pricing, or risk_assessment. There is no when-to-use or when-not-to-use guidance; the agent must infer applicability from the tool name alone.

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 read-only, idempotent, non-destructive, and closed-world behavior. The description adds genuinely new operational context: it is free, requires no authentication, and is rate limited — the latter being a real invocation constraint not visible in the schema.

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 rate structure and input definition come first, exclusions and operational facts follow. 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 fully covers input semantics, rate logic, exclusions, auth, and rate limits for a single-parameter estimation 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?

Schema description coverage is 0%, so the description must carry the burden, and it does clarify that the input is taxable income in AED that must already be adjusted, plus the bracket thresholds that give the value meaning. It omits the schema's numeric bounds and units edge cases, but the core semantics are covered.

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 (Estimate) and resource (UAE corporate tax) and even encodes the rate structure (0% up to 375000, 9% above), making it unmistakable against sibling tax tools like uae_vat and uae_real_estate_vat.

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?

Explicitly bounds scope with 'already-adjusted taxable income' and enumerates what it does NOT handle (deductions, free-zone rules, relief, multinational minimum tax), which is strong when-not guidance. It stops short of naming an alternative tool for those excluded cases.

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. The description adds valuable behavioral context beyond annotations: eligibility scope (private-sector, full-time, foreign workers), assumptions (continuous service, no unpaid leave, no deductions), calculation method, cap, and free/rate-limited status. Missing details like authentication specifics are covered by 'no authentication required'.

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 core purpose and calculation method, then eligibility and assumptions, then operational details. Every sentence is packed with useful information and no waste.

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?

Given the tool's complexity (UAE labor law specifics), the description is quite complete: it covers eligibility, calculation rules, caps, assumptions, and operational parameters (free, no auth, rate limited). With an output schema present, it need not explain return values. Minor gap: doesn't clarify date semantics or salary currency assumptions beyond 'AED'.

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% – the schema has no parameter descriptions. The description mentions 'monthly basic salary' for basicSalary and implies date range from startDate/endDate through service duration, but doesn't explain date formats or how dates are used. Baseline 3 because schema structure is simple and the description adds some context, but it doesn't fully compensate for the coverage 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?

States a specific verb+resource: 'AED estimate for UAE end-of-service gratuity' with clear scope. Distinguishes from siblings like uae_vat, uae_corporate_tax, uae_real_estate_vat by focusing on gratuity. An agent can immediately identify this tool's unique function.

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?

Description implies usage through eligibility criteria ('covered private-sector full-time foreign workers', 'at least one year service') but provides no explicit when-to-use guidance or alternatives. It doesn't say when NOT to use this tool or what sibling might be better. Implied context only.

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 the description adds exactly the context the rubric rewards: 'Free, no authentication required. Rate limited.' It also discloses the substantive zero-rating rule the calculation applies, so the agent knows the behavioral bounds of the estimate.

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?

Four telegraphic sentences, front-loaded with the core purpose before the caveats and operational notes. Dense and mostly waste-free, though the clipped phrasing ('FIRST supply', 'Rate limited') assumes some domain familiarity.

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 described. The description covers scope, exclusions, the key domain rule, and operational constraints (free, no auth, rate limited), leaving only minor parameter documentation gaps against a 0%-coverage 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 0% across 5 parameters, so the description carries the full documentation burden. It explains the semantics behind firstSupply and yearsSinceCompletion ('zero-rating requires FIRST supply within three years of completion') and the propertyType split, but says nothing about amount or the includeVat toggle and its default.

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?

Specific verb (Estimate) plus resource (VAT on ordinary commercial/residential property in AED), with an explicit boundary against transfer fees and against sibling uae_vat's broader scope. The exclusion of mixed-use/specialist properties further sharpens what this tool does and does not cover.

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 clear when-to-use conditions (ordinary commercial or residential property) and when-not conditions (transfer fees, mixed-use, specialist properties). It stops short of naming the sibling tool to use instead (e.g. uae_vat) for the excluded cases, which keeps it from 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?

The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful behavioral context beyond annotations: free, no authentication required, rate limited, and the inclusive/exclusive handling. It does not quantify the rate limit, but the added access and constraint information is meaningful.

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?

Four short sentences, front-loaded with the core estimate behavior and followed by exclusions and operational constraints. Every sentence adds useful information, and there is 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?

For a simple two-parameter calculation tool with rich annotations and an output schema, the description is complete enough. It covers purpose, scope exclusions, currency, access requirements, and rate limiting; return-value details are appropriately left to the output 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 0%, so the description must compensate. It clarifies the includeVat concept as 'inclusive or exclusive' and establishes AED as the currency, but it does not document the amount parameter's required status, allowed range, or includeVat's default of false. It partially compensates but leaves gaps.

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 (Estimate), resource (standard 5% UAE VAT in AED), and scope (inclusive or exclusive). It also distinguishes itself from broader tax tools by explicitly excluding exempt and zero-rated supplies, so an agent can tell what this tool is for without opening the 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?

It gives a clear condition for use: standard 5% UAE VAT estimates, inclusive or exclusive. It also gives an explicit when-not condition by saying it does not classify exempt or zero-rated supplies. However, it does not name any alternative sibling tool for those excluded cases.

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=true, destructive=false, openWorld=true, so the safety profile is covered. The description earns credit for adding non-obvious operational context: the tool never sends messages, requires server-side provider configuration, is free and unauthenticated, and is rate limited — auth and rate-limit details are exactly what annotations cannot convey.

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?

Five short, front-loaded sentences with no filler; the most decision-relevant constraint (drafts only, never sends) appears immediately. 'Provider configuration required server-side' is slightly cryptic but still 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?

An output schema exists, so return values need no explanation, and the description covers safety, auth, cost, rate limits, and the non-sending guarantee. The one meaningful gap is that no parameter semantics are conveyed despite 0% schema coverage.

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 description mentions no parameters at all — nothing about useCase, businessBio, businessName, messageTone, or addEmoji. With five undocumented parameters and no schema descriptions, the description fails to compensate for the coverage 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?

States a specific verb ('Generate'), resource ('business WhatsApp message draft'), and names the underlying provider. The 'Only drafts text; never sends messages' clause pins down exactly what the tool does and does not produce, making it unmistakable against the unrelated sibling set.

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 strong scope boundaries (draft only, never sends) and operating conditions (free, no auth, rate limited), but never states when to reach for this tool versus an alternative or what a caller must supply to get a good result. Usage is implied by the drafting scope rather than explicitly guided.

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