US rental listings for AI assistants: free live search and rent statistics, plus licensed feeds.
Scored across 5 tools
feed_status vs feed_changes are clearly distinct (current version metadata vs specific adds/changes/removals), and rent_summary is aggregate stats versus listing results. The two search tools (search_my_feed and search_rentals_sample) share the same verb and purpose, distinguished only by key requirement and result caps, so they could be momentarily confused, but the descriptions make the access-tier difference explicit.
Four of five tools follow a consistent snake_case pattern (feed_changes, feed_status, search_my_feed, search_rentals_sample). rent_summary breaks the verb_noun convention by leading with a noun, but the overall style remains readable and predictable.
Five tools is slightly lean but well-scoped for a read-only rental feed API: feed metadata, feed deltas, feed search, public rent stats, and public sample search. Nothing is redundant, though a bit more (e.g. listing detail lookup) could be added without bloat.
The surface covers feed lifecycle visibility (status + changes), authenticated and unauthenticated search with pagination, and market statistics, which is solid for a consumption-only data API. A minor gap is the absence of a single-listing detail endpoint by ID and any way to export/retrieve the full licensed dataset beyond paged searches.
Requires a HousingFeed key. Listings added, changed or removed in the latest weekly update of your feed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Changes to return (default 20). | |
| since | No | Changes since this earlier version (one of feed_status's changes_from) instead of since the previous week; for a client that missed a week. | |
| change | No | Only this kind of change. | |
| offset | No | Skip this many changes (for paging). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description's one genuine addition is the credential requirement (HousingFeed key), which the annotations do not convey; return format and pagination are left unaddressed.
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 short sentences with no filler or redundancy. It leads with the credential prerequisite rather than the tool's purpose, which is mildly backward for selection scanning, but nothing is wasted.
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 parameter-light read tool with no output schema, the description plus rich param docs cover what an agent needs. The auth requirement is called out, and no critical invocation detail appears missing.
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 all four parameters (limit, since, change, offset) are already documented with defaults, bounds and enum values. The description adds no syntax or format detail beyond the schema, which is the expected baseline.
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 outcome: listings added, changed or removed in the latest weekly feed update. The 'weekly update' framing implicitly separates it from search_my_feed's arbitrary-query behavior, though it never names that sibling outright.
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?
The prerequisite ('Requires a HousingFeed key') is stated, which is real guidance, and the 'since' parameter text points at feed_status's changes_from for the missed-week case. However, there is no explicit statement of when to prefer this over search_my_feed or feed_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Requires a HousingFeed key. The current version of your licensed feed: listing count, when it was published, when the next weekly update is due, and how many listings were added, changed and removed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds the meaningful operational constraint that a HousingFeed key is required, plus a preview of exactly which metrics are returned, which the annotations do not convey.
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 wasted words, with the key requirement front-loaded before the enumeration of returned data. The trailing list is dense but each item is informative rather than filler.
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 no parameters and no output schema, the description carries the return-value burden itself and does so by naming the four data points returned. What an agent needs to call this zero-arg read tool is present; only explicit sibling routing is missing.
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 nothing for the description to disambiguate; baseline 4 applies. The description correctly focuses on return content instead of inventing parameter semantics.
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 resource ('your licensed feed') and enumerates exactly what the tool returns: listing count, publish date, next update due, and added/changed/removed counts. It is clearly distinguishable from rental-search siblings by scope, though it never names an alternative tool to sharpen the boundary.
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?
The prerequisite ('requires a HousingFeed key') and the phrase 'your licensed feed' imply this is for querying the caller's own feed rather than sample data, but there is no explicit when-to-use/when-not guidance or reference to feed_changes or search_my_feed as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What rent costs right now in one US city or ZIP, no key needed: number of listings and the median, 25th and 75th percentile monthly asking rent, overall and by bedroom count (studio, 1, 2, 3, 4+). Based on listings verified at the source in the last 30 days. Give a state and a city or a ZIP.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | Exact 5-digit ZIP code; use instead of or with city. | |
| beds | No | Only this bedroom count: 0 = studio, 4 = four or more. | |
| city | No | Full city name, e.g. Austin or New York (New York includes its five boroughs). Not a partial match. | |
| state | Yes | Two-letter US state code, e.g. TX. | |
| include_rooms | No | true = include rooms in shared homes (excluded by default). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world and non-destructive, so safety is covered. The description adds genuinely non-obvious context: no key needed, data freshness ('listings verified at the source in the last 30 days'), and that shared-home rooms are excluded by default — all beyond what the structured fields say.
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 dense sentences with zero filler: the metric list and geographic scope come first, freshness second, and the required input form last. Every clause carries information an agent needs.
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 no output schema, the description correctly enumerates the return shape (counts plus median/25th/75th percentiles, overall and per bedroom count) and covers input requirements, coverage, and freshness. Nothing essential for a correct call is missing, and the annotations carry the safety profile.
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 all five parameters are already documented, including beds encoding and the include_rooms default. The description only restates the bedroom dimensions and the state+city/ZIP combination rule, adding no format or syntax detail beyond the schema.
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 ('what rent costs right now'), the exact geography (one US city or ZIP), and enumerates the returned statistics (listing count, median/25th/75th percentile, overall and by bedroom count). An agent can distinguish it from search_rentals_sample without opening either schema.
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?
The description gives input guidance ('Give a state and a city or a ZIP') and notes no API key is required, which implies a drop-in lookup. However, it never says when to use this versus the sibling search_rentals_sample, nor what the caller should do when they lack a city/ZIP — usage is implied rather than routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Requires a HousingFeed key. Search the listings in your licensed feed by city, ZIP, rent, bedrooms or map box. Returns up to 50 per call with a total; page with offset.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | Exact ZIP code. | |
| city | No | City name, partial match. | |
| full | No | true = every field of each listing, including description and photos. | |
| limit | No | Listings to return (default 10). | |
| state | No | Two-letter US state code. | |
| offset | No | Skip this many matches (for paging). | |
| max_lat | No | North edge of a map box. | |
| max_lng | No | East edge of a map box. | |
| min_lat | No | South edge of a map box. | |
| min_lng | No | West edge of a map box. | |
| max_beds | No | Maximum bedrooms. Same as min_beds for exactly N. | |
| max_rent | No | Maximum monthly rent in USD. | |
| min_beds | No | Minimum bedrooms; 0 = studio. | |
| min_rent | No | Minimum monthly rent in USD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value with the auth requirement and the 50-per-page cap with offset paging and a total. It stops short of describing output shape or edge-case behavior, so a 3 fits.
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 dense sentences, front-loaded with the auth requirement, then the capability, then the paging contract. No filler.
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 14-param read-only list tool with no output schema, the description covers the key operational facts: auth, filter dimensions, page size cap, total, and paging. It could say more about result shape or the 'full' flag's cost, but the essentials are present.
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 coverage is 100% and every parameter is documented in the schema. The description only restates the filter categories and the limit/paging mechanism, adding little beyond what the schema already provides. Baseline 3 is appropriate.
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 ('Search the listings in your licensed feed') and enumerates the filterable dimensions. It is distinguishable from siblings like feed_changes and rent_summary, though it doesn't explicitly name how it differs from search_rentals_sample.
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?
Mentions the HousingFeed key requirement, which is a useful precondition. However, it never says when to prefer this over search_rentals_sample or how the two differ, leaving the main sibling-selection decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live US rental listings for an area and budget, no key needed. Returns at most 10 listings per call (rent, beds, baths, size, address, coordinates, photo, source link, days listed). Use a state code and a city for one market; add rent and bedroom limits to narrow it. For complete results a HousingFeed key is needed.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name, partial match, e.g. Brooklyn. | |
| sort | No | best (default): photo and coordinates first, freshest, mixed sources. | |
| state | No | Two-letter US state code, e.g. NY. | |
| max_lat | No | North edge of a map box. | |
| max_lng | No | East edge of a map box. | |
| min_lat | No | South edge of a map box. | |
| min_lng | No | West edge of a map box. | |
| max_beds | No | Maximum bedrooms. Same as min_beds for exactly N. | |
| max_rent | No | Maximum monthly rent in USD. | |
| min_beds | No | Minimum bedrooms; 0 = studio. | |
| min_rent | No | Minimum monthly rent in USD. | |
| new_since_days | No | Only listings first seen in the last N days (new listings land weekly, Sunday to Tuesday UTC). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful traits beyond that: a hard cap of 10 listings per call, the exact fields returned, and the data-freshness cadence ('new listings land weekly, Sunday to Tuesday UTC'). That is close to rate-limit context, though it says nothing about authentication behavior for the keyed path.
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 sentences, front-loaded with the value proposition and the free-tier caveat, then the return shape, then the narrowing advice. No sentence is filler; the key-needed note earns its place by signaling the upgrade path.
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 no output schema, the description correctly enumerates returned fields and the max-result cap, and it explains the main parameter combinations for a 12-parameter tool. It omits any mention of pagination limits or how geo-box coordinates interact with city/state, minor gaps given 0 required parameters.
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 the geo box corners and bed/rent bounds) is already documented in the schema; baseline is 3. The description reinforces how city/state and rent/bed limits combine but adds no syntax or format detail beyond the schema.
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+resource ('Live US rental listings') and scopes it ('for an area and budget, no key needed'), which separates it from the keyed sibling search_my_feed by implication. It never names the sibling outright, so the agent must infer that search_my_feed is the full-coverage alternative.
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 concrete usage guidance: 'Use a state code and a city for one market; add rent and bedroom limits to narrow it,' and flags that a HousingFeed key is required for complete results. It does not explicitly say when to prefer this over search_my_feed or rent_summary, so the routing decision is left partly to inference.
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.
feed_changes1 field changedInput schema / properties / sinceAdded value: +{
+ "description": "Changes since this earlier version (one of feed_status's changes_from) instead of since the previous week; for a client that missed a week.",
+ "type": "string"
+}feed_changesfeed_statusrent_summarysearch_my_feedsearch_rentals_sampleCurrent US rental market data for AI agents: 1,500+ submarkets, monthly rent + vacancy + trends.
US real estate market data for AI agents: prices, yields, forecasts and scores for 894 markets.
U.S. real-estate data: property records, AVM value + rent estimates, sale/rental listings.
AI-native real estate discovery with structured property search and market intelligence.
Add one secure layer between your agents and this server.
