Section 13 notice dates and eligibility for England. Read-only guidance, not legal advice.
Scored across 2 tools
The two tools have clearly separate jobs: one computes dates/timing, the other returns a rules checklist. Both live in the same narrow Section 13 domain and share vocabulary (Form 4A, assured periodic tenancy), so an agent asking a general 'can I raise the rent?' question could plausibly hit either, but the descriptions give enough signal to route correctly.
Both names are snake_case with a clear verb_noun structure (calculate_notice_dates, get_eligibility_requirements). The verbs differ appropriately for the action type (compute vs. retrieve), which is a sensible convention rather than an inconsistency.
Two tools is thin even for a deliberately narrow scope; the server covers only a sliver of the Section 13 workflow. Each tool is substantive rather than trivial, so this is borderline rather than a mismatch.
The surface covers the two most common questions (timing and eligibility), but stops there: no support for validating an existing notice, checking the 12-month frequency rule, or the tenant's tribunal-challenge window. Tool descriptions explicitly disclaim creating or serving notices, which is a legitimate boundary but leaves the lifecycle incomplete.
Calculate the earliest permissible start date for a Section 13 (Form 4A) rent increase for an assured periodic tenancy in England, and the latest date to serve the notice. Use when a UK landlord asks about raising rent, Section 13 notice periods, Form 4A timing, or when a rent increase can take effect. England only; general guidance, not legal advice; does not create or serve a notice.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Country of the tenancy (for example england, scotland, wales). Defaults to england. | |
| tenancy_type | No | Type of tenancy, for example assured_periodic or fixed_term. Defaults to assured_periodic. | |
| rent_due_date | Yes | A date rent is currently due (YYYY-MM-DD), used to anchor the rent period. Any recent or upcoming due date works. | |
| payment_frequency | Yes | How often rent is paid under the tenancy. | |
| tenancy_start_date | Yes | The date the tenancy started (YYYY-MM-DD). | |
| proposed_start_date | No | Optional date the landlord has in mind for the increase (YYYY-MM-DD). | |
| last_rent_increase_date | No | The date the rent last took effect after an increase (YYYY-MM-DD), if it has been increased before. |
| Name | Required | Description |
|---|---|---|
| checks | No | |
| in_scope | Yes | |
| next_step | No | |
| disclaimer | Yes | |
| scope_note | No | |
| explanation | No | |
| notice_period | No | |
| more_information | No | |
| latest_date_to_serve_notice | No | |
| proposed_start_date_assessment | No | |
| earliest_permissible_start_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: jurisdiction restriction to England, that output is guidance rather than legal advice, and critically that it does not create or serve a notice — an important expectation to set for a landlord-facing workflow.
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. The capability statement comes first and the usage/scoping caveats follow, so the agent gets the what before the when-not. Every clause carries 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?
With an output schema present and annotations covering safety, the description does not need to explain return values, and it appropriately spends its words on jurisdiction, disclaimers and non-action. The only shortfall is the unresolved tension between the England-only scope and the country parameter that accepts scotland/wales.
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 including rent_due_date anchoring and the optional proposed_start_date is already documented in structured form. The description adds no additional parameter meaning, so the baseline of 3 applies. It also leaves unaddressed why the country parameter enumerates scotland and wales while the tool is stated as England only.
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 chain: calculating the earliest permissible start date and latest service date for a Section 13 (Form 4A) rent increase for an assured periodic tenancy in England. It is concrete enough that an agent cannot confuse it with the sibling get_eligibility_requirements, and the two outputs it produces are stated up front.
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 explicit triggers (landlord asking about raising rent, Section 13 notice periods, Form 4A timing, when an increase can take effect) plus boundaries (England only, general guidance not legal advice, does not create or serve a notice). The one gap is that it never names or routes to the sibling tool get_eligibility_requirements as an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the eligibility requirements for increasing rent with a Section 13 notice (Form 4A) for an assured periodic tenancy in England. Use when someone asks whether they can use Section 13, what the rules for a rent increase are, or what Form 4A is. England only; general guidance, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| disclaimer | Yes | |
| jurisdiction | Yes | |
| requirements | Yes | |
| more_information | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds genuinely new context the annotations cannot convey: England-only scope and an explicit 'general guidance, not legal advice' caveat, which matters for how an agent frames 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?
Three short sentences, each earning its place: the first names the resource and its scope, the second gives usage triggers, the third bounds jurisdiction and liability. The most decision-relevant content (what it lists) is front-loaded.
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-only lookup with an output schema and rich annotations, nothing an agent needs to select or call it correctly is missing. Return-value structure is left to the output schema, and scope plus the legal-advice caveat are stated.
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 no parameter meaning to convey and the baseline of 4 applies. The description correctly avoids inventing inputs and the empty schema matches the described parameterless lookup.
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 (list eligibility requirements) tied to a named instrument (Section 13 notice, Form 4A), a tenancy type (assured periodic) and a jurisdiction (England). An agent can tell this is a static rules-lookup tool, distinct from the sibling calculate_notice_dates which computes dates.
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 three explicit trigger questions (can I use Section 13, what are the rent-increase rules, what is Form 4A), which is clear when-to-use guidance. It does not explicitly exclude or route to the sibling calculate_notice_dates, so an agent must infer that boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calculate_notice_datesget_eligibility_requirementsUK tenancy and employment rule checks: deposits, notice, rent increases, holiday and minimum wage.
Landlord rules for England by postcode: council licensing, the landlord register and the law, cited.
Free tools for UK tenants: Awaab's Law and complaint deadlines, repair letters, housing help search
Check a home to rent in England: rent, licensing, flood risk, energy rating and the free report.
Add one secure layer between your agents and this server.