SiteCheck Jobs & Property

US homes for sale from Estately for a city: per listing

realestate_estately

Read-only

US homes for sale from Estately (regional MLS data) for a city: per listing the address, ZIP, county, coordinates, list price, beds, baths, living area and lot size (sq ft), property type, status, annual tax, MLS and listing number, listing office and phone, next open house, photo count, main photo, time on Estately and link, plus the total listings in the city. Filter by type, price range and minimum bedrooms; up to 200 listings per page. Related tools on this server, for a different need: realestate_seloger when you need SeLoger homes for sale or rent in a town: listing id; realestate_zoocasa when you need Zoocasa homes for sale in a city: MLS number, address. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

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": {
      "state": "<state>",
      "city": "<city>"
    },
    "name": "realestate_estately"
  }
}

Input Schema

Name	Required	Description
`city`	Yes	City name, e.g. Austin
`page`	No	Result page of 200 listings, 1 to 25 (default 1)
`type`	No	house, condo, townhouse, land, multi_family … (filters this page)
`limit`	No	Listings returned, 1 to 200 (default 50)
`state`	Yes	Two-letter US state code, e.g. TX
`minBeds`	No	Minimum bedrooms (filters this page)
`maxPrice`	No	Maximum list price in USD (filters this page)
`minPrice`	No	Minimum list price in USD (filters this page)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4/5.0

Behavior4/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description adds a genuine operational detail that changes agent behavior: $0.002 USDC per successful call via x402, with failed calls not charged. It also discloses the 200-listings-per-page cap and that the response includes the city-wide total, though it omits result-ordering or rate-limit behavior.

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?

Purpose and routing are front-loaded well, but roughly half the text is a ~20-item enumeration of returned fields. Since an output schema exists, that catalogue is largely redundant with structured data and crowds out the far more actionable pricing and filtering sentences.

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 paid, read-only listing tool with a full output schema, the description covers source, geography, filters, page cap, cost model and sibling routing. The remaining gap is the per-page filtering subtlety (filters apply within the returned page, not the whole city) which is disclosed only in the schema, not the description.

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 schema already documents all eight parameters with examples and defaults. The description only echoes the filter set (type, price range, minimum bedrooms) and the page size, adding no format or constraint detail — notably it drops the schema's "filters this page" caveat, so it does not compensate with meaning beyond what the schema provides.

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?

"US homes for sale from Estately (regional MLS data) for a city" states a specific verb, resource, data source and geographic scope. The related-tools sentence explicitly separates it from realestate_seloger (France) and realestate_zoocasa (Canada), so an agent can pick this one for US city-level for-sale listings without opening a schema.

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 names two sibling tools and the condition that routes to them ("for a different need"), plus the supported filters and page size. It does not state exclusions for this tool itself — e.g. that rentals are out of scope and belong to a rentals tool — so the routing is clear but not complete.

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

All SiteCheck Jobs & Property 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?