Close Knit

Check area rent

check_area_rent

Read-onlyIdempotent

Rent prices in an area by bedrooms or home type (ONS Price Index of Private Rents, borough-wide): the average, London's, the trend and 24 months, rights on a rise (gov.uk), a page link. With current_rent: against the average; with current_since: indexedRent and a verdict on proposed_rent; levers, talking points, and links.report (the page with the tenant's figures, to send the landlord). Never one home's market rent.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "postcode": "<postcode>"
    },
    "name": "check_area_rent"
  }
}

Input Schema

Name	Required	Description	Default
`bedrooms`	No	[input value] 0 reads the 1-bed figures.
`postcode`	Yes	[input value] Full postcode in England.
`comparables`	No	[input value] Listings the tenant found.
`rent_period`	No	[option] Period of the rents.	month
`current_rent`	No	[input value] The tenant's rent; omit for the area only.
`current_since`	No	[input value] YYYY-MM the rent started or last rose.
`property_type`	No	[input value] Used only without bedrooms.
`proposed_rent`	No	[input value] Landlord's proposal.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 13, 2026

TDQS

A3.6/5.0

Behavior4/5

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), so the bar is lower, and the description nonetheless adds real behavioral detail: a 24-month trend, a London comparison, gov.uk rights context, an indexedRent value, a verdict on proposed_rent, and a links.report page explicitly framed as 'the page with the tenant's figures, to send the landlord.' That goes well beyond what the annotations disclose.

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

Conciseness3/5

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

It is compact and front-loads the resource, but it is one dense run-on sentence with verbless fragments ('the average, London's, the trend and 24 months, rights on a rise (gov.uk), a page link') that force re-reading. Nothing is obviously padding, yet the structure costs parseability.

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 an 8-parameter tool with an output schema, the description covers the core resource, the conditional output modes, and the report artifact an agent can hand back. The omission of how comparables are used is the main gap, but the presence of an output schema means return-value detail need not be restated.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3, and the description earns that by explaining what current_rent and current_since trigger and tying proposed_rent to the verdict. However, the comparables array (up to 5 tenant-found listings) is never mentioned, and the mode logic is stated cryptically rather than as clear parameter guidance, so it adds only moderate meaning on top of a fully documented schema.

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?

The description names the resource precisely (area-level rent prices by bedrooms or home type, sourced from the ONS Price Index of Private Rents, borough-wide) and closes with a scoping exclusion, 'Never one home's market rent,' that separates it from listing-level siblings like assess_listing. The telegraphic phrasing ('rights on a rise (gov.uk), a page link') blunts the opening a little, but an agent can still tell what the tool returns.

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

Usage Guidelines3/5

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

Conditional guidance is present in the form of 'With current_rent: against the average; with current_since: indexedRent and a verdict on proposed_rent,' which tells the agent what each mode unlocks. It also states a when-not ('Never one home's market rent') but never names the sibling tool an agent should use for a single home, so the routing is implied rather than explicit.

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

All Close Knit tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.