Skip to main content
Glama
BACH-AI-Tools

Zillow56 MCP Server

by BACH-AI-Tools
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Zillow56 MCP Server

English | 简体中文 | 繁體中文

🚀 使用 EMCP 平台快速体验

EMCP 是一个强大的 MCP 服务器管理平台，让您无需手动配置即可快速使用各种 MCP 服务器！

快速开始：

  1. 🌐 访问 EMCP 平台

  2. 📝 注册并登录账号

  3. 🎯 进入 MCP 广场，浏览所有可用的 MCP 服务器

  4. 🔍 搜索或找到本服务器（bach-zillow56）

  5. 🎉 点击 "安装 MCP" 按钮

  6. ✅ 完成！即可在您的应用中使用

EMCP 平台优势：

  • ✨ 零配置：无需手动编辑配置文件

  • 🎨 可视化管理：图形界面轻松管理所有 MCP 服务器

  • 🔐 安全可靠：统一管理 API 密钥和认证信息

  • 🚀 一键安装：MCP 广场提供丰富的服务器选择

  • 📊 使用统计：实时查看服务调用情况

立即访问 EMCP 平台 开始您的 MCP 之旅！

Related MCP server: Zillow MCP Server

简介

这是一个 MCP 服务器，用于访问 Zillow56 API。

  • PyPI 包名: bach-zillow56

  • 版本: 2.0.0

  • 传输协议: stdio

安装

从 PyPI 安装:

pip install bach-zillow56

从源码安装:

pip install -e .

运行

方式 1: 使用 uvx（推荐，无需安装）

# 运行（uvx 会自动安装并运行）
uvx --from bach-zillow56 bach_zillow56

# 或指定版本
uvx --from bach-zillow56@latest bach_zillow56

方式 2: 直接运行（开发模式）

python server.py

方式 3: 安装后作为命令运行

# 安装
pip install bach-zillow56

# 运行（命令名使用下划线）
bach_zillow56

配置

API 认证

此 API 需要认证。请设置环境变量:

export API_KEY="your_api_key_here"

环境变量

变量名

说明

必需

API_KEY

API 密钥

是

PORT

不适用

否

HOST

不适用

否

在 Claude Desktop 中使用

编辑 Claude Desktop 配置文件 claude_desktop_config.json:

{
  "mcpServers": {
    "zillow56": {
      "command": "uvx",
      "args": ["--from", "bach-zillow56", "bach_zillow56"],
      "env": {
        "API_KEY": "your_api_key_here"
      }
    }
  }
}

注意: 请将 E:\path\to\zillow56\server.py 替换为实际的服务器文件路径。

可用工具

此服务器提供以下工具:

search_polygon_search_for_properties_by_polygon

Search for filtered properties by polygon coordinates. For a list of properties, you can select the output format (JSON , CSV , XLSX) using the optional \

端点: GET /search_polygon

参数:

  • polygon (string) 必需: It is required if the location is empty. Format: lat lng,lat1 lng1,lat2 lng2 34.03959576441558 -118.50636536779786,34.0418716916327 -118.50276047888184,34.042440663894304 -118.49846894445801,34.04201393505594 -118.49417741003418,34.04087598099002 -118.4897142142334,34.03945351693672 -118.48525101843262,34.03788877892429 -118.48095948400879,34.03618175908096 -118.47683961096192,34.034190192514366 -118.47271973791504,34.031629538228394 -118.46962983312989,34.02835747861639 -118.4677415579834,34.02

  • page (string): Example value:

  • output (string): Output format possible values : json (Default value) :Data in a JSON format csv : URL to the generated CSV file xlsx : URL to the generated XLSX (excel) file

  • status (string): Status type of the properties Default : forSale -forSale -forRent -recentlySold

  • sortSelection (string): Sorting possible values : days: Newest (Default value), saved: Date Saved, listingstatus: Listing Status, mostrecentchange: Most Recent Change, globalrelevanceex: Homes for You, featured: Verified Source, priced: Price (High to Low), pricea: Price (Low to High), paymentd: Payment (High to Low), paymenta: Payment (Low to High), beds: Bedrooms, baths: Bathrooms, size: Square Feet, lot: Lot Size, zest: Zestimate (High to Low), zesta: Zestimate (Low to High),

  • listing_type (string): Listing Type possible values : by_agent : By agent (Default value) by_owner_other : By owner & other (for off market properties)

  • isSingleFamily (string): Example value:

  • isMultiFamily (string): Example value:

  • isApartment (string): Example value:

  • isCondo (string): Example value:

  • isManufactured (string): Example value:

  • isTownhouse (string): Example value:

  • isLotLand (string): Example value:

  • doz (string): Days on Zillow (For Sale/Rent listings)/ Sold In Last (Sold listings) Possible values : any: Any, 1: 1 day, 7: 7 days, 14: 14 days, 30: 30 days, 90: 90 days, 6m: 6 months, 12m: 12 months, 24m: 24 months, 36m: 36 months

  • price_min (string): Example value:

  • price_max (string): Example value:

  • sqft_min (string): Example value:

  • sqft_max (string): Example value:

  • monthlyPayment_min (string): Example value:

  • monthlyPayment_max (string): Example value:

  • beds_min (string): Example value:

  • beds_max (string): Example value:

  • baths_min (string): Example value:

  • baths_max (string): Example value:

  • hoa_min (string): Example value:

  • hoa_max (string): Example value:

  • hasPool (string): Example value:

  • hasGarage (string): Example value:

  • built_min (string): Example value:

  • built_max (string): Example value:

  • isForSaleByOwner (string): Example value:

  • isForSaleByAgent (string): Example value:

  • isCityView (string): Example value:

  • isWaterfront (string): Example value:

  • isPublicSchool (string): Example value:

  • isPrivateSchool (string): Example value:

  • isMountainView (string): Example value:

  • singleStory (string): Example value:

  • onlyPriceReduction (string): Example value:

  • onlyRentalAcceptsApplications (string): Example value:

  • isZillowOwnedOnly (string): Example value:

  • hasAirConditioning (string): Example value:

  • isMiddleSchool (string): Example value:

  • isWaterView (string): Example value:

  • onlyRentalIncomeRestricted (string): Example value:

  • isComingSoon (string): Example value:

  • isForSaleForeclosure (string): Example value:

  • onlyWithPhotos (string): Example value:

  • onlyRentalCatsAllowed (string): Example value:

  • onlyRentalPetsAllowed (string): Example value:

  • onlyRentalSmallDogsAllowed (string): Example value:

  • onlyRentalLargeDogsAllowed (string): Example value:

  • isAuction (string): Example value:

  • is3dHome (string): Example value:

  • isNewConstruction (string): Example value:

  • parkingSpots_min (string): Example value:

  • greatSchoolsRating_min (string): Example value:

  • isElementarySchool (string): Example value:

  • isParkView (string): Example value:

  • enableSchools (string): Example value:

  • lotSize_max (string): in sqft

  • keywords (string): Example value:

market_data_rental_market_trends

Get market rental data of a location by city or ZIP

端点: GET /market_data

参数:

  • location (string) 必需: Example value: houston, tx

market_sale_overview

This endpoint delivers a comprehensive snapshot and historical trends of the housing market in a given region using metrics aligned with the Zillow Home Value Index (ZHVI) framework

端点: GET /market_sale_overview

参数:

  • location (string): Example value: houston,tx

zhvi_range

This endpoint provides monthly historical data for the Zillow Home Value Index (ZHVI) for a specified region. The ZHVI is a proprietary metric that captures median home values across a wide variety of geographies and housing types, reflecting trends in the real estate market over time.

端点: GET /zhvi_range

参数:

  • location (string) 必需: Example value: 11771

  • type (string): Home type

search_search_for_properties_by_neighborhood_city_or_zip_code

Search for filtered properties by neighborhood, city, or ZIP code. PS : To search for an address of a property, use the \

端点: GET /search

参数:

  • location (string) 必需: Location can be an address, neighborhood, city, or ZIP code.

  • page (string): Example value:

  • output (string): Output format possible values : json (Default value) :Data in a JSON format csv : URL to the generated CSV file xlsx : URL to the generated XLSX (excel) file

  • status (string): Status type of the properties Default : forSale -forSale -forRent -recentlySold

  • sortSelection (string): Sorting possible values : days: Newest (Default value), saved: Date Saved, listingstatus: Listing Status, mostrecentchange: Most Recent Change, globalrelevanceex: Homes for You, featured: Verified Source, priced: Price (High to Low), pricea: Price (Low to High), paymentd: Payment (High to Low), paymenta: Payment (Low to High), beds: Bedrooms, baths: Bathrooms, size: Square Feet, lot: Lot Size, zest: Zestimate (High to Low), zesta: Zestimate (Low to High),

  • listing_type (string): Listing Type possible values : by_agent : By agent (Default value) by_owner_other : By owner & other (for off market properties)

  • isSingleFamily (string): Example value:

  • isMultiFamily (string): Example value:

  • isApartment (string): Example value:

  • isCondo (string): Example value:

  • isManufactured (string): Example value:

  • isTownhouse (string): Example value:

  • isLotLand (string): Example value:

  • doz (string): Days on Zillow (For Sale/Rent listings)/ Sold In Last (Sold listings) Possible values : any: Any, 1: 1 day, 7: 7 days, 14: 14 days, 30: 30 days, 90: 90 days, 6m: 6 months, 12m: 12 months, 24m: 24 months, 36m: 36 months

  • price_min (string): Example value:

  • price_max (string): Example value:

  • sqft_min (string): Example value:

  • sqft_max (string): Example value:

  • monthlyPayment_min (string): Example value:

  • monthlyPayment_max (string): Example value:

  • beds_min (string): Example value:

  • beds_max (string): Example value:

  • baths_min (string): Example value:

  • baths_max (string): Example value:

  • hoa_min (string): Example value:

  • hoa_max (string): Example value:

  • hasPool (string): Example value:

  • hasGarage (string): Example value:

  • built_min (string): Example value:

  • built_max (string): Example value:

  • isForSaleByOwner (string): Example value:

  • isForSaleByAgent (string): Example value:

  • isCityView (string): Example value:

  • isWaterfront (string): Example value:

  • isPublicSchool (string): Example value:

  • isPrivateSchool (string): Example value:

  • isMountainView (string): Example value:

  • singleStory (string): Example value:

  • onlyPriceReduction (string): Example value:

  • onlyRentalAcceptsApplications (string): Example value:

  • isZillowOwnedOnly (string): Example value:

  • hasAirConditioning (string): Example value:

  • isMiddleSchool (string): Example value:

  • isWaterView (string): Example value:

  • onlyRentalIncomeRestricted (string): Example value:

  • isComingSoon (string): Example value:

  • isForSaleForeclosure (string): Example value:

  • onlyWithPhotos (string): Example value:

  • onlyRentalCatsAllowed (string): Example value:

  • onlyRentalPetsAllowed (string): Example value:

  • onlyRentalSmallDogsAllowed (string): Example value:

  • onlyRentalLargeDogsAllowed (string): Example value:

  • isAuction (string): Example value:

  • is3dHome (string): Example value:

  • isNewConstruction (string): Example value:

  • parkingSpots_min (string): Example value:

  • greatSchoolsRating_min (string): Example value:

  • isElementarySchool (string): Example value:

  • isParkView (string): Example value:

  • enableSchools (string): Example value:

  • lotSize_min (string): in sqft

  • lotSize_max (string): in sqft

  • keywords (string): Example value:

mortgagerates_mortgage_rates

Get mortgage rates

端点: GET /mortgage/rates

参数:

  • program (string) 必需: The loan program. You can select one or two programs, separated by commas. Available: Fixed30Year, Fixed20Year, Fixed15Year, Fixed10Year, ARM3, ARM5, ARM7, HomeEquity30Year, HomeEquity30YearDueIn15, HomeEquity15Year, HELOC20Year, HELOC15Year, HELOC10Year

  • state (string): The state abbreviation. AK,AL,AR,AS,AZ,CA,CO,CT,DC,DE,FL,GA, GU,HI,IA,ID,IL,IN,KS,KY,LA,MA,MD,ME,MH, MI,MN,MO,MP,MS,MT,NC,ND,NE, NH,NJ,NM,NV,NY,OH,OK,OR,PA,PR,RI,SC,SD,TN,TX,UT,VA,VI,VT,WA,WI,WV,WY,US

  • refinance (string): Example value:

  • loanType (string): Example value:

  • loanAmount (string): Micro < $100,000 SmallConforming $100,000 - $200,000 Conforming > $200,000 SuperConforming Jumbo

  • loanToValue (string): Normal < 80% High > 80% < 95% VeryHigh >= 95%

  • creditScore (string): Low < 680 credit score. High > 680 < 740 VeryHigh > 740

  • duration (string): From 0 to 4000

buildersdetails_builders_details

Get details of builders by their builderId (found in builders/search results)

端点: GET /builders/details

参数:

  • builderId (string) 必需: Example value: 14987

builderscommunity_cards_builders_community_cards

Get community cards of a builder by their builderId (found in builders/search results)

端点: GET /builders/community_cards

参数:

  • builderId (string) 必需: Example value: 14987

  • regionId (string): Example value:

  • page (string): Example value:

buildersreviews_builders_reviews

Get reviews of a builder by their builderId (found in builders/search results)

端点: GET /builders/reviews

参数:

  • builderId (string) 必需: Example value: 14987

  • regionId (string): Example value:

  • page (string): Example value:

builderssearch_search_for_builders

Searchfor builders by location or name

端点: GET /builders/search

参数:

  • location (string): Example value: Houston,Tx

  • name (string): Example value:

  • page (string): Example value:

other_professionalsreviews_professionals_reviews

Get reviews of a professional by their zuid (found in /other_professionals/details result)

端点: GET /other_professionals/reviews

参数:

  • zuid (string) 必需: Example value: X1-ZU1328lo3ng72mh_5xifh

  • page (string): Example value:

  • size (string): Example value:

other_professionalsdetails_professionals_details

Get details of a professional by username (found in /other_professionals/search results)

端点: GET /other_professionals/details

参数:

  • username (string) 必需: Example value: InnerLoopHomes

other_professionalssearch_search_for_professionals

Search for professoinals (property managers, inspectors,photographers,home_improvement,etc) by location or name

端点: GET /other_professionals/search

参数:

  • location (string): Example value: Houston,tx

  • type (string) 必需: Example value:

  • name (string): Example value:

  • page (string): Example value:

walk_transit_bike_score_walk_transit_and_bike_score

Get Walk, Transit and Bike Score of a property by zpid

端点: GET /walk_transit_bike_score

参数:

schools_nearby_schools

Nearby schools of a property by ZPID

端点: GET /schools

参数:

photos_photos_of_a_property

Returns a property's photos with different sizes and types.

端点: GET /photos

参数:

property_deprecated

Get a property's details by its zpid

端点: GET /property

参数:

propertyv2_property_details_by_zpid

Get a property's details by its zpid

端点: GET /propertyV2

参数:

lenderreviews

Get lender reviews

端点: GET /lender/reviews

参数:

  • screenName (string) 必需: Example value: mortgagecapitalpartners

  • page (string): Example value:

lenderdetails

Get lender details

端点: GET /lender/details

参数:

  • screenName (string) 必需: Example value: mortgagecapitalpartners

lendersearch

Search for Lenders

端点: GET /lender/search

参数:

  • location (string) 必需: City, State or Zip. Only lenders licensed in the state will be displayed.

  • lenderName (string): Example value:

  • page (string): Example value:

similar_rent_properties_similar_for_rent_properties

List of similar for rent properties by Zpid or URL or address

端点: GET /similar_rent_properties

参数:

search_coordinates_search_for_properties_by_coordinates

Search for filtered properties by coordinates. You can select the output format (JSON , CSV , XLSX) using the optional \

端点: GET /search_coordinates

参数:

  • lat (string) 必需: Latitude

  • long (string) 必需: Longitude

  • page (string): Example value:

  • status (string): Status type of the properties Default : forSale -forSale -forRent -recentlySold

  • output (string): Output format possible values : json (Default value) :Data in a JSON format csv : URL to the generated CSV file xlsx : URL to the generated XLSX (excel) file

  • sort (string): Sorting possible values : priorityscore: Default, saved: Date Saved, listingstatus: Listing Status, mostrecentchange: Most Recent Change, globalrelevanceex: Homes for You, featured: Verified Source, priced: Price (High to Low), pricea: Price (Low to High), paymentd: Payment (High to Low), paymenta: Payment (Low to High), days: Newest, beds: Bedrooms, baths: Bathrooms, size: Square Feet, lot: Lot Size, zest: Zestimate (High to Low), zesta: Zestimate (Low to High),

  • listing_type (string): Listing Type possible values : By agent (Default value) By owner & other (for off market properties)

  • isSingleFamily (string): Example value:

  • isMultiFamily (string): Example value:

  • isApartment (string): Example value:

  • isCondo (string): Example value:

  • isManufactured (string): Example value:

  • isTownhouse (string): Example value:

  • isLotLand (string): Example value:

  • doz (string): Days on Zillow possible values : any: Any, 1: 1 day, 7: 7 days, 14: 14 days, 30: 30 days, 90: 90 days, 6m: 6 months, 12m: 12 months, 24m: 24 months, 36m: 36 months

  • price_min (string): Example value:

  • price_max (string): Example value:

  • sqft_min (string): Example value:

  • sqft_max (string): Example value:

  • monthlyPayment_min (string): Example value:

  • monthlyPayment_max (string): Example value:

  • beds_min (string): Example value:

  • beds_max (string): Example value:

  • baths_min (string): Example value:

  • baths_max (string): Example value:

  • hoa_min (string): Example value:

  • hoa_max (string): Example value:

  • hasPool (string): Example value:

  • hasGarage (string): Example value:

  • built_min (string): Example value:

  • built_max (string): Example value:

  • isForSaleByOwner (string): Example value:

  • isForSaleByAgent (string): Example value:

  • isCityView (string): Example value:

  • isWaterfront (string): Example value:

  • isPublicSchool (string): Example value:

  • isPrivateSchool (string): Example value:

  • isMountainView (string): Example value:

  • singleStory (string): Example value:

  • onlyPriceReduction (string): Example value:

  • onlyRentalAcceptsApplications (string): Example value:

  • isZillowOwnedOnly (string): Example value:

  • hasAirConditioning (string): Example value:

  • isMiddleSchool (string): Example value:

  • isWaterView (string): Example value:

  • onlyRentalIncomeRestricted (string): Example value:

  • isComingSoon (string): Example value:

  • isForSaleForeclosure (string): Example value:

  • onlyWithPhotos (string): Example value:

  • onlyRentalCatsAllowed (string): Example value:

  • onlyRentalPetsAllowed (string): Example value:

  • onlyRentalSmallDogsAllowed (string): Example value:

  • onlyRentalLargeDogsAllowed (string): Example value:

  • isAuction (string): Example value:

  • is3dHome (string): Example value:

  • isNewConstruction (string): Example value:

  • greatSchoolsRating_min (string): Example value:

  • isElementarySchool (string): Example value:

  • isParkView (string): Example value:

  • enableSchools (string): Example value:

  • keywords (string): Example value:

search_url_list_of_properties_by_url

Get a list of properties by providing the zillow search results URL You can select the output format (JSON , CSV , XLSX) using the optional \

端点: GET /search_url

参数:

search_mls_search_by_mls

Search for properties by their MLS ID.

端点: GET /search_mls

参数:

  • mls (string) 必需: Example value: SR25078433

agent_details_by_username

Get agent's details by username(contact infos, active listings and reviews etc). PS : username is the profile link Example : username : Pardee-Properties for https://www.zillow.com/profile/Pardee-Properties/

端点: GET /agent

参数:

  • username (string) 必需: Example value: Pardee-Properties

agents_rental_listings

Get agent's rental listings by zuid

端点: GET /agent_rental_listings

参数:

  • zuid (string) 必需: Example value: X1-ZUz0nmomozy2o9_9bpwk

  • page (string): Example value:

agent_reviews

Get agent reviews by the agent's zuid

端点: GET /agent_reviews

参数:

  • zuid (string) 必需: Example value: X1-ZUz0nmomozy2o9_9bpwk

  • page (string): Example value:

agents_active_listings

Get agent's active listings by zuid

端点: GET /agent_active_listings

参数:

  • zuid (string) 必需: Example value: X1-ZUz0nmomozy2o9_9bpwk

  • page (string): Example value:

search_for_agents

Search for agents by location and name

端点: GET /search_agents

参数:

  • location (string) 必需: Example value: houston, tx

  • name (string): Example value:

  • page (string): Example value:

  • specialty (string): Example value:

  • language (string): Example value:

agents_past_sales

Get agent's past sales by zuid

端点: GET /agent_past_sales

参数:

  • zuid (string) 必需: The zuid can be extracted from the agent's details "/agent"

  • page (string): Example value:

similar_sold_properties_similar_sold_properties

List of similar sold properties by Zpid or URL or address

端点: GET /similar_sold_properties

参数:

similar_properties_similar_for_sale_properties

List of similar for sale properties by Zpid or URL or address

端点: GET /similar_properties

参数:

price_tax_history_price_and_tax_history

Price and Tax history of a property by ZPID

端点: GET /price_tax_history

参数:

rent_estimate_rent_zestimate

Returns a property's rent zestimate and it's comparable properties in the same area.

端点: GET /rent_estimate

参数:

  • address (string) 必需: Example value: 1545 Yale St, Santa Monica, CA 90404

  • activeTypes (string): SimilarFloorPlans filter: Possible values: any (Default) active (Active Rentals) inactive (Inactive Rentals)

  • activatedDays (string): [SIMILARFLOORPLANS] Filter for Active Rentals within X days: Possible values: any (Default) 30 (Within 30 days) 15 (Within 15 days) 7 (Within 7 days)

  • deactivatedDays (string): [SIMILARFLOORPLANS] Filter for inactive rentals within X days: Possible values: 30 (Within 30 days (max)) 15 (Within 15 days) 7 (Within 7 days)

  • distanceInMiles (string): [SIMILARFLOORPLANS] Filter for distance in Miles: Possible values: any 1 2 3 4 5

  • propertyTypes (string): [SIMILARFLOORPLANS] Filter for Property Types: (To choose multiple values separate with comma eg : house,condo) Possible values: any (Default) apartment house townhouse condo

  • bedrooms (string): [SIMILARFLOORPLANS] Filter for number of bedrooms: (To choose multiple values separate with comma eg : 0,1,2) Possible values: 0 1 2 3 4plus

  • pets (string): [SIMILARFLOORPLANS] Filter for Pets: (To choose multiple values separate with comma eg : dogs,cats) Possible values: any (Default) dogs cats

  • laundry (string): [SIMILARFLOORPLANS] Filter for Laundry: (To choose multiple values separate with comma eg : inUnit,shared) Possible values: any (Default) inUnit shared

  • amenities (string): [SIMILARFLOORPLANS] Filter for amenities: (To choose multiple values separate with comma eg : cooling,parking) Possible values: any (Default) cooling heating parking

zestimate_history_zestimate_history

Zestimate history by zpid

端点: GET /zestimate_history

参数:

search_address_search_for_a_property_by_address

Search for a property by address.

端点: GET /search_address

参数:

  • address (string) 必需: Example value: 1161 Natchez Dr College Station Texas 77845

技术栈

  • 传输协议: stdio

  • HTTP 客户端: httpx

开发

此服务器由 API-to-MCP 工具自动生成。

版本: 2.0.0

Available Tools

37 tools
agent_details_by_usernameB

Get agent's details by username(contact infos, active listings and reviews etc). PS : username is the profile link Example : username : Pardee-Properties for https://www.zillow.com/profile/Pardee-Properties/

ParametersJSON Schema
NameRequiredDescriptionDefault
usernameYesExample value: Pardee-Properties

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It describes what data is returned (contact infos, active listings, reviews) but doesn't disclose important behavioral aspects like rate limits, authentication requirements, error conditions, or pagination behavior. The description adds some value but leaves significant gaps for a tool with no annotation coverage.

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?

The description is appropriately concise with two sentences that each earn their place. The first states the purpose and scope, the second clarifies the username parameter with a helpful example. No wasted words, though the 'PS' formatting could be cleaner.

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

Completeness3/5

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

Given no annotations and no output schema, the description provides adequate basic information about purpose and parameter semantics, but lacks details about return format, error handling, and behavioral constraints. For a tool with rich sibling relationships and no structured metadata, more completeness would be helpful.

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 description coverage is 100%, so the schema already documents the username parameter. However, the description adds crucial semantic context by explaining that 'username is the profile link' and providing a concrete example with the URL relationship. This significantly enhances understanding beyond the schema's basic type information.

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 clearly states the tool's purpose: 'Get agent's details by username' with specific examples of what details are included (contact infos, active listings and reviews etc). It distinguishes from siblings like 'agent_reviews' or 'agents_active_listings' by being more comprehensive, though it doesn't explicitly name those alternatives.

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?

The description implies usage context through the example showing username format and URL relationship, but doesn't explicitly state when to use this tool versus alternatives like 'search_for_agents' or the more specific sibling tools. No explicit when-not-to-use guidance is provided.

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

agent_reviewsC

Get agent reviews by the agent's zuid

ParametersJSON Schema
NameRequiredDescriptionDefault
zuidYesExample value: X1-ZUz0nmomozy2o9_9bpwk
pageNoExample value: 0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It states 'Get' implying a read operation, but lacks details on behavioral traits such as authentication needs, rate limits, pagination behavior (implied by 'page' parameter but not explained), or what happens with invalid zuid. The description is minimal and doesn't compensate for missing annotations.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose, making it easy to parse quickly. Every word earns its place without redundancy.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a tool with parameters. It doesn't explain what 'reviews' entail (e.g., content, format), how pagination works, or error handling. For a read operation with potential complexity, more context is needed to guide effective use.

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 documents both parameters (zuid and page). The description adds no meaning beyond the schema, as it only mentions 'zuid' without explaining its format or purpose. With high schema coverage, the baseline is 3, but no extra value is provided.

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 clearly states the action ('Get') and resource ('agent reviews'), specifying retrieval by 'zuid'. It distinguishes from siblings like 'agent_details_by_username' by focusing on reviews rather than general details, but doesn't explicitly contrast with 'search_for_agents' or other review tools (e.g., 'buildersreviews_builders_reviews').

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives is provided. It doesn't mention when to choose it over sibling tools like 'search_for_agents' or 'agents_active_listings', nor does it specify prerequisites or exclusions (e.g., requires a specific zuid format).

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

agents_active_listingsC

Get agent's active listings by zuid

ParametersJSON Schema
NameRequiredDescriptionDefault
zuidYesExample value: X1-ZUz0nmomozy2o9_9bpwk
pageNoExample value: 0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only states what the tool does ('Get agent's active listings'), without disclosing behavioral traits like pagination details (implied by 'page' parameter), rate limits, authentication needs, error handling, or what 'active listings' entails. This leaves significant gaps for a read operation.

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

Conciseness5/5

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

The description is a single, efficient sentence: 'Get agent's active listings by zuid'. It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple tool.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It lacks details on return values (e.g., format of listings), pagination behavior (implied by 'page' parameter), error cases, or what qualifies as 'active'. For a tool with 2 parameters and no structured output, this leaves the agent with insufficient context.

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 both parameters ('zuid' and 'page'). The description adds no additional meaning beyond implying 'zuid' is required for fetching listings. With high schema coverage, the baseline is 3, as the description doesn't compensate with extra context.

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 clearly states the tool's purpose: 'Get agent's active listings by zuid'. It specifies the verb ('Get'), resource ('agent's active listings'), and key identifier ('by zuid'). However, it doesn't explicitly differentiate from sibling tools like 'agents_past_sales' or 'agents_rental_listings', which would require a 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'agents_past_sales' or 'agents_rental_listings', nor does it specify prerequisites or contexts for usage. The agent must infer usage from the name alone.

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

agents_past_salesB

Get agent's past sales by zuid

ParametersJSON Schema
NameRequiredDescriptionDefault
zuidYesThe zuid can be extracted from the agent's details \"/agent\"
pageNoExample value: 0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It states the tool retrieves past sales, implying a read-only operation, but doesn't disclose behavioral traits like pagination handling (page parameter), rate limits, authentication needs, or what constitutes 'past sales' (e.g., time range, status). The mention of page parameter hints at pagination but lacks details.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.

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

Completeness3/5

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

Given no annotations and no output schema, the description is minimally adequate for a simple read operation. It covers the basic purpose and key parameter (zuid), but lacks details on behavior (e.g., pagination, data format) and doesn't compensate for the absence of output schema or annotations. It's complete enough to understand what the tool does but not how to use it effectively.

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 both parameters (zuid and page). The description adds minimal value by noting zuid can be extracted from '/agent', but doesn't clarify semantics beyond what the schema provides (e.g., format of zuid, how page works). Baseline 3 is appropriate as the schema does the heavy lifting.

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 clearly states the tool's purpose: 'Get agent's past sales by zuid'. It specifies the verb ('Get'), resource ('agent's past sales'), and key identifier ('by zuid'). However, it doesn't explicitly differentiate from siblings like 'agent_details_by_username' or 'search_for_agents', which might also retrieve agent information.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions the zuid can be extracted from '/agent', but doesn't specify if this is the only way to obtain it or when to prefer this tool over other agent-related tools like 'agent_reviews' or 'agents_active_listings'.

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

agents_rental_listingsB

Get agent's rental listings by zuid

ParametersJSON Schema
NameRequiredDescriptionDefault
zuidYesExample value: X1-ZUz0nmomozy2o9_9bpwk
pageNoExample value: 0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, the description doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the listings come in. For a tool with no annotation coverage, this leaves significant behavioral gaps.

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

Conciseness5/5

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

The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information.

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

Completeness3/5

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

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks behavioral context, usage guidance, and output information. With no annotations to supplement, the description should provide more complete operational context.

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 both parameters (zuid and page) with descriptions. The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 reflects adequate coverage through the schema alone.

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 clearly states the tool's purpose: 'Get agent's rental listings by zuid'. It specifies the verb ('Get'), resource ('agent's rental listings'), and key identifier ('by zuid'). However, it doesn't distinguish this tool from sibling tools like 'agents_active_listings' or 'agents_past_sales', which likely retrieve different types of listings.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With multiple agent-related tools available (agent_details_by_username, agent_reviews, agents_active_listings, agents_past_sales), there's no indication of when rental listings are appropriate versus active listings or past sales. No prerequisites or exclusions are mentioned.

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

builderscommunity_cards_builders_community_cardsB

Get community cards of a builder by their builderId (found in builders/search results)

ParametersJSON Schema
NameRequiredDescriptionDefault
builderIdYesExample value: 14987
regionIdNoExample value:
pageNoExample value:

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes a read operation ('Get'), but lacks details on permissions, rate limits, pagination (despite a 'page' parameter), error handling, or what 'community cards' entail. This leaves significant gaps for an AI agent to understand the tool's behavior beyond basic retrieval.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose and includes a helpful note about builderId sourcing. There's no redundancy or unnecessary elaboration, making it appropriately concise for the tool's complexity.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'community cards' are, their structure, or the tool's return format. For a tool with three parameters and behavioral unknowns, this leaves the AI agent with insufficient context to use it effectively beyond basic invocation.

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%, with all parameters documented in the schema (builderId, regionId, page). The description adds minimal value by clarifying builderId's source ('found in `builders/search` results'), but doesn't explain regionId or page usage. Baseline 3 is appropriate as the schema handles most parameter documentation.

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 clearly states the action ('Get community cards') and target resource ('of a builder'), specifying it retrieves community cards for a builder identified by builderId. It distinguishes from siblings by focusing on builders' community cards rather than details, reviews, or other builder-related data, though it doesn't explicitly contrast with all siblings.

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?

The description implies usage by referencing where to find builderId ('found in `builders/search` results'), providing some context for when to use this tool. However, it doesn't explicitly state when to choose this over alternatives like buildersdetails_builders_details or buildersreviews_builders_reviews, nor does it mention exclusions or prerequisites beyond the builderId requirement.

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

buildersdetails_builders_detailsB

Get details of builders by their builderId (found in builders/search results)

ParametersJSON Schema
NameRequiredDescriptionDefault
builderIdYesExample value: 14987

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('Get details') but doesn't disclose any behavioral traits such as whether it's a read-only operation, what format/details are returned, error conditions, rate limits, or authentication requirements. For a tool with no annotation coverage, this is a significant gap in transparency.

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

Conciseness5/5

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

The description is extremely concise (one sentence) and front-loaded with the core purpose. Every word earns its place - it states the action, resource, parameter, and even provides a usage hint about where to obtain the parameter. There's zero waste or redundancy.

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

Completeness2/5

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

Given that there are no annotations and no output schema, the description is incomplete for a tool that presumably returns detailed builder information. It doesn't describe what 'details' include, the response format, potential errors, or any behavioral aspects. For a detail-retrieval tool with zero structured metadata, the description should provide more context about what information is returned.

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% (the single parameter 'builderId' has a description in the schema), so the baseline is 3. The description adds minimal value beyond the schema by mentioning where to find builderId ('found in `builders/search` results'), but doesn't provide additional semantic context about the parameter's format, constraints, or examples beyond what's already in the 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 clearly states the tool's purpose: 'Get details of builders by their builderId' - a specific verb ('Get details') and resource ('builders'). It distinguishes from some siblings like 'builderssearch_search_for_builders' (search vs. details) but doesn't explicitly differentiate from similar detail tools like 'agent_details_by_username' or 'lenderdetails'. The description is clear but lacks explicit sibling differentiation.

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?

The description provides implied usage guidance by mentioning that builderId is 'found in `builders/search` results', suggesting this tool should be used after obtaining IDs from the search tool. However, it doesn't explicitly state when to use this vs. alternatives (e.g., when you need detailed information vs. search results), nor does it mention any exclusions or prerequisites beyond the ID requirement.

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

buildersreviews_builders_reviewsB

Get reviews of a builder by their builderId (found in builders/search results)

ParametersJSON Schema
NameRequiredDescriptionDefault
builderIdYesExample value: 14987
regionIdNoExample value:
pageNoExample value:

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does ('Get reviews') without mentioning behavioral aspects like whether it's a read-only operation, if it requires authentication, rate limits, pagination behavior (implied by 'page' parameter but not explained), or what the response format looks like. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

Conciseness5/5

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

The description is a single, efficient sentence that clearly states the tool's purpose and provides helpful context about where to find the required parameter. There's no wasted language or unnecessary elaboration, making it appropriately front-loaded and concise.

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

Completeness2/5

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

Given that there are no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (review format, structure, or fields), behavioral constraints, or error conditions. For a tool that presumably returns review data, the lack of output information creates significant uncertainty about what to expect from the operation.

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 three parameters with example values. The description adds minimal value beyond the schema by mentioning that builderId comes from 'builders/search' results, but doesn't provide additional context about optional parameters (regionId, page) or their effects. This meets the baseline expectation when schema coverage is high.

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 clearly states the tool's purpose: 'Get reviews of a builder by their builderId'. It specifies the verb ('Get') and resource ('reviews of a builder'), and mentions where to find the builderId. However, it doesn't explicitly differentiate from sibling tools like 'agent_reviews' or 'lenderreviews', which serve similar functions for different entity types.

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?

The description provides some usage context by indicating that builderId can be found in 'builders/search' results, which implies this tool should be used after obtaining a builderId from that sibling tool. However, it doesn't explicitly state when to use this tool versus alternatives like 'buildersdetails_builders_details' or provide clear exclusions for other entity types.

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

builderssearch_search_for_buildersC

Searchfor builders by location or name

ParametersJSON Schema
NameRequiredDescriptionDefault
locationNoExample value: Houston,Tx
nameNoExample value:
pageNoExample value:

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Search for' implies a read-only operation, the description doesn't address pagination behavior (despite a 'page' parameter), rate limits, authentication requirements, result format, or error conditions. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.

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?

The description is a single, efficient sentence that communicates the core functionality without unnecessary words. However, it lacks front-loading of critical details like behavioral traits or usage context, and the missing space in 'Searchfor' slightly affects readability.

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

Completeness2/5

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

Given the complexity of a search tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of builders with basic info), how results are ordered, pagination details, or error handling. For a tool that likely returns structured data, this leaves too much unspecified.

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%, with all three parameters ('location', 'name', 'page') documented in the schema. The description mentions 'location or name' which aligns with two parameters but doesn't add meaning beyond what the schema provides (e.g., format examples, search logic, or how 'page' works). With high schema coverage, the baseline score of 3 is appropriate.

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 clearly states the verb ('Search for') and resource ('builders'), and specifies the search criteria ('by location or name'). However, it doesn't explicitly distinguish this tool from sibling tools like 'search_for_agents' or 'other_professionalssearch_search_for_professionals', which appear to perform similar search functions for different entity types.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'buildersdetails_builders_details' for detailed information or 'buildersreviews_builders_reviews' for reviews, nor does it specify prerequisites, constraints, or typical use cases for searching builders versus other professionals.

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

lenderdetailsC

Get lender details

ParametersJSON Schema
NameRequiredDescriptionDefault
screenNameYesExample value: mortgagecapitalpartners

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get lender details' implies a read-only operation, but it does not specify if authentication is required, rate limits apply, or what the output format looks like. For a tool with zero annotation coverage, this is a significant gap in transparency.

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?

The description is a single, efficient sentence with no wasted words, making it easy to parse. However, it is under-specified rather than concise, as it lacks necessary details for full understanding, but it is structured well for its brevity.

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

Completeness2/5

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

Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It does not explain what 'lender details' includes, how to interpret the output, or any behavioral aspects like error handling. For a tool with no annotations or output schema, more context is needed to be fully helpful to an agent.

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?

The input schema has 100% description coverage, with 'screenName' documented as 'Example value: mortgagecapitalpartners'. The description does not add any meaning beyond this, such as explaining what a 'screenName' represents or its format. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.

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

Purpose3/5

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

The description 'Get lender details' states a clear verb ('Get') and resource ('lender details'), which provides a basic understanding of the tool's function. However, it lacks specificity about what 'details' includes (e.g., contact info, loan products, ratings) and does not distinguish it from sibling tools like 'lenderreviews' or 'lendersearch', making it vague in comparison.

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

Usage Guidelines2/5

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

The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing a 'screenName', or suggest when to choose this over sibling tools like 'lenderreviews' for reviews or 'lendersearch' for finding lenders, leaving the agent without usage context.

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

lenderreviewsC

Get lender reviews

ParametersJSON Schema
NameRequiredDescriptionDefault
screenNameYesExample value: mortgagecapitalpartners
pageNoExample value:

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get lender reviews' implies a read-only operation, but it doesn't specify aspects like authentication requirements, rate limits, pagination (given the 'page' parameter), error handling, or the format of returned reviews. For a tool with no annotation coverage, this is a significant gap in transparency.

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

Conciseness5/5

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

The description is extremely concise with just three words, front-loading the key action and resource. There is no wasted language or unnecessary elaboration, making it efficient and easy to parse. This is an example of optimal conciseness for a simple tool.

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

Completeness2/5

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

Given the complexity (a read operation with 2 parameters), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., review data format), how to handle the 'page' parameter for pagination, or any behavioral constraints. For a tool without structured output documentation, the description should provide more context to be fully helpful.

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%, with both parameters ('screenName' and 'page') documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain what 'screenName' represents or how 'page' is used). With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.

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

Purpose3/5

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

The description 'Get lender reviews' clearly states the verb ('Get') and resource ('lender reviews'), making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'lenderdetails' or 'lendersearch', which might also involve lender information. The purpose is clear but lacks sibling differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'lenderdetails' (likely for lender details) and 'lendersearch' (likely for searching lenders), there's no indication of when this tool is appropriate (e.g., for retrieving reviews specifically) or when to choose other tools. This leaves usage ambiguous.

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

lendersearchC

Search for Lenders

ParametersJSON Schema
NameRequiredDescriptionDefault
locationYesCity, State or Zip. Only lenders licensed in the state will be displayed.
lenderNameNoExample value:
pageNoExample value: 0

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Search for Lenders' implies a read-only operation, but it doesn't specify whether this is a filtered list, paginated results, or any rate limits. It misses details like what data is returned or how results are structured, which is critical for a search tool with no output schema.

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

Conciseness5/5

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

The description is extremely concise with just three words, 'Search for Lenders', which is front-loaded and wastes no space. It's appropriately sized for a simple tool name, though this brevity contributes to gaps in other dimensions.

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

Completeness2/5

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

Given the complexity of a search tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the search returns, how results are filtered, or any behavioral traits. This leaves significant gaps for an agent to understand and use the tool effectively.

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 three parameters (location, lenderName, page) with descriptions. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or search logic. Baseline 3 is appropriate since the schema does the heavy lifting.

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

Purpose3/5

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

The description 'Search for Lenders' clearly states the verb ('Search') and resource ('Lenders'), providing a basic purpose. However, it doesn't differentiate from sibling tools like 'lenderdetails' or 'lenderreviews', nor does it specify what kind of search this is (e.g., by location, name, etc.). It's adequate but vague about scope.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'lenderdetails' or 'lenderreviews'. It lacks context about prerequisites, such as needing a location parameter, and doesn't mention any exclusions or typical use cases. This leaves the agent without direction on tool selection.

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

market_sale_overviewC

This endpoint delivers a comprehensive snapshot and historical trends of the housing market in a given region using metrics aligned with the Zillow Home Value Index (ZHVI) framework

ParametersJSON Schema
NameRequiredDescriptionDefault
locationNoExample value: houston,tx

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It describes the output ('comprehensive snapshot and historical trends') but lacks critical behavioral details such as data freshness, rate limits, authentication needs, error handling, or whether it's read-only. For a tool with no annotations, this is a significant gap in transparency.

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?

The description is a single, well-structured sentence that efficiently conveys the core purpose without redundancy. It's appropriately sized and front-loaded, though it could be slightly more concise by trimming phrases like 'using metrics aligned with'.

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

Completeness2/5

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

Given no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It lacks details on output format, behavioral traits, and usage context, making it inadequate for an agent to fully understand the tool's operation and limitations.

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 the 'location' parameter with an example. The description adds no additional parameter semantics beyond implying regional scope, which is minimal value. Baseline 3 is appropriate as the schema does the heavy lifting.

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 clearly states the tool's purpose: to deliver a comprehensive snapshot and historical trends of the housing market using ZHVI metrics. It specifies the verb ('delivers') and resource ('housing market in a given region'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'market_data_rental_market_trends' or 'zhvi_range', which appear related, so it misses full sibling distinction.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions the ZHVI framework but doesn't specify contexts, exclusions, or compare to sibling tools like 'market_data_rental_market_trends' or 'zhvi_range', leaving the agent without usage direction.

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

mortgagerates_mortgage_ratesC

Get mortgage rates

ParametersJSON Schema
NameRequiredDescriptionDefault
programYesThe loan program. You can select one or two programs, separated by commas. Available: Fixed30Year, Fixed20Year, Fixed15Year, Fixed10Year, ARM3, ARM5, ARM7, HomeEquity30Year, HomeEquity30YearDueIn15, HomeEquity15Year, HELOC20Year, HELOC15Year, HELOC10Year
stateNoThe state abbreviation. AK,AL,AR,AS,AZ,CA,CO,CT,DC,DE,FL,GA, GU,HI,IA,ID,IL,IN,KS,KY,LA,MA,MD,ME,MH, MI,MN,MO,MP,MS,MT,NC,ND,NE, NH,NJ,NM,NV,NY,OH,OK,OR,PA,PR,RI,SC,SD,TN,TX,UT,VA,VI,VT,WA,WI,WV,WY,US
refinanceNoExample value:
loanTypeNoExample value:
loanAmountNoMicro < $100,000 SmallConforming $100,000 - $200,000 Conforming > $200,000 SuperConforming Jumbo
loanToValueNoNormal < 80% High > 80% < 95% VeryHigh >= 95%
creditScoreNoLow < 680 credit score. High > 680 < 740 VeryHigh > 740
durationNoFrom 0 to 400030

TDQS

C2/5.0
Behavior1/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. 'Get mortgage rates' doesn't reveal whether this is a read-only operation, if it requires authentication, whether it makes external API calls, what format the results come in, if there are rate limits, or any error conditions. For a tool with 8 parameters that presumably queries financial data, this lack of behavioral context is critically inadequate.

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

Conciseness5/5

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

The description is maximally concise at just three words. While this represents under-specification rather than ideal conciseness, according to the scoring framework, 'Process' received a 2 for being under-specified, but this description is even more minimal. However, given that every word earns its place and there's zero redundancy, it technically meets the criteria for perfect conciseness despite being inadequate in content.

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

Completeness1/5

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

Given the complexity (8 parameters, financial data tool), absence of annotations, and no output schema, the description is completely inadequate. It doesn't explain what the tool returns, how results are structured, what authentication might be needed, or any behavioral characteristics. For a mortgage rates tool that likely makes important financial queries, this minimal description fails to provide the necessary context for proper tool usage.

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?

The schema description coverage is 100%, meaning all parameters are documented in the input schema itself. The description adds no additional parameter information beyond what's already in the schema descriptions. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

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

Purpose2/5

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

The description 'Get mortgage rates' is a tautology that essentially restates the tool name 'mortgagerates_mortgage_rates'. It provides a basic verb ('Get') and resource ('mortgage rates'), but lacks specificity about what kind of mortgage rates (e.g., current market rates, historical rates, personalized quotes) or how they're obtained. Compared to sibling tools like 'market_data_rental_market_trends' or 'zestimate_history_zestimate_history', it doesn't clearly differentiate its scope.

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

Usage Guidelines1/5

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

The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or compare it to any sibling tools (like 'lenderdetails' or 'lendersearch' which might provide related information). There's no indication of when this tool is preferred or what scenarios it's designed for.

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

other_professionalsdetails_professionals_detailsB

Get details of a professional by username (found in /other_professionals/search results)

ParametersJSON Schema
NameRequiredDescriptionDefault
usernameYesExample value: InnerLoopHomes

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states what the tool does (get details) and a prerequisite (username from search). It lacks behavioral context: what details are returned (contact info, credentials?), whether it's a read-only operation, authentication requirements, rate limits, error handling, or response format. For a tool with zero annotation coverage, this is insufficient disclosure.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose and includes essential context. There's zero waste—every word earns its place by specifying the action, target, parameter source, and prerequisite tool.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a tool that presumably returns detailed professional information. It doesn't explain what 'details' include, the response structure, or any behavioral traits (e.g., read-only, error cases). For a tool with rich expected output and zero structured coverage, the description should provide more context about what the agent can expect.

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%, with the 'username' parameter fully documented in the schema. The description adds minimal value beyond the schema by mentioning the username comes from '/other_professionals/search' results, which provides context but no additional semantic detail about the parameter itself. Baseline 3 is appropriate when schema does the heavy lifting.

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 clearly states the tool's purpose: 'Get details of a professional by username'. It specifies the verb ('Get details'), resource ('a professional'), and key constraint ('by username'). However, it doesn't explicitly differentiate from sibling tools like 'agent_details_by_username' or 'buildersdetails_builders_details', which likely serve similar purposes for different professional types.

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?

The description provides clear context for when to use this tool: after finding a username from '/other_professionals/search' results. This establishes a workflow dependency. However, it doesn't explicitly state when NOT to use it (e.g., vs. agent_details_by_username for agents) or name alternative tools for different professional types.

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

other_professionalsreviews_professionals_reviewsB

Get reviews of a professional by their zuid (found in /other_professionals/details result)

ParametersJSON Schema
NameRequiredDescriptionDefault
zuidYesExample value: X1-ZU1328lo3ng72mh_5xifh
pageNoExample value:
sizeNoExample value:

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that it 'Get reviews', which implies a read-only operation, but doesn't disclose other traits such as whether it requires authentication, has rate limits, returns paginated results (hinted by 'page' and 'size' parameters but not explained), or what the output format looks like. This leaves significant gaps for a tool with no annotation coverage.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose and provides a key usage hint without any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.

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

Completeness3/5

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

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is somewhat complete but has clear gaps. It covers the basic purpose and zuid sourcing, but lacks details on behavioral aspects (e.g., pagination, authentication) and doesn't explain the return values. This is adequate as a minimum viable description but could be more comprehensive.

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 parameters (zuid, page, size) with example values. The description adds minimal value beyond the schema by specifying that the zuid is 'found in `/other_professionals/details` result', which provides context for sourcing the zuid but doesn't elaborate on parameter usage or semantics. This meets the baseline of 3 when schema coverage is high.

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 clearly states the verb 'Get reviews' and the resource 'of a professional by their zuid', making the purpose specific and understandable. It distinguishes from some siblings like 'other_professionalsdetails_professionals_details' by focusing on reviews rather than general details, though it doesn't explicitly differentiate from 'agent_reviews' or 'buildersreviews_builders_reviews' which might have similar functions for different professional types.

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?

The description implies usage by specifying that the zuid is 'found in `/other_professionals/details` result', which provides context for when to use this tool (i.e., after obtaining a zuid from that sibling tool). However, it doesn't offer explicit guidance on when to use this versus alternatives like 'agent_reviews' or 'buildersreviews_builders_reviews', nor does it mention exclusions or prerequisites beyond the zuid requirement.

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

other_professionalssearch_search_for_professionalsC

Search for professoinals (property managers, inspectors,photographers,home_improvement,etc) by location or name

ParametersJSON Schema
NameRequiredDescriptionDefault
locationNoExample value: Houston,tx
typeYesExample value:
nameNoExample value:
pageNoExample value: 0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions search functionality but doesn't describe pagination behavior (implied by the 'page' parameter), rate limits, authentication needs, or what the response format looks like. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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?

The description is a single, efficient sentence that front-loads the core purpose. However, it contains a typo ('professoinals') and could be slightly more structured by separating examples or clarifying parameters, but it's generally concise with no wasted words.

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

Completeness2/5

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

Given the complexity of a search tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, response format, pagination, and usage context, making it inadequate for an AI agent to fully understand how to invoke and interpret results from this tool.

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 parameters. The description adds minimal value by mentioning search by 'location or name', which aligns with the 'location' and 'name' parameters, but doesn't explain the 'type' parameter's purpose or provide context beyond what's in the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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 clearly states the action ('Search for professionals') and the resource ('professionals'), with specific examples of professional types (property managers, inspectors, photographers, home improvement, etc.). It distinguishes from sibling tools that focus on agents, builders, lenders, or properties, but doesn't explicitly differentiate from 'search_for_agents' or 'search_for_builders' beyond the professional type scope.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'search_for_agents' or 'search_for_builders', nor does it mention prerequisites or exclusions. It only states what the tool does, not when it's appropriate.

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

photos_photos_of_a_propertyB

Returns a property's photos with different sizes and types.

ParametersJSON Schema
NameRequiredDescriptionDefault
zpidNoThe zpid can be extracted from the searching endpoints (/search , /search_url…), or from a property's URL.
urlNoProperty details URL - eg :https://www.zillow.com/homedetails/15626-Laurel-Heights-Dr-Houston-TX-77084/28253016_zpid/

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It states it 'Returns' data, implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or response format. For a tool with no annotation coverage, this is a significant gap in transparency about how it behaves.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose ('Returns a property's photos') and adds useful detail ('with different sizes and types'). There is no wasted text, making it appropriately sized and well-structured for quick understanding.

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

Completeness3/5

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

Given no annotations, no output schema, and a simple input schema, the description is minimally complete for a read operation. It covers the purpose and output characteristics but lacks behavioral context (e.g., response format, errors) and usage guidelines. For a tool with low complexity, this is adequate but has clear gaps.

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 both parameters (zpid and url) with clear descriptions. The description adds no parameter-specific information beyond implying the tool operates on a property. Baseline 3 is appropriate as the schema handles parameter documentation adequately.

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 clearly states the verb ('Returns') and resource ('a property's photos'), specifying what the tool does. It adds detail about output characteristics ('with different sizes and types'), which helps distinguish it from general property details tools. However, it doesn't explicitly differentiate from potential photo-related siblings (none are listed, but context suggests it's unique in this server).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context for photo retrieval, or comparisons to other property data tools (e.g., propertyv2_property_details_by_zpid might include photos). This leaves the agent without usage direction beyond the basic purpose.

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

price_tax_history_price_and_tax_historyC

Price and Tax history of a property by ZPID

ParametersJSON Schema
NameRequiredDescriptionDefault
zpidNoThe zpid can be extracted from the searching endpoints (/search , /search_url…), or from a property's URL.
urlNoProperty details URL - eg :https://www.zillow.com/homedetails/15626-Laurel-Heights-Dr-Houston-TX-77084/28253016_zpid/

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves historical data but doesn't specify whether this is read-only (implied by 'history'), what format the output takes, potential rate limits, authentication needs, or error conditions. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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?

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It could be slightly improved by adding a brief usage note, but it avoids redundancy and waste, earning a high score for conciseness.

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

Completeness3/5

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

Given the tool's moderate complexity (retrieving historical data with two parameters), no annotations, and no output schema, the description is minimally adequate. It states what the tool does but lacks details on output format, error handling, or behavioral traits. With schema coverage at 100%, the description meets a basic threshold but doesn't fully compensate for the missing context.

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%, with clear documentation for both parameters ('zpid' and 'url'). The description doesn't add meaning beyond the schema, such as explaining the relationship between these parameters (e.g., if one is preferred over the other) or usage examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

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 clearly states the tool's purpose: retrieving 'Price and Tax history of a property by ZPID'. It specifies the verb ('history'), resource ('property'), and key identifier ('ZPID'). However, it doesn't explicitly differentiate from sibling tools like 'zestimate_history_zestimate_history' or 'propertyv2_property_details_by_zpid', which might offer overlapping or related data.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or comparisons to sibling tools (e.g., 'zestimate_history_zestimate_history' for Zestimate trends or 'propertyv2_property_details_by_zpid' for general details), leaving the agent to infer usage based on the name alone.

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

property_deprecatedC

Get a property's details by its zpid

ParametersJSON Schema
NameRequiredDescriptionDefault
zpidNoThe zpid can be extracted from the searching endpoints (/search , /search_url…), or from a property's URL.
urlNoProperty details URL - eg :https://www.zillow.com/homedetails/15626-Laurel-Heights-Dr-Houston-TX-77084/28253016_zpid/

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose whether this is a read-only operation, potential rate limits, authentication needs, error conditions, or what 'details' include, leaving significant gaps.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a tool that presumably returns property details. It doesn't explain what 'details' encompass, potential response formats, or error handling, leaving the agent with insufficient context for reliable use.

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 parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond implying 'zpid' is the primary identifier, meeting the baseline for high schema coverage.

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 clearly states the action ('Get') and resource ('a property's details'), specifying it's done 'by its zpid'. However, it doesn't differentiate from sibling 'propertyv2_property_details_by_zpid' which appears to serve a similar purpose, preventing a perfect score.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'propertyv2_property_details_by_zpid' or other property-related tools. The description lacks context about prerequisites or exclusions, offering minimal usage direction.

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

propertyv2_property_details_by_zpidC

Get a property's details by its zpid

ParametersJSON Schema
NameRequiredDescriptionDefault
zpidNoThe zpid can be extracted from the searching endpoints (/search , /search_url…), or from a property's URL.
urlNoProperty details URL - eg :https://www.zillow.com/homedetails/15626-Laurel-Heights-Dr-Houston-TX-77084/28253016_zpid/

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It states this is a 'Get' operation, implying read-only behavior, but doesn't disclose any behavioral traits such as authentication requirements, rate limits, response format, or error handling. For a tool with no annotations, this leaves significant gaps in understanding how it behaves beyond the basic purpose.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and uses clear, direct language. Every word earns its place, making it easy to parse quickly without unnecessary elaboration.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a tool with 2 parameters. It lacks information on behavioral aspects like safety, response format, or error handling. While the purpose is clear, the overall context for an AI agent to use this tool effectively is insufficient, especially without structured data to fill the gaps.

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%, with both parameters ('zpid' and 'url') well-documented in the schema. The description adds no additional parameter semantics beyond implying 'zpid' is the primary lookup method. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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 clearly states the verb ('Get') and resource ('a property's details'), specifying the lookup method ('by its zpid'). It distinguishes from siblings like search tools that find properties rather than retrieve details for a known property. However, it doesn't explicitly differentiate from similar tools like 'property_deprecated' or 'photos_photos_of_a_property' that might also provide property details.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention whether to use this for known zpids versus other search methods, nor does it reference sibling tools like 'search_address_search_for_a_property_by_address' for unknown properties. The only implied usage is when you have a zpid, but no explicit context or exclusions are provided.

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

rent_estimate_rent_zestimateC

Returns a property's rent zestimate and it's comparable properties in the same area.

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYesExample value: 1545 Yale St, Santa Monica, CA 90404
activeTypesNoSimilarFloorPlans filter: Possible values: any (Default) active (Active Rentals) inactive (Inactive Rentals)
activatedDaysNo[SIMILARFLOORPLANS] Filter for Active Rentals within X days: Possible values: any (Default) 30 (Within 30 days) 15 (Within 15 days) 7 (Within 7 days)
deactivatedDaysNo[SIMILARFLOORPLANS] Filter for inactive rentals within X days: Possible values: 30 (Within 30 days (max)) 15 (Within 15 days) 7 (Within 7 days)
distanceInMilesNo[SIMILARFLOORPLANS] Filter for distance in Miles: Possible values: any 1 2 3 4 5
propertyTypesNo[SIMILARFLOORPLANS] Filter for Property Types: (To choose multiple values separate with comma eg : house,condo) Possible values: any (Default) apartment house townhouse condo
bedroomsNo[SIMILARFLOORPLANS] Filter for number of bedrooms: (To choose multiple values separate with comma eg : 0,1,2) Possible values: 0 1 2 3 4plus
petsNo[SIMILARFLOORPLANS] Filter for Pets: (To choose multiple values separate with comma eg : dogs,cats) Possible values: any (Default) dogs cats
laundryNo[SIMILARFLOORPLANS] Filter for Laundry: (To choose multiple values separate with comma eg : inUnit,shared) Possible values: any (Default) inUnit shared
amenitiesNo[SIMILARFLOORPLANS] Filter for amenities: (To choose multiple values separate with comma eg : cooling,parking) Possible values: any (Default) cooling heating parking

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns data but doesn't mention potential limitations like rate limits, authentication requirements, error handling, or data freshness. For a tool with 10 parameters and no structured safety hints, this leaves significant gaps in understanding its operational behavior.

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?

The description is a single, efficient sentence that front-loads the core functionality. It avoids unnecessary words and directly states the tool's purpose. However, it could be slightly improved by clarifying 'it's' to 'its' for grammatical precision, but this doesn't significantly impact clarity.

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

Completeness3/5

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

Given the complexity (10 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool returns but lacks details on output format, error conditions, or behavioral traits. The high schema coverage helps, but for a data-fetching tool with many filters, more context on result structure or usage scenarios would enhance completeness.

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 fully documents all 10 parameters with examples and enum values. The description adds no parameter-specific information beyond implying that 'address' is used to identify the property and that filters apply to 'comparable properties.' This meets the baseline for high schema coverage but doesn't enhance understanding of parameter roles or interactions.

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 clearly states the tool's purpose: 'Returns a property's rent zestimate and it's comparable properties in the same area.' It specifies the verb ('returns'), resource ('rent zestimate'), and scope ('comparable properties in the same area'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'similar_rent_properties_similar_for_rent_properties' or 'market_data_rental_market_trends', which prevents a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a valid address, or compare it to sibling tools like 'similar_rent_properties_similar_for_rent_properties' for similar functionality. Usage is implied by the purpose but lacks explicit context or exclusions.

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

schools_nearby_schoolsC

Nearby schools of a property by ZPID

ParametersJSON Schema
NameRequiredDescriptionDefault
zpidNoThe zpid can be extracted from the searching endpoints (/search , /search_url…), or from a property's URL.
urlNoProperty details URL - eg :https://www.zillow.com/homedetails/15626-Laurel-Heights-Dr-Houston-TX-77084/28253016_zpid/

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states what the tool does without disclosing behavioral traits such as rate limits, authentication needs, error handling, or output format. For a tool with no annotations, this is a significant gap in transparency.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects, output format, and usage context. For a tool with 2 parameters and no structured support, the description should provide more guidance to be fully helpful.

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 both parameters (zpid and url) with clear descriptions. The description adds no additional meaning beyond the schema, such as usage examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.

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 clearly states the tool's purpose: to find nearby schools for a property identified by ZPID. It specifies the verb ('Nearby schools') and resource ('a property'), making the function evident. However, it doesn't differentiate from sibling tools, which are unrelated (e.g., agent details, market data, photos), so it lacks explicit sibling distinction.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions that ZPID can be extracted from searching endpoints or URLs, but this is parameter documentation, not usage context. There's no mention of prerequisites, constraints, or comparisons to other tools, leaving the agent without clear direction.

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

search_address_search_for_a_property_by_addressC

Search for a property by address.

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYesExample value: 1161 Natchez Dr College Station Texas 77845

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the action ('Search') but doesn't disclose behavioral traits such as whether it's read-only, requires authentication, has rate limits, returns structured data, or handles errors. For a search tool with zero annotation coverage, this is a significant gap in transparency.

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?

The description is a single, efficient sentence with no wasted words, making it front-loaded and easy to parse. However, it lacks structure like bullet points or examples that could enhance clarity without sacrificing conciseness.

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

Completeness2/5

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

Given the tool's complexity (a search operation with no output schema and no annotations), the description is incomplete. It doesn't explain what the search returns (e.g., property details, listings), potential limitations, or error handling, leaving the agent with insufficient context for effective use.

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?

The input schema has 100% description coverage, with the 'address' parameter documented as an example string. The description adds no additional meaning beyond the schema, such as format requirements or search scope. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose3/5

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

The description 'Search for a property by address' clearly states the verb ('Search') and resource ('property'), but it's vague about what 'property' entails (e.g., real estate listing, details) and doesn't differentiate from siblings like 'search_search_for_properties_by_neighborhood_city_or_zip' or 'search_coordinates_search_for_properties_by_coordinates'. It avoids tautology but lacks specificity.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, exclusions, or compare to sibling tools like those for searching by coordinates or neighborhood, leaving the agent without context for selection.

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

search_coordinates_search_for_properties_by_coordinatesC

Search for filtered properties by coordinates. You can select the output format (JSON , CSV , XLSX) using the optional \

ParametersJSON Schema
NameRequiredDescriptionDefault
latYesLatitude34.01822
longYesLongitude-118.504744
pageNoExample value: 0
statusNoStatus type of the properties Default : forSale -forSale -forRent -recentlySold
outputNoOutput format possible values : json (Default value) :Data in a JSON format csv : URL to the generated CSV file xlsx : URL to the generated XLSX (excel) file
sortNoSorting possible values : priorityscore: Default, saved: Date Saved, listingstatus: Listing Status, mostrecentchange: Most Recent Change, globalrelevanceex: Homes for You, featured: Verified Source, priced: Price (High to Low), pricea: Price (Low to High), paymentd: Payment (High to Low), paymenta: Payment (Low to High), days: Newest, beds: Bedrooms, baths: Bathrooms, size: Square Feet, lot: Lot Size, zest: Zestimate (High to Low), zesta: Zestimate (Low to High),
listing_typeNoListing Type possible values : By agent (Default value) By owner & other (for off market properties)
isSingleFamilyNoExample value:
isMultiFamilyNoExample value:
isApartmentNoExample value:
isCondoNoExample value:
isManufacturedNoExample value:
isTownhouseNoExample value:
isLotLandNoExample value:
dozNoDays on Zillow possible values : any: Any, 1: 1 day, 7: 7 days, 14: 14 days, 30: 30 days, 90: 90 days, 6m: 6 months, 12m: 12 months, 24m: 24 months, 36m: 36 months
price_minNoExample value: 0
price_maxNoExample value: 0
sqft_minNoExample value: 0
sqft_maxNoExample value: 0
monthlyPayment_minNoExample value: 0
monthlyPayment_maxNoExample value: 0
beds_minNoExample value: 0
beds_maxNoExample value: 0
baths_minNoExample value: 0
baths_maxNoExample value: 0
hoa_minNoExample value: 0
hoa_maxNoExample value: 0
hasPoolNoExample value:
hasGarageNoExample value:
built_minNoExample value: 0
built_maxNoExample value:
isForSaleByOwnerNoExample value:
isForSaleByAgentNoExample value:
isCityViewNoExample value:
isWaterfrontNoExample value:
isPublicSchoolNoExample value:
isPrivateSchoolNoExample value:
isMountainViewNoExample value:
singleStoryNoExample value:
onlyPriceReductionNoExample value:
onlyRentalAcceptsApplicationsNoExample value:
isZillowOwnedOnlyNoExample value:
hasAirConditioningNoExample value:
isMiddleSchoolNoExample value:
isWaterViewNoExample value:
onlyRentalIncomeRestrictedNoExample value:
isComingSoonNoExample value:
isForSaleForeclosureNoExample value:
onlyWithPhotosNoExample value:
onlyRentalCatsAllowedNoExample value:
onlyRentalPetsAllowedNoExample value:
onlyRentalSmallDogsAllowedNoExample value:
onlyRentalLargeDogsAllowedNoExample value:
isAuctionNoExample value:
is3dHomeNoExample value:
isNewConstructionNoExample value:
greatSchoolsRating_minNoExample value: 0
isElementarySchoolNoExample value:
isParkViewNoExample value:
enableSchoolsNoExample value:
keywordsNoExample value:

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the output format selection, failing to describe critical behaviors like pagination (implied by the 'page' parameter), rate limits, authentication requirements, error handling, or what the search results actually contain. For a complex search tool with 61 parameters, this is a significant gap.

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?

The description is a single sentence that's reasonably concise, but it's incomplete and poorly structured. It ends abruptly with 'using the optional "' (likely a truncation error), which undermines clarity. While brief, it fails to front-load the most critical information about the tool's core functionality.

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

Completeness2/5

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

Given the tool's complexity (61 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain the search scope, result format, pagination, error conditions, or how the numerous filtering parameters interact. For a sophisticated property search tool, users need more guidance about what to expect from the results and how to effectively use the many available filters.

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 61 parameters thoroughly. The description adds minimal value beyond the schema by mentioning the output format parameter, but doesn't provide additional context about parameter interactions, default behaviors, or practical usage examples. This meets the baseline for high schema coverage.

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 clearly states the tool's purpose: 'Search for filtered properties by coordinates.' It specifies the verb ('search'), resource ('properties'), and key constraint ('by coordinates'). However, it doesn't distinguish this from sibling tools like 'search_address_search_for_a_property_by_address' or 'search_polygon_search_for_properties_by_polygon' which offer alternative search methods.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions an optional output format parameter but doesn't explain when coordinate-based searching is preferable to address-based or polygon-based searches, nor does it mention any prerequisites or exclusions for usage.

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

search_for_agentsC

Search for agents by location and name

ParametersJSON Schema
NameRequiredDescriptionDefault
locationYesExample value: houston, tx
nameNoExample value:
pageNoExample value: 0
specialtyNoExample value:
languageNoExample value:

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the tool is for searching, implying a read-only operation, but doesn't disclose behavioral traits such as pagination handling (implied by the 'page' parameter), rate limits, authentication needs, or what the search returns (e.g., list of agents with basic info). This leaves gaps in understanding how the tool behaves beyond its basic function.

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

Conciseness5/5

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

The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently states the key parameters, making it easy to parse quickly.

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

Completeness2/5

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

Given the complexity of a search tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format (e.g., what data about agents is included), how pagination works with the 'page' parameter, or how multiple criteria interact. This leaves significant gaps for an agent to use the tool effectively.

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%, with all parameters documented in the schema (e.g., 'location' as required, 'page' with default '0'). The description adds minimal value by mentioning 'location and name' as search criteria, which aligns with the schema but doesn't provide additional semantics like format hints or usage examples beyond what's already in the schema descriptions.

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 clearly states the tool's purpose: 'Search for agents by location and name'. It specifies the verb ('Search') and resource ('agents'), and mentions two search criteria. However, it doesn't differentiate from sibling tools like 'agents_active_listings' or 'agents_past_sales' which might also involve agent data, though those seem to serve different purposes (listing vs. searching).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'agent_details_by_username' for specific agent details or 'search_for_properties_by_neighborhood_city_or_zip' for property searches, leaving the agent to infer usage based on context alone.

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

search_mls_search_by_mlsC

Search for properties by their MLS ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
mlsYesExample value: SR25078433

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool searches for properties, implying a read-only operation, but doesn't cover aspects like authentication requirements, rate limits, error handling, or the format of results (e.g., whether it returns a list or single property). This leaves significant gaps for an agent to understand how to interact with it effectively.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's front-loaded and easy to parse, making it highly concise and well-structured.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete for a search tool. It doesn't explain what the search returns (e.g., property details, a list), potential limitations, or how to handle errors. With one parameter and no behavioral context, it leaves the agent under-informed about the tool's full operation.

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?

The input schema has 100% description coverage, with the 'mls' parameter documented as a string with an example. The description adds no additional meaning beyond this, such as explaining what an MLS ID is or its format constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

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 clearly states the action ('Search for properties') and the resource ('by their MLS ID'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'search_address_search_for_a_property_by_address' or 'search_coordinates_search_for_properties_by_coordinates', which also search for properties but use different criteria.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a valid MLS ID, or compare it to other search tools in the sibling list, leaving the agent to infer usage from the name alone.

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

search_polygon_search_for_properties_by_polygonC

Search for filtered properties by polygon coordinates. For a list of properties, you can select the output format (JSON , CSV , XLSX) using the optional \

ParametersJSON Schema
NameRequiredDescriptionDefault
polygonYesIt is required if the location is empty. Format: lat lng,lat1 lng1,lat2 lng2 34.03959576441558 -118.50636536779786,34.0418716916327 -118.50276047888184,34.042440663894304 -118.49846894445801,34.04201393505594 -118.49417741003418,34.04087598099002 -118.4897142142334,34.03945351693672 -118.48525101843262,34.03788877892429 -118.48095948400879,34.03618175908096 -118.47683961096192,34.034190192514366 -118.47271973791504,34.031629538228394 -118.46962983312989,34.02835747861639 -118.4677415579834,34.02
pageNoExample value: 0
outputNoOutput format possible values : json (Default value) :Data in a JSON format csv : URL to the generated CSV file xlsx : URL to the generated XLSX (excel) file
statusNoStatus type of the properties Default : forSale -forSale -forRent -recentlySold
sortSelectionNoSorting possible values : days: Newest (Default value), saved: Date Saved, listingstatus: Listing Status, mostrecentchange: Most Recent Change, globalrelevanceex: Homes for You, featured: Verified Source, priced: Price (High to Low), pricea: Price (Low to High), paymentd: Payment (High to Low), paymenta: Payment (Low to High), beds: Bedrooms, baths: Bathrooms, size: Square Feet, lot: Lot Size, zest: Zestimate (High to Low), zesta: Zestimate (Low to High),
listing_typeNoListing Type possible values : by_agent : By agent (Default value) by_owner_other : By owner & other (for off market properties)
isSingleFamilyNoExample value:
isMultiFamilyNoExample value:
isApartmentNoExample value:
isCondoNoExample value:
isManufacturedNoExample value:
isTownhouseNoExample value:
isLotLandNoExample value:
dozNoDays on Zillow (For Sale/Rent listings)/ Sold In Last (Sold listings) Possible values : any: Any, 1: 1 day, 7: 7 days, 14: 14 days, 30: 30 days, 90: 90 days, 6m: 6 months, 12m: 12 months, 24m: 24 months, 36m: 36 months
price_minNoExample value: 0
price_maxNoExample value: 0
sqft_minNoExample value: 0
sqft_maxNoExample value: 0
monthlyPayment_minNoExample value: 0
monthlyPayment_maxNoExample value: 0
beds_minNoExample value: 0
beds_maxNoExample value: 0
baths_minNoExample value: 0
baths_maxNoExample value: 0
hoa_minNoExample value: 0
hoa_maxNoExample value: 0
hasPoolNoExample value:
hasGarageNoExample value:
built_minNoExample value: 0
built_maxNoExample value:
isForSaleByOwnerNoExample value:
isForSaleByAgentNoExample value:
isCityViewNoExample value:
isWaterfrontNoExample value:
isPublicSchoolNoExample value:
isPrivateSchoolNoExample value:
isMountainViewNoExample value:
singleStoryNoExample value:
onlyPriceReductionNoExample value:
onlyRentalAcceptsApplicationsNoExample value:
isZillowOwnedOnlyNoExample value:
hasAirConditioningNoExample value:
isMiddleSchoolNoExample value:
isWaterViewNoExample value:
onlyRentalIncomeRestrictedNoExample value:
isComingSoonNoExample value:
isForSaleForeclosureNoExample value:
onlyWithPhotosNoExample value:
onlyRentalCatsAllowedNoExample value:
onlyRentalPetsAllowedNoExample value:
onlyRentalSmallDogsAllowedNoExample value:
onlyRentalLargeDogsAllowedNoExample value:
isAuctionNoExample value:
is3dHomeNoExample value:
isNewConstructionNoExample value:
parkingSpots_minNoExample value: 0
greatSchoolsRating_minNoExample value: 0
isElementarySchoolNoExample value:
isParkViewNoExample value:
enableSchoolsNoExample value:
lotSize_maxNoin sqft0
keywordsNoExample value:

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the output format option, failing to describe critical behaviors like pagination (implied by the 'page' parameter), rate limits, authentication needs, error handling, or what the search returns (e.g., property list details). For a complex search tool with 62 parameters, this leaves significant gaps in understanding how the tool behaves.

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?

The description is a single run-on sentence that awkwardly introduces the output format parameter. It's front-loaded with the core purpose but lacks structure and clarity. While concise, the phrasing is slightly confusing (e.g., 'For a list of properties, you can select...'), making it less efficient than it could be.

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

Completeness2/5

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

Given the tool's complexity (62 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain the return format beyond output type options, omits pagination behavior, and provides no context on search limitations or result structure. For a tool with such extensive filtering capabilities, more guidance on usage and outcomes is necessary for effective agent operation.

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 parameters thoroughly. The description adds minimal value by mentioning the optional output format, but it doesn't provide additional context like typical use cases for polygon searches or how parameters interact. With high schema coverage, the baseline is 3, as the description doesn't significantly enhance parameter understanding beyond the 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 clearly states the tool's purpose: 'Search for filtered properties by polygon coordinates.' It specifies the verb ('search'), resource ('properties'), and key constraint ('by polygon coordinates'), making the intent unambiguous. However, it doesn't explicitly differentiate this from sibling tools like 'search_coordinates_search_for_properties_by_coordinates' or 'search_search_for_properties_by_neighborhood_city_or_zip', which would require a 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions an optional output format parameter but doesn't clarify when this polygon-based search is appropriate compared to other search tools (e.g., by address, coordinates, or neighborhood). Without any context or exclusions, the agent must infer usage from the tool name alone.

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

search_search_for_properties_by_neighborhood_city_or_zipC

Search for filtered properties by neighborhood, city, or ZIP code. PS : To search for an address of a property, use the \

ParametersJSON Schema
NameRequiredDescriptionDefault
locationYesLocation can be an address, neighborhood, city, or ZIP code.
pageNoExample value: 0
outputNoOutput format possible values : json (Default value) :Data in a JSON format csv : URL to the generated CSV file xlsx : URL to the generated XLSX (excel) file
statusNoStatus type of the properties Default : forSale -forSale -forRent -recentlySold
sortSelectionNoSorting possible values : days: Newest (Default value), saved: Date Saved, listingstatus: Listing Status, mostrecentchange: Most Recent Change, globalrelevanceex: Homes for You, featured: Verified Source, priced: Price (High to Low), pricea: Price (Low to High), paymentd: Payment (High to Low), paymenta: Payment (Low to High), beds: Bedrooms, baths: Bathrooms, size: Square Feet, lot: Lot Size, zest: Zestimate (High to Low), zesta: Zestimate (Low to High),
listing_typeNoListing Type possible values : by_agent : By agent (Default value) by_owner_other : By owner & other (for off market properties)
isSingleFamilyNoExample value:
isMultiFamilyNoExample value:
isApartmentNoExample value:
isCondoNoExample value:
isManufacturedNoExample value:
isTownhouseNoExample value:
isLotLandNoExample value:
dozNoDays on Zillow (For Sale/Rent listings)/ Sold In Last (Sold listings) Possible values : any: Any, 1: 1 day, 7: 7 days, 14: 14 days, 30: 30 days, 90: 90 days, 6m: 6 months, 12m: 12 months, 24m: 24 months, 36m: 36 months
price_minNoExample value: 0
price_maxNoExample value: 0
sqft_minNoExample value: 0
sqft_maxNoExample value: 0
monthlyPayment_minNoExample value: 0
monthlyPayment_maxNoExample value: 0
beds_minNoExample value: 0
beds_maxNoExample value: 0
baths_minNoExample value: 0
baths_maxNoExample value: 0
hoa_minNoExample value: 0
hoa_maxNoExample value: 0
hasPoolNoExample value:
hasGarageNoExample value:
built_minNoExample value: 0
built_maxNoExample value:
isForSaleByOwnerNoExample value:
isForSaleByAgentNoExample value:
isCityViewNoExample value:
isWaterfrontNoExample value:
isPublicSchoolNoExample value:
isPrivateSchoolNoExample value:
isMountainViewNoExample value:
singleStoryNoExample value:
onlyPriceReductionNoExample value:
onlyRentalAcceptsApplicationsNoExample value:
isZillowOwnedOnlyNoExample value:
hasAirConditioningNoExample value:
isMiddleSchoolNoExample value:
isWaterViewNoExample value:
onlyRentalIncomeRestrictedNoExample value:
isComingSoonNoExample value:
isForSaleForeclosureNoExample value:
onlyWithPhotosNoExample value:
onlyRentalCatsAllowedNoExample value:
onlyRentalPetsAllowedNoExample value:
onlyRentalSmallDogsAllowedNoExample value:
onlyRentalLargeDogsAllowedNoExample value:
isAuctionNoExample value:
is3dHomeNoExample value:
isNewConstructionNoExample value:
parkingSpots_minNoExample value: 0
greatSchoolsRating_minNoExample value: 0
isElementarySchoolNoExample value:
isParkViewNoExample value:
enableSchoolsNoExample value:
lotSize_minNoin sqft0
lotSize_maxNoin sqft0
keywordsNoExample value:

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only mentions it's a search tool with filtering capabilities. It doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior (implied by 'page' parameter but not explained), or what happens when no results are found. For a complex search tool with 63 parameters, this is a significant gap.

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

Conciseness2/5

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

The description is extremely brief (one incomplete sentence) for a tool with 63 parameters. While brevity can be good, this is under-specified rather than concise. The second sentence is cut off ('use the "'), making it structurally flawed. It fails to front-load critical information about this being a comprehensive property search with numerous filters.

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

Completeness2/5

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

Given the tool's complexity (63 parameters, no annotations, no output schema), the description is woefully incomplete. It doesn't explain the search scope, result format, pagination, error conditions, or how the numerous filters interact. The schema documents parameters but doesn't provide holistic context. For such a rich tool, the description should do much more to guide effective use.

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%, meaning all parameters are documented in the schema itself. The description adds minimal value beyond the schema - it only mentions the 'location' parameter context (neighborhood, city, or ZIP code) and hints at filtering. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though the description could have better explained how parameters interact or typical usage patterns.

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 clearly states the tool's purpose: 'Search for filtered properties by neighborhood, city, or ZIP code.' It specifies the verb ('search'), resource ('properties'), and scope ('filtered by neighborhood, city, or ZIP code'). However, it doesn't explicitly distinguish this tool from its many sibling search tools (e.g., search_address, search_coordinates, search_polygon), which would be needed for a perfect score.

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

Usage Guidelines2/5

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

The description provides minimal usage guidance. It mentions an alternative for address searches ('To search for an address of a property, use the...'), but this is incomplete (cut off mid-sentence). It doesn't explain when to use this tool versus other search siblings like search_coordinates or search_polygon, nor does it provide any context about prerequisites, typical use cases, or limitations.

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

search_url_list_of_properties_by_urlC

Get a list of properties by providing the zillow search results URL You can select the output format (JSON , CSV , XLSX) using the optional \

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesExample value: https://www.zillow.com/homes/for_sale/2_p/?searchQueryState=%7B%22pagination%22%3A%7B%22currentPage%22%3A2%7D%2C%22mapBounds%22%3A%7B%22west%22%3A-112.39143704189931%2C%22east%22%3A-110.78468655361806%2C%22south%22%3A32.79032628812945%2C%22north%22%3A33.7227901388417%7D%2C%22isMapVisible%22%3Atrue%2C%22filterState%22%3A%7B%22con%22%3A%7B%22value%22%3Afalse%7D%2C%22apa%22%3A%7B%22value%22%3Afalse%7D%2C%22mf%22%3A%7B%22value%22%3Afalse%7D%2C%22ah%22%3A%7B%22value%22%3Atrue%7D%2C%22sort%22%3A%7B%22value%22%3A%22globalrelevanceex%22%7D%2C%22land%22%3A%7B%22value%22%3Afalse%7D%2C%22manu%22%3A%7B%22value%22%3Afalse%7D%2C%22apco%22%3A%7B%22value%22%3Afalse%7D%7D%2C%22isListVisible%22%3Atrue%7D
pageNoExample value: 33
outputNoOutput format possible values : json (Default value) :Data in a JSON format csv : URL to the generated CSV file xlsx : URL to the generated XLSX (excel) file
listing_typeNoListing Type possible values : By agent (Default value) By owner & other (for off market properties)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions output format options but doesn't describe what the tool actually does beyond 'Get a list of properties'. It doesn't disclose whether this is a read-only operation, whether it requires authentication, rate limits, pagination behavior, error conditions, or what the returned data structure looks like. For a tool with 4 parameters and no annotations, this leaves significant behavioral questions unanswered.

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?

The description is reasonably concise at two sentences. The first sentence states the core purpose, and the second mentions the output format option. However, the second sentence is incomplete (ends with 'using the optional "' which appears truncated) and could be more polished. Overall, it's front-loaded with the main purpose and avoids unnecessary verbiage.

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

Completeness2/5

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

Given the tool's complexity (4 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain what kind of properties are returned, how many, in what structure, or what the URL parameter should contain. With no output schema and no behavioral annotations, the description should provide more context about the tool's operation and results. The incomplete second sentence further reduces completeness.

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 parameters thoroughly. The description adds minimal value by mentioning the optional output format parameter, but doesn't provide additional context about parameter interactions, dependencies, or real-world usage patterns beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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 clearly states the tool's purpose: 'Get a list of properties by providing the zillow search results URL'. It specifies the verb ('Get'), resource ('list of properties'), and key input mechanism ('by providing the zillow search results URL'). However, it doesn't explicitly differentiate from sibling tools like 'search_address_search_for_a_property_by_address' or 'search_coordinates_search_for_properties_by_coordinates', which appear to be alternative search methods.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions an optional output format parameter but doesn't explain when this URL-based search approach is preferred over address-based, coordinate-based, or other search methods available in the sibling tools. There's no mention of prerequisites, limitations, or typical use cases for URL-based property searches.

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

similar_properties_similar_for_sale_propertiesC

List of similar for sale properties by Zpid or URL or address

ParametersJSON Schema
NameRequiredDescriptionDefault
zpidNoThe zpid can be extracted from the searching endpoints (/search , /search_url...), or from a property's URL.
urlNoProperty details URL - eg :https://www.zillow.com/homedetails/15626-Laurel-Heights-Dr-Houston-TX-77084/28253016_zpid/
addressNoExample value:

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists properties but doesn't describe output format, pagination, rate limits, or error handling. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates the tool's function and input options, making it easy to parse quickly.

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

Completeness2/5

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

Given the tool's complexity (listing similar properties) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'similar' means, the scope of results, or return format, leaving the agent with insufficient context to use the tool effectively.

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 three parameters (zpid, url, address) with descriptions. The description adds no additional meaning beyond implying these are alternative identifiers, aligning with the baseline score when schema does the heavy lifting.

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 clearly states the action ('List') and resource ('similar for sale properties'), specifying it operates on properties identified by Zpid, URL, or address. It distinguishes from siblings like 'similar_rent_properties_similar_for_rent_properties' and 'similar_sold_properties_similar_sold_properties' by focusing on 'for sale' properties, though it doesn't explicitly contrast them.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a valid property identifier, or compare it to other search tools like 'search_address_search_for_a_property_by_address' or 'propertyv2_property_details_by_zpid' for context.

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

similar_rent_properties_similar_for_rent_propertiesC

List of similar for rent properties by Zpid or URL or address

ParametersJSON Schema
NameRequiredDescriptionDefault
zpidNoThe zpid can be extracted from the searching endpoints (/search , /search_url...), or from a property's URL.
urlNoProperty details URL - eg :https://www.zillow.com/homedetails/15626-Laurel-Heights-Dr-Houston-TX-77084/28253016_zpid/
addressNoExample value:

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists similar properties but doesn't describe key behaviors: whether it's a read-only operation, what the output format looks like (e.g., list structure, pagination), any rate limits, or error conditions. For a tool with zero annotation coverage, this is a significant gap in transparency.

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?

The description is a single, efficient sentence that directly states the tool's purpose and input options without unnecessary words. It's front-loaded with the core function ('List of similar for rent properties'), making it easy to parse. However, it could be slightly more structured (e.g., separating purpose from input guidance) for optimal clarity.

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

Completeness2/5

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

Given the tool's complexity (a search/list operation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects (e.g., read-only nature, output format), usage guidelines, or how to handle the optional parameters. For a tool in this context, more detail is needed to adequately guide an AI agent.

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%, meaning the input schema already documents all three parameters (zpid, url, address) with descriptions. The description adds minimal value by listing the input options ('by Zpid or URL or address') but doesn't provide additional semantics beyond what's in the schema (e.g., format details, examples beyond the schema's url example, or how parameters interact). This meets the baseline of 3 when schema coverage is high.

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 clearly states the tool's purpose: 'List of similar for rent properties' with specific input options (by Zpid, URL, or address). It uses a specific verb ('List') and resource ('similar for rent properties'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'similar_properties_similar_for_sale_properties' or 'similar_sold_properties_similar_sold_properties', which would be needed for a score of 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or compare it to sibling tools (e.g., 'similar_properties_similar_for_sale_properties' for sale properties). Usage is implied through the input parameters but not explicitly stated, leaving gaps for an AI agent to infer context.

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

similar_sold_properties_similar_sold_propertiesC

List of similar sold properties by Zpid or URL or address

ParametersJSON Schema
NameRequiredDescriptionDefault
zpidNoThe zpid can be extracted from the searching endpoints (/search , /search_url...), or from a property's URL.
urlNoProperty details URL - eg :https://www.zillow.com/homedetails/15626-Laurel-Heights-Dr-Houston-TX-77084/28253016_zpid/
addressNoExample value:

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists similar sold properties but doesn't describe what 'similar' means (e.g., criteria like location, price, size), how many results are returned, pagination behavior, rate limits, authentication needs, or error handling. This leaves significant gaps for an agent to understand the tool's behavior.

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?

The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words and gets straight to the point, though it could be slightly more structured (e.g., separating input methods with commas for clarity).

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'similar sold properties' entails (e.g., matching criteria, result format), behavioral aspects like rate limits or errors, or how to interpret results. For a tool with 3 parameters and no structured output guidance, more context is needed for effective use.

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%, with each parameter (zpid, url, address) documented in the schema. The description adds minimal value by listing the parameter types ('by Zpid or URL or address'), but doesn't provide additional context like usage examples, constraints, or relationships between parameters beyond what the schema already covers.

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 clearly states the tool's purpose: 'List of similar sold properties by Zpid or URL or address'. It specifies the action (list), resource (similar sold properties), and input methods (Zpid, URL, or address). However, it doesn't explicitly differentiate from sibling tools like 'similar_properties_similar_for_sale_properties' or 'similar_rent_properties_similar_for_rent_properties', which handle different property types.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'similar_properties_similar_for_sale_properties' (for sale) or 'similar_rent_properties_similar_for_rent_properties' (for rent), nor does it specify prerequisites, exclusions, or contextual cues for selecting this tool over others.

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

walk_transit_bike_score_walk_transit_and_bike_scoreC

Get Walk, Transit and Bike Score of a property by zpid

ParametersJSON Schema
NameRequiredDescriptionDefault
zpidNoThe zpid can be extracted from the searching endpoints (/search , /search_url…), or from a property's URL.20485700
urlNoProperty details URL - eg :https://www.zillow.com/homedetails/15626-Laurel-Heights-Dr-Houston-TX-77084/28253016_zpid/

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves—e.g., whether it's a read-only operation, what the output format looks like, if there are rate limits, or if it requires authentication. For a tool with zero annotation coverage, this is a significant gap in transparency.

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?

The description is a single, efficient sentence: 'Get Walk, Transit and Bike Score of a property by zpid.' It's front-loaded with the core purpose and avoids unnecessary words. However, it could be slightly more structured by explicitly mentioning the optional 'url' parameter or output details, but it's still highly concise.

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

Completeness2/5

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

Given the tool's complexity (fetching specific property scores), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the scores represent, their format (e.g., numerical values, ranges), or any behavioral aspects like error handling. For a tool with no structured support, the description should provide more context to be fully helpful.

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?

The schema description coverage is 100%, so the schema already documents both parameters ('zpid' and 'url') with descriptions. The tool description adds no additional parameter semantics beyond what's in the schema, such as clarifying if both parameters are needed or how they interact. With high schema coverage, the baseline score of 3 is appropriate.

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 clearly states the tool's purpose: 'Get Walk, Transit and Bike Score of a property by zpid.' It specifies the action ('Get'), the resource ('Walk, Transit and Bike Score'), and the key identifier ('zpid'). However, it doesn't differentiate from siblings like 'propertyv2_property_details_by_zpid' or 'schools_nearby_schools', which might also provide property-related data, so it's not a perfect 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or sibling tools that might be better suited for different scenarios (e.g., using 'propertyv2_property_details_by_zpid' for general property info). This lack of context leaves the agent to guess based on the tool name alone.

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

zestimate_history_zestimate_historyC

Zestimate history by zpid

ParametersJSON Schema
NameRequiredDescriptionDefault
zpidNoThe zpid can be extracted from the searching endpoints (/search , /search_url…), or from a property's URL.
urlNoProperty details URL - eg :https://www.zillow.com/homedetails/15626-Laurel-Heights-Dr-Houston-TX-77084/28253016_zpid/

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does ('Zestimate history by zpid') without any information on permissions required, rate limits, data freshness, or what the output looks like (e.g., time series format). For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

Conciseness5/5

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

The description is extremely concise at just three words, front-loading the core purpose without any fluff. It efficiently communicates the tool's function, though this brevity contributes to gaps in other dimensions like guidelines and transparency.

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

Completeness2/5

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

Given the complexity of retrieving historical property data, no annotations, and no output schema, the description is incomplete. It lacks details on output format, data scope, error handling, and how it differs from sibling tools. The minimal description doesn't provide enough context for an agent to use this tool effectively without additional trial or documentation.

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?

The description adds no parameter semantics beyond what the input schema provides. Schema description coverage is 100%, with clear documentation for both 'zpid' and 'url' parameters. The description itself doesn't explain parameters, their relationships, or usage examples. Baseline score of 3 is appropriate as the schema adequately covers parameters, but the description doesn't add value in this dimension.

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 clearly states the tool's purpose: retrieving Zestimate history for a property using a zpid. It specifies the verb ('Zestimate history') and resource ('by zpid'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'price_tax_history_price_and_tax_history' or 'propertyv2_property_details_by_zpid', which might offer overlapping or related property data.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It mentions that zpid can be extracted from searching endpoints or property URLs, but this is parameter information, not usage context. There's no mention of when to choose this tool over siblings like 'price_tax_history_price_and_tax_history' or 'rent_estimate_rent_zestimate' for historical property data.

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

zhvi_rangeC

This endpoint provides monthly historical data for the Zillow Home Value Index (ZHVI) for a specified region. The ZHVI is a proprietary metric that captures median home values across a wide variety of geographies and housing types, reflecting trends in the real estate market over time.

ParametersJSON Schema
NameRequiredDescriptionDefault
locationYesExample value: 11771
typeNoHome type

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the data is 'monthly historical' and describes ZHVI as a 'proprietary metric,' but it doesn't cover critical aspects like rate limits, authentication needs, data freshness, pagination, or error handling. This leaves significant gaps for an AI agent to understand operational constraints.

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?

The description is appropriately sized with two sentences that are front-loaded: the first sentence states the core functionality, and the second provides context about ZHVI. There's no wasted text, but it could be slightly more structured by explicitly separating purpose from additional context.

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

Completeness3/5

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

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose and high-level data context but lacks behavioral details, usage guidelines, and output information. Without annotations or an output schema, the description should do more to compensate, but it provides a basic foundation.

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 both parameters ('location' and 'type') with descriptions. The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining valid formats for 'location' (e.g., ZIP code) or clarifying 'type' options. Baseline 3 is appropriate when the schema handles parameter documentation adequately.

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 clearly states the tool's purpose: 'provides monthly historical data for the Zillow Home Value Index (ZHVI) for a specified region.' It specifies the verb ('provides'), resource ('monthly historical data for ZHVI'), and scope ('for a specified region'). However, it doesn't explicitly differentiate from sibling tools like 'zestimate_history_zestimate_history' or 'market_data_rental_market_trends', which might offer related but different data.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, prerequisites, or specific contexts for usage. For example, it doesn't clarify if this is for historical trends versus current estimates or how it differs from 'zestimate_history_zestimate_history'.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 37 tool updates
    • First observedagent_details_by_username
    • First observedagent_reviews
    • First observedagents_active_listings
    • First observedagents_past_sales
    • First observedagents_rental_listings
    • First observedbuilderscommunity_cards_builders_community_cards
    • First observedbuildersdetails_builders_details
    • First observedbuildersreviews_builders_reviews
    • First observedbuilderssearch_search_for_builders
    • First observedlenderdetails
    • First observedlenderreviews
    • First observedlendersearch
    • First observedmarket_data_rental_market_trends
    • First observedmarket_sale_overview
    • First observedmortgagerates_mortgage_rates
    • First observedother_professionalsdetails_professionals_details
    • First observedother_professionalsreviews_professionals_reviews
    • First observedother_professionalssearch_search_for_professionals
    • First observedphotos_photos_of_a_property
    • First observedprice_tax_history_price_and_tax_history
    • First observedproperty_deprecated
    • First observedpropertyv2_property_details_by_zpid
    • First observedrent_estimate_rent_zestimate
    • First observedschools_nearby_schools
    • First observedsearch_address_search_for_a_property_by_address
    • First observedsearch_coordinates_search_for_properties_by_coordinates
    • First observedsearch_for_agents
    • First observedsearch_mls_search_by_mls
    • First observedsearch_polygon_search_for_properties_by_polygon
    • First observedsearch_search_for_properties_by_neighborhood_city_or_zip
    • First observedsearch_url_list_of_properties_by_url
    • First observedsimilar_properties_similar_for_sale_properties
    • First observedsimilar_rent_properties_similar_for_rent_properties
    • First observedsimilar_sold_properties_similar_sold_properties
    • First observedwalk_transit_bike_score_walk_transit_and_bike_score
    • First observedzestimate_history_zestimate_history
    • First observedzhvi_range
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.6/5.0
Disambiguation3/5

Most tools target distinct resources like agents, builders, properties, or market data, but there is notable overlap in search tools (e.g., search_address_search_for_a_property_by_address, search_coordinates_search_for_properties_by_coordinates, search_search_for_properties_by_neighborhood_city_or_zip) that could confuse agents on which to use for location-based queries. Additionally, property_deprecated and propertyv2_property_details_by_zpid serve similar purposes, though the deprecated tag helps clarify.

Naming Consistency2/5

Naming is highly inconsistent with mixed patterns: some use snake_case (agent_details_by_username), some use camelCase-like concatenation (builderscommunity_cards_builders_community_cards), and others have verbose, redundant names (search_address_search_for_a_property_by_address). There is no uniform verb_noun structure, making it hard to predict tool names.

Tool Count2/5

With 37 tools, the count is excessive for a real estate data server, leading to bloat and potential confusion. Many tools could be consolidated (e.g., multiple similar property search variants), and the high number suggests poor scoping, making it cumbersome for agents to navigate efficiently.

Completeness4/5

The tool set covers a broad range of real estate domains including agents, builders, lenders, properties, market data, and searches, with good CRUD-like coverage for details, reviews, and listings. Minor gaps exist, such as lack of tools for updating or deleting data (likely read-only by design), but overall it provides comprehensive access to Zillow's data surface.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Zillow MCP Server

    sap156
    A
    license
    Not graded
    quality
    F
    maintenance
    Provides real-time access to Zillow real estate data, enabling property search, details, Zestimates, market trends, and mortgage calculations via natural language.
    14
    48
    MIT

  • Zillow MCP Server

    EmilyThaHuman
    A
    license
    Not graded
    quality
    D
    maintenance
    Integrates Zillow real estate data with AI assistants, enabling property search, neighborhood insights, and affordability calculations through natural language.
    14
    1
    MIT

  • zillow-mcp

    chrischall
    A
    license
    A
    quality
    A
    maintenance
    Enables natural-language access to Zillow real-estate data, including property search, details, Zestimate history, saved searches/homes, and market reports, by routing requests through the user's authenticated browser session.
    5
    20
    612
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BACH-AI-Tools/zillow56'

If you have feedback or need assistance with the MCP directory API, please join our Discord server