building-intelligence

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 discloses the prerequisite of needing a slug, the fact that a URL with exhaustive details is returned, and that it should be shared with the user. It does not explicitly state read-only behavior or error handling, but given the 'get' nature and the level of detail, this is adequate.

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 yet comprehensive, using three sentences: the first lists the report contents, the second specifies the prerequisite and alternative, and the third explains the returned URL. Every sentence contributes unique value without redundancy.

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?

This is a complex tool with no output schema, but the description enumerates the key result fields (violations, complaints, rent summaries, etc.) and clarifies that a URL provides the full timeline. It is not exhaustive about output formatting, but it covers the essential information an agent would need.

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

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

Schema description coverage is 100%, with both city and slug properties already described. The description adds contextual guidance about calling search_buildings, but this is implicitly already in the slug's schema description. Therefore, 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.

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

The description clearly states that the tool returns a 'full report card' for a single building and enumerates specific data points (LucidIQ score, violations, complaints, etc.). It distinguishes itself from sibling tools by focusing on an individual building and requiring a slug, which contrasts with search_buildings.

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 explicitly instructs users to call search_buildings first if only an address is available, and it requires the building slug. This provides clear when-to-use guidance and names the alternative 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?

With no annotations, the description carries the full burden and does a good job: it discloses the type of record (public), the specific data returned, and the output format (a URL with per-building records). It also notes that the 'worst building' is included only where available, adding nuance. It lacks explicit statements about side effects, but 'public record' strongly implies a read-only lookup.

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, front-loading the purpose and key data fields, then covering inputs and output. Every word earns its place with no repetition of schema details.

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 two-parameter tool with no output schema, the description is complete: it specifies inputs, output content, and the shape of the return value (a URL with per-building records). It leaves no critical gaps for the agent to infer.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining what slugOrName means and giving an example owner name ("SMITH REALTY LLC"), as well as clarifying that building reports contain the exact owner name. This enriches the schema's short parameter description.

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 provides a public record for a landlord/property owner, listing specific data points like portfolio size, violations, 311 complaints, and building scores. It distinguishes itself from sibling tools by focusing on the landlord entity rather than individual buildings or neighborhoods.

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 when to use it by explaining that it accepts an owner name or landlord slug, and notes that building reports include the exact owner name. However, it does not explicitly compare against sibling tools like get_building_report or search_buildings, so the usage guidance is implied rather than explicit.

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 the full burden. It discloses the data source (local police department), the time frame (12-month crime summary with year-over-year totals), and that the returned URL contains building listings and trend charts. This is good transparency for a read-only stats tool, though it could mention response format or potential caveats.

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, front-loaded with the core function and data content, then adds usage examples and the URL detail. Every sentence provides valuable information with no redundancy or 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?

With no output schema and no annotations, the description explains the main return data (rents, crime summary, URL) and usage context. It is reasonably complete for a stats tool, though it could be slightly more explicit about response structure or data limitations.

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 input schema covers both parameters (city and zip) with descriptions, achieving 100% schema coverage. The tool description adds minimal extra parameter detail beyond reinforcing that the zip code is the focus. Baseline 3 is appropriate when the schema already documents the parameters well.

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 explains that the tool provides a neighborhood snapshot for a zip code, specifically median asking rents by bedroom count and a 12-month crime summary. It distinguishes from siblings by focusing on neighborhood-level data (rents + crime) rather than building/landlord/review-specific info.

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 states explicit use cases: 'Use this for "what does rent cost in <area>" and "is <area> safe" questions.' This provides clear context for when to use the tool, but does not explicitly mention when not to use it or point to 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?

With no annotations provided, the description carries the full burden. It discloses the summary contents, the limitation of up to 3 quotes, and that the returned URL contains full text of all reviews. This goes beyond the schema and gives useful behavioral detail, though it doesn't explicitly state read-only or discuss error cases.

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, with the first sentence front-loading the core functionality and outputs. The subsequent sentences add necessary prerequisite and return details. Every sentence earns its place with no redundant information.

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's simplicity (2 params, no output schema, no annotations), the description is sufficiently complete. It covers what the tool returns, prerequisite knowledge, and a useful detail about the full-text URL. It does not elaborate on edge cases or formatting, but these are not critical for this summary 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?

Schema description coverage is 100%, so baseline is 3. The description adds context connecting slug to search_buildings, but the schema already documents that relationship. No significant additional parameter meaning is provided 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 provides a tenant review summary for one building, listing specific components (review count, average rating, 1-5 star distribution, up to 3 recent pull quotes). This action is distinct from sibling tools like get_building_report or get_neighborhood_stats, establishing a clear purpose.

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 instructs to call search_buildings first if only an address is available, and explains the need for a building slug. While it doesn't explicitly name alternative tools for comparison, the prerequisite guidance gives clear context for when and how to use this 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?

No annotations are provided, so the description carries the full burden. It does well by disclosing the coverage (~2M buildings, three cities), the data types included, the max result count (up to 10), and the return items (slug, URL). It doesn't mention rate limits or pagination, but for a simple search this is not a major gap.

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

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

Three sentences, front-loaded with the core purpose, and every clause adds value: coverage, data types, output, and downstream usage. No filler or redundancy.

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?

Even without an output schema, the description explains what the tool returns (up to 10 matches, slug, URL) and why that matters. It gives the agent sufficient context to decide when to invoke it, what parameters matter, and how to use the results with sibling tools.

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 input schema already documents both parameters with descriptions, examples, and enum values, so the schema coverage is 100%. The description adds the notion of 'partial address' and connects the output slug to downstream tools, but it doesn't add significant parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific action ('Search LucidRents for apartment buildings') with clear scope (by address, name, or partial address) and differentiates from siblings by emphasizing the search/starting role. It clearly distinguishes what this tool does from the get_* report tools.

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 says 'Start here when the user gives an address,' which is direct usage guidance. It also names the dependent tools (get_building_report / get_review_summary) and clarifies the output slug is needed for them, effectively telling the agent when and how to chain the tools.

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