Skip to main content
Glama

Plan a rental's year

plan_rental
Read-onlyIdempotent

Use when a landlord in England asks what is due for a rented home and when, or wants a plan or calendar for it. Give the postcode and whatever the landlord knows: every other argument is optional. Returns each duty with its status, date, plain explanation and cited rules for the next 12 months, the questions still worth asking (as argument names), and links to an interactive plan and a calendar file. Statuses rely on the landlord's own answers, not documents. Read-only. Nothing is stored. Information, not legal advice.

Input Schema

NameRequiredDescriptionDefault
has_gasNoWhether the home has any gas appliance, such as a boiler, hob or gas fire
lettingNonow: tenants live there; next: a tenancy is starting, or the home is being got ready to let
postcodeYesFull postcode of the rented property, not the landlord's own, e.g. SW9 7AA
furnishedNoWhether the landlord supplies any furniture
householdNosingle: one household; small_hmo: 3-4 people from 2+ households; large_hmo: 5+ people from 2+ households. Defaults to single.
epc_expiryNoThe date the EPC expires, as YYYY-MM-DD
epc_ratingNoThe EPC's current energy rating, A to G
licence_endNoThe date the council licence ends, as YYYY-MM-DD
rent_periodNoHow often the rent is due
deposit_takenNoWhether a tenancy deposit was (or will be) taken
holds_licenceNoWhether the landlord holds the kind of council licence the address needs for this household (the plan's licence question names it); only matters where one is needed
tenancy_startNoThe current tenancy's start (letting now) or the next tenancy's planned start (letting next), as YYYY-MM-DD
last_gas_checkNoThe date of the last gas safety check, from the gas safety record, as YYYY-MM-DD
deposit_receivedNoThe date the deposit was received, often before the tenancy starts, as YYYY-MM-DD
last_rent_increaseNoThe date the last rent increase took effect, if there was one during this tenancy, as YYYY-MM-DD
right_to_rent_checkedNoWhether every adult's right to rent was checked before the tenancy was agreed
alarms_tested_at_startNoWhether the smoke and carbon monoxide alarms were tested on the day the tenancy started
tenancy_document_givenNoTenancies from before 1 May 2026: whether the government information sheet (or written terms, for an oral tenancy) was given by 31 May 2026. Later tenancies: whether the written statement of terms was given before the tenancy was agreed. late: given, but after that
deposit_protected_in_timeNoWhether the deposit was protected and the prescribed information given within 30 days of receiving it
last_electrical_inspectionNoThe inspection date on the last electrical installation condition report (EICR), as YYYY-MM-DD
next_electrical_inspectionNoThe next inspection date the last EICR sets, which can be sooner than 5 years, as YYYY-MM-DD

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive and open-world. The description adds real substance: statuses depend on the landlord's own answers rather than documents, nothing is stored, and the output is information rather than legal advice. It also discloses the return shape, which the annotations cannot.

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

Conciseness5/5

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

Front-loaded with the trigger condition, then argument guidance, then the return payload, then caveats. Every sentence carries distinct information, and the long return sentence is dense rather than padded.

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

Completeness4/5

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

For a 21-parameter tool with no output schema, the description does the essential work: it summarises the return payload, warns that statuses rest on self-reported answers, and tells the agent how to handle partial knowledge. Minor gaps remain around failure modes, such as an unrecognised postcode or a plan the tool cannot produce.

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

Parameters4/5

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 meaning: only the postcode is required and every other argument is best-effort knowledge the landlord happens to have. The note that unanswered questions are returned as argument names ties the output back to the input schema, which helps the agent reason about filling a 21-parameter tool.

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

Purpose4/5

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

Names a specific verb and resource: producing a 12-month plan/calendar of duties for a rented home in England, including each duty's status, date and cited rules. That clearly separates it from rule-lookup siblings like get_rule and search_rules, 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.

Usage Guidelines4/5

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

"Use when a landlord in England asks what is due for a rented home and when, or wants a plan or calendar for it" gives a concrete trigger and jurisdiction. It also says to supply the postcode plus whatever the landlord knows, since all other arguments are optional. It stops short of stating exclusions or naming alternatives such as get_rule or council_licensing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources