AskRentAI

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely non-derivable behavior: 1-3 minute latency when unscoped, seconds when scoped, 5-minute result caching, and the caveat that PropertyIDs are honored even though the CSV has no Property column. That last point prevents a client-side filtering mistake.

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 the report contents, then scope, then the performance warning, then args — a sensible priority order with no filler. The trailing Args block partially restates the inline scoping prose, a minor redundancy, but nothing is wasted overall.

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?

An output schema exists, so return-value explanation is unnecessary, and annotations cover the safety profile. Everything an agent needs to call this correctly — scope semantics, latency expectation, caching, all four parameter formats — is present.

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 carries the full burden and does. It defines portfolio format (name or 3-letter prefix), property_ids format (comma-separated) with the OR relationship, as_of_date format (MM/DD/YYYY) and default, and top_n default plus max (50), which the schema does not state.

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?

States a specific verb+resource and enumerates the actual output (AP by aging bucket, top GL accounts owed, 61+ day GL accounts), then names the sibling it mirrors ('Mirror image of analyze_aged_receivables'). An agent can distinguish it from the other ~60 analyze_* tools without opening a schema.

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?

Explicit when-to-use guidance: scope with portfolio/property_ids for fast returns, and the exact prompt to send the user before an unscoped call. Also states the mutually exclusive relationship ('Use this OR portfolio') and the caching window, which changes how an agent should sequence calls.

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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description still adds real behavioral content beyond that: the underlying data source (AgedReceivables report 78) and the transformation performed (aggregation per property, ranking of delinquent tenants). It does not mention constraints such as permissions or row limits, keeping it at 4.

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 the aging buckets, then one sentence on processing, then example questions. Compact and every line is relevant, though the fragmented multi-line formatting is slightly choppier than a single tight paragraph would be.

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?

An output schema exists, so return values need not be described, and annotations fully cover the safety profile. What remains is mostly adequate for a read-only analytical tool with all-optional parameters, though the unexplained as_of_date and property_ids scoping leaves a modest gap.

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 carry all four parameters. It only illuminates 'portfolio' (via 'for a portfolio' and the GSP example) and weakly implies 'top_n' through ranking. The critical 'as_of_date' for an aging analysis and the 'property_ids' scoping parameter are entirely unexplained in both description and 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?

States a specific resource (aged receivables), the exact aging buckets (30 / 31-60 / 61-90 / 91+), the scope (a portfolio), and the processing (aggregates per property, ranks delinquent tenants). An agent can immediately distinguish this from the payables counterpart, analyze_aged_payables, and from general AR tools like analyze_rent_roll.

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 three example questions ('who's most past-due', 'how much is 90+ days old', 'what's our total AR for the GSP portfolio') give concrete invocation contexts that map directly onto the tool's output. It stops short of naming alternatives or stating when not to use it (e.g., versus analyze_delinquency), so it falls short of a 5.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior context: it runs a specific report (553) and is portfolio-wide only because RM does not expose a property column. That limitation is valuable and not derivable from structured fields.

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?

It is front-loaded — purpose first, then report mechanics and breakdowns, then usage examples, then the scope caveat. Mostly every sentence earns its place, though 'A collections-efficiency lever' is mild 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?

An output schema exists, so return values need not be explained. The description covers what it computes, the underlying report, the dimension breakdowns, and the portfolio-wide constraint — everything an agent needs to call it 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?

The tool takes zero parameters, so the baseline is 4. The description's note that results are portfolio-wide reinforces that no filtering argument exists, which is consistent with the empty 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 opening line states a specific resource and metric — autopay/ePay enrollment, how many residents are on automatic payments — and grounds it in a concrete artifact (TenantAutoPayConfiguration, report 553). It is clearly distinguishable from siblings like analyze_payment_trends or analyze_rent_composition.

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 gives explicit trigger phrasings ('how many residents are on autopay', 'autopay adoption', 'ePay enrollment breakdown') and states a scope limitation ('Portfolio-wide only'). However, it never names a sibling alternative or a when-not-to-use condition, so the agent must infer routing on its own.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description earns credit by adding runtime behavior instead: unscoped queries take ~2 minutes, and it discloses the source report (ReportWriter RW 107) and the computed fields. Missing only things like rate limits or connection 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?

Front-loads the definition ('Available (vacant) inventory + exposure by property and unit type') and every following sentence carries information – the report source, the example queries, the scoping/time note, and the alternative. Slightly dense but no waste.

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?

An output schema exists, so return values need no prose, and the description still supplies the report identity, scoping/time guidance, and the sibling disambiguation. The remaining gap is parameter-level semantics (top_n, property_ids format), which is a real but secondary omission.

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 carry parameter meaning, but it only partially does: it explains that portfolio/property scoping is a performance tradeoff, yet leaves top_n and the format of property_ids (comma-separated IDs? names?) entirely undefined. Partial compensation over a bare 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?

States a specific verb+resource (analysis of available/vacant inventory and exposure) scoped by property and unit type, and explicitly distinguishes itself from the sibling analyze_vacancy ('For a unit-level vacant list use analyze_vacancy'). It also names the underlying report (RW 107), which pins down exactly what is computed.

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 concrete trigger phrases ('what's our available inventory / exposure', 'vacancy rate by property', 'which parks have the most vacant lots'), names the alternative (analyze_vacancy) with the condition that selects it, and explains when to scope (portfolio/property set for speed). This is explicit when-to-use and when-to-use-something-else 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: parallel per-property CSV downloads and the company-wide fallback when no portfolio/property_ids are supplied. No rate-limit or output-shape notes, but the output schema exists.

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 short, front-loaded sentences with no filler; the resource definition leads and the scoping rule follows. Efficient, though the parenthetical acronym breakdown is minor padding.

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?

An output schema exists so return values need not be described. The description covers the read-only analysis, its data source and its scoping behavior adequately; only the show_detail flag and property_ids format remain undocumented.

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% for 4 parameters, so the description must compensate. It implicitly covers as_of_date ('as of a date'), portfolio and property_ids (via the company-wide default sentence), but says nothing about show_detail or the expected format of property_ids, leaving one parameter and one format question unanswered.

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?

States a specific verb and resource ('Downloads BalanceSheet (report 38) CSVs') with a clear scope qualifier ('as of a date', 'per property' vs 'company-wide'). The resource name distinguishes it from the many analyze_* financial siblings, but it never explicitly contrasts itself with adjacent tools such as analyze_financials or trial_balance.

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?

'With no portfolio/property_ids, pulls the company-wide balance sheet' tells the agent what happens by default, which is useful implied guidance. It does not state when to prefer this tool over analyze_financials/trial_balance or any explicit exclusions, so guidance remains implicit.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful output context (net income, total adjustments, net change in cash, bucketing by Account Type, and what show_detail=True changes), but says nothing about permissions, rate limits, or per-property scope behavior.

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 the report identity and scope, then the returned figures, then the detail flag. It is dense but every clause conveys content; no 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?

With an output schema present, the description needn't explain return values, and readOnly annotations cover safety. However, the date filters, portfolio selection, and property_ids are undocumented anywhere, which is a real gap for a 5-parameter analytical 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 0% across 5 parameters, so the description carries the full burden. It only explains show_detail's behavior; end_date, start_date, portfolio, and property_ids are never addressed (no date format, no portfolio vs property_ids relationship), leaving most parameters ambiguous.

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 names a specific verb+resource ('Indirect-method cash flow per property') and anchors it to a concrete report (CashFlow, report 54), which is more precise than most siblings. It does not, however, distinguish itself from related financial siblings like analyze_noi, analyze_financials, or analyze_balance_sheet.

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?

There is no when-to-use or when-not-to-use guidance and no alternative tool is named. The agent must infer from the name that this is the cash-flow report rather than the P&L, NOI, or balance-sheet analyses.

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?

Annotations already cover read/idempotent/non-destructive, so the bar is lower, and the description adds real behavioral context: the API excludes tenants with a balance but no current unit, so results may differ from the RM UI by 1-2 tenants / $50-200. This is a substantive data-completeness caveat beyond what annotations provide, though nothing is said about pagination or rate limits.

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 purpose is front-loaded in the first line, followed by sibling differentiation, example questions, and the footer caveat. Efficient overall, though the trailing footer paragraph could be tightened.

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 an output schema present, the description needn't explain return values, and it covers purpose, sibling routing, and a key data caveat. The main gap is parameter documentation, which the low schema coverage leaves unaddressed.

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% across four parameters, so the description must carry the load, but it only hints at top_n via the phrase 'top 10' and the charge-type dimension. portfolio, as_of_date, and property_ids remain entirely undocumented in both the schema and the 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?

States a specific resource and scope ('Delinquency by tenant + charge type') and immediately differentiates itself from the closest sibling by naming analyze_aged_receivables and contrasting the slice (charge category vs aging bucket). An agent can tell exactly what this returns without opening the schema.

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 names the alternative (analyze_aged_receivables) and explains the distinction, plus lists concrete questions it answers ('who's behind on rent vs utilities', 'top 10 delinquent tenants'). That is clear contextual routing, though there is no explicit when-not/exclusion guidance to reach a 5.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description adds genuine value by disclosing the analytical shape of the response (histogram, top-N, averages) and the upstream report ID, though it omits potentially useful traits such as whether results are scoped to currently-open cases only or pagination behavior.

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-loads the core purpose, then outputs, then the questions it answers—a sensible order with little waste. It is slightly list-like, but every clause adds selection 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?

With an output schema present and read-only annotations, the description needn't detail return values, and it nonetheless characterizes them. The main residual gap is the undocumented parameters (as_of_date, property_ids), which the schema does not compensate for.

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 carry parameter meaning, and it largely doesn't. It hints at top_n ('top-N oldest cases') and portfolio ('for a portfolio'), but as_of_date and property_ids are never mentioned, and no formats, defaults, or filtering semantics are given for any of the four.

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?

States a specific verb (analyze) and resource (open evictions) with scope ('for a portfolio') and even cites the source report. The enumerated outputs (per-property count, balance at risk, days in stage, reason histogram, top-N oldest) let an agent distinguish it from sibling analyze_* tools like analyze_delinquency without opening the schema.

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 'Answers:' clause gives concrete question patterns (count of open evictions, balance at risk, longest-stuck cases, reason breakdown) that clearly signal when to reach for this tool. It stops short of naming alternatives or exclusions, so it's clear context without explicit routing.

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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing which underlying report it runs (report 43) and the conditional behavior of line items when show_detail=True. It does not cover auth needs or return/pagination behavior, but the output schema exists, so this is a minor 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?

The definition is front-loaded: the first sentence states the deliverable and report, then the routing guidance follows. It is somewhat long, but each sentence (what it pulls, when to use it, which sibling to prefer otherwise) earns its place.

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 an output schema present, return values need not be explained, and annotations carry the read-only/idempotent profile. The description routes correctly and defines the report precisely. The main residual gap is parameter documentation, which neither the schema nor the description supplies.

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% across 5 parameters, so the schema provides no meaning and the description must compensate. The description only addresses show_detail (per-account line items when True) and says nothing about end_date, portfolio, start_date, or property_ids — formats, filters, or date-range semantics remain undocumented. This is a significant shortfall against a 0% coverage baseline.

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?

States a specific verb and resource ('pulls the standard ProfitLoss report (report 43)') and defines the deliverable ('detailed single-period financial breakdown with per-account line items'). It explicitly distinguishes itself from the sibling analyze_pl_trend by naming that tool and its report (ProfitLossRecapMonth).

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?

Gives explicit when-to-use conditions ('ONLY when the user explicitly wants line-item detail for a single period, an audit-style breakdown, or specifically references "the standard P&L statement"') and when-not ('For any general "P&L"... prefer analyze_pl_trend'). Names the alternative and the condition that selects it, leaving nothing to inference.

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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely new behavior: the exact source report, and the performance note that unscoped calls are 'fanned out in batches.' It omits anything about pagination or result size, keeping it from a 5.

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 the core purpose in the first sentence, then layers report detail, use cases, sibling differentiation, and a performance tip. Every sentence adds value; the use-case list is slightly dense but earns its place.

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?

An output schema exists, so return values need not be explained, and complexity is moderate. The description covers purpose, use cases, and key behaviors well; the only gap is parameter format detail, which is minor against the rest of the coverage.

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% for the two parameters (portfolio, property_ids), so the description carries the burden. It hints at portfolio/park scoping ('Scope to a portfolio/park for speed') but never explains the format of property_ids or how portfolio relates to property_ids, so it only partially compensates.

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?

States a specific verb and resource (summarizes park-owned-home sales pipeline), names the underlying report (Available Inventory Report / ReportWriter 106), and enumerates the exact metrics produced. It even differentiates itself from siblings with 'The MHP home-sale revenue view the rent-roll tools miss,' so an agent can separate it from analyze_rent_roll without opening schemas.

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 explicit trigger phrases ('how many park-owned homes are for sale', 'total list value...', 'which homes are aging') and frames the rent-roll tools as the tools it complements. It stops short of naming a specific alternative tool to use instead when the question is about leased-unit revenue, so it is one notch below full when/alternatives coverage.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered and the bar is lower. The description adds the shape of the result (severity-ranked lists, leaderboard, open/closed split), but withholds operational traits such as pagination, permission requirements, or how the ranking tie-breaks. Useful but not rich.

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 the purpose, then the metric breakdown, then example questions — a logical flow with no filler sentences. The parenthetical '(InspectionActivity, 273)' is opaque internal shorthand that costs a line without helping the agent.

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?

An output schema exists, so return-value explanation is not required, and the safety profile is fully annotation-covered. However, five parameters at 0% coverage with no description-level semantics leaves a genuine gap: an agent knows what the tool answers but not how to scope it by portfolio, property set, or date range.

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 carries the full burden, yet it never mentions top_n, start_date, end_date, portfolio, or property_ids. The 'how many inspections happened this quarter' example only vaguely hints at date scoping and does not explain the date format, portfolio scoping, or that top_n controls ranking depth.

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?

States a specific resource (inspection compliance and action items) and enumerates concrete outputs: per-property counts, open vs closed, severity ranking, worst inspections, inspector leaderboard. An agent can tell this is the inspections-analytics tool. It does not explicitly differentiate itself from any sibling, and the potentially confusable 'inspect_property_api' is never addressed, so it stops short of a 5.

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 'Answers:' clause gives three concrete query shapes ('which properties have open inspections', 'which inspections flagged the most severe items', 'how many inspections happened this quarter'), which effectively tells the agent when to reach for this tool. It offers no exclusions or named alternatives among the many analyze_* siblings, so no 5.

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?

Annotations already declare readOnly, idempotent, non-destructive, openWorld. The description goes beyond them by disclosing the underlying report (SummaryRentRoll #69), the aggregation grain (by unit type), the time window (full calendar month of as_of_date, defaulting to current month), and a hard data prerequisite (market rent on units). It adds real invocation context rather than restating the 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?

Front-loads the metric definition, then the computation, then usage examples, then the prerequisite and time-window caveat — a logical order with little waste. The 'The #1 multifamily revenue-capture metric' line is mild marketing filler, keeping it from a 5.

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?

An output schema exists, so return values need not be described, and the description covers computation, grain, timing, and prerequisites adequately. The only real hole is scope-parameter semantics (portfolio vs property_ids), which leaves an agent unsure how to target a subset of properties.

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% for three parameters, so the description carries the full burden. It explains as_of_date well (full calendar month, defaults to current month) but says nothing about what 'portfolio' or 'property_ids' accept, their format, or how they interact — two of three parameters remain semantically opaque.

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?

Names a specific metric and defines it inline ('gap between market rent and in-place rent on occupied units'), then states exactly how it is computed (SummaryRentRoll / report 69, summed by unit type). This clearly differentiates it from near siblings like analyze_rent_roll and analyze_rent_composition.

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 concrete trigger phrases ('what's our loss to lease', 'how far below market are we', 'which unit types have the biggest market gap') and a prerequisite (market rent must be set on units). It does not explicitly name a competing sibling to use instead when that prerequisite fails or when a raw rent roll is wanted, so it stops short of a 5.

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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds real behavioral context: the default trailing ~90-day window and the semantic scope (everything that drops out vs everything coming in). Doesn't mention pagination or result size, keeping it short of a 5.

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 the report identifier and purpose, then progressively more detail. Every sentence adds information; no 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?

An output schema exists, so return values needn't be described. However, for a 5-parameter analytical tool with 0% schema coverage, the description leaves the parameter surface entirely unexplained, which is a meaningful completeness gap for an agent trying to invoke it with the right arguments.

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% across 5 parameters, and the description only obliquely touches the date window via the ~90-day default. It never explains top_n, portfolio, or property_ids, so it fails to compensate for the total lack of parameter documentation.

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?

States a specific verb+resource ('lost-lead funnel analysis') and enumerates the concrete outputs: funnel-stage breakdown, agents with lost leads, properties with worst conversion, timeline. It explicitly contrasts with the sibling analyze_prospect_pipeline, so an agent can route correctly without opening a schema.

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?

Names the alternative (analyze_prospect_pipeline) and the selecting condition: that tool counts inbound leads, this one counts dropouts. Also gives the default time window (~90 days). It lacks explicit when-not-to-use guidance, but the alternative contrast 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?

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so safety is covered. The description adds behavioral context beyond that: a default trailing-30-day window and what the output surfaces (top movers, most-recent move-outs). This is useful, though it doesn't discuss pagination or ranking tie-breaking.

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 the core purpose and appropriately short. The '(MoveInMoveOut, 77)' token is unexplained internal jargon that adds noise without meaning for an agent.

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?

An output schema exists, so return-value detail is unnecessary, and the description conveys the aggregate nature of the tool. However, with 5 undocumented parameters and no guidance on scoping fields, an agent lacks enough to construct calls confidently.

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% for 5 parameters, so the description must carry the burden and largely fails to. It indirectly covers the date window ('default trailing 30 days') and alludes to top_n via 'top movers', but says nothing about portfolio, property_ids, date format, or how the two scoping fields interact or are mutually exclusive.

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?

States a specific verb+resource (move-in/move-out turnover summary) with explicit scope: per-property counts over a window, top movers, and recent move-outs. It also names the sibling listing tool (move_ins_outs) and how it differs ('adds aggregates and rankings'), so an agent can distinguish it without opening the schema.

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 routes between this tool and move_ins_outs: use this one for aggregates/rankings, the sibling for raw listing. That is clear context for selection, though it does not spell out a true when-not condition or prerequisites.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds domain-specific behavior beyond annotations: NOI excludes non-operating items, the tool reports a single aggregate period, and default start/end dates are Jan 1 and Dec 31. It does not cover authentication or rate limits, but those are less critical for a read-only analytical 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 front-loaded with the computation, followed by the critical usage restriction and alternative, then a compact parameter list. Every sentence adds necessary routing, scope, or parameter information without waste.

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 financial-analysis context, four parameters, 0% schema coverage, and an existing output schema, the description supplies everything needed to call correctly: the formula, single-period scope, sibling routing, mutual-exclusivity rule for portfolio vs property_ids, and date formats. Return values can remain in 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?

With schema description coverage at 0%, the description fully compensates by explaining all four parameters: 'portfolio' as a named portfolio or 3-letter prefix, 'property_ids' as comma-separated IDs with an explicit 'Use this OR portfolio' rule, and both dates with MM/DD/YYYY format and their defaults.

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 verb and resource: 'Compute Net Operating Income (NOI) for a single period — Operating Income minus Operating Expenses, non-operating items excluded.' It also explicitly distinguishes itself from the closest sibling by naming analyze_pl_trend for general P&L/T12 requests.

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 gives explicit when-to-use guidance: 'Use this ONLY when the user specifically asks about NOI as a single aggregate number for a period.' It then names the alternative, analyze_pl_trend, and states the condition ('general P&L, Profit and Loss, or T12 request') that should route there instead.

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?

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds substantial operational context: the report source, rollup mechanics, timeout/fan-out behavior when unscoped, and the forward-looking nature of post-current months.

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 front-loaded with the metric definition, then report source, use cases, and operational caveats. It is somewhat long but each section is relevant for an analytical report with performance constraints.

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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The description supplies data source, scope caveat, and forward-looking semantics, though parameter usage remains thin.

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%, and neither portfolio nor property_ids is described in the schema. The phrase 'Scope to a portfolio/property set' only vaguely implies both parameters, leaving format, delimiter, and usage details undocumented.

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?

States a specific verb and resource: a 12-month physical occupancy trend with monthly occupied percentage. It also names the underlying RM ReportWriter report RW 111 and clarifies the per-unit-to-monthly rollup, though it does not explicitly distinguish itself from siblings like analyze_vacancy.

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 concrete usage examples such as 'occupancy trend this year', month-over-month improvement, and identifying parks that drag occupancy down. It also gives scope guidance and a timeout caveat, but does not explicitly state when to choose an alternative sibling 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's added value is the trailing ~90-day default window and the default 50% drop threshold, plus the shape of what gets returned. It does not discuss cost, rate limits, or data freshness, but it adds meaningful operational context beyond the 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 output summary is front-loaded before the sample questions, and the parenthetical report identifier is compact. The phrasing is a bit fragmentary ('Month-over-month payment trends (PaymentComparison, 32)') but every line conveys usable 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?

With an output schema present, the description need not explain return values, yet it still outlines the three result surfaces, which helps an agent predict fit. The remaining gap is the unexplained filter parameters, but for a read-only analytics tool the coverage is close to sufficient.

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% across 6 parameters, so the description carries the burden. It clarifies drop_threshold_pct (payment drops larger than this value, default 50%) and the default date window, but says nothing about top_n, portfolio, property_ids, start_date, or end_date semantics or formats. Partial compensation only.

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 names a specific verb and resource (month-over-month payment trends / collections) and enumerates the three outputs it produces: monthly totals with % change, per-property rollup, and tenant-level drops. That lets an agent separate it from siblings like analyze_delinquency or analyze_rent_roll without opening a schema.

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 gives concrete selection cues via the 'Answers:' list ('which tenants stopped paying', 'how did collections trend last quarter'), which implicitly tells the agent the conditions this tool fits. It stops short of naming an alternative tool or stating when not to use this one, so it falls just below the top mark.

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?

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds real behavioral context beyond that: the default 3-year window when no dates are given, and the ranking rule (absolute total). It doesn't mention pagination or granularity limits, so a 4 rather than 5.

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 the report identity and output shape, then defaults, then the routing sentence. Every line earns its place with zero 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. The description is nearly complete; the only gap is the undocumented portfolio and property_ids 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 coverage is 0% across 5 parameters, so the description must carry the load. It clarifies date behavior (defaults to a 3-year window) and implies top_n via 'ranked by absolute total', but leaves portfolio, property_ids, top_n semantics, and date format entirely unexplained.

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?

States a specific verb+resource ('Multi-year P&L by account'), names the underlying report (ProfitLossRecapYear, report 201), and describes the output shape (year-matrix per account ranked by absolute total). It clearly distinguishes itself from the two nearest siblings by naming them.

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 routes the agent: 'For year-over-year deltas use analyze_pl_yoy; for monthly trajectory use analyze_pl_trend', and provides sample questions ('how has revenue moved across 3 years') that anchor when to reach for this tool. Nothing is left to inference.

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?

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial value beyond them: it discloses the return is COMPUTED TEXT rather than a file, that it issues a single RM call regardless of park count, and warns that synthesizing a PDF from the numbers produces an unauthorized document. This is exactly the extra context annotations cannot carry.

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 the DEFAULT designation and the routing rules, and every block (purpose, alternatives, download exclusion, output, args) earns its place. It is longer than strictly minimal – the multiple quoted example queries are somewhat redundant – but the length is justified by genuine routing stakes.

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 four-parameter, read-only analysis tool, the description covers routing, exclusions, output shape (combined Income/Expenses/NOI series, one column per month, park list), and call efficiency, and an output schema exists to carry return detail. Nothing an agent needs to call it correctly is missing.

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% and all four properties are bare strings with empty defaults, so the description must compensate and does: it gives portfolio ('name or 3-letter prefix'), property_ids (comma-separated), and MM/DD/YYYY formats plus semantic defaults (Jan 1 of current year / today) for the date range. Also explains scoping to a single park via portfolio or property_ids.

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?

States a specific verb and resource ('runs the 12-month recap report (ProfitLossRecapMonth, report 45)') and explicitly names itself as the DEFAULT P&L/T12 tool. It distinguishes itself from siblings analyze_financials and analyze_noi by parenthetical contrast, so an agent can route without opening either schema.

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?

Gives explicit when-to-use triggers ('show me a P&L', 'T12 for SCE', 'how has NOI moved'), names the two near-sibling alternatives and what distinguishes them, and adds an explicit when-NOT-to-use rule routing download requests to run_report(report_id=45). Nothing is left to inference.

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?

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety bar is met structurally. The description adds genuine behavioral context beyond that: it defines how the two comparison periods are derived, what is returned (per-property deltas + percentages, combined totals, top-mover lists), and which movers are surfaced. It omits rate limits or empty-result behavior, keeping it at 4.

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 the report name/ID and the crucial Period-1/Period-2 semantics before any detail. Every sentence earns its place: report identity, period derivation, returned metrics, then concrete user questions. No 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?

An output schema exists, so return values need not be re-explained, and annotations cover the safety profile. The description supplies the analysis semantics and example intents. The only real hole is parameter meaning for a 5-param, 0%-coverage schema, which keeps it from 5.

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% across 5 parameters, so the description carries the full burden. It only indirectly hints at the date-range parameters ('requested range') and top_movers ('top-mover lists'); it says nothing about portfolio vs property_ids, their relationship or exclusivity, date formats, or the meaning of the defaults. Two filter parameters remain entirely unexplained.

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?

States a specific verb (analyze/comparison), resource (P&L year-over-year), and even the underlying report ID (ProfitLossComparePreviousYear, 144). The definition of Period 1 vs Period 2 makes the exact computed semantics unambiguous and differentiable from siblings like analyze_pl_trend and analyze_pl_multi_year.

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?

Example questions ('how's NOI tracking vs last year', 'what's driving income growth', 'which expenses are up the most YoY') give clear situational context for when to reach for this tool, and the Period-2 definition implicitly scopes it to YoY questions. It never names the alternative sibling reports (analyze_pl_trend, analyze_pl_multi_year) or states exclusions, so it stops short of 5.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful behavioral fact that results are aggregated portfolio-wide with no property filtering, plus the report identifier (ProspectBoxScore, 21). It does not disclose any aggregation thresholds, tenant/connection scoping, or rate-limit behavior beyond that.

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 report's subject is front-loaded in the first sentence, the portfolio-wide scoping caveat follows immediately, and the question list is compact and information-dense. No filler, though splitting the content across three short paragraphs slightly fragments the read.

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?

An output schema exists, so return values need not be described, and the description does convey what the report contains. The gap is parameter behavior: a date-ranged, top-n report with three completely undocumented parameters leaves the agent guessing how to call it 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 description coverage is 0% and none of the three parameters (top_n, start_date, end_date) are mentioned anywhere in the description, so an agent gets no field-level meaning: is top_n applied per agent, per source, or per portfolio? Are dates inclusive and in what format? Nothing compensates for the empty schema descriptions.

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 names the specific analysis: leasing activity broken out by agent and inquiry source, portfolio-wide, with top agents, source-mix percentages, and an application-rate proxy. That is far more than a restatement of the tool name. It stops short of naming any sibling (e.g. lead_source_summary or analyze_lost_prospects, which overlap in subject matter), so it does not fully differentiate itself within the crowded analyze_* family.

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 'Answers: ...' framing implies the kinds of questions this report serves, which gives an agent some selection signal, and the note that it is portfolio-wide (not property-filtered) is a genuine usage constraint. However there is no explicit when-not-to-use guidance and no named alternative for the overlapping source-mix / lost-prospect reports, so routing must be inferred.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful content about what it computes (the market-rent signal) but discloses nothing about rate limits, auth, or data freshness beyond the annotation set.

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 the core purpose and the sibling differentiator, and every clause adds signal. The cryptic parenthetical '(LeaseExpiration, 76)' is dead weight but minor.

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?

An output schema exists, so return values needn't be explained and the description's output enumeration is bonus. However, with 6 undocumented parameters at 0% coverage and no usage prerequisites, the definition is not complete enough for confident invocation.

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% across 6 parameters (top_n, dates, portfolio, property_ids), so the description must carry the burden. It only loosely implies 'top-N' and date windows; it never explains start_date/end_date/as_of_date formats, portfolio, or property_ids. Significant gap.

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?

States a specific verb+resource ('Lease renewal + below-market rent gap analysis') and enumerates the concrete outputs (active/m2m/renewed/on-notice counts, 30/60/90-day expirations, market-vs-current rent gap, top-N lists). It also names the sibling it differs from, so an agent can distinguish it from lease_expirations without opening schemas.

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 contrasts with lease_expirations ('API-based and lighter') and explains the differentiator (market-rent column for pricing decisions). That routes the agent well, though it stops short of stating when-not-to-use or other alternatives among the many analyze_* siblings.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the description only needs to add analytical context – which it does by disclosing the data source (report 69), the unit-type dimensions, and that values are expressed as shares of total. Nothing about auth, rate limits, or pagination is mentioned, keeping it short of a 5.

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?

Purpose and the key split are front-loaded in the first sentence, and the example queries are compact and useful. Slightly verbose between the header line and the examples, but no sentence is wasted.

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 an output schema present, return values need not be explained, and the analytical framing is solid. However, the complete absence of parameter documentation for a zero-coverage schema leaves an agent unable to construct a well-formed call without guessing.

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% for all three parameters (portfolio, as_of_date, property_ids), so the description carries the full burden of explaining them. It says nothing about accepted formats, whether ids are comma-separated, or the default date behavior, leaving a real gap.

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?

States a specific verb and resource ('Scheduled-rent composition by unit type') plus the exact analytical split it performs (lot rent vs DOH vs RV vs apartments, base rent vs misc charges). This clearly differentiates it from sibling analyze_rent_roll, which supplies the underlying report 69.

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?

Gives concrete trigger phrases ('how much of our rent is lot rent vs home rent', 'revenue mix by unit type') and names the source report, which implicitly routes agents away from analyze_rent_roll. It stops short of an explicit when-not-to-use or a named alternative for raw rent-roll data.

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?

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add context beyond that. It does: it names the underlying report (SummaryRentRoll, report 69) and explains that vacant units are included so space counts and occupancy rates are accurate, which is genuinely useful for interpreting results.

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 tight sentences with zero filler, and the core purpose is front-loaded before the implementation detail about report 69. Nothing is wasted, though the second sentence borders on implementation trivia.

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?

An output schema exists so return values needn't be described, and annotations cover the safety profile. The remaining gap is parameter documentation: three inputs with 0% schema coverage and no format guidance leaves the agent guessing at call syntax.

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% across all three parameters, so the description must compensate and largely does not. Only 'for a portfolio' loosely hints at the portfolio parameter; there is no guidance on the format of as_of_date or how property_ids should be supplied (comma-separated? list string?).

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?

States a specific output (occupancy + scheduled rent summary) for a specific scope (a portfolio), which is a clear verb+resource pairing. It does not, however, differentiate itself from overlapping siblings such as analyze_occupancy_trend, analyze_vacancy, or analyze_rent_composition, so the agent must still infer which is appropriate.

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 what the tool produces but gives no when-to-use, when-not-to-use, or named alternative. With many adjacent analytical siblings, an explicit routing hint between this and analyze_occupancy_trend / analyze_rent_composition is exactly what is missing.

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?

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds the scope of returned content but says nothing about how as_of_date affects the snapshot, portfolio scoping behavior, or result limits. With annotations carrying the behavioral load, a 3 is appropriate.

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 what the tool returns, followed by usage framing; two tight sentences with little waste. The parenthetical '(SecurityDeposit, 83)' is cryptic code-like noise that doesn't earn its place.

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?

An output schema exists, so return values need not be explained, and annotations cover safety. The remaining gap is parameter documentation: with four undocumented parameters at 0% schema coverage, an agent lacks guidance on filtering and date scoping.

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% for all four parameters, so the description must carry the burden and largely does not. 'Top largest individual deposits' hints at top_n and 'per-property breakdown' hints at property_ids, but portfolio and as_of_date are never mentioned, leaving their meaning and format unexplained.

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?

Names a specific resource (SecurityDeposit) and enumerates exactly what the snapshot contains: total held liability, lifecycle totals (charged/received/refunded), per-property breakdown, and top deposits. No sibling tool covers deposits, so an agent can route to it without ambiguity.

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 concrete use-case framing ('how much in deposits are we sitting on', per-property liability questions), which tells the agent when this tool is the right pick. It stops short of naming alternatives or stating exclusions (e.g., a date-range caveat).

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond that by disclosing the scope constraint that this report has no Property column and is portfolio-wide, which is exactly the kind of behavioral caveat an agent needs to avoid misusing it.

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 what the report is and its scope caveat, followed by output contents, filters, and example questions. No redundant sentences; the parenthetical report code is compact metadata.

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 an output schema present, the description need not explain return values, and it covers scope, filters, and content well. The one gap is that two date parameters are undocumented anywhere, leaving the time-window semantics for an agent to guess.

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% across 7 parameters, so the description carries the burden. It mentions category/priority/status filters, implies open_only via 'age distribution of open issues', and implies top_n via 'lists the oldest open issues', but says nothing about start_date/end_date or the default of open_only.

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 concrete deliverable (work-order/service-issue backlog summary) and names the underlying report and its portfolio-wide scope, which clearly differentiates it from the sibling get_work_orders list tool. An agent can tell exactly what this produces without opening the schema.

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 'Answers:' block gives explicit question-shaped triggers ('how many open work orders', 'how stale is the backlog', 'oldest unresolved issues') that map well to when to invoke it. It stops short of naming the alternative (get_work_orders) for row-level lookups, so it is clear context without explicit exclusions.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely non-obvious behavior: RM logs a session only at LOGOUT, so today's hours understate concurrency while completed days are accurate. That caveat — plus the per-day-peak vs hourly-profile return shape and the org-wide scoping constraint — is exactly the kind of context structured fields cannot carry.

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 purpose, then a scannable bulleted example block, then returns, then the caveat, then the args. Length is justified by the amount of genuinely useful information; every sentence contributes routing or invocation value with no 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?

Although an output schema exists (so return values need not be explained), the description still summarizes the key outputs, then covers scope, the today-incompleteness caveat, and both argument formats/defaults. For a zero-required-param, zero-coverage-schema analysis tool, nothing an agent needs to call it correctly is missing.

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 and it does: both parameters are documented with their MM/DD/YYYY format and their defaults (start_date = 6 days ago / 7-day window, end_date = today). No ambiguity remains about how to supply the arguments.

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 opening sentence names a specific verb and resource ('Rent Manager user login activity and concurrent-user counts') and even cites the underlying source (UserLog, 3). It also declares the scope boundary ('Org-wide by nature — there is no property scope'), which sharply separates it from property-scoped analyses like analyze_occupancy_trend or analyze_rent_roll in the sibling set.

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?

Four concrete example user questions ('How many users were logged in at one time yesterday?', 'peak concurrent user count this week', 'failed login attempts') give an agent strong routing signal for when to pick this tool. It does not, however, name an alternative sibling or an explicit when-not condition, so it falls just short of the 5 bar.

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?

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description's job is to add context beyond that. It does: it discloses the snapshot-vs-time-series nature of the result and the composition of the payload (aging buckets, unit-type breakdown), which tells the agent what it will actually get. It stops short of noting rate limits, pagination, or scoping behavior for portfolio/property filters.

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?

Four short sentences, each carrying distinct information: identity, metric list, payload composition, and the temporal caveat. It is front-loaded with the core purpose and has no 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?

An output schema exists, so return values need not be documented, yet the description still usefully previews them. The tool's scope and data shape are clear; the only real gap is that none of the four inputs (especially as_of_date and the portfolio/property filters) are described, which matters for correct invocation.

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% across four parameters, so the description must compensate and largely does not. 'Top-N longest-vacant units' loosely maps to top_n and 'per property' loosely hints at property_ids/portfolio, but as_of_date and the semantics of the filter strings are never explained.

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 names a specific analysis ('Vacancy snapshot per property') and enumerates the exact outputs: vacant count, average/oldest days-vacant, foregone monthly rent, aging histogram, unit-type breakdown, and top-N longest-vacant units. It also cites the underlying report (74), and the 'point-in-time snapshot, not a time-series' line distinguishes it from trend-oriented siblings such as analyze_occupancy_trend.

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?

Usage is implied rather than stated: an agent can infer this is the tool for vacancy-level analysis, and the 'not a time-series' note implicitly points to trend tools for temporal questions. However, no sibling is named and there are no explicit when-to-use/when-not conditions, so the routing burden falls on the reader.

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?

Adds substantial context beyond the annotations: VOIDs are excluded by default with include_voids=True to net them in, long ranges (90+ days) can take 1-3 minutes and return ~5800 rows, and follow-up queries within 5 minutes are cached. These performance, default-filtering, and caching traits are exactly what an agent needs and are not covered by the readOnly/idempotent hints.

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-loads what the tool reports and its defaults, then covers performance caveats. The slow-range warning and the scripted user one-liner are slightly verbose but each earns its place by preventing a bad UX on long queries.

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 an output schema present, return values need not be described, and the description covers scope, defaults, void handling, and performance. It is nearly complete; only the scoping parameters (portfolio vs. property_ids) lack clarifying semantics.

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 carry the parameter burden. It explains include_voids well, implies top_n ('top vendors') and the date window defaults, but leaves portfolio vs. property_ids semantics and expected string formats (e.g. comma-separated IDs) undocumented, so it only partially compensates.

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?

States a specific verb+resource ('Vendor spend / AP outflows') and details the exact output surfaces: top vendors by gross spend, per-property totals, and largest individual bills. This scope is specific enough to distinguish it from sibling payables tools like analyze_aged_payables or get_bills without opening schemas.

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 its usage domain (AP outflows over a window, trailing 30-day default) and gives operational guidance about when to warn the user on long windows. However, it never explicitly routes the agent away from or toward alternatives such as analyze_aged_payables, get_bills, or vendor_compliance, so the 'vs alternatives' dimension is left to inference.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond the purpose statement — it does not say what the reconciliation output contains, whether missing meter data is surfaced, or how partial periods are treated.

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?

A single front-loaded sentence with no filler or repetition. It is efficient, though at the cost of the detail needed for the four undocumented parameters.

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?

An output schema exists, so return values need not be described, and the read-only annotations cover the safety profile. However, with 0% parameter coverage and no usage guidance, the definition is thin for a tool that takes a date range and property/portfolio scope.

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% across four parameters (start_date, end_date, portfolio, property_ids), and the description supplies no date format, no hint that portfolio and property_ids are alternative scoping mechanisms, and no statement that all parameters are optional. The description does not compensate for the schema gap.

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 names a specific verb and resource pair ("Reconcile ... water/sewer consumption") and adds the comparison being performed — master-meter totals against tenant sub-meter totals. That is concrete and distinct from the other analyze_* siblings, none of which touch utilities, though it never explicitly states how it differs from them.

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?

There is no when-to-use guidance, no prerequisites (e.g., that meter reads or rate cards must exist first), and no alternative tool is named. An agent knows what the tool does but not under what circumstances to choose 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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive), and the description adds real behavioral context on top: PDFs are rendered page-by-page so contents are readable rather than merely saved, the response reports which pages came back and what to request next, and a parent identifier is required when the FileID wasn't sourced from a listing in the current conversation.

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 the core action ('Download and READ ... by FileID') and organized into purposeful paragraphs covering purpose, sources, prerequisites, and paging. The framing is slightly conversational ('which is the only way to read a scanned signed lease') and could be tightened, but no paragraph is 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 10-parameter, no-required-argument tool with no output schema, the description covers the essential call path and return behavior (page reporting) plus annotations handle safety. The remaining gap is the file-output semantics — whether save_as writes to disk and what as_images=true returns — which an agent must currently 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?

With 0% schema coverage the description carries the load, and it does document file_id's provenance, the five parent-record IDs, and pages syntax ('1-40'). It leaves save_as, as_images, and max_pages unexplained — and max_pages=10 by default is in mild tension with the advice to request 40-page chunks, which is exactly the kind of interaction an agent needs clarified.

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?

States a specific verb and resource ('Download and READ a Rent Manager attachment by FileID') and scopes it to record-level attachments filed on tenants, payments, and GL entries. The list of source tools and parent-record IDs (tenant_id, check_id, bill_id, credit_card_transaction_id, journal_id) effectively separates it from download_property_attachment, download_unit_attachment, and download_invoices.

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 names the alternatives it draws FileIDs from (get_tenant_notes, get_check_attachments, get_credit_card_attachments, get_journal_attachments, get_tenant_udfs, get_property_udfs) and the condition under which the parent record must also be supplied. It also prescribes the chunking workflow for long documents, so an agent knows both when to call it and how to iterate.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety and repeatability profile is covered. The description adds only the destination detail (per-tenant FileStore) and says nothing about pagination, batch limits, overwrite behavior, or what happens on re-runs against an idempotent 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 single sentence is front-loaded and free of filler, which is good, but for a tool with seven undocumented parameters it is undersized rather than appropriately 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?

An output schema exists, so return values need not be explained, but the description leaves the seven input filters, the meaning of return_images, and the scope of limit completely unaddressed. An agent cannot confidently call this tool with correct arguments.

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?

Seven parameters exist at 0% schema description coverage, and the description mentions none of them: limit, vendor, start_date/end_date, portfolio, property_ids, and return_images are entirely undocumented anywhere. The description does no work to compensate for this gap.

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?

States a specific verb (download) and resource (vendor-invoice attachments) plus the destination (per-tenant FileStore), which distinguishes it from generic siblings like download_attachment and download_property_tax_bill. It stops short of explicitly naming or contrasting those siblings, so it falls short of a 5.

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?

There is no indication of when to use this tool versus the other download_* siblings, nor any prerequisites, exclusions, or filtering context. The agent must infer usage entirely from the name.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful side-effect context that the file is placed into FileStore, but says nothing about permissions, rate limits, or overwrite behavior.

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?

A single front-loaded sentence with the verb and resource up front and zero wasted words. It is appropriately terse, though it could have carried a few more bytes of routing or parameter detail at little cost.

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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. However, with five undocumented parameters and no when-to-use guidance against three similarly named download siblings, the definition is only minimally adequate.

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% across five parameters, so the description must compensate. It only loosely hints at udf_name ('property UDF') and save_as ('into FileStore'), leaving file_id, shortname, and property_id completely unexplained in both schema and 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 states a specific verb and resource: pulling a file attached to a property UDF into FileStore, with concrete examples (W9, COI, license). It is clear what the tool does, though it does not explicitly distinguish itself from close siblings like download_attachment, download_unit_attachment, or download_property_tax_bill.

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?

There is no guidance on when to use this tool rather than download_attachment, download_unit_attachment, or get_property_udfs. No prerequisites, no exclusions, and no mention of required vs optional params are given.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds that the artifact comes from an AP bill linked to a GL account and that the return can be a PDF or an image. It says nothing about behavior when no bill matches, or about volume/size limits for image returns, which would have been valuable given openWorldHint=true.

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?

A single front-loaded sentence with zero filler. It is arguably too sparse for a 9-parameter tool, but it wastes no words.

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 9 undocumented parameters, 0% schema coverage, and an output schema that removes the need to explain return values, the description should still clarify how to scope the lookup (date range, portfolio, property IDs, latest-only behavior). It does not, leaving an agent guessing on nearly every input.

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% across 9 parameters, so the description carries the full burden and largely fails: it hints at gl_code/gl_name and return_images, but leaves year, start_date, end_date, portfolio, property_ids and latest_only completely unexplained. No formats, no defaults rationale, no indication that latest_only defaults to true.

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?

States a specific verb+resource (pull the tax-bill PDF/image) and the source (the AP bill that hits a GL account), which separates it from download_attachment, download_invoices and download_property_attachment. The phrasing 'hits a GL account' is jargon but does convey scope. Clear, though it never explicitly names a sibling it is not.

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?

No when-to-use guidance, no prerequisites (must the GL account be resolved first via list_gl_accounts?), and no direction on which download sibling to pick when the user just says 'get the bill'. The agent must infer everything from the one-line description.

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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds genuine behavioral context beyond that: 'PDF pages are rendered so the contents can be read, not just saved', plus the conditional that 'udf_name is optional' when a unit holds exactly one file. It does not cover rate limits or the return format, but adds meaningful value.

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-loads the core action and is reasonably compact, but the 'unit equivalent of download_property_attachment' framing and the photo-exclusion sentence add lines that could be tighter. Every sentence earns its place by routing or clarifying, but it is not maximally lean.

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, no required parameters, and 10 undocumented inputs, the description does the conceptual heavy lifting well but leaves the parameters opaque. For a tool with this many optional knobs (pages, save_as, as_images, etc.), an agent cannot fully determine correct invocation from the description alone.

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% across 10 parameters, so the description must carry the burden. It clarifies only udf_name (optional when one file exists) and gestures at page rendering; the remaining parameters (pages, max_pages, as_images, save_as, shortname, unit_name, unit_id, property_id, file_id) are undocumented anywhere, leaving most semantics unexplained.

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?

States a specific verb and resource ('Download and READ a file attached to a unit's UDF') and immediately positions it as 'The unit equivalent of download_property_attachment'. It distinguishes the tool from the photo path by naming get_unit_images, so an agent can tell it apart from siblings without opening any schema.

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?

Gives explicit context ('titles, certificates of occupancy, inspection reports and anything else filed on a unit's File-type UDFs') and one clear exclusion with the alternative named: 'For unit PHOTOS ... use get_unit_images.' It does not address the generic download_attachment sibling, so guidance is strong but not fully comprehensive.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description does add genuinely new behavioral information — that output lands in FileStore as a multi-sheet XLSX — but says nothing about how the file is retrieved, how long a full-fleet export takes, or the effect of max_workers/sample_consumption on cost.

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?

A single front-loaded sentence with the output artifact and destination stated first; nothing is padded. The arrow shorthand is slightly telegraphic but costs no extra tokens.

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?

An output schema exists, so return-value explanation is not needed. However, for a fan-out export tool with a concurrency knob and a sampling knob, the definition omits parameter meaning, any warning about scale/runtime, and any hint of how the resulting FileStore object is consumed — leaving the agent under-informed on the parts that matter.

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% across all three parameters, so the description carries the full burden — and it contributes nothing. 'active_only' and 'max_workers' are guessable from their names, but 'sample_consumption' (default 1,000,000) is opaque and its units, purpose, and impact on accuracy are undocumented anywhere.

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 concrete verb ('Build'), a concrete artifact ('multi-sheet XLSX of every meter type's rate card'), and the destination ('FileStore'). It implicitly distinguishes itself from the sibling get_meter_rate_card by covering 'every' meter type, but it never names that sibling or any other alternative, so the differentiation is left to inference.

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?

Usage is only implied by the word 'every' — an agent can infer this is the bulk-export counterpart to the single-card reader. There is no explicit when-to-use, when-not-to-use, or named alternative, and no prerequisite (permissions, connection, expected runtime) is stated.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds nothing behavioral beyond that: no pagination or limit semantics, no date-window behavior, no scoping rules for the optional filters.

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?

A single front-loaded sentence with no filler, which is good structure. It is arguably too terse for a six-parameter tool with no schema documentation, but there is no wasted 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?

An output schema exists, so return values need not be explained, and annotations cover safety. However, with six undocumented filter parameters and no usage guidance, the description leaves genuinely needed call-time information (date filtering, vendor matching, limit behavior) unstated.

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% across six parameters, so the description carries the full burden and largely fails. 'One or more properties' loosely hints that property_ids/portfolio are filtering inputs, but vendor, start_date, end_date, and limit are never explained — an agent cannot tell date format, whether vendor is exact-match, or how limit interacts with defaults.

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 gives a specific verb and resource ('List vendor bills'), and the parenthetical '(AP invoices)' disambiguates it from sales/AR invoices and other financial siblings. It states the scope ('for one or more properties') but does not explicitly differentiate itself from neighbors like analyze_aged_payables or download_invoices.

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?

There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as analyze_aged_payables for aging analysis or download_invoices for attachments. The agent must infer usage purely from the name and the surrounding tool list.

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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuine workflow behavior: this is a two-step flow whose results must be handed to download_attachment, and it explains why the sibling tools cannot reach these rows. It does not mention pagination or rate limits, so it stops short of a 5.

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 tight paragraphs: purpose and output front-loaded, then the usage condition and next step. Every sentence earns its place with no 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?

With an output schema present, return values need not be explained, and annotations carry the safety profile. The description covers purpose, routing, and the follow-up workflow; the only gap is the undocumented check_id and limit 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%, so the description must compensate. It names the conceptual search axes ('date range, payee, or amount'), covering start_date/end_date, payee, and amount, but omits check_id and limit entirely and gives no format details for dates or amounts. Partial compensation only.

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?

States a specific verb and resource ('List invoice scans attached to CHECKS, with their FileIDs') and immediately scopes it against siblings by naming the exact situation (checks with no AP bill record). An agent can distinguish this from get_bills and download_invoices without opening any schema.

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?

Explicit when-to-use ('when a vendor was paid by check with no AP bill record'), names the alternatives that fail (get_bills, download_invoices) and why ('those rows show with no BillID'), and prescribes the follow-up step (pass FileID to download_attachment). Nothing is left to inference.

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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds real context beyond them: where these attachments physically live in the data model and that the result feeds download_attachment via FileID. It does not mention pagination behavior, which is a minor omission.

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 short sentences, purpose front-loaded, no filler. The middle sentence explaining the data-model quirk is long but earns its place by justifying the tool's existence and its distinctness from the bill/check tools.

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 an output schema present, the description needn't explain return values, and the read-only annotations handle safety. It covers the discovery scenario and the download handoff well; the remaining gap is filter semantics for transaction_id and limit, which no structured field documents.

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% and all seven parameters carry only generic titles, so the burden is on the description. It names the filter dimensions (date range, vendor, amount, card), which maps to start_date/end_date, payee, amount, and credit_card_id, but transaction_id and limit go unmentioned, and the 'vendor' wording does not match the 'payee' parameter name, risking a mismatch.

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?

Specific verb+resource: 'List invoice/receipt scans attached to CREDIT CARD transactions.' It draws the boundary against the nearest siblings by noting these attachments live on card transactions and are 'out of reach of the bill and check tools,' which separates it from get_bills, get_check_attachments, and get_journal_attachments.

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 supplies the discovering scenario (card purchases whose invoices attach to the card transaction, not an AP bill) and the search facets, plus the follow-on step of passing a FileID to download_attachment. It does not state an explicit exclusion or fallback for the case where the document is actually on a bill, but the routing 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that — the documents are scans tied to GL entries and the returned FileID is the input to download_attachment — but it omits pagination/limit behavior and any auth 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?

Three sentences, front-loaded with the purpose, then the disambiguation, then the search/next-step guidance. The middle sentence is slightly long but each sentence carries distinct information, so there is little waste.

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?

An output schema exists, so return values needn't be explained, and annotations cover the safety profile. The description is complete enough to select and call the tool, with the only real gap being the undocumented limit and journal_id 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%, so the description must carry the parameter burden. It names 'date range, memo, or amount' (covering start_date/end_date, memo, amount) but says nothing about limit or journal_id, leaving two of six parameters undocumented anywhere. Partial compensation only.

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?

States a specific verb ('List') and resource ('invoice/receipt scans attached to JOURNAL (GL) entries'), and explicitly distinguishes itself from the sibling attachment tools by noting the documentation is 'out of reach of the bill, check, and card tools.' An agent can tell it apart from get_check_attachments and get_credit_card_attachments without opening any schema.

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?

Names the scenario that selects this tool (charges posted straight to the GL, including credit card purchases entered as journal entries rather than card transactions) and the alternative attachment tools it is not. It also gives the follow-up path: 'pass a FileID to download_attachment to read the document.' When-to-use and the next step are both 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?

Annotations already establish read-only/idempotent/open-world, so the description's added value is the report backing it and the fact that 'open_only' (default True) hides closed items and that scoping is done via portfolio/property_ids. That is genuine behavioral context beyond the annotations, though return shape and pagination are left to the 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.

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

Front-loads the definition and purpose, then enumerates returned fields, then usage cues, then parameter behavior. Dense and mostly waste-free, though the field enumeration is list-like and slightly padded relative to the two sentences that actually drive selection.

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 an output schema present, the description needn't explain return values, and it supplies purpose, scope, and the key filtering semantics. The only material gaps are the meaning/format of 'limit' and the string format expected for portfolio/property_ids.

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 carry the load. It explains open_only (default True, hides closed) and the portfolio/property_ids scoping concept, but says nothing about 'limit' and gives no format hints for the id/portfolio strings, leaving one of four parameters undocumented.

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?

States a specific verb+resource ('lease/community-rule violations — open compliance items by property') and even names the underlying report (TenantViolationsListing, report 637) plus the exact fields returned. No sibling in the list covers violations/compliance for tenants, so an agent can route here unambiguously.

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?

Gives concrete triggering phrasings — 'what violations are open at <park>', 'compliance issues', 'who has an open violation' — which map user intent onto the tool. It never names a competing tool to avoid (e.g. get_resident_concerns or analyze_evictions), so it stops short of explicit when-not 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?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds the marketing allow-list scoping trait, which is useful, but it says nothing about pagination, result size, or the openWorld behavior implied by the annotation.

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?

A single front-loaded sentence with no filler or repetition. It is telegraphic to the point of being a fragment, but every word carries 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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. Still, for a two-parameter tool with 0% schema coverage and three closely related UDF siblings, the description leaves usage and parameter meaning unresolved.

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% for two parameters. The description's phrase 'property-level' loosely maps to property_id, but 'shortname' is entirely unexplained and no format, default behavior, or interaction between the two params is given, so the description does not compensate for the coverage gap.

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?

States a specific resource (property-level UDFs) and a scope qualifier (filtered to the marketing allow-list), which is enough to distinguish it from the tenant/unit/property UDF siblings. However, it never names get_property_udfs, so the agent must infer the distinction from the scope phrase alone.

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?

No when-to-use or when-not-to-use guidance. With get_property_udfs, get_tenant_udfs, and get_unit_udfs in the sibling list, an agent calling this tool has no stated rule for choosing it over the unfiltered variant.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that output is pretty-printed and sourced from Report 514, which is useful framing, but it says nothing about auth, rate limits, or what happens if the meter_type_id is unknown.

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?

A single front-loaded sentence with the action first and the source last; 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?

With an output schema present, return values need not be described, and annotations cover the safety profile. The remaining gap is the undocumented sample_consumption parameter, which the description should have clarified given zero schema coverage.

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 neither parameter is documented anywhere. The description does not explain meter_type_id or, more importantly, sample_consumption, which defaults to 1,000,000 and whose purpose and unit are entirely opaque to a caller.

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?

States a specific verb (pull and pretty-print) and resource (one meter type's rate card), and the singular scope implicitly distinguishes it from the dump_all_rate_cards sibling. It stops short of naming that alternative, so the differentiation is inferable rather than explicit.

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?

There is no explicit when-to-use, when-not-to-use, or named alternative. The phrase 'one meter type's' hints that dump_all_rate_cards handles the bulk case, but the description never states the selection condition, leaving the agent to infer 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful context that results are individual sub-meter readings tied to billing cycles and sourced from Report 104, but says nothing about pagination, volume, or formatting behavior.

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 single sentence is front-loaded and free of padding, which is good. But for a 7-parameter tool it is under-specified rather than genuinely concise, so the brevity reflects missing information rather than efficient editing.

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?

An output schema exists, so return values need not be described. However, an agent still lacks usage context, sibling differentiation, and any documentation for seven undocumented parameters, leaving the definition incomplete for correct invocation.

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% across 7 parameters (unit, tenant, start_date, end_date, portfolio, property_ids, exception_only), and the description supplies no parameter meaning at all. An agent cannot tell what 'exception_only' toggles, what format the dates take, or whether property_ids is a list.

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 names a specific resource (individual sub-meter readings) and scoping (per billing cycle) plus the data source (Report 104), so the purpose is discernible. However, it does not distinguish this tool from close siblings like get_meter_rate_card, list_meter_types, or analyze_water_consumption, leaving an agent to infer the boundary.

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?

There is no when-to-use guidance, no prerequisites, and no naming of alternatives among the ~70 sibling tools. The 'Report 104' note implies a reporting origin but does not tell an agent when to prefer this over the rate card or water consumption 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful output-shape fact that results are one row per unit, but says nothing about scope limits, performance, or how 'all home UDFs' interacts with property scoping.

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?

A single front-loaded sentence with no filler. It is efficiently written, though the brevity stems partly from under-specification rather than from trimming 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?

An output schema exists, so return values need not be described, but the description still leaves four undocumented parameters, no usage context, and no explanation of how UDF selection or property scoping works. For a 4-parameter tool with 0% schema coverage, this is inadequate.

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% across four parameters (fields, shortname, property_id, only_with_data), and the description documents none of them. It only hints at the UDF domain, which loosely relates to 'fields', leaving property_id scoping and the only_with_data filter entirely unexplained.

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?

States a specific action and output shape: 'Build a one-row-per-unit home-inventory table across all home UDFs.' This is distinguishable from siblings like get_property_udfs or analyze_rent_roll, but the term 'home-inventory table' is domain jargon that leaves the actual content somewhat opaque.

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?

No when-to-use guidance, no prerequisites, and no mention of how this differs from get_property_udfs, get_unit_udfs, or the many analyze_* siblings. The agent must guess at the intended scenario.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds only that a 'state summary' accompanies the table, which is behaviorally marginal and overlaps with the output schema. No rate limits, auth, or pagination 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?

A single tight sentence with no filler, and the core output description comes first. Slightly under-specified rather than bloated, so it earns its brevity but adds little substance.

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 four-parameter tool with zero schema description coverage, the description should clarify what portfolio and property_ids accept and how the filters combine. The presence of an output schema means return values need not be explained, but the parameter gaps leave the definition incomplete.

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% for all four parameters. The description mentions state and city filters, which partially covers two of them, but portfolio and property_ids are entirely undocumented in both the schema and the description, leaving half the inputs opaque.

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 identifies the resource (park/property addresses) and the output shape (a table plus a state summary), so an agent can form a rough idea of what it returns. However, there is no clear verb and no differentiation from the many sibling get_* / list_* tools, and 'park addresses' is loose phrasing for property locations.

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?

No indication of when this tool should be chosen over alternatives such as list_properties, list_property_units, or get_property_udfs. The only usage-relevant information is that state/city filters exist, which is inferred from the schema anyway.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds one useful piece of context beyond that — that file attachments are included in the result — but says nothing about scope, permissions, or result size for what could be an attachment-heavy response.

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?

A single front-loaded sentence with no filler. The resource and the one notable result detail (attachments) lead the sentence, and nothing is wasted.

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?

An output schema exists so return values need not be described. The remaining gaps are parameter semantics and sibling differentiation, which I penalized in their own dimensions; for a simple two-parameter read-only list tool this is close to adequate.

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% for two parameters (shortname and property_id), so the description must compensate and does not — neither parameter is mentioned, and their mutual relationship, default empty values, and required-less invocation are unexplained. The agent cannot tell whether shortname or property_id is preferred, or what an empty shortname does.

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?

States a specific verb and resource: 'List all UDF values for a property'. However, the sibling set contains get_tenant_udfs, get_unit_udfs, and get_marketing_udfs, and the description makes no attempt to distinguish this property-scoped variant from those, leaving the agent to infer the distinction from the name alone.

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?

There is no guidance on when to use this tool versus the three sibling UDF tools, nor any stated prerequisites about needing a property identifier or shortname. The agent must infer usage context entirely from the name.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered externally. The description's only added behavioral value is the shape of what comes back ('full detail'), which is largely superseded by the existing 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.

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

A single front-loaded sentence with no filler; every clause earns its place by naming the resource and the payload contents.

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 one-parameter read tool with an output schema and full annotation coverage, the description covers the essentials, but it omits the only thing an agent must reason about: how to obtain a valid prospect_id, which the sibling list_prospects would provide.

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% and the lone parameter prospect_id carries only a title with no type guidance or source. The description never mentions the identifier at all, so it fails to compensate for the schema gap on the one input that must be supplied correctly.

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?

States a specific verb and resource ('Full detail for one prospect') and enumerates the returned fields (contact info, lead source, status, dates), which distinguishes it from list_prospects and the analyze_* siblings that aggregate rather than retrieve. It stops short of naming a sibling alternative, but the singular-record scope is 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?

'one prospect' implies the single-record lookup case, which is a weak usage cue at best. There is no statement of when to prefer this over list_prospects or analyze_prospect_pipeline, and no prerequisite (e.g. where the prospect_id comes from) is mentioned.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the underlying endpoint, the returned linked entities (tenant, unit, property, full complaint text), the 'Resident Concern' issue scoping, and the newest-first ordering.

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 the core capability and the sibling contrast, then filters, then example queries. Slightly long, but each block—contrast, data payload, filters, triggers—carries distinct information, so little is wasted.

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 an output schema present, return-value detail is not needed, and annotations cover the safety profile. The description supplies source, payload contents, ordering, and filter semantics, leaving only the limit param unexplained—a minor gap for a 7-param, read-only 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 0%, so the description carries the parameter burden and mostly delivers: it explains property (name or short code), status, priority, and the start_date/end_date window with accepted formats (M/D/YYYY or ISO). It only leaves limit and the open_only toggle unaddressed, though 'open resident complaints' hints at open_only's default behavior.

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