Pad Count: mobile home park loan sizer

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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety bar is lower. The description adds real value beyond them: every rule is returned with its primary source and date, and SBA is disclosed up front as a not-eligible result with an SOP quote — an agent can anticipate a negative-result shape rather than treating it as an error.

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 resource and providers, then a compact list of returned fields — no filler sentences. The single sentence is long and list-heavy, which slightly hurts scannability, but every clause 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?

With one optional enum parameter, no output schema, and full annotation coverage, the description supplies everything an agent needs: what it returns field-by-field, that provenance (source + date) accompanies each rule, and the notable SBA not-eligible outcome. Nothing material is missing 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?

The single parameter has 100% schema coverage with an explicit enum and default, so the schema does the heavy lifting. The description expands the program acronyms (Fannie Mae MHC, Freddie Mac Optigo MHC, HUD Section 223(f) MHC, SBA 7(a)/504), which adds modest meaning over the bare enum values but nothing about filtering behavior.

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 ('published rules for financing a mobile home park') and enumerates the four programs covered, plus the exact rule fields returned (max LTV, min DSCR, amortization, occupancy, etc.). It is clearly distinguishable from siblings like size_park_loan or value_park_on_lot_rent, which compute numbers rather than retrieve rules.

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 content strongly implies when to call it (need underwriting criteria or program eligibility rules), and it usefully warns that SBA comes back as not eligible. However, it never states when to prefer a sibling or explicitly scopes itself against alternatives such as size_park_loan, leaving routing 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, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real substance beyond that: the upstream data source, the three segment breakdowns (single-section, double-section, all), and the time coverage (latest month plus prior months). It does not say how far back the series goes or in what unit/currency values return, which keeps it out of 5 territory.

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

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

Two sentences with no repetition: provenance and content first, interpretive use case second. The breakdown dimensions are front-loaded, and nothing in the text merely restates the title. Every clause carries information an agent would not otherwise have.

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

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

With no output schema and no parameters, the description carries the burden of describing returns, and it does so at a structural level: monthly observations, split by single-section, double-section and all homes. Missing is any indication of series depth, units, or response shape, which are minor but real gaps for a data-retrieval tool.

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

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

The tool takes zero parameters and the schema is fully specified as an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter confusion is possible.

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 and provenance: the Census Bureau Manufactured Housing Survey average sales price of a new manufactured home, broken out by month of shipment into single-section, double-section and all homes. That is precise enough to distinguish it from the sibling tools (loan rules, park sizing, lot-rent valuation), which are different domains entirely. The only weakness is that the verb is implicit — it never says 'retrieves/returns' explicitly, though the framing makes the read obvious.

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 closing sentence, 'A yardstick for what filling a vacant pad with a new park-owned home costs,' supplies a concrete use context. However, it gives no when-not guidance, no prerequisites, and never names a sibling tool or condition that would route the agent elsewhere. Usage is implied by the framing rather than stated as a rule.

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, non-destructive behavior. The description adds substantial behavioral detail beyond annotations: the verdict categories, the loan amount formula, which limit binds, the rate construction, failed rules, and the SBA SOP quote.

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 core action and then packs in return details. It is dense and slightly run-on, but every clause contributes useful information about outputs or scope.

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 complex 18-parameter tool with no output schema, the description explains the return values, program coverage, SBA exclusion, and sizing formula. Combined with the fully documented input schema and safety annotations, it is complete enough for an agent to call 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 100%, so the schema already documents all 18 parameters thoroughly. The description adds conceptual context around value, LTV, NOI, coverage, and loan constant, but does not add parameter-specific meaning beyond the schema.

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

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

The description states a specific verb and resource: it runs the Pad Count loan sizer on one mobile home park and returns a verdict plus loan details. It is clear what the tool does, but it does not explicitly differentiate itself from siblings such as get_mhc_loan_program_rules or value_park_on_lot_rent.

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 by 'on one mobile home park' and by the note that SBA 7(a) and 504 come back as not eligible. However, there is no explicit guidance on when to choose this tool over the sibling rules or valuation 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral value by disclosing the specific lender checks returned (85% occupancy, 25%/35% park-owned home caps, Fannie Mae 5% vacancy floor, park-paid utilities), which tells the agent what analytical judgments the tool performs beyond a raw arithmetic pass.

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 a single front-loaded sentence that leads with the verb and worksheet name, with no filler or restatement of the title. It is long and dense—listing every output in one breath—but each clause carries information, so a small deduction for density rather than 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?

With 22 parameters and no output schema, the description carries the burden of explaining the return value, and it does so explicitly: collected income, operating expenses, NOI, NOI from lots alone, low/mid/high cap-rate values, value per pad and lender flags. An agent can predict the response shape without an output schema.

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

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

Schema description coverage is 100% and each of the 22 parameters already carries ranges, defaults and examples, so the baseline is 3. The description only groups parameters into rough categories (pads, occupancy, lot rent, park-owned homes, other income and expenses) and adds no syntax or semantic detail beyond the schema.

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

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

The description names a specific worksheet ('Pad Count lot-rent valuation') and a concrete verb ('runs'), then enumerates its inputs and outputs so the agent knows exactly what the tool produces. That output set (NOI, value at a cap-rate range, value per pad, lender flags) makes it unmistakably a valuation tool rather than the loan-sizing or rules-lookup siblings.

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 enumerated inputs, chiefly the required cap_rate_low_pct/high_pct, which signal 'use this to value a park'. There is no explicit instruction on when to pick this over size_park_loan or get_mhc_loan_program_rules, and no stated preconditions or exclusions despite three siblings in the same domain.

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