Landlord Lookout: Making Tax Digital

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

Annotations already establish a safe, read-only, idempotent, closed-world call, so the bar is lower. The description adds genuine behavioral context beyond them: the statutory basis, the threshold rules driving the result, and what is returned (start date, reasons, GOV.UK sources, matching Landlord Lookout page).

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 core purpose before the input requirements. The second sentence is dense but every clause (income types, per-year figures, share of jointly owned property) carries real instruction, with 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 single read-only check with no output schema, the description covers the eligibility logic, required inputs, and the shape of the response (start date, reasons, sources, link). 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?

Schema description coverage is 100% and the per-year fields already spell out the £50k/£30k/£20k thresholds and dates, so the schema does the heavy lifting. The description restates the qualifying-income definition and adds only the mild instruction to include each tax year 'you know', 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 precise verb and resource ('Says whether a UK sole trader or landlord must use Making Tax Digital for Income Tax, from when, and why') and anchors it to a legal test (SI 2026/336). It is clearly distinguishable from the software- and deadline-oriented 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?

The description tells the agent exactly what to supply ('Give the person's income types and, for each tax year you know, their qualifying income') and how to compute qualifying income, which is clear usage context. It does not explicitly state when to prefer this over get_mtd_deadlines or find_mtd_software, but those siblings cover plainly different questions.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-derivable behavior: results are ranked by fit and explicitly unsponsored ('no product pays for its place'), and it discloses the per-product payload (price, why it fits, watch-outs, HMRC listing, vendor site, Landlord Lookout link). Minor gap: no mention of pagination beyond the limit cap.

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 purpose and ordering, then filters, then the return payload. Dense but every clause carries information; the long filter enumeration is slightly list-like but matches the ten-parameter surface it must cover.

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 ten optional parameters, no output schema and a non-obvious ranking behavior, the description supplies the missing pieces: fit ordering, sponsor-neutrality, and the shape of each returned product record. Nothing an agent needs in order to call and interpret this tool is absent.

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 every parameter is already documented at a high standard, including enum semantics for records and other_income. The description largely restates the same filter list and adds no syntax or edge-case detail beyond the schema (it does echo the bridging-software nuance, but that is already in the schema). 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?

Opens with a specific verb and resource ('Lists software from HMRC's list of Making Tax Digital for Income Tax software') plus the ordering rule ('in fit order'), which cleanly separates it from the sibling get_mtd_software_product (single product) and check_mtd. An agent knows exactly what comes back and in what order 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?

The description enumerates the filters that drive selection (income types, records, free plan, properties, filing, VAT, Welsh, platforms), which implies the conditions under which the tool is the right pick. However, it never names an alternative tool or states when NOT to use it (e.g. when a specific product is already known, use get_mtd_software_product), leaving routing 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 destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the result set is anchored to today, it bundles penalty rules and a calendar feed alongside the date list, and start_year narrows the view rather than replacing the default output — useful for a read-only tool with no 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?

The primary payload is front-loaded in the first sentence, with the start_year conditional placed last where it belongs. It is a dense enumeration, but every clause names a distinct return component, so the length is largely earned.

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

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

With no output schema, the description carries the burden of describing returns and does so concretely (next quarterly update plus period, next SA return and payment date, upcoming list, penalty rules, calendar feed). Combined with annotations covering the read-only profile and a fully documented schema, an agent has enough to call it correctly; only the count/pagination interaction and date-relative framing are left implicit.

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 both parameters (count with its 1–12 bounds and default 6, start_year with its three-value enum) are fully documented in the schema. The description restates start_year's filtering effect but adds no detail the schema lacks, and never mentions count. 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 resource and enumerates exactly what comes back: the next quarterly update with its covered period, the next Self Assessment return and payment date, the upcoming list, current penalty rules, and a calendar feed. That content profile is clearly distinct from check_mtd or the software-lookup siblings, though it never names an alternative explicitly, which keeps it just 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 only guidance is conditional on a parameter: 'Give start_year to see only the dates for people who start MTD that year.' There is no statement of when to reach for this tool versus its siblings, and no exclusions or prerequisites (e.g. that it is date-relative to today). Usage is implied by the tool's nature rather than described.

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), so the bar is lower. The description still adds real behavior: the fuzzy-match fallback ('if several products match, returns their names to choose from'), which an agent needs to handle the response correctly.

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 resource and its field coverage. The long field list earns its place because there is no output schema, though it reads as a run-on enumeration rather than being structured.

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

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

With no output schema, the description compensates by enumerating the returned fields (price, free plan, income types, year-end filing, VAT, Welsh, platforms, HMRC listing, vendor site, link). Combined with the multi-match behavior, an agent has everything needed 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 100% for the single 'name' parameter, including examples, so the schema does the heavy lifting and the baseline is 3. The description adds only the soft hint that matching may be non-exact via the multi-match 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 specific verb (look up facts about one product) and resource (HMRC MTD for Income Tax software list), and the field enumeration makes the scope concrete. It implicitly separates itself from find_mtd_software via 'by name' and 'one product', but never names the sibling or states the distinction 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 implied: you already have a product or vendor name and want that one product's details. There is no explicit when-to-use/when-not, and no pointer to find_mtd_software for the discovery case, which is the natural alternative.

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