FactLot

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

Annotations declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description adds valuable behavior beyond that: determinism, that it returns balance due plus a full trace, and that warnings should be surfaced. It does not detail rate limits or failure modes, keeping it below 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?

The description is two dense sentences: the first front-loads the full scope of the reconciliation, the second delivers the key operational instruction. Every clause maps to a real behavior or parameter family, 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?

For a complex 7-parameter nested tool with no output schema, it covers the calculation domains, tells the agent not to reimplement the math, and notes a trace plus warnings are returned. It omits the currency/units and what the trace contains in detail, but the schema already documents units, leaving only a minor 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 coverage is 100%, so the baseline is 3, but the description adds meaning by naming the cap methods (compounding_from_base, simple_from_base, year_over_year) and the structural choices (base year or expense stop) in prose. It explains the conceptual inputs rather than restating field syntax, though it does not clarify every parameter.

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 ("Reconcile a tenant's annual CAM charge") and enumerates the exact lease mechanics handled: exclusions, occupancy gross-up, pro rata share, controllable caps, base year or expense stop, and estimates paid. It clearly distinguishes this from siblings like calc_net_effective_rent or calc_rent_schedule, which do not perform CAM reconciliation.

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

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

It explicitly says "use this instead of doing the math yourself" and instructs the agent to cite formula calc.cam_reconciliation@1 and the returned steps, surfacing warnings. This is direct when-to-use guidance with a clear alternative (manual math) ruled out, though no sibling tool is named as an alternative.

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 the safety profile is fully covered. The description adds genuine context beyond that: deterministic behavior, the formula version to cite (calc.compare_proposals@1), the presence of returned steps, and the instruction to surface warnings. It does not describe failure behavior (e.g., what happens with fewer than 2 proposals or an invalid schedule), so it adds value but not rich behavioral context.

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

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

Two tightly packed sentences: the operation and output basis come first, followed by the determinism/citation protocol. Both sentences earn their place, though the second is a dense clause chain that could be split for readability.

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?

No output schema exists, and the description partly compensates by naming the two result concepts and pointing to 'returned steps' and 'warnings', so an agent knows roughly what comes back. Combined with 100% parameter coverage and strong annotations, the definition is nearly complete; a brief note on output ordering or error conditions would close the remaining 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?

With 100% schema description coverage, the baseline is 3, and the description exceeds it by explaining what the `perspective` enum actually computes — effective occupancy cost for tenant vs. discounted net effective rent for landlord — plus the fact that all proposals are ranked on one shared discounted basis. That is semantics the schema does not supply. It says nothing additional about `discount_rate_annual`, so it is not a 5.

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 ('Rank') and resource ('2–20 lease proposals') and states the output basis (discounted $/SF/yr, effective occupancy cost vs. discounted net effective rent). The 2–20 cardinality implicitly separates it from single-proposal siblings like calc_net_effective_rent, but no sibling is named, so differentiation still requires 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?

'Use this instead of doing the math yourself' is a clear directive against the manual-math alternative and 'Deterministic' reinforces why. However, there is no explicit when-not guidance and no routing to/away from the many calc_* siblings (calc_net_effective_rent, calc_rent_schedule, calc_renew_vs_relocate), which is a real gap in a crowded calc namespace.

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, closed-world, non-destructive), so the description's job is to add operational context, which it does: deterministic output, a binding-constraint report, debt service and resulting metrics, returned steps, and warnings to surface. It does not address edge behavior such as what happens when no constraint is supplied.

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

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

Three sentences, front-loaded with the core purpose, then outputs, then the determinism/citation directive. Nothing is redundant, though the citation-string instruction adds mild density that 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 no output schema, the description must convey return content; it names the binding constraint, debt service, resulting metrics, steps, and warnings, which is enough for an agent to interpret results. Missing only explicit mention of the loan amount field and handling of a no-constraint call.

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

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

Schema coverage is 100% with units and examples for every property, so the baseline is 3. The description's phrase 'any combination of' hints that the constraint parameters are combinable, but it never states whether at least one constraint is required or how conflicts between them are resolved.

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 ('Size the maximum loan') and names the exact constraint set (max LTV, min DSCR, min debt yield) plus the required inputs (NOI, rate, amortization). It is unmistakably distinct from the other calc_* siblings such as calc_irr or calc_npv.

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?

'Deterministic: use this instead of doing the math yourself' is an explicit use directive against the main alternative (manual computation), and the citation/warning instruction tells the agent how to present results. It stops short of stating when-not to use it or which sibling to prefer for related sizing questions.

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 safety is covered. The description adds genuinely new behavioral context beyond that: the computation is deterministic, it returns intermediate steps, it can emit warnings, and results should be cited as calc.hotel_metrics@1 — all of which affect how an agent should present the output. It does not describe error behavior or input-validation failure modes.

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: the first front-loads the full output inventory, the second states the operating directive (deterministic, prefer over manual math, cite the formula, surface warnings). No filler, no repetition of schema content, and the most decision-relevant information leads.

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 13-parameter, read-only calculator with no output schema, the description sufficiently enumerates what comes back (the full metric ladder including NOI) so an agent knows what to expect. It omits any note on output shape or how the 'steps' and 'warnings' are structured, which is a minor gap given there is no output schema to fall back on.

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 13 parameters carries a detailed USALI-anchored description, so the schema does the heavy lifting. The description adds only one implicit parameter clarification ('NOI = EBITDA less replacement reserve', which maps to ffe_reserve_rate) and otherwise does not restate or extend parameter meaning; baseline 3 applies.

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 metrics produced (occupancy, ADR, RevPAR, TRevPAR, GOP, GOPPAR, EBITDA, NOI) and the resource domain (hotel operating metrics, USALI), which lets an agent distinguish it from the other calc_* siblings by subject matter. It stops short of explicitly contrasting itself with any named sibling, but the domain scope is unmistakable.

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 one clear usage directive — 'use this instead of doing the math yourself' — which tells the agent to prefer this tool over manual computation. It offers no guidance on when not to use it, what preconditions apply (e.g. data availability, period alignment), or how it relates to the many sibling calc_* tools beyond implicit domain separation.

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?

Goes well past the annotations by disclosing the solution method (1-point grid scan plus bisection on sign changes), a known correctness limit (two roots inside one grid step can be missed), the accepted rate window (-99.99% to 1000% per period), and error conditions for sign changes absent. That is the kind of caveat an agent needs to interpret results and warnings correctly.

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 output format are front-loaded and no sentence is filler, but the middle section is one long semicolon-chained clause that buries the error conditions and the missing-root caveat in dense prose. Slightly tighter sentence splitting would improve scanability.

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, the description still covers result format (decimal rates, annualized vs periodic), failure modes, and the multiplicity caveat, which is everything needed to call it and to report its output responsibly. Nothing material is missing for a two-parameter read-only calculation.

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 the schema already documents sign convention, the 1200-item cap, and the annualization purpose of periods_per_year. The description adds only the decimal output convention and the root-search range, so the baseline 3 is appropriate.

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

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

States a specific computation ('Periodic and annualized IRR of periodic cash flows') with the output convention spelled out ('as decimals (0.085 = 8.5%)'), which unambiguously separates it from the NPV/rent-schedule siblings in the calc_* family. An agent can identify the operation and result type 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?

Explicitly directs the agent to prefer this tool over computing IRR itself and specifies follow-on obligations (cite calc.irr@2, cite returned steps, surface warnings). It gives clear context but never contrasts with calc_npv or other siblings where an agent might mis-route.

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 goes beyond by promising warnings where judgment is needed, asserting determinism, and requiring citation of calc.lease_remeasurement_asc842@1 with returned steps. It does not describe failure conditions or input validation behavior, 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 action and outputs, and every clause carries content (triggers, outputs, warnings, citation duty). The single dense sentence chain is slightly run-on but 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 no output schema, the description usefully enumerates the return components (new liability, liability and ROU adjustments with gain, per-period amortization table split by operating/finance). It does not specify the exact response shape or units, but the schema's 100% coverage and detailed enum documentation compensate.

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 explains classification, payment_timing, discount_rate_updated, and the payment array semantics in detail. The description adds no parameter-level meaning beyond the trigger list already implicit in the event enum, so the baseline 3 applies.

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 precise verb and resource ('Remeasure a lessee's lease liability and right-of-use asset under ASC 842') and immediately enumerates the triggering events, distinguishing it from generic calculators like calc_npv or calc_rent_schedule. An agent can tell what it produces (new liability, adjustment, amortization table) 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?

Gives explicit when-to-use conditions (after a modification, lease-term reassessment, contingency resolution, or residual value guarantee change) and an exclusion embedded in the event enum note (index/rate change is not a remeasurement trigger by itself). It also directs the agent to use this rather than doing the math, but never names a specific sibling tool to prefer for the initial or non-remeasurement schedule.

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 a safe read-only, idempotent, closed-world operation, and the description adds substantial context beyond them: determinism, the optional after-tax mode, the year-by-year tables, the break-even residual output, and possible warnings. It also tells the agent to cite the formula version, which is genuine behavioral guidance.

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 comparison, then the determinism/citation instruction. The first sentence is long and parenthetical-heavy, but nearly every clause carries model detail that the schema does not restate in aggregate.

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

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

Even with no output schema, the description explains what comes back (year-by-year tables, break-even residual, steps, warnings) and how the two cases are constructed. For a complex nested four-parameter model with full schema coverage, an agent has what it 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?

Schema coverage is 100%, so parameter-level meaning is already covered. The description still adds model-level semantics by mapping which inputs belong to which cash-flow stream (rent, free rent, tenant expenses, move-in costs vs. equity, debt service, reserves, sale) and clarifying the after-tax toggle, going beyond the field 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?

States a specific verb and comparison (lease vs. own over a fixed horizon) and enumerates the cash-flow components of each case, including the horizon sale via stated value or exit cap rate. An agent can distinguish this from generic calculators such as calc_npv or calc_renew_vs_relocate 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?

Explicitly directs the agent to use this rather than doing the math manually and to cite formula calc.lease_vs_own@2 and surface warnings. It does not, however, state exclusions against close siblings like calc_renew_vs_relocate or calc_npv, so the when-not guidance is partial.

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 read-only/idempotent/non-destructive profile, and the description adds genuinely new traits: the computation is deterministic, it returns intermediate steps the caller is expected to cite, and it may emit warnings that must be surfaced. It does not say what triggers warnings or how invalid inputs (e.g. abated months beyond the term) are handled.

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

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

Two sentences, front-loaded with what is computed and in what units, then the usage directive and citation requirement. No filler or restatement of the title.

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 a nested-but-fully-documented input schema and no output schema, the description carries the return-value burden and does name the key returns (the three rent figures, steps, warnings), but never sketches the response structure beyond that. For a deterministic calculator this is nearly sufficient, though a note on partial-failure or warning cases would close the 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 coverage is 100%, so the baseline is 3; the description still adds the grouping of ti_allowance_psf, leasing_commissions, and other_concessions as landlord concessions applied against rent, and frames discount_rate_annual as selecting the discounted versus straight-line output. The remaining parameters (schedule internals, include_monthly, round_rate_to_cents) are left entirely to 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?

States a specific verb (compute) and resource (net effective rent) with three named variants and explicit output units ($/SF/yr), plus the concession categories netted out. The mention of free rent, TI, commissions, and discounting clearly separates it from calc_rent_schedule, which only builds the base-rent stream.

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?

"Deterministic: use this instead of doing the math yourself" is a clear call-to-action with a citation obligation (calc.net_effective_rent@1) and an instruction to surface warnings. It stops short of stating exclusions, e.g. when to use calc_rent_schedule first or when calc_compare_proposals supersedes this for multi-scenario work.

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?

Beyond the read-only, idempotent, non-destructive annotations, it discloses determinism, a versioned formula identifier, returned calculation steps, and possible warnings. These details establish useful expectations for reproducibility and result reporting.

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 dense but readable sentences front-load the calculation and timing convention, then provide concise invocation and reporting guidance. There is no filler or unnecessary background.

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

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

For a simple two-parameter deterministic calculation, the description, fully documented schema, and safety annotations collectively cover invocation, timing, reproducibility, and reporting. The absence of detailed warning conditions or explicit sibling exclusions is a minor gap rather than an obstacle to correct use.

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

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

The schema already fully documents both parameters, including rate-period matching and cash-flow signs. The description adds the important computational convention that the t = 0 cash flow is not discounted, although its decimal-rate and periodicity wording otherwise repeats 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 precisely identifies the computation as NPV for periodic cash flows at a supplied per-period discount rate and clarifies that the t = 0 flow is not discounted. It does not explicitly contrast the tool with calc_irr or other financial siblings, so sibling selection still relies partly on tool names.

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

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

It explicitly directs the agent to use the deterministic tool rather than perform the calculation manually and explains how to report the result using calc.npv@1, returned steps, and warnings. It lacks when-not guidance, such as where to route irregularly timed flows or requests to solve for a rate of return.

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 non-destructive, so the safety profile is covered. The description adds behavior beyond that: determinism, the requirement to cite formula calc.percentage_rent@1 and returned steps, and the instruction to surface warnings — real operational context about what the tool returns and how to report 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?

Two sentences, front-loaded with the core definition followed by the usage/determinism directive. Every clause carries information; nothing is redundant with the title or annotations.

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?

There is no output schema, but the description names what comes back (returned steps and warnings) and mandates citing the formula version, which covers the agent's reporting needs. A little more on output shape or rounding conventions would make it fully complete for a seven-parameter financial calculation.

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

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

Schema coverage is 100%, so the baseline is 3. The description earns more by explaining how the parameters combine — exclusions reduce gross sales before the breakpoint is applied, the breakpoint may be natural or fixed, and proration applies to partial years — which is more than a restatement of the individual field 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?

States a specific verb+resource (percentage/overage rent for a lease year) and enumerates the computation chain: net sales after exclusions, breakpoint comparison, proration, less amounts paid. That is precise enough to separate it from siblings such as calc_rent_schedule or calc_net_effective_rent 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?

"Use this instead of doing the math yourself" gives clear positive guidance for the deterministic case, and the partial-year proration clause implies the scope. It does not name a sibling alternative or state when this tool would be the wrong choice (e.g. when a full rent schedule is needed), so it stops short of full routing 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, non-destructive, closed-world behavior, so the safety profile is covered. The description adds meaningful context beyond that: it is deterministic, the formula reference calc.prepayment_and_defeasance@1 is citeable, returned steps should be used, and warnings should be surfaced. It does not describe the response shape in detail, but the annotation bar is already met.

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 dense paragraph with no filler, and the core capability is front-loaded before the mode list and the determinism directive. The nested clauses make it slightly heavy to scan, but every sentence carries substantive 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?

For a complex tool with a nested oneOf prepayment parameter and no output schema, the description covers the computational models, the determinism expectation, the citation requirement, and warning surfacing. It could say more about the returned fields (steps, warnings, cost share), but overall it gives an agent enough to call it responsibly.

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 itself fully documents the parameters, including the oneOf branches, defaults, and conventions. The description adds only a high-level summary of the four provision modes (minimum floor, discounting convention, stated defeasance costs) that the schema already spells out, so baseline 3 applies.

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 outputs (premium, total payoff, cost as a share of balance) and the exact loan and provision types covered: yield maintenance, step-down schedule, flat percentage, and defeasance. That level of specificity clearly separates it from siblings like calc_npv or calc_debt_sizing 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?

It gives a clear directive: 'Deterministic: use this instead of doing the math yourself,' plus instructions to cite the formula ID and surface warnings. It stops short of naming alternatives or exclusions (e.g., when to prefer calc_npv or calc_debt_sizing), so it is clear context but not full when/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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context: the computation is deterministic, it returns warnings that must be surfaced, and outputs include a citation token calc.renew_vs_relocate@2 plus intermediate steps. It does not discuss failure modes or validation errors, which keeps 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?

The purpose and output set are front-loaded in the first sentence, with the operational instructions (cite formula, surface warnings) in a short second sentence. The long parenthetical cost enumeration is informative but dense; overall 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?

For a nested five-parameter comparison tool with no output schema, the description compensates by naming each returned figure and flagging that warnings and steps are returned. The main gap is that it does not clarify that both cases run over horizon_months or how allows offset costs is handled in the results, though the schema carries that.

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 every parameter including nested schedule and escalation variants is already documented in the schema; baseline 3 applies. The description's parenthetical cost list (TI net of allowance, moving, downtime, double rent, termination, disruption) lightly mirrors the relocate parameters and confirms the offset behavior for allowances, but adds no syntax or format 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?

"Compare renewing in place with moving over one horizon" gives a specific verb and decision resource, and enumerates the outputs (NPV, discounted effective rent, break-even starting rent, year-by-year cash flows). It is clearly distinguishable from siblings like calc_net_effective_rent, calc_rent_schedule, and calc_lease_vs_own, which compute single-case metrics rather than a two-scenario comparison.

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?

"Deterministic: use this instead of doing the math yourself" gives an explicit directive and distinguishes it from manual calculation. However, it does not name the sibling alternatives (e.g. calc_rent_schedule for one-case schedules, calc_npv for generic discounting) or state when this tool is not appropriate, so routing is good but not exhaustive.

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, closed-world), so the description's job is to add behavior beyond that, and it does: it lists the return payload (rent steps, totals, expiration date, calculation trace), states the tool is deterministic, and instructs the agent to surface warnings. It does not mention rounding behavior or the potentially long monthly table, but those are documented in the schema.

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

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

Three sentences, each doing distinct work: inputs, outputs, then determinism/citation guidance. The most operationally important instruction (don't do the math yourself; cite the formula) is placed last but is short and unambiguous, and there is 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 no output schema, the description correctly compensates by summarizing the return payload and noting warnings and a calculation trace. Combined with a fully documented 8-parameter schema and safety annotations, an agent has enough to call it correctly; only minor gaps (rounding defaults, monthly-table size implications) remain and those are covered in the 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%, so every parameter including the escalation oneOf variants, abated_months indexing, and rounding flag is already fully documented in the schema. The description only restates the parameter names in prose without adding constraints, units, or edge cases beyond what the schema provides, which is the baseline for high coverage.

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 ('Build a base-rent schedule') and enumerates the exact inputs that drive it (commencement date, term, area, starting $/SF, escalations, abated months). It is clearly a rent-schedule generator, but it never names the closest siblings (calc_net_effective_rent, calc_lease_remeasurement_asc842, calc_percentage_rent) to draw 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?

'Deterministic: use this instead of doing the math yourself' gives an explicit directive on when to reach for the tool, which is meaningful guidance for an agent that might otherwise compute rent in-head. It stops short of exclusions or routing rules (e.g. when to use calc_net_effective_rent instead), so it is clear context without alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond that: the tool is deterministic, it returns intermediate steps and warnings, and outputs should be cited with formula id calc.walt@1 — useful attribution behavior an agent would not otherwise know. It does not describe response shape or how warnings affect the result, keeping it below 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 front-loaded sentences with no filler; the definition of the metric comes first and the operational instruction second. The second sentence is dense with citation and warning clauses, but every clause carries actionable 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?

For a read-only calculator with no output schema and fully documented parameters, the description covers purpose, determinism, and post-call obligations (cite the formula, surface warnings). Minor gaps remain around edge cases such as expired leases or zero-weight portfolios, but an agent has enough to invoke 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 100% and the schema already documents as_of, weight_by, and the per-lease fields including the conditional requirements (area_sf when weight_by=area, annual_rent when weight_by=rent). The description restates the weighting choice without adding format, default behavior, or edge-case rules, so the baseline 3 applies.

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 precise computed quantity with its unit ("weighted average remaining lease term in years"), the two weighting options, and the as-of basis, so an agent can immediately tell this apart from the other calc_* tools such as calc_rent_schedule or calc_net_effective_rent. It stops short of naming any sibling explicitly, which keeps it from 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?

"use this instead of doing the math yourself" gives an explicit selection rule: any WALT request should route here rather than to ad-hoc arithmetic. There are no when-not conditions or exclusion cases (e.g. single-lease portfolios, all leases already expired), so the guidance is clear but not exhaustive.

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, closed-world), so the description's job is lighter. It adds real value by disclosing the return shape { valid, issues } in the absence of an output schema, plus the pre-store gate. It doesn't say whether validation is strict or advisory, or what issues contains, so not 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 sentences, no filler: the first defines what is checked, the second gives the return shape and the call-site guidance. Front-loaded and appropriately sized for a single-parameter tool.

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 validator with no output schema, the description covers what is checked, when to call it, and the top-level return keys. It leaves the contents of `issues` unspecified, which is a minor gap given there is no output schema to fall back on.

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

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

Schema coverage is 100%, so 3 is the baseline, but the schema's fact object is free-form (additionalProperties: {}), meaning the description's enumeration of expected fields is what actually tells the agent what to put in. It adds specifics like the dotted predicate format and citation-bearing provenance beyond the schema's terse 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?

States a specific verb and resource ("Check that a fact conforms to the FactLot model") and enumerates the model's parts: subject ID, dotted predicate, as_of date, provenance with citations, optional AI-use rights. No sibling tool does validation, so no differentiation is needed and none is missing.

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 an explicit trigger: "Call before storing or sharing extracted facts." That is a clear when-to-use. It does not name an alternative or state when not to bother (e.g. already-validated facts), 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is free. The description adds value beyond that by clarifying the return payload is the full document text (as opposed to search snippets) and that ids must be sourced from search. It does not describe what happens for an unknown or stale id, which is the main remaining 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?

One sentence, front-loaded with the verb and resource, with the id-provenance constraint folded in without filler. Nothing to cut.

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 no output schema, the description covers purpose, input provenance, and the nature of the return value. Missing only edge-case behavior (unknown id, very large documents or truncation), which is minor at this complexity.

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

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

Schema coverage is 100% and the schema already gives the id format example (tool:calc_cam_reconciliation). The description still adds meaning by tying id provenance to search, which discourages fabricated identifiers — a real constraint rather than a restatement.

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 (fetch), a specific resource (full text of a FactLot knowledge document), and the keying mechanism (by id). The phrase 'id returned from search' cleanly separates it from the sibling search tool that produces those ids.

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 establishes the prerequisite workflow: ids come from search, so an agent knows to call search first rather than inventing an id. There is no explicit statement of when not to use it, but with a single clear retrieval purpose and no competing sibling (search returns matches, this returns full text), the guidance is sufficient.

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 carry readOnly, idempotent, closed-world, and non-destructive hints, so the safety profile is covered. The description adds the hashing algorithm (SHA-256) and the content-addressed property, which explains why identical content yields identical IDs, but it omits what happens when both inputs are empty (required set is empty) and what the return value looks like.

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 that identifies the tool, its mechanism, and its domain with 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?

For a simple deterministic ID tool with rich annotations and full schema coverage this is close to sufficient, but with no output schema the description should say the result is a hex digest string, and it should clarify behavior when neither optional input is supplied.

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 both parameters are documented with encoding and preference guidance, so baseline 3 applies. The description itself adds no parameter-level meaning beyond naming SHA-256 as the hashing scheme.

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 resource (FactLot document ID), the derivation method (content-addressed, SHA-256), and the input domain (lease, amendment, estoppel), which separates it from sibling identifiers like id_entity, id_parcel, and id_space. It never states the operative verb explicitly ('compute'/'derive'), leaving the action implied rather than declared.

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?

Listing document types (lease, amendment, estoppel) hints at the domain but gives no when-to-use rule and no comparison against alternatives; nothing tells the agent why it would pick this over id_parse or id_entity. It also offers no guidance on the text-vs-bytes choice beyond what the schema already says.

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

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

The annotations already declare this operation as read-only, idempotent, non-destructive, and closed-world, so the key safety traits are covered. The definition adds one genuinely useful behavior beyond the annotations: the output is deterministic, so the same inputs always yield the same ID. It says nothing about failure modes such as an unknown jurisdiction, a malformed file number, or an entity with no LEI.

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 a single front-loaded sentence that leads with the output (the deterministic ID) and then the input source. Every clause carries information, with no filler or redundant restatement.

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

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

The tool is simple, with two required string parameters and rich annotations, so the definition is close to sufficient. However, it never says what the returned ID looks like (format, length, or prefix), which matters for a tool whose entire output is that identifier, and it has no output schema to cover that 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 coverage is 100%, so both parameters and the "lei" pseudo-jurisdiction are already documented in the input schema. The definition restates the two input modes (registry jurisdiction plus file number, or LEI), which reinforces rather than extends the schema, so it lands at the 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?

The definition names a specific action (compute a deterministic FactLot ID) and a specific resource (a legal entity — LLC, LP, corporation, trust), which cleanly separates it from the other id_* siblings such as id_parcel, id_document, and id_space. It stops short of explicitly contrasting those siblings, so sibling differentiation is implied by the resource type rather than stated.

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 definition implicitly tells the agent to call it when it needs a stable identifier for a legal entity and even sketches two input paths: registry jurisdiction plus file number, or LEI. It does not say when to prefer one path over the other, what to do if the entity type is ambiguous, or what replaces this tool for individuals or non-registered entities.

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 value by stating the output is deterministic and computed offline. However, with no output schema, it never says what the returned ID actually looks like (format, length, prefix), which is the main behavioral unknown for a key-generating 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?

Three short sentences, front-loaded with the derivation formula, then the determinism guarantee, then the intended use. No filler or repetition.

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

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

For a simple, side-effect-free derivation tool with full schema coverage and rich annotations, the definition covers inputs, determinism and purpose. The only real omission is a description of the returned identifier, which matters because no output schema exists.

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 parameter already documents its format and example, so the schema carries the parameter burden. The description only restates the three inputs in prose and adds no normalization or edge-case semantics beyond the schema's own note that APN formatting is normalized.

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 output (a deterministic FactLot parcel ID) and the exact inputs that derive it (state FIPS, county FIPS, APN), which cleanly separates it from id_document, id_entity, id_space and id_parse. It stops short of explicitly naming those siblings, so an agent must infer the boundary from the resource word 'parcel'.

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?

'Use it as the join key across systems' implies the intended role but gives no when-to-use/when-not conditions and no routing against the other id_* tools. The usage context is inferable rather than 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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description. The description does add that it returns kind, components, and short ID, but is silent on what happens when a URN fails validation — an error versus a negative result is ambiguous, which matters for a validation 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?

One short sentence that front-loads the action and immediately states the return payload; no filler or redundant restatement of the title.

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?

There is no output schema, and the description compensates by naming the three returned fields, which is adequate for a single-argument parser. The remaining gap is failure behavior and the shape of 'components', which an agent would want to know before relying on the result.

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 including a concrete URN example, so the schema carries the semantics. The description adds nothing about URN structure or what 'components' means beyond the schema's example, which is a baseline 3.

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 pairs a specific verb ('Validate') with a specific resource ('FactLot URN') and names the payload it returns (kind, components, short ID). It does not, however, distinguish this from nearby siblings such as id_parcel, id_entity, id_space, or fact_validate, so an agent must infer which identifier family this handles.

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 phrase 'FactLot URN' — an agent can guess this is the parser for FactLot identifiers, but there is no explicit when-to-use, no when-not-to-use, and no pointer to id_parcel/id_entity or fact_validate as alternatives.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds one genuine behavioral fact beyond annotations: suite designators are normalized. It says nothing about what happens when the suite does not exist in the building or whether an ID is created on the fly.

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 short sentences, front-loaded with the resource and scope, with the normalization behavior second. No padding; only the missing verb keeps it from being a model of tightness.

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

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

For a simple two-parameter lookup, the annotations and fully documented schema carry most of the load, but there is no output schema and the description does not say what is returned (bare ID string versus an object) or how a non-matching suite is reported. Those are the gaps an agent would want closed before calling.

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

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

Schema coverage is 100% and the suite property already documents normalization with concrete examples ('Suite 400', 'STE 400', '#400', '3rd Floor'), so the description's normalization note largely duplicates the schema. It adds no format or constraint detail beyond what the properties provide, so the baseline 3 applies.

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 resource (a FactLot ID for a suite/unit inside a building) and scopes it by requiring the building URN, which separates it from id_parcel and id_document. However, it is a noun phrase with no verb ('returns'/'resolves'), so the action is only implied, and it never explicitly contrasts itself with id_parse or id_entity.

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

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

It states the prerequisite input (the building's FactLot URN) but gives no when-to-use versus when-not guidance and names no alternative among the id_* siblings. An agent must infer that id_parse is the free-text alternative and id_entity/id_parcel cover other granularities.

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, closed-world and non-destructive, so the safety profile is covered; the description adds genuine value by promising returned statute citations, a verification status, and the rule identifier to cite. The one gap is the 'conservative file-by date' — the size of that buffer is never quantified, so the agent cannot explain the margin.

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 tight sentences with the rule core front-loaded, then output behavior, then the citation requirement. Slight redundancy in restating 'Verification status: verified' as both a promise and a value, but no padding otherwise.

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 only two parameters, no output schema, and full annotation coverage, the description supplies what is needed: the computation, the fallback, the return content, and the citation ID. The unquantified conservative buffer is the only thing an agent would still have to guess at.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining how notice_delivered_date drives the computation (30 days after delivery) and why omitting it falls back to May 15. That connective meaning is not present in the schema itself.

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 subject and precise computation: the Texas property tax protest filing deadline, defined as the later of May 15 or 30 days after notice delivery, rolled past weekends and Texas holidays. It is instantly distinguishable from the calc_* financial siblings and the id_/search utilities 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 a clear operational cue by telling the agent to omit notice_delivered_date when unknown, in which case May 15 is the only basis. It lacks explicit when-not-to-use framing or naming of an alternative tool, but the applicable context is unambiguous.

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 a closed-world profile, so the safety story is covered. The description adds content scope by naming the five model components returned, but says nothing about whether the result is one schema or five, static versus versioned, or how large it is.

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 sentence with no filler, front-loaded with the action and immediately naming the returned components. Nothing could be removed without losing 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?

For a no-parameter, read-only lookup with no output schema, the description conveys both the purpose and the payload contents, which is close to sufficient. The only real gap is the shape of the response (single bundled document versus named per-entity schemas), which an agent would need to know to consume it.

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 there is nothing for the description to disambiguate; baseline applies. The description correctly implies the call is parameterless and fully determined by the tool itself.

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 ('Return') and a specific resource (the FactLot data model rendered as JSON Schema), and enumerates the model components (Fact, Provenance, SourceRef, Rights, Relationship) so the agent knows exactly what comes back. It is distinguishable from siblings like fact_validate or fetch by resource, though it never explicitly contrasts itself with 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?

No explicit when-to-use or when-not-to-use guidance is given; the usage is only implied by the purpose (call it when you need the FactLot structure, presumably before building or validating facts). No mention of a relationship to fact_validate or other siblings that might otherwise be confused with retrieving the schema.

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

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

The annotations already establish read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful behavioral detail beyond annotations by stating the return shape (matching document ids, titles, URLs) and the recommended next action, though it does not mention ranking, pagination, or result 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 description is two compact sentences, front-loaded with the core purpose and followed by return values and the fetch handoff. Every clause 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?

For a one-parameter, read-only search tool with annotations and no output schema, the description covers scope, result shape, and follow-up behavior sufficiently. Missing pagination detail is minor at this complexity level.

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?

There is one required query parameter with 100% schema description coverage and examples, so the schema already carries most parameter meaning. The description adds domain scope for what can be searched but does not explain query syntax or limits 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 verb and resource: searching FactLot's knowledge base. It enumerates the covered domains (tools, inputs, CRE predicates, ID and fact specifications) and distinguishes the tool from fetch by positioning fetch as the full-text follow-up.

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 a clear usage path by saying to call fetch for full text, which implies search is the discovery step. It does not explicitly compare against schema_get or the id_* lookup tools, so some sibling-selection guidance is left implicit.

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