Contract Lily

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

Annotations already declare this read-only, idempotent and non-destructive, so the safety profile is covered. The description adds genuine domain context beyond them: which deposit type is capped in each nation (England both, Wales holding only, Scotland and NI tenancy only), which tells the agent what the result will and will not contain. Return shape 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?

A single dense sentence that front-loads the core computation and appends the optional check, followed by the jurisdiction caveat. No filler, and the most important information (what it computes) comes first.

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 read-only, idempotent calculation tool with a full output schema and 100%-documented parameters, this covers scope, jurisdiction coverage and the optional validation path. Slightly more could be said about how non-monthly rent periods (week/four_weeks) are normalised, but the essentials are present.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by clarifying that depositAsked is an optional validation input ('optionally check a deposit the user was asked for') and that the core computation is driven from the rent figure, framing the required-vs-optional distinction in one clause.

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: works out the maximum tenancy and holding deposit from rent, for any UK nation, with an optional check of a deposit already asked for. This is clearly distinguishable from siblings like check_rent_increase_notice or check_notice_period, which cover different regulatory questions.

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 trigger condition clear: computing statutory deposit caps from a rent figure, and optionally validating an amount the user was quoted. It gives clear context but does not explicitly route the agent away from or toward any named sibling, so it stops short of the 5 bar.

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, closed-world behaviour, so the description's job is domain context — and it delivers the calculation rule (5.6 weeks), the statutory cap (28 days), and the important caveat that the figure may include bank holidays. It doesn't mention rounding or that this is the statutory minimum rather than contractual entitlement, which would have pushed it to a 5.

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

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

A single front-loaded sentence that leads with the output ('in days') and packs the jurisdiction, the 5.6-week rule, the 28-day cap and the bank-holiday caveat without a wasted word.

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 both required parameters are fully described in the schema. The description supplies the legal basis and caveats an agent needs to interpret the result correctly, leaving nothing material missing for a two-parameter calculator.

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

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

Schema description coverage is 100% and both parameters are documented (nation as an enum of the four UK nations, daysPerWeek with 0.5–7 bounds). The description echoes 'set number of days a week' and 'any UK nation' but adds no syntax or edge-case guidance beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource: 'Work out the statutory minimum paid holiday a year, in days,' scoped to a worker's days-per-week and UK nation. It is clearly distinct from siblings like check_minimum_wage or check_deposit_cap, though it never names or contrasts them 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?

Usage is only implied by the domain framing ('for a worker who works a set number of days a week'). There is no statement of when to reach for this versus another check, no prerequisites, and no exclusions (e.g. self-employed, part-year workers).

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 the valuable behavioural facts the annotations lack: jurisdiction (UK), the effective date floor, and that it returns the applicable rate alongside the check.

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

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

A single front-loaded sentence that states the check, the inputs that drive it, and the effective date with no filler. The phrasing 'for the worker's age, and apprenticeship, on a date from 1 April 2024' is slightly awkward but not costly.

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 five all-required parameters fully documented in schema, complete annotations, and an output schema covering the return value, the description only needs to supply the non-structural context — which it does (UK scope, 1 April 2024 start, returns applicable rate). What happens for out-of-range dates or unsupported worker categories remains unstated.

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

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

Schema coverage is 100%, so every parameter including the subtle pastSchoolAge flag is already documented, establishing a baseline of 3. The description adds only the date-floor constraint on 'date'; it says nothing about the pastSchoolAge or apprentice enum values that materially change the result.

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 ('Check whether an hourly rate of pay meets the UK minimum wage') and even states the criteria used (age, apprenticeship, date). It does not explicitly distinguish itself from any sibling, but the domain is unambiguous against check_holiday_entitlement or check_deposit_cap.

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 supplies clear applicability context: the check is UK-specific and only valid for a date from 1 April 2024, which is a real precondition an agent must respect. It gives no explicit exclusions (e.g. agricultural wages or salaried staff), so it stops short of full when/when-not 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 declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds value beyond that by declaring the legal scope of the judgment and the explicit limitation on fairness assessment. It stops short of saying what form the result takes, which the output schema covers.

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

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

A single dense sentence, but front-loaded with the object of the check and the jurisdiction, with the rule list following. The parenthetical exclusion is placed where it is most needed. Slightly long for one sentence but every clause carries legal meaning.

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?

Covers jurisdiction, effective-date scope, tenancy type, the conditions evaluated, the exclusion, and the limit of the judgment. With a full-coverage schema and an output schema present, nothing an agent needs in order to select and 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 100%, so the baseline is 3. The description goes further by tying parameters to the rules they feed — 'written' to the in-writing test, 'received'/'starts' to the three-month rule, 'tenancyStart'/'history'/'lastIncrease' to the 12-month rule — giving an agent the reasoning behind each input.

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 the specific verb (check), resource (a landlord's rent increase notice) and jurisdiction (Northern Ireland, private tenancy), and enumerates exactly what is being tested: written form, three-month lead time, and the 12-month spacing rules. This clearly distinguishes it from the England, Scottish and Welsh rent-increase siblings.

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

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

Explicitly scopes applicability: notices given from 1 April 2025, Northern Ireland only, private tenancy, and an explicit exclusion ('do not use it for a controlled tenancy, which has different rules'). It also states a boundary the tool will not answer ('does not judge whether the new rent is fair'), which prevents misrouted calls.

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 that this is a read-only, idempotent, non-destructive operation. The description adds meaningful behavioral context beyond the annotations, including the special cases where a landlord cannot end the tenancy by notice in England or must apply to a tribunal in Scotland. With an output schema present, it does not need to explain return values.

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 two sentences, front-loaded with the core computation and followed by the important jurisdictional exceptions. Every sentence contributes useful scope or behavioral information without repetition.

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 complexity of UK tenancy notice rules, the description clearly frames the tool's scope, parties, nations, and key legal exceptions. The input schema is fully documented and an output schema exists, so the description does not need to restate parameter or return details.

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 all seven parameters are already documented in the input schema. The description does not add further meaning about parameters such as rentDueDay, rentDueDate, or given. A baseline score of 3 is appropriate when the schema carries the parameter documentation.

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

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

The description states a specific verb and resource: it works out the least notice and earliest end date for ending a periodic private tenancy, across UK nations and for either party. It is clear what the tool computes, but it does not explicitly differentiate itself from sibling tools such as check_statutory_notice or check_rent_increase_notice.

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 clear usage context by specifying periodic private tenancies, all UK nations, and both tenant- and landlord-given notice. It also notes important jurisdictional limitations for England and Scotland. However, it does not explicitly say when to use this tool instead of a sibling tool.

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 genuinely non-obvious context: jurisdiction limits, the 1 May 2026 commencement boundary, and the negative scope on rent fairness. It doesn't discuss how 'unknown' history or 'unsure' prescribed form are handled, which is the remaining behavioral gap.

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

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

A single front-loaded sentence naming the resource and scope first, then the outputs, with zero filler. The colon-and-comma construction makes it dense to parse in one pass, which keeps it just short of ideal structure.

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, the description needn't explain returns, and annotations carry the safety profile; what remains is scope and limits, which are covered. The only omission is guidance on how uncertain inputs (history 'unknown', prescribedForm 'unsure') affect the result, which an agent might want before calling.

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

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

Schema description coverage is 100% and all seven parameters, including the three enum-constrained ones, are documented in the schema itself. The description adds no parameter-level meaning beyond what the schema already says, so the baseline 3 applies.

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

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

States a specific verb and resource ("Check a section 13 rent increase notice") and pins the scope precisely: assured periodic tenancy, England, served from 1 May 2026. It also enumerates the three things it evaluates, so an agent knows exactly what answer shape to expect and can distinguish it from the employment/other-tenancy siblings.

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

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

Gives clear applicability conditions (England only, assured periodic tenancy, notices served on or after 1 May 2026) and one explicit exclusion ("does not judge whether the new rent is fair"). It does not name a sibling or alternative tool for the excluded question, so routing for fairness checks is left 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 readOnly/idempotent/non-destructive/non-open-world, so the safety profile is covered; the description adds substantive behavioral boundaries beyond that — the jurisdictional and rent-control-area limits, the three specific legal tests applied, and an explicit statement of what it will not opine on. That is exactly the extra context a calling agent needs to trust and frame the result.

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

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

Front-loaded with purpose, then scope, then outputs, then limits — a sensible order with no filler sentences. It is a single very long semicolon-chained sentence, which is dense but every clause 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?

For a five-parameter read-only checker with an output schema and full annotations, the description supplies everything still needed: scope, the decision rules, the two derived outputs (new rent start date, referral deadline), and the fairness disclaimer. Nothing an agent requires to call it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents all five inputs and their enums. The description nevertheless adds meaning by tying parameters to the legal rules they feed (three months' notice from `received` to `starts`, the 12-month lookback on `history`/`lastIncrease`, the `prescribedForm` test), which helps an agent supply correct values.

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

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

States a specific verb (check), a specific resource (a landlord's rent-increase notice), and narrows scope to private residential tenancies in Scotland outside rent control areas. It then enumerates the exact questions answered, so an agent can tell it apart from check_rent_increase_notice and the other check_* siblings without opening a schema.

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

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

Gives clear applicability conditions ('private residential tenancy in Scotland, outside a rent control area') and an explicit exclusion ('it does not judge whether the new rent is fair'), which is real when-to-use guidance. What it lacks is naming an alternative tool for notices outside that scope, which would be needed for 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 genuine interpretive context beyond that: it computes both employer and employee notice, and warns that the result is a legal minimum a contract may exceed — which affects how the agent should present the answer.

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 sentences, no filler, with the core computation stated first and the contract caveat following. Every clause carries meaning.

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 the three-parameter surface is simple. The remaining gap is selection context: a sibling named 'check_notice_period' sits next to this tool and the description gives no basis for choosing between them.

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%, with 'given', 'nation' and 'started' each documented including date format and an enum for nation. The description restates the same inputs ('start date', 'day notice is given', 'any UK nation') without adding format or edge-case detail, so baseline 3 applies.

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

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

A specific verb ('work out') and resource ('the least notice the law requires to end employment'), with the scope of both directions (employer and employee) stated. However, it never distinguishes itself from the sibling 'check_notice_period', which by name appears to overlap heavily — an agent cannot tell which one to pick.

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 second sentence ('A contract can require more notice, never less') establishes that this returns a statutory floor rather than the actual contractual notice, which is a useful scope boundary. But there is no explicit when-to-use, when-not-to-use, or routing to the similarly named 'check_notice_period' sibling.

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 that this is a read-only, idempotent, non-destructive, closed-world check. The description adds useful domain behavior: it enumerates the three legal checks and states that it does not judge whether the rent is fair, clarifying the tool's limits beyond the safety annotations.

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

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

The description is dense but front-loaded: it leads with the check being performed, then the legal tests, the jurisdictional scope, and the fairness limitation. Every clause contributes useful selection or invocation context.

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 output schema, complete parameter descriptions, and clear annotations, the description supplies enough context for correct selection and invocation. It covers scope, legal checks, and the key limitation that fairness is not assessed.

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 the schema already documents all five parameters thoroughly. The description adds meaningful context by tying those inputs to the substantive legal tests, such as the two-month timing rule and the one-year rule based on prior increase history.

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: checking a landlord's rent-increase notice for a Welsh periodic standard occupation contract. It also names the exact legal checks and the jurisdiction, which distinguishes it from the generic and other UK-jurisdiction rent-increase siblings.

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

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

It clearly limits use to Wales and explicitly excludes fairness of rent from the tool's scope, which gives strong when-to-use and when-not-to-use context. It does not explicitly name sibling alternatives such as check_rent_increase_notice or the Scotland/Northern Ireland variants.

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 destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: nothing is uploaded, and the payload includes availability, nations, report contents, accepted files and price — telling the agent what to expect before calling.

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 sentences, front-loaded with the action and link first, then usage. The list of covered items is dense but each item answers a real pre-call question; nothing is padded.

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?

A zero-parameter, read-only link tool with an output schema, fully covered by the annotations plus a description of the payload's scope. An agent has everything needed to decide and call 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly avoids inventing inputs.

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 ('Get the link to a full Contract Lily review of a UK employment contract, offer letter or written statement') and enumerates what the response covers. The employment-contract scope cleanly separates it from the tenancy-agreement sibling without needing to name 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?

'Use it when the user wants their whole contract checked' gives a clear triggering condition, and 'it doesn't upload anything' pre-empts a likely user concern. There is no explicit when-not or named alternative, but the document-type scoping makes the boundary obvious.

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 behavior: that nothing is uploaded and that the payload reports review availability, supported nations, accepted file types and price. It could mention whether the link is stable or time-limited, but the added context is solid.

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

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

A single sentence with a compact list of covered details, front-loaded with the core action. The clause after the colon is long but each item (availability, nations, contents, files, price) is informative rather than 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 zero-parameter read tool with an output schema, the description supplies purpose, when-to-use and a summary of what comes back, so an agent can call it without further inference. Nothing needed for correct invocation 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?

Zero parameters, which is the baseline-4 case; the description correctly signals a parameterless call by framing it as simply retrieving a link and its metadata. No ambiguity that arguments might be expected.

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

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

Names a specific verb and resource: fetching the Contract Lily review link for a UK tenancy agreement. It also enumerates what the response covers (availability, nations, report contents, accepted files, price). It doesn't explicitly name the sibling get_employment_contract_review_link, though the tenancy scope implicitly separates them.

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

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

"Use it when the user wants their whole agreement checked" gives an explicit trigger condition, and "it doesn't upload anything" sets a clear boundary on what this call does versus an upload/start flow. No alternative tool is named for narrower checks, which keeps it short of a 5.

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