Server Quality Checklist

Tool Scores

• search_propertiesA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavior, but it includes filter capabilities (lat/long, radius, square footage) that do not exist in the input schema. This is misleading about the tool's actual behavior. It does mention the summarized output and units, but the inaccuracies significantly reduce transparency.

  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 moderately concise and front-loaded with the main purpose. However, it includes extraneous details about non-existent filters, which adds confusion rather than value. It could be shorter and more accurate.

  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?

  The description is incomplete because it omits how filters combine and misleadingly includes unsupported filters. It also does not explain that address overrides area filters in the main text (only in the schema). For a tool with 8 parameters and no output schema, the description should be more precise and cover actual invocation constraints.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema already documents value formats for bedrooms and bathrooms. The description repeats that information and adds irrelevant parameters (lat/long, squareFootage) that are not in the schema, which can confuse an agent into using unsupported arguments. No meaningful added semantics for the actual parameters.

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

  Purpose5/5

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

  The description clearly states the tool searches RentCast's property records database and explicitly distinguishes it from active listings by instructing to use list_active_listings instead. The verb 'Search' plus the resource 'property records database' makes the purpose specific and unambiguous.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool versus list_active_listings, and advises using the returned id or address with get_property_details for full attributes. This directly addresses alternatives and complements sibling tools effectively.

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

• get_property_detailsA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the transparency burden. It discloses return format ('Returns the complete record as JSON; prices are USD, areas are in square feet'), data completeness caveats ('owner info where available'), and clarifies the scope ('single property'). It does not mention id/address precedence, which is already covered in the schema.

  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 moderately long but each sentence provides distinct value: what the tool fetches, how to look up, when to use it, return format, and what it is not. It is front-loaded with the core purpose and avoids redundancy.

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

  Completeness5/5

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

  No output schema exists, so the description effectively explains expected return content by listing structural attributes, features, tax assessments, last sale, and owner info. It also clarifies units and data availability, making the tool's behavior sufficiently predictable for 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?

  Schema coverage is 100%, so the parameters are well-documented in the schema. The description restates the two lookup options (id or address) but does not add extra meaning beyond what the schema already provides, such as formats or precedence details.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'Fetch the FULL record for a single property' and lists concrete attributes. It explicitly distinguishes from siblings by stating 'This is a property RECORD, not a for-sale/rent listing', making the tool's scope unambiguous.

  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 when-to-use guidance: 'Use this after search_properties to drill into one property, or on its own when you already have the exact address.' It also warns against using it for listings, though it does not explicitly name alternative tools like get_rent_estimate or list_active_listings.

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

• get_rent_estimateA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It explains the AVM mechanism, mentions automatic lookup via lookup_subject_attributes, and discloses return contents ('point rent estimate plus a low–high range ... and the top comparable rentals'). It does not disclose failure modes or rate limits, but it clearly describes observable behavior for a read-only estimation tool.

  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 dense paragraph that front-loads the main purpose, then covers input, recommendations, output, and usage context. No filler words, but it is somewhat long and could be tightened. Still, every sentence earns its place.

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

  Completeness4/5

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

  Given 9 parameters and no output schema, the description sufficiently covers the main intent, input alternatives, optional parameter improvements, output structure, and complementary sibling usage. It doesn't mention every parameter (e.g., comp_count) but the schema fully defines those, and the description adds the missing high-level context about AVM behavior and return values.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds valuable relationships: 'For the sharpest estimate, also pass the property's propertyType, bedrooms, bathrooms, and squareFootage — or set lookup_subject_attributes=true' and 'Give an address, or a lat/long.' This explains how parameters interact and which combinations are recommended, exceeding schema-only descriptions.

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

  Purpose5/5

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

  The description opens with a specific verb+resource: 'Estimate the fair-market LONG-TERM monthly rent for a property using RentCast's AVM.' This clearly distinguishes it from sibling get_value_estimate, which would be for property value rather than rent, and the explicit 'rent' and 'LONG-TERM monthly rent' phrases make the tool's purpose unambiguous.

  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?

  Provides explicit usage context: 'pair it with get_market_stats to compare an estimate against the zip-code average, or call it per-listing to rank rental opportunities.' It also offers input-method guidance ('Give an address, or a lat/long') and suggests parameter improvements for a sharper estimate. Missing a direct 'when not to use' or comparison with get_value_estimate, but the guidance is clear enough.

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

• get_market_statsA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses return behavior (summarized snapshot, omitted blocks when data is sparse), currency units (USD, rents per month), and data_type effects. It doesn't cover rate limits or auth, but these are likely common to all tools. The core behavioral aspects are well covered.

  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 five sentences, front-loaded with the tool's purpose, then usage guidance, then return semantics. Every sentence earns its place; there is no redundancy or filler.

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

  Completeness5/5

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

  Given there is no output schema, the description offers a complete picture: what metrics are returned, the units, how data_type affects output, and what happens when data is insufficient. For a moderate-complexity stats tool, this is fully sufficient.

  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?

  The input schema covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds value by clarifying data_type options ('sale stats, rental stats, or both') and the purpose of zip_code as a geographic baseline. history_range is not explicitly described in the description, but the schema covers it adequately.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Get aggregate market statistics and trends for a ZIP CODE' and lists specific metrics (sale/rent prices, days on market, etc.). It is distinct from sibling tools, which focus on individual properties or listings, and even mentions a sibling (get_rent_estimate) for comparison.

  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 explicitly says when to use the tool: 'Use this to establish the local baseline' and gives concrete examples (comparing a property's rent estimate, gauging whether an area is hot). It does not include explicit when-not-to-use or alternative tools, but the context is clear and actionable.

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

• get_value_estimateA
  4.6/5.0
  Behavior4/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 explains the return payload (point estimate, low–high range, comparable sales with attributes) and input alternatives (address vs lat/long, lookup_subject_attributes). While it does not mention side effects, permissions, or rate limits, the read-only nature is strongly implied by the word 'estimate' and the described output.

  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?

  At about 130 words across four sentences, the description is appropriately sized for a 9-parameter tool. Every sentence earns its place: purpose, sibling relationship, input options, return details, and use cases. It could be slightly more structured (e.g., bullet points), but it is not wasteful or redundant.

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

  Completeness5/5

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

  Despite having no output schema and no annotations, the description is remarkably complete. It covers the tool's purpose, input flexibility (address or coordinates, optional attributes), the effect of lookup_subject_attributes, the return shape (point value, range, comparable sales), and practical use cases. This is more than sufficient for an agent to select and invoke the tool correctly in most scenarios.

  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?

  The schema has 100% coverage with detailed parameter descriptions, so the baseline is 3. The description adds semantic value by grouping optional subject attributes (propertyType, bedrooms, bathrooms, squareFootage) and explaining the shortcut of setting lookup_subject_attributes=true. This helps an agent understand the intended filing-in strategy beyond what the schema alone provides.

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

  Purpose5/5

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

  The description uses a specific verb ('Estimate the current SALE (market) value') and resource ('RentCast's AVM'), and explicitly positions itself as the sale-price counterpart to get_rent_estimate. This clearly distinguishes it from sibling tools like get_rent_estimate and get_market_stats.

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

  Usage Guidelines5/5

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

  The description provides explicit use cases: gauging what a property is worth, computing a rent-to-value / gross-yield ratio alongside get_rent_estimate, or sanity-checking a list price. It also names the closest sibling (get_rent_estimate) as a counterpart, giving an agent clear guidance on when to select this tool.

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

• list_active_listingsA
  5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and does so impressively. It discloses that RentCast does not filter by price server-side and the agent must filter/rank by returned price. It also reveals ordering (most recently seen first), price units (USD, sale total vs monthly rent), and downstream API cost implications for the limit parameter.

  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 information-dense yet compact. It front-loads the core purpose, then covers scoping, return format, key caveats, and a workflow example. Every sentence earns its place without fluff or repetition.

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

  Completeness5/5

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

  Given an 8-parameter tool with no output schema, the description is remarkably complete. It specifies the return structure (id, address, price, beds/baths, square footage, days on market, status), explains the price filter absence, and shows how the tool fits into a larger workflow with sibling tools. No critical gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Though schema coverage is 100%, the description adds meaningful context: it explains how listing_type selects the market, how city+state work together, and warns that keeping limit modest matters because each downstream rent estimate is a separate API call. This goes beyond the schema's raw parameter definitions.

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

  Purpose5/5

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

  The description states the tool lists currently active sale or rental listings with a clear verb+resource+scope ('List CURRENTLY ACTIVE sale or rental listings for an area'), and explicitly distinguishes it from search_properties, which searches historical property records. This makes the purpose unambiguous and differentiates it from a sibling.

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

  Usage Guidelines5/5

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

  It says when to use this tool ('entry point for workflows') and provides a concrete example: 'find 3-bed listings in <city> under $X, then estimate rent for each' — feed each result's address to get_rent_estimate. It also explicitly contrasts with search_properties, offering an alternative and exclusion.

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