Zillow56 MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.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.
Average 2.9/5 across 37 of 37 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 'Get' which implies a read-only operation, but fails to describe any behavioral traits such as data freshness, rate limits, authentication needs, or what 'market rental data' entails (e.g., trends, averages, listings). 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 with no wasted words. It front-loads the core purpose ('Get market rental data') and includes essential details ('of a location by city or ZIP'), making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's function.
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 market data tools, no annotations, and no output schema, the description is incomplete. It lacks details on what the tool returns (e.g., data format, metrics like median rent or trends), behavioral constraints, or how it differs from similar tools. This leaves the agent with insufficient context to use the tool effectively without trial and error.
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 'location' parameter documented as 'Example value: houston, tx'. The description adds minimal value by specifying 'by city or ZIP', which slightly clarifies the parameter's semantics beyond the schema. Since schema coverage is high, the baseline score of 3 is appropriate, as the description compensates only marginally.
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 ('market rental data of a location'), specifying it can be by city or ZIP. It distinguishes itself from siblings like 'market_sale_overview' by focusing on rental data rather than sale data. However, it doesn't explicitly differentiate from 'rent_estimate_rent_zestimate', which might overlap in purpose.
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 such as 'rent_estimate_rent_zestimate' or 'search_search_for_properties_by_neighborhood_city_or_zip'. It lacks context on prerequisites, exclusions, or specific scenarios where this tool is preferred, leaving the agent to 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![zillow56 MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/zillow56/badges/card.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/zillow56)

Score Badge

Copy to your README.md:

[![zillow56 MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/zillow56/badges/score.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/zillow56)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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