Heffl Free Tools

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered; the description adds non-derivable context about cost/auth ('Free, no authentication required') and throttling ('Rate limited'). It stops short of quantifying the rate limit or describing the calculation order for overhead and riskBuffer.

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 the core purpose front-loaded and no filler. 'Rate limited' is terse to the point of being uninformative, but nothing is wasted or buried.

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

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

An output schema exists so return values need not be explained, and the tool is a pure read-only calculation with no side effects. What remains missing is the mechanics an agent would need for correct invocation: how the percentage additions compose and what units hourlyCost and hours are in.

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 partially does: it clarifies that 'margin is percentage of selling price' while 'overhead and riskBuffer are percentage additions', which are genuinely non-obvious and mathematically distinct. However, hourlyCost and hours receive no explanation, and the units/order of application of the percentage additions remain ambiguous.

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 ('Calculate') and resource ('project price') plus the input basis (labor, overhead, risk buffer), so the agent knows exactly what the tool produces. It does not, however, differentiate itself from pricing siblings like freelance_rate or photography_pricing, which compute prices from different inputs.

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?

Contains no when-to-use or when-not-to-use guidance and never references the competing pricing siblings in the toolset (freelance_rate, photography_pricing, quotation_generate). 'Free, no authentication required' is an operational fact, not selection 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?

Goes well past the readOnly/idempotent annotations by disclosing UTC-only dates, Monday–Friday scope, holiday exclusion behavior, exact boundary semantics (start included, end excluded, offset excludes start), and operational facts (free, no auth, rate limited). These are precisely the traits an agent needs to avoid off-by-one and holiday errors.

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 sentences, front-loaded with the two modes, then boundary semantics, then operational constraints. Every clause carries information; nothing is boilerplate or repetitive of the 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 an output schema present, return values need not be described, and the description covers the remaining gaps: mode selection, date format expectations, boundary rules, holiday caveats, and auth/rate-limit context. Nothing an agent needs to call this 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 reported at 100%, so the baseline is 3, but the description contributes real semantic value the schema's bare property names do not: it explains includeEnd's inclusive behavior, the offset's exclusive start, and implicitly what businessOnly governs (weekdays). Direction's add/subtract meaning is self-evident from the enum.

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 two concrete operations with clear verbs and resources: count weekdays between two dates, or add/subtract days. An agent can match the task to the tool instantly, and no sibling tool in the list competes for date arithmetic.

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 opening sentence delineates the two supported modes, which is the main selection decision an agent faces, and the schema's oneOf enforces which params each mode needs. It stops short of explicit 'use this instead of X' routing, but no sibling overlaps this domain.

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. The description adds genuinely useful traits beyond them: placeholder substitution for missing fields, draft-only status requiring legal review, no auth, and rate limiting.

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 sentences, each carrying distinct information (output format, placeholder behavior, legal caveat, access, limits), with the core purpose front-loaded. 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?

Output schema exists so return values need no explanation, and defaults make all 11 params optional. Still, with 0% schema coverage the description says nothing about what any parameter means, which is a real gap for a tool with this many 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 burden, yet it explains no parameter meaning. Only the note that 'missing text fields use placeholders' hints at how empty defaults behave, which partially compensates but leaves fee, coachName, dates, and enums 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 and resource ('Generate the website's coaching agreement') plus the output format ('as plain text'). It is distinguishable from retainer_agreement and sow_generate by resource name alone, though no sibling is named 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?

Gives a legal caveat ('Draft only; legal review may be needed') and access facts ('Free, no authentication required. Rate limited'), but never says when to choose this tool over retainer_agreement, sow_generate, or other agreement siblings, nor any prerequisite for use.

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: discloses the side-effect profile ('Sends no email'), the auth situation ('No login or API key required'), and a rate limit. It also defines the result vocabulary ('unknown means inconclusive or mailbox not checked; likely_deliverable is evidence, not a delivery guarantee'), which is exactly the interpretive context an agent needs.

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 sentences, each carrying distinct information: what is checked, no send, DNS limitation, result interpretation, auth, and rate limit. The most important scope statement is front-loaded and nothing is redundant.

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 restated, yet the description still supplies the semantic meaning of key result values. Combined with the side-effect, auth, and rate-limit disclosures, an agent has everything required to call and interpret this 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 only declares a bare string with min/max length. The description compensates slightly by stating it takes 'one email,' implying a single address rather than a list, but adds no format or constraint detail. Adequate but leaves the parameter largely to inference.

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) plus the exact resource (one email) and enumerates the concrete checks performed: syntax, mail routing, disposable/free-provider/role flags, and SMTP recipient acceptance. The scope is unmistakable and no sibling tool overlaps this domain.

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?

Clearly frames the operation as a non-sending verification and warns that 'DNS alone does not verify a mailbox,' which tells the agent what this result does and does not establish. There are no sibling alternatives to route against, so only the absence of explicit when-to-use phrasing 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: free, no authentication required, rate limited, and a currency-consistency constraint. That is real behavioral value, though it omits what the rate-limited threshold is.

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 with the core action front-loaded and no filler. The currency and auth/rate-limit notes are compact and each carries information. Minor waste in 'matching the website,' which is not actionable for the agent.

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, but for a six-parameter computation with zero schema descriptions the description is far too thin. Units and relationships between billableWeeks, billableHours, and hoursPerDay are never resolved, which is exactly the ambiguity the description should remove.

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 6 required numeric parameters, so the description must carry the full explanatory burden. It only clarifies 'margin' (a percentage buffer over income plus overhead) and leaves annualIncome, overhead, billableWeeks, billableHours, and hoursPerDay completely undefined. An agent cannot tell, for example, whether billableHours is per week or per year.

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 verb and resource ('Calculate sustainable rates'), but 'sustainable rates' is vague about what is actually being computed and what domain it applies to. It does not distinguish itself from siblings like agency_pricing or photography_pricing, which likely compute similar rate outputs. An agent must infer the scope from the parameter names.

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 choose this tool over agency_pricing or photography_pricing. It states 'matching the website' and a currency rule, but never explains the scenario this tool fits. Usage must be inferred entirely from the schema.

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 context beyond annotations: free access, no authentication, rate limiting, and that margin is a percentage of selling price with no currency conversion. It does not specify rate-limit thresholds or detailed output behavior, but the annotations and output schema carry much of that burden.

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 description is four short, front-loaded sentences. The purpose is stated first, followed by the key margin and currency semantics, then authentication and rate-limit facts. Every sentence adds actionable information without 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?

Given that an output schema exists and annotations are rich, the description covers the main gaps: what is calculated, how margin works, currency behavior, authentication, and rate limiting. It is largely complete for invocation, though it could better explain the six non-margin parameters; their self-documenting names mitigate this.

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 valuably clarifies the most ambiguous parameter by defining margin as a percentage of selling price and notes that monetary values are currency-neutral. However, it leaves hoursOnSite, hourlyRate, editingHours, editingRate, gearTravelCost, and numPhotos without added semantic explanation, relying entirely on their names and schema ranges.

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 calculation verb and enumerates the exact outputs: session price, costs, profit, and per-photo price. This is clear and agent-readable. It does not explicitly distinguish this tool from sibling pricing tools such as agency_pricing or freelance_rate, so it falls short of 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?

The description gives operational facts (free, no authentication, rate limited) but does not say when to use this tool versus alternatives like agency_pricing or freelance_rate. There is no when-not or alternative-selection guidance, so an agent must infer usage 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 declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavioral facts beyond that: nothing is persisted or dispatched, no authentication is required, the endpoint is rate limited, and currency is treated as an opaque label with no FX conversion.

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 dense sentences with no filler, and the core capability plus calculation model is front-loaded before the boundary and constraint statements. Every sentence carries information, though the constraint list reads slightly as a run of short fragments.

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-value description is rightly omitted, and the calculation and boundary behavior is covered. The gap is input completeness: with five required parameters and zero schema descriptions, the description leaves sender, client, quotationNumber, and the line-item array shape 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 0%, so the description carries the full burden and only partially meets it. It usefully defines discount as a percentage per line item and tax as applied to the already-discounted amount, and clarifies the currency field's semantics, but says nothing about quotationNumber, sender, client, or the lineItems array limits.

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: generate a quotation JSON and plain-text draft, with the calculation model spelled out (per-item percentage discounts, tax on discounted amounts). This clearly separates it from document-oriented siblings like sow_generate or retainer_agreement, though it never names those siblings 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?

The negative boundaries are stated ('does not save, send, or render PDF; website provides visual export'), which tells the agent this is a data-draft generator rather than a delivery pipeline. However, no alternative tool is named for any of those downstream needs, and no prerequisites or when-to-prefer-this-over-siblings guidance is given.

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, yet the description still adds real operational context: plain-text output, placeholder substitution for missing fields, draft-only with legal-review caveat, free/no-auth access, and rate limiting. That is meaningful disclosure beyond the structured 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?

Four short, front-loaded sentences with no filler; the core action leads and constraints follow. Compact for the amount of behavioral context conveyed.

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 format need not be described, and the draft/placeholder caveats are useful. But for a 10-parameter tool with zero schema descriptions, the absence of any parameter guidance leaves an agent guessing about inputs it must supply.

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 must carry the load, and it does not. It only notes that missing text fields become placeholders; it explains nothing about what includedScope, overageRate, providerName, or the enum-backed terms actually control.

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: 'Generate the website's monthly retainer agreement as plain text.' That clearly separates it from sibling document generators like coaching_agreement, sow_generate, or quotation_generate. No explicit sibling routing, but the document type 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?

Usage is implied by the document type and reinforced by 'Draft only; legal review may be needed,' which sets expectations for a generated draft. However, it never states when to pick this over, say, sow_generate, nor any prerequisite or exclusion conditions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds operating context the annotations cannot: free, no authentication required, and rate limited. The rate limit is disclosed but unquantified, and it does not say what happens on limit breach, which keeps this short of 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?

Four short sentences, front-loaded with the core action and formula, then the band cutoffs, the input constraint, and the operational facts. No filler and nothing repeated from the 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?

An output schema exists, so return structure need not be described, and the description nonetheless supplies the scoring bands needed to interpret the result. Only minor gaps remain: batch size ceiling and the specifics/behavior of the rate limit.

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 carries the burden and does so for the critical inputs: likelihood and impact are caller-supplied 1-5 values and are explicitly not inferred. It does not mention the optional 'mitigation' field, the 1-100 item cap, or the 2000-character limits, which are left to the schema.

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+resource ('Score user-supplied risks') and immediately pins down the exact calculation (likelihood x impact on a 1-5 scale) and the resulting bands (low <=6, medium <=14, high >=15). No sibling tool in the set does anything comparable, so no sibling 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?

'Does not infer likelihood or impact' is a real precondition that tells the agent it must extract and supply both values itself rather than pass free text. No alternatives or when-not-to-use conditions are named, but the sibling set is unrelated domains, so there is nothing to route against.

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: it discloses that output is untrusted HTML, that it is not legal advice, that drafts may hallucinate/infer, that server-side provider config is required, that it is free with no auth, and that it is rate limited. These are exactly the operational facts an agent needs and cannot get from readOnlyHint/openWorldHint.

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 tight sentences, front-loaded with the verb and resource, then layered caveats. No filler; each clause carries a distinct operational warning.

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 available, the return value need not be described, and the behavioral caveats are thorough for a single-shot generation call. However the total absence of parameter guidance against a 0% schema coverage leaves the input side under-specified.

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 description says nothing about any of the six parameters, and schema description coverage is 0%, so nothing compensates. Constraints such as the required projectTitle/projectGoals, the 4000-char goal limit, or the 30-item deliverables cap are left entirely to the raw schema.

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 (a scope-of-work draft) and names the underlying service (Heffl DeepSeek). The resource distinguishes it from pricing/agreement/email siblings, but the description never explicitly contrasts it with other generation tools like quotation_generate or whatsapp_generate.

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 no guidance on when to choose this tool over the other generation siblings, nor any preconditions for invoking it. 'Verify before use' is a caution about the output, not a when-to-use rule, so the agent gets no routing help.

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 readOnly, idempotent, non-destructive, closed-world, so the burden is light; the description nonetheless adds operationally relevant context by disclosing 'Free, no authentication required' and 'Rate limited'. Its main gap is not describing the response shape, but that is covered by the output 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?

Three sentences, front-loaded with the computation itself, followed by scope exclusions and then practical notes. Every sentence adds information and none is 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 single-parameter, read-only calculation with both annotations and an output schema present, this is complete: an agent knows the input meaning, the exact rates, the limits of applicability, and the auth/rate-limit situation. Nothing needed to call it correctly is missing.

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

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

With 0% schema description coverage, the description must carry the parameter, and it does define the input as taxable income that is 'already-adjusted' and denominated in AED, which is meaningful disambiguation. It does not mention the 0 floor or the 1e12 ceiling present in the schema, so it stops short of fully compensating.

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

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

Names a specific verb and resource ('Estimate standard UAE corporate tax') and pins the computation down with exact brackets (0% to 375,000, 9% above), so an agent knows precisely what is being calculated. It is clearly distinguishable from the VAT and real-estate VAT siblings even without opening their schemas.

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?

States the input condition explicitly ('on already-adjusted taxable income') and lists what the tool does not cover: deductions, free-zone rules, relief, and multinational minimum tax. That is strong when-not-to-use guidance, though no sibling alternative is named 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 establish the safe-read profile (readOnly, idempotent, non-destructive, closed-world), so the description earns credit for the extra operational context it adds: free, no authentication required, rate limited, and the key modeling assumption of continuous service without unpaid leave. It does not quantify the rate limit or describe the response shape, but the added constraints are genuinely useful.

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?

It is front-loaded with the result type and eligibility, then layers the calculation rule, cap, assumptions, and access notes. Dense but every clause carries information; the long semicolon-joined sentences are the only mild readability cost.

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. The description supplies eligibility, the accrual formula, the 24-month cap, modeling assumptions, and access constraints. What is missing is only peripheral detail such as date-format expectations and what happens for sub-one-year service.

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 parameter burden. It clarifies that the salary input is monthly basic salary (not gross or allowances), which is meaningful disambiguation, and the service-period requirement implicitly maps to startDate/endDate. However, it says nothing about the expected date format or how partial-year service is handled, leaving two of three parameters only loosely 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?

The description names a specific verb and resource (an AED end-of-service gratuity estimate) and pins down the population it applies to: covered private-sector full-time foreign workers. That scope makes it unmistakable against siblings like uae_vat or uae_corporate_tax, which cover entirely different obligations.

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 the qualifying conditions clearly (covered private-sector, full-time, foreign, at least one year of service) and rules out related-but-unsupported cases (no deductions or alternative schemes assessed). It does not, however, name or route to any alternative tool for those excluded cases, so it stops short of explicit when-not/alternatives 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 safety (readOnly, idempotent, non-destructive, closed-world). The description adds operationally useful context beyond them: free, no authentication required, and rate limited. The rate limit is not quantified, 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?

Four short sentences, fully front-loaded: purpose, tax rule, exclusions, then cost/auth/limits. No filler or repetition of schema 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?

An output schema exists, so return values need not be described. The description covers scope exclusions, the key tax rule, auth, and rate limits. Minor gap: it never states the actual VAT rate assumptions being applied (e.g., standard rate vs. zero/exempt outcomes) for a tool whose whole job is a rate-based estimate.

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 bears the param burden. It usefully explains the domain logic behind firstSupply and yearsSinceCompletion (zero-rating only on first supply within three years), but leaves amount, propertyType, and includeVat entirely to the schema. Partial compensation, so baseline 3.

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?

Clear verb (estimate) plus resource (VAT on ordinary UAE commercial/residential property) and currency (AED). It implicitly separates itself from the generic uae_vat sibling via "not transfer fees" and the property-type scope, but never names an actual alternative. Purpose is unambiguous even without explicit 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?

Provides concrete when-not guidance: no transfer fees, no mixed-use, no specialist properties, and the residential zero-rating condition (first supply within three years of completion). It stops short of naming a specific alternative tool to use instead, so it is clear context without explicit 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 readOnly, idempotent, non-destructive and closed-world, and the description adds operational context the annotations cannot carry: free, no authentication required, and rate limited. The rate-limit statement is unquantified, which keeps this short of 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?

Three short sentences, front-loaded with what it computes, then constraints, then access terms. No padding, though "Rate limited" is a bare assertion that could be trimmed or made specific.

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 only two simple scalar parameters and an output schema already defining the return shape, the description covers everything an agent needs: what is computed, the mode, the exclusions, and the access/rate constraints.

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 two parameters, so the description must compensate. "Inclusive or exclusive" does explain the includeVat flag's intent, but the amount parameter's bounds and expected units (AED magnitude, non-negative) are never addressed in prose.

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 ("Estimate standard 5% UAE VAT in AED") plus the key mode (inclusive or exclusive), which is concrete and actionable. It implicitly separates itself from uae_real_estate_vat by emphasizing the standard 5% rate, but never names the sibling, so the differentiation is left 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?

"Does not classify exempt or zero-rated supplies" gives one useful exclusion, which is more than most calculators offer. However, it never routes the agent to an alternative (e.g. uae_real_estate_vat for property scenarios), so the when-to-use guidance is only half present.

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?

With readOnlyHint/destructiveHint already declaring a safe profile, the description still adds genuine context: a no-send guarantee (draft-only), required server-side provider configuration, no authentication, and rate limiting. These are operational facts an agent cannot derive from the annotations. It does not describe return or error behavior, but the output schema covers returns.

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 purpose and followed by distinct operational facts. No filler, though the 'Heffl's DeepSeek service' brand mention is incidental rather than decision-relevant.

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 moderate five-parameter generation tool with an output schema and safe annotations, the description covers the operational essentials (auth, cost, rate limits, no side effects) that an agent needs to invoke it. The remaining gap is parameter-filling guidance, which is unaddressed anywhere.

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 five parameters, so the schema offers no per-field guidance and the description never names or explains any parameter (useCase, businessBio, messageTone, businessName, addEmoji). The words 'business' and 'message' hint at context but add essentially no fill-in semantics for an agent.

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 (business WhatsApp message draft) plus the backing service (Heffl's DeepSeek). The purpose is unambiguous. Sibling tools are all in unrelated domains (pricing, agreements, tax), so no explicit differentiation is needed, but none is provided either.

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 implies the usage context ('business WhatsApp message draft') and clarifies via 'Only drafts text; never sends messages,' which is a useful boundary. However, it gives no explicit when-to-use guidance or named alternatives, so the guidance remains implied rather than stated.

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