MyPorta

Search homes

search_homes

Read-onlyIdempotent

Use this when the user wants to find homes for sale or to rent in the UK. Give a place (town, area or postcode) and any budget, bedrooms or type they mention. Put what they want from the home or area in their own words in wishes (for example "a garden", "walk to a station", "good primary schools nearby", "within 45 minutes of King's Cross"); homes are then ranked by fit, each with a 0-100 match score and the evidence behind it (station and school distances, advertised features). Put a physical feature they insist on and an advert would state ("garage", "annexe") in must_haves; anything about lifestyle or the area ("near the sea", "wild swimming", "good schools") always goes in wishes. Returns up to 10 homes with price, bedrooms, agent and a link, and for each home what is nearby: the nearest primary and secondary schools with their Ofsted grade, station, park, GP surgery, supermarket and broadband.

Input Schema

TableJSON Schema

Name	Required	Description
`sort`	No
`limit`	No	Default 6.
`place`	Yes	One UK place: a town, city, district, county, region, national park, National Landscape, named coast, island or postcode, e.g. "Harrogate", "Dorset", "the Lake District", "the South West", "the south coast", "Jersey", "LS6". Each is searched as one whole area. "near Totnes" takes in about 3 miles around it.
`wishes`	No	What the user wants, in their words. Homes are ranked by how well they match.
`max_beds`	No
`min_beds`	No
`max_price`	No	Pounds. For rent, per calendar month.
`min_price`	No	Pounds. For rent, per calendar month.
`must_haves`	No	A physical feature the advert must state word for word, e.g. "garage". Never lifestyle or area wishes: those go in wishes.
`buy_or_rent`	No	Default buy.
`property_type`	No

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No
`homes`	Yes
`place`	No
`towns`	No	For a coast or national park: the towns searched, each with its search on MyPorta.
`more_url`	No	The same search on MyPorta, with every result.
`place_found`	No	False when MyPorta did not recognise the place; no homes are returned then.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already establish this as a safe, idempotent read (readOnlyHint, idempotentHint, destructiveHint false), so the bar is lower. The description goes further by disclosing the ranking behavior (homes ranked by fit with a 0-100 match score and supporting evidence) and the result cap of 10 homes with price, bedrooms, agent and link.

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

Conciseness4/5

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

Front-loaded with the when-to-use condition and the key parameter guidance; every sentence carries operational content rather than filler. It is dense and somewhat long, with the returning-amenities enumeration being the least essential part given an output schema exists.

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

Completeness5/5

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

For an 11-parameter, open-ended search with an output schema already describing results, the description supplies everything an agent needs: trigger condition, geographic granularity of `place`, the wishes/must_haves distinction, and the ranking/scoring model. Nothing material is left ambiguous.

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 64%, and the description meaningfully compensates by drawing the tricky wishes vs must_haves boundary with concrete examples ('garage' vs 'near the sea', 'good schools'), which is the most error-prone parameter decision here. It adds little on sort, limit, property_type or the bed/price ranges, which the schema covers.

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

Purpose5/5

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

The opening sentence states a specific verb and resource ('find homes for sale or to rent in the UK'), including the geographic scope. It is immediately distinguishable from siblings like compare_homes, get_home and get_area_guide, which handle comparison, single-listing retrieval and area narrative respectively.

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?

It clearly states the triggering condition ('when the user wants to find homes for sale or to rent') and instructs the agent on what to pass along (place, budget, bedrooms, type). It does not explicitly name when to prefer compare_homes or get_home instead, so the routing vs alternatives is implied rather than spelled out.

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

All MyPorta 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.

Resources

Need Help?