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

No annotations are provided, so the description carries the burden. It discloses concurrent data combining from 14 sources, but does not mention read-only behavior, authentication requirements, or potential rate limits. This is a moderate disclosure for a read-heavy aggregate tool.

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

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

The description is two sentences with no redundant information. The first sentence front-loads the core purpose, and the second sentence provides usage guidance, making it highly concise.

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

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

Given the complexity of aggregating 14 sources and only one parameter, the description adequately captures the tool's purpose and when to use it. However, it lacks details about output format, processing time, or any constraints, which would be beneficial for a comprehensive tool.

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

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

The single parameter 'bbl' has no description in the schema (0% coverage) and the tool description provides no additional meaning. The abbreviation is domain-specific but not explained, leaving the agent to infer its format and purpose.

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

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

The description clearly states the tool generates a comprehensive due diligence summary for a NYC property, listing 14 data sources. It distinguishes itself from sibling tools which are individual source-specific tools, making its aggregate purpose unambiguous.

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

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

It explicitly advises using this tool for a complete picture for investment analysis. While it doesn't specify when not to use it, the sibling context implicitly guides agents to use individual tools for single-source needs.

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

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

With no annotations, the description carries full burden. It explains that complaints are filed before violations, high volume is a red flag, and includes default limit and case-insensitive filtering. It does not mention pagination or rate limits but provides sufficient behavioral context.

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

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

The description is well-structured with a clear header, explanatory paragraph, and a bullet-like parameter list. It is concise with no redundant information, every sentence adds value.

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

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

Despite having an output schema (not shown), the description covers the tool's purpose, parameters, and the nature of 311 data. For a tool with 6 parameters, it provides sufficient context for correct usage without relying on the output schema.

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

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

Schema description coverage is 0%, so the description must compensate. It thoroughly explains all six parameters: address, bbl, complaint_type, since_year, status, and limit, including constraints and examples. This adds significant value beyond the schema.

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

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

The description clearly states it retrieves 311 service request complaints at or near a property address, specifies the data source (NYC Open Data), and lists complaint categories. It distinguishes from siblings like get_hpd_complaints or get_dob_complaints by focusing on 311 data.

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

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

Provides guidance on using either address or bbl, includes examples of complaint types and parameters, and explains the significance of 311 data as a leading indicator. However, it lacks explicit alternatives or when-not-to-use scenarios compared to sibling tools.

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

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

The description lacks annotations, so it must bear the full burden of behavioral disclosure. It describes the data returned (costs, status, etc.) but does not disclose any operational behavior such as read-only property, authentication needs, rate limits, or data freshness. This is insufficient for a read tool with no annotations.

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

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

The description is concise, consisting of three sentences with no redundancy. The first sentence states the action, the second details what is shown, and the third provides usage context. Every sentence adds value.

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

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

The description covers the main purpose and typical use, and an output schema exists to document return values. However, it lacks explanations for parameters (especially 'job_type' and 'limit') and does not mention any pagination or constraints. It is minimally adequate but not fully complete.

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

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

With 0% schema description coverage and 3 parameters, the description should provide meaningful explanations beyond the schema. It implies 'bbl' is a property identifier but does not describe 'job_type' or 'limit' (e.g., valid values, effect on results). This leaves significant gaps for the agent.

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

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

The description clearly states 'Get DOB building permit filings and job applications for a property,' specifying the action (Get) and resource (building permits). It distinguishes from sibling tools by focusing on construction permits, which is distinct from complaints or other property data.

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

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

The description advises 'Use this to understand planned or completed construction activity,' providing clear context for when to use the tool. However, it does not explicitly mention alternatives or when not to use it, missing some guidance compared to tools that name sibling alternatives.

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

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

No annotations provided, so description carries full burden. It mentions the data source and that complaints precede violations, but does not disclose any side effects, rate limits, or authentication needs. However, as a read-only query, the lack of behavioral notes is acceptable but not exemplary.

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

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

Well-structured with clear sections, parameter list, and contextual insights. Every sentence adds value without redundancy. Appropriate length given tool complexity.

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

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

Covers all necessary aspects: dataset origin, usage context, parameter details, interpretation guidance, and connection to sibling tools. With an output schema present, return values are implicitly covered.

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

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

Schema coverage is 0%, but description adds comprehensive meaning: explains address/BBL relationship, lists common category codes with examples, specifies status keywords, bounds for limit, and since_year semantics. This far exceeds what the raw schema provides.

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

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

Clearly states 'Get DOB complaints filed against a property with the Dept of Buildings', specifies the dataset (NYC Open Data eabe-havv), and contrasts with sibling `get_property_issues`, distinguishing when to use each.

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

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

Explicitly advises when to use this tool vs `get_property_issues`, provides interpretation guidance (complaints vs violations), and specifies to provide either address or BBL, with no duplication.

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

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

With no annotations, the description carries full burden. It discloses that it returns executed evictions (not filed), covers since 2017, and distinguishes query performance (local DB vs Socrata API). It does not mention rate limits, authentication, or error handling, but for a read operation this is sufficient.

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

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

The description is concise and front-loaded: first sentence states the purpose, then expands with details, usage guidance, and an Args section. Every sentence adds value, no fluff.

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

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

Despite no annotations and 5 parameters, the description covers purpose, use cases, parameter details, data sources, and mutual exclusivity. The presence of an output schema (noted in context) handles return values, so the description is complete for an agent to use this tool correctly.

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

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

Schema coverage is 0%, so the description must compensate. It explains each parameter in detail (address, bbl, eviction_type, since_year, limit) including defaults, mutual exclusivity, and year range. It adds value beyond the schema's property names and types.

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

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

The description starts with a specific verb+resource ('Get marshal eviction execution records for a property address') and clearly distinguishes this tool from siblings by focusing on evictions only. It also outlines the scope (citywide from 2017, residential/commercial) and query methods (BBL vs address).

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

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

The description explains when to use this tool ('assess tenant instability and cash-flow risk') and provides guidance on parameter selection ('provide either address OR bbl (not both)'). It does not explicitly state when not to use it or list alternatives, but sibling tools are clearly different.

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

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

With no annotations, the description fully discloses behavioral traits: it queries a local database with Socrata API fallback, resolves BBL to zip code, and returns incidents associated with zip code/borough. It also mentions data availability from 2013. No contradictions with annotations.

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

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

The description is well-structured with a clear purpose statement, usage context, and a bullet-style parameter list. It is slightly verbose but each sentence adds value.

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

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

Given the lack of annotations and the presence of an output schema, the description adequately covers purpose, usage, parameters, and behavior. It explains BBL resolution, date filters, and limit constraints. Minor omissions like pagination don't significantly detract.

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

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

Schema description coverage is 0%, so the description must compensate. It provides clear details for each parameter: address examples, BBL format, incident_type keywords, since_year range, and limit range with default. This adds significant meaning beyond the schema.

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

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

The description clearly states the tool retrieves FDNY fire and emergency incident history for a property address, specifying data sources and fallback behavior. It distinctly targets a niche not covered by sibling tools like get_311_complaints or get_building_permits.

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

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

The description advises using the tool to identify fire history and structural fire risk, and explicitly warns against providing both address and BBL. However, it does not elaborate on when to prefer this tool over alternatives or provide exclusion criteria.

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

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

With no annotations, the description provides some behavioral context: it notes historical depth and potential data differences from NYC Open Data. However, it does not disclose other behaviors such as authentication requirements, rate limits, or whether the operation is read-only (though implied). The description adds value but leaves gaps.

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

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

The description is reasonably concise, with a clear front-loaded purpose in the first sentence. The subsequent sentences add context about usage and data depth without excessive verbosity. It earns its place, though the note about historical depth could be slightly tighter.

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

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

Given the tool has 6 parameters (0% schema coverage) and no annotations, the description should provide comprehensive context. It explains the data source and use case but omits parameter details, making it incomplete for an agent to use correctly without additional inference.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions categories like 'PLUMBING' and 'HEAT/HOT WATER' but does not describe other parameters (bbl, status, since_date, limit, include_summary). The explanation of 'BBL' is absent, and parameter meanings rely on names alone, which is insufficient.

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

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

The description clearly states the verb 'Get' and the resource 'HPD tenant complaints and reported problems for a property'. It distinguishes from sibling tools like get_dob_complaints and get_311_complaints by specifying 'HPD' and 'tenant complaints', making the purpose unambiguous.

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

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

The description suggests using this tool alongside violations to assess building condition, but it does not explicitly state when to use this tool versus alternatives or when not to use it. The guidance is implied rather than explicit, missing a clear decision framework.

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

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

No annotations provided, so description must carry full burden. It lists returned data types but does not disclose side effects, rate limits, or behavior on invalid inputs.

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

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

Front-loaded with purpose, concise at 5 sentences, but includes some redundant emphasis on regulatory risk.

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

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

Given no output schema, description lists key returned fields (case types, findings, etc.), but could be more complete about the output structure.

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

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

The single parameter 'bbl' has 0% schema coverage and the description does not mention it or explain its format/purpose.

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

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

Clearly states 'Get HPD litigation history' and differentiates from sibling tools (e.g., get_hpd_complaints) by specifying it covers cases where HPD sued the owner. Also explains that only worst-offending buildings are litigated, which adds context.

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

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

Implies usage for investors evaluating regulatory risk and notes that HPD only litigates worst-offending buildings, but does not explicitly compare with sibling tools or mention when not to use.

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

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

With no annotations, the description carries the full burden. It discloses the types of information returned (managing agent, etc.) but does not mention error handling, authentication needs, or behavior for invalid BBLs. The missing details limit full transparency.

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

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

The description is composed of four concise, front-loaded sentences. Every sentence adds value: the first states the action, the second details the output, and the last two provide usage context. No redundant or vague language exists.

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

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

For a simple lookup tool with a single parameter and no output schema, the description covers the essential aspects: what it does, what data it returns, and a key context (building size requirement). It is almost complete, though it could mention return format or read-only nature.

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

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

The only parameter 'bbl' has no schema description (0% coverage) and the description does not explain what BBL means or its format. The description adds no meaning beyond the parameter name, leaving the agent without important context for constructing valid requests.

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

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

The description clearly states it retrieves HPD building registration and contact info, listing specific contact types (managing agent, corporate owner, etc.). It distinguishes from siblings like get_hpd_complaints by focusing on registration data, making the purpose unambiguous.

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

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

The description specifies that registration is required for buildings with 3+ residential units and directly says 'Use this to find who manages or owns a building.' It provides clear context for when to use the tool but does not explicitly mention alternatives or when not to use it.

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

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

No annotations are provided. The description discloses the data sources (DOF, ACRIS) and record types (tax lien sale entries, mortgage documents, lender names, amounts, satisfaction records), adding value beyond the schema. However, it does not cover aspects like pagination, data freshness, rate limits, or required permissions.

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

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

The description is three sentences long and efficiently conveys purpose, details, and use case without unnecessary words or repetition.

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

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

For a tool with 4 parameters, no schema descriptions, and no annotations, the description covers the core functionality and data sources but lacks parameter explanations and mentions of error conditions or rate limits. The presence of an output schema partially compensates, but overall completeness is moderate.

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

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

Schema description coverage is 0%. The description indirectly links the boolean parameters to tax liens and mortgages but does not explain the 'bbl' or 'limit' parameters, nor does it provide explicit parameter-level guidance. The agent may miss the meaning of 'bbl' as a Borough-Block-Lot identifier.

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

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

The description clearly states the action (get), the specific resources (tax liens and mortgage/encumbrance records), and details the data sources (DOF and ACRIS) and contents (lender names, amounts, satisfaction records). This distinguishes it from sibling tools like get_tax_info or get_property_history.

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

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

The description provides a use case ('assess a property's debt profile and lien exposure'), suggesting when to use, but does not explicitly state when not to use or compare with alternatives. The implied usage is present but lacks explicit exclusions or comparisons.

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

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

With no annotations, the description carries the full burden. It discloses the geospatial bounding-box search, use of PLUTO coordinates, default radius, and fallback behavior. It mentions filtering capabilities but does not address auth needs, rate limits, or error cases. Still, it provides meaningful behavioral context.

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

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

The description is well-structured with a front-loaded purpose paragraph followed by detailed parameter list. Every sentence adds value, though some phrases could be trimmed. Overall, it is appropriately sized for the tool's complexity.

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

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

Given the 7 parameters and existence of an output schema, the description covers the essential aspects: purpose, data source, filtering parameters, and use cases. It lacks info on output format and error handling, but these are partly addressed by the output schema and parameter defaults.

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

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

Schema description coverage is 0%, so the description compensates fully. It explains each parameter in detail: address/bbl mutual exclusivity, radius range and default, law_category case-insensitive values, offense examples, since_year range, and limit range. This adds significant meaning beyond the input schema.

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

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

The description clearly states the tool's purpose: 'Get NYPD crime complaints within a radius of a property.' It specifies the data source, geospatial approach, and types of complaints returned. It distinguishes itself from sibling tools (e.g., get_311_complaints) by focusing on crime data, making selection unambiguous.

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

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

The description provides explicit use cases: 'Use this to assess neighborhood safety for buyers, lenders, or underwriters.' It also explains the fallback behavior to Socrata API. However, it does not directly compare with alternatives or specify when not to use, though the context is clear.

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

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

The description explains the data sources (DOF for sales, ACRIS for ownership) and what fields are shown, indicating a read operation. However, it does not disclose any behavioral traits like rate limits, data freshness, or permissions, which would be helpful given the lack of annotations.

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

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

The description is three short sentences, with the purpose first, then data sources, then use case. No redundant information; each sentence adds value. It is well-structured and concise.

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

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

Given the presence of an output schema, the description adequately covers what the tool returns (sale prices, dates, buyer/seller names, document types) and the data sources. It could be more complete by explaining how the include_* parameters affect the output, but overall it is sufficient for a look-up tool.

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

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

The schema has 0% description coverage for parameters, and the description does not explain the meaning or usage of parameters (e.g., bbl, include_sales, doc_type_filter). The description only provides high-level context about the tool's outputs, not the input parameters.

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

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

The description clearly states it gets the history of a NYC property including sales and ownership transfers, specifically from DOF and ACRIS records. This distinguishes it from sibling tools that cover other aspects like permits, complaints, tax info, etc.

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

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

The description says 'Use this to understand a property's transaction history and price trajectory,' clarifying its applicability. However, it does not explicitly state when not to use it or mention alternative tools for related but distinct purposes.

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

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

With no annotations, the description carries full burden. It includes a detailed note about historical data retention explaining why totals may exceed NYC's public data, which is excellent transparency. However, it does not explicitly state that it is a read-only operation or mention authentication requirements.

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

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

The first paragraph is concise. The second paragraph, while important for transparency, is somewhat lengthy but earned. Overall, minimal redundancy and front-loaded with key purpose.

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

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

Despite having an output schema, the description fails to cover parameter semantics, which are important for correct invocation. It provides good behavioral context and purpose, but the parameter gap lowers completeness given the tool's complexity (7 parameters).

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

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

Schema description coverage is 0%, meaning the description must compensate. It does not describe any of the 7 parameters (bbl, source, status, etc.) or their meanings, leaving the agent to infer from schema names and types alone.

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

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

The description clearly states it retrieves HPD, DOB, and ECB/OATH violations for a property, and mentions it returns summary counts and details. This distinguishes it from sibling tools like get_hpd_complaints which focus on single complaint types.

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

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

The description recommends using this to assess a building's regulatory risk profile, providing a clear use case. However, it does not explicitly state when not to use it or mention alternatives like get_dob_complaints for specific violations.

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

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

With no annotations, the description provides some behavioral context: it shows historical counts from 2007-2017 and indicates counts can be estimated or confirmed. However, it does not disclose authentication needs, rate limits, error handling, or what happens with invalid BBLs.

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

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

Three concise sentences front-load the purpose and key details. Every sentence provides useful information with no redundancy or filler.

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

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

For a simple tool with one parameter and no output schema, the description partially explains the output (counts and confirmation status) but lacks details on output structure, error states, or data coverage assumptions. It is moderately complete but could be improved.

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

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

Schema coverage is 0%, meaning the description does not explain the 'bbl' parameter (e.g., what it stands for, required format, or how to obtain it). The description adds no semantic value beyond the schema's type and required flag.

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

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

The description clearly states it retrieves rent stabilization history, specifies the data range (2007-2017) and type (counts, estimated/confirmed). It distinguishes itself from sibling tools like tax info or complaints by focusing on rent stabilization specifically.

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

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

The description includes explicit usage guidance: 'Use this to check if a building is rent-stabilized and track unit count changes over time.' It does not mention when not to use it or alternatives, but the context of siblings implies distinct purposes.

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

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

No annotations are provided, and the description only lists returned data fields without addressing side effects, permissions, cost, or read-only nature. For a tool with zero annotation coverage, this is insufficient.

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

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

The description is two sentences and front-loads the main purpose. While concise, it could be slightly more streamlined but remains effective.

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

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

Given one required parameter and no output schema, the description is minimal. It lacks explanation of the bbl parameter and does not distinguish from siblings beyond scope. Adequate but with clear gaps.

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

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

The required parameter 'bbl' is not explained in the description. With 0% schema description coverage, the agent has no guidance on format (e.g., Borough-Block-Lot identifier) or example values, making correct invocation unlikely.

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

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

The description uses a specific verb ('Get') and resource ('property tax assessment, market value, exemption details'), listing concrete data types. It clearly distinguishes from sibling tools like get_property_history or get_rent_stabilization.

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

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

The description implies use when tax assessment details are needed, but it does not explicitly state when to avoid or name alternatives, which is acceptable for a focused tool.

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

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

Describes the lookup and return of a full property profile. Implicitly a read operation, but lacks explicit statement of safety; no annotations to contradict.

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

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

Two sentences, front-loaded with action and resource, no filler. Efficient and well-structured.

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

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

Covers purpose, usage context, and high-level return value. Lacks explicit mention of borough parameter but otherwise complete for a lookup tool with output schema.

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

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

Description mentions address and BBL as identifiers but does not detail the borough parameter. With 0% schema coverage, description partially compensates but misses full parameter context.

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

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

Clearly states it looks up a NYC property by address or BBL and returns a full profile. Distinguishes from siblings by positioning itself as the first tool to call.

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

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

Explicitly states it is always the first tool to call and that a BBL is needed before using other tools, providing clear when-to-use guidance.

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

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. It does not mention whether the tool is read-only, idempotent, or has any side effects, rate limits, or authentication needs. The name 'search' implies read-only, but that's implicit at best.

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

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

The description is three sentences, front-loading the core purpose. Each sentence adds distinct value: purpose, search criteria, and return information. No redundant or verbose text.

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

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

Given 10 parameters, no annotations, and an output schema (which partially mitigates return documentation), the description is incomplete. It does not cover all parameters, and lacks context on behavior, privacy, or data freshness.

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

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

Schema description coverage is 0%, yet the description only mentions zip_code, building_class, min/max_sqft, and months. It omits price parameters, limit, include_stats, and bbl's special behavior is partially covered. With 10 parameters, the description adds limited meaning beyond the schema.

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

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

The description clearly states the tool finds comparable property sales and neighborhood market statistics. It specifies search criteria (zip code, building class, size, time period) and return types (sales with price per sqft, quarterly trends), distinguishing it from siblings like search_neighborhood_stats.

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

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

The description provides concrete usage guidance: search by various filters and use of a reference BBL to inherit defaults. However, it does not explicitly compare to sibling tools or state when not to use it.

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

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

With no annotations, the description carries full burden. It states that the tool combines multiple data sources into aggregate statistics, but does not disclose behavioral details like rate limits, response structure, or that it returns only aggregates (no individual records). The existence of an output schema mitigates some gaps.

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

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

The description is relatively concise (two sentences plus a usage note) and front-loads the main purpose. It could benefit from a more structured format (e.g., bullet points) but avoids unnecessary detail.

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

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

Given the tool has 7 parameters and an output schema, the description adequately covers the purpose and main inputs but omits details about boolean flags and months parameter. It completes the context for the tool's role as an aggregate querier, but not fully for parameter usage.

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

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

Schema description coverage is 0%, yet the description only explains zip_code and neighborhood. Five other parameters (building_class, months, include_quarterly_trends, include_violations, include_rent_stabilization) are not described, leaving the agent to infer from names alone. This is a significant gap for a tool with 7 parameters.

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

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

The description clearly states 'Get aggregate neighborhood statistics' and lists the combined data types (property stock, sales, violations, rent stabilization). It distinguishes from sibling tools that return specific records (e.g., get_evictions, get_rent_stabilization) by emphasizing aggregation and area analysis.

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

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

The description provides explicit use cases: compare areas, identify investment hotspots, understand neighborhood character before drilling into individual properties. It also notes that at least one of zip_code or neighborhood is required. However, it does not explicitly name alternative sibling tools for specific data needs.

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