RemedyBridge free tools for tenants

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds useful context beyond that: the answer is a static prepared checklist, it covers both universal and conditional items, and explicitly 'asks for no personal details', which is a meaningful privacy disclosure for a housing-advice tool.

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

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

Front-loaded with the core action and the output structure before the enum glosses, and every sentence carries information. The single dense paragraph with an inline label list is slightly hard to scan, which keeps it below a 5.

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 optional enum parameters and no output schema, the description does the necessary work of explaining what the checklist contains and that it is personalized by landlord and problems. It stops short of describing format or length of the result, but nothing critical to invoking 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 baseline is 3, but the description goes further by glossing the enum values ('damp' = damp or mould, 'leak' = leaks or water ingress, 'structural' = structural or plaster) and by explaining that 'landlord' selects which landlord-specific case items are returned. That mapping between input value and output branch is real added meaning.

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 ('Lists the evidence worth gathering about disrepair in a rented home') and spells out the output shape: common items, then per-problem items, then per-landlord items. That is clearly distinguishable from siblings that compute deadlines (calculate_landlord_complaint_deadlines, check_awaabs_law_deadlines) or supply letters (get_repair_letter_template).

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 when this applies – you have a landlord type and a set of problems and want an evidence list – but never states when to prefer it over siblings like search_housing_repair_help or get_repair_letter_template, and gives no exclusions or prerequisites. Usage is inferable rather than guided.

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, non-destructive, idempotent calculation, and the description adds meaningful behavior: working-day counting, exclusion of weekends and English/Welsh bank holidays, next-working-day treatment for weekend or bank-holiday receipt, and stage-specific acknowledgement/response periods. It does not describe the exact return shape or how any extension is represented, but it is substantially more informative than the annotations alone.

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

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

The description is front-loaded with the core purpose and then adds the legal timing rules, working-day logic, applicability limits, and outcome boundary. It is dense but largely earns its length, though the single long paragraph and statutory paragraph citations could be tightened for easier scanning.

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 calculator, the definition covers the relevant statutory stages, working-day conventions, applicability exclusions, and how optional dates are used. Since there is no output schema, it could say more about the returned fields or compliance status, but it gives enough context to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema already explains the landlord, stage, receivedOn, acknowledgedOn, respondedOn, and asAt parameters in detail. The description reinforces the stage distinction and the optional acknowledgement/response dates, but it does not add parameter syntax or constraints beyond what the schema provides. Baseline 3 is appropriate.

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 gives a specific verb and resource: it works out when a council or housing association in England must acknowledge and answer a tenant complaint under the Housing Ombudsman Complaint Handling Code. The subject matter is distinct from the sibling tools, which concern repairs, pre-action protocol, evidence, letters, and searches, so an agent can identify the right tool without ambiguity.

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 explains the relevant context (council or housing association complaints in England at stage 1 or stage 2) and notes when the Code does not usually apply, such as private landlords and Wales. It does not explicitly compare itself with the sibling deadline calculators, so the when-to-use guidance is strong but not fully comparative.

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 substantial non-obvious behavior: deemed receipt two days after the letter date, working-day counting that excludes weekends and England/Wales bank holidays, and that long stops can be varied by agreement. It only gestures at the return shape ('each next date and whether each step was on time') rather than describing it, which with no output schema 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?

Front-loaded with the purpose, then the step sequence, then usage advice and jurisdiction caveats. The long enumeration of statutory paragraphs (6.2, 7.2(a), 7.4(a), 7.4(b) and (d), 6.3) is dense and mostly citation detail an agent does not need in order to call the tool, which costs a point.

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

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

For a one-required-parameter, deterministic date calculator with no output schema, the description supplies everything needed: the governing rules, the working-day/bank-holiday convention, the incremental-date usage model, and the England versus Wales distinction. Nothing essential to 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?

Schema coverage is 100%, so baseline is 3, but the description adds derivation semantics beyond the schema: the letter date is treated as received two days after its date, and each subsequent deadline is measured from the prior supplied date. That meaningfully expands what the parameters imply.

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

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

States a specific verb and resource: computes the Pre-Action Protocol for Housing Conditions Claims (England) timetable. It is clearly distinguished from siblings like check_awaabs_law_deadlines and calculate_landlord_complaint_deadlines by naming the exact protocol, jurisdiction, and the sequence of steps it derives.

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 practical usage guidance: 'Give the later dates as they happen to see each next date and whether each step was on time,' which tells the agent to supply replyDate/inspectionDate/reportReceivedDate progressively. It also notes the Wales variant has its own protocol. It does not explicitly name an alternative sibling and when to prefer it, so it stops 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.

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

Annotations only declare the safe-read profile (readOnlyHint, idempotent, closed-world); the description goes well beyond by disclosing the working-day computation rule (day after discovery, excluding weekends and England & Wales bank holidays), the 24-hour emergency rule, the Phase 2 source of truth, and the interpretive limit that a missed date is a 'dated failure, not an entitlement'.

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

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

Front-loaded with the core action and scope, and every sentence carries substantive information. Slightly long — the full statutory citation parenthesis and the explicit exclusion list partially restate what the landlord enum already encodes.

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 still tells the agent what comes back (each deadline date plus whether it has passed, plus the 24-hour rule and Phase 2 position) and what the tool will not adjudicate. Nothing needed to invoke or interpret 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 already 100%, so the baseline is 3; the description earns an extra point by clarifying the pivotal counting convention behind awareOn ('from the day after the landlord found out') and the passed/not-passed output logic, which the schema's field descriptions do not spell out.

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 concrete verb and resource — it works out the Awaab's Law deadlines a council or housing association in England has for investigating damp/mould, providing a written summary, and completing work. The statutory anchor (SI 2025/1042) and named output dates distinguish it clearly from siblings like calculate_landlord_complaint_deadlines and calculate_pre_action_protocol_timetable.

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 states the negative case — private landlords, Wales, shared ownership and long leases are out of scope — and bounds the tool's judgement ('does not decide whether a hazard is significant'). It stops short of naming a sibling to use instead when the answer is out of scope, so it is a strong 4 rather than 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/closed-world, so the bar is met; the description adds real context beyond them: the output contains [bracketed] gaps the agent must fill, it never accepts or embeds tenant details, and the letters assert facts and promise no outcome. It does not say what is returned when the tenure/landlord/country combination disqualifies awaabs-law, leaving that edge behavior implicit.

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

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

Front-loads the core action and the variant list, then closes with the two operational constraints (bracketed gaps, eligibility). Some repetition — the Awaab's Law eligibility is restated across sentences, and 'states facts and make a request' partly re-says 'promise no outcome' — but no sentence is wasted overall.

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 template fetcher with an all-enum schema and rich annotations, the description covers the output shape (text with bracketed gaps) and the main precondition. The one real gap is fallback behavior when the eligibility condition for awaabs-law is not met, which an agent may need to know to react correctly.

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

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

Schema coverage is 100% and each parameter carries its own enum docstring, so the baseline is 3; the description adds interpretive value by tying template choices to factual scenarios and by stating the tenure/Awaab's Law dependency ('only a tenancy gets the Awaab's Law letter'), which explains the interaction between the template and tenure parameters. Country and landlord semantics are largely 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 specific verb and resource (returns the text of a tenant-to-landlord repair letter) and enumerates the four named template variants with the situation each serves. An agent can tell this is a static text-retrieval tool, distinct from the deadline/checklist calculators among its siblings, 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?

Explicitly maps each template value to a situation: first-report for reporting in writing the first time, chaser when a report went unanswered, complaint for a formal complaint, awaabs-law for a hazard under Awaab's Law. It also states the eligibility gate for awaabs-law (council/housing association tenant in England with a tenancy). It gives no verbal routing to the sibling tools (e.g. deadline calculators) and no explicit 'when not to use', so it stops just 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.

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered. The description adds genuine context beyond them: it discloses exactly what corpus is searched (quick answer and Q&A of every guide, plus a 54-term glossary) and what comes back (each answer with the link to its page), which helps the agent judge result quality.

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

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

The purpose is front-loaded and the usage sentence is crisp, but the middle is one very long run-on enumeration of topic areas. Much of that list earns its place for retrieval matching, yet it reads as undifferentiated padding rather than scannable 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?

For a one-parameter read-only search tool with full schema coverage, this is nearly complete: domain scope, corpus searched, return format (answers plus page links), and a clear exclusion are all present. It stops short of describing behavior when nothing matches, which is the only remaining gap an agent might care about.

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 single query parameter is already well documented with examples in the schema. The description only lightly reinforces this by implying free-text questions and terms, adding little beyond what the schema states, 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?

The description names a specific activity (answering tenants' repair questions from RemedyBridge's published guides) and enumerates the exact subject matter covered — section 11, Awaab's Law, HHSRS, the Housing Ombudsman, pre-action protocol — so an agent can bound the tool's knowledge domain precisely. It never names a sibling tool, but the enumerated scope implicitly separates it from the deadline calculators and letter template tools, which is slightly weaker than explicit differentiation.

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 for 'what is', 'who is responsible', 'how long' and 'what can I do' questions" gives clear positive selection criteria, and "It does not assess anyone's situation" draws a useful boundary. What's missing is routing to alternatives: it never says to use calculate_landlord_complaint_deadlines or check_awaabs_law_deadlines for date arithmetic, even though those siblings cover topics this tool also mentions.

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