cmbs.news: CMBS loan data

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered elsewhere. The description adds topical scope (license, plan limits, changelog links) but says nothing about response shape, freshness guarantees, or whether any of the values are authoritative for downstream queries.

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 compact fragment with no filler, but it is a bare noun list rather than a sentence, so the agent has to reconstruct the subject ('this tool returns...'). The most important fact — that this is the dataset orientation entry point — is not front-loaded as a claim.

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 zero-parameter read-only tool with no output schema, the description carries the burden of explaining what comes back, and it does so only by topic labels rather than structure. It is adequate to know roughly what to expect but not enough to know exactly what fields or how to use them.

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 no parameter semantics to document and the baseline of 4 applies. The description correctly implies a call-anytime, no-argument tool.

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 enumerates concrete contents (coverage, as-of dates, counts, headline index, plan limits, license, docs/OpenAPI/changelog links), which makes it clear this is dataset metadata rather than a data query. It never uses an explicit verb like 'returns', and sibling differentiation is only implicit via the fact that all siblings are loan/trust queries.

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 at all: nothing says to call this first before querying loans, nor any exclusion or alternative. An agent must infer that this is a discovery/orientation tool purely from the listed contents.

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 and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: it returns aggregated medians alongside per-square-foot figures, which tells the agent this is a comparative analytics call rather than a raw record listing. It does not disclose ordering or error behavior, 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?

One sentence, front-loaded with the resource and followed by the returned metrics and filters in a logical order. It is dense but every clause carries information; the only cost is that a single long sentence is harder to scan than two shorter ones.

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 does the work of enumerating return fields (revenue, opex, NOI, expense ratio, occupancy, DSCR, valuations, medians), which is the right call for a read-only aggregation tool. All seven parameters are schema-documented, so the remaining gap is minor: no note on result ordering or what an empty comp set looks like.

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 every filter (cbsa, type, state, min/max_sqft, built_after, limit) is already documented in structured form. The description only restates the filter dimensions as a category list ('type, metro, state, size and year built') without adding syntax, defaults, or interaction rules, 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 a specific resource ('Single-property CMBS loans as comparables') and enumerates the metrics returned (NOI, DSCR, occupancy, valuations), so an agent can tell it apart from search_loans or tenant_exposure. It stops short of explicitly naming which sibling to use instead, so it is clear but not fully differentiated.

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?

Framing the data 'as comparables' implies the use case is benchmarking a property against similar loans, and the filter list hints at how to narrow a comp set. However, there is no explicit when-to-use versus search_loans/get_loan, and no stated prerequisites such as needing a metro or type to get meaningful medians.

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, closed-world behavior, so the description's burden is lighter. It adds genuinely non-obvious context the annotations cannot supply: the balance-weighted methodology, the 'every public trust' coverage universe, and the CC BY 4.0 open-data licensing. It does not describe output size, pagination, or update cadence, 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?

A single front-loaded sentence that names the source and index first, then stacks the covered metrics and breakdowns. It is dense and runs long, but nearly every clause contributes a distinct data dimension. The licensing clause is useful attribution information rather than 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 input parameters and no output schema, the description carries the full burden of telling the agent what comes back, and it does so by enumerating the metric families and cross-tabs. What is missing is the response shape itself: whether these are time series or single-period snapshots, and how the by-type/by-vintage breakdowns are keyed.

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 are no parameter semantics to disambiguate and the baseline of 4 applies. The description correctly implies the result set is fixed rather than filterable, 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 description names a concrete artifact and enumerates its contents: monthly delinquency, special-servicing and matured-unpaid rates, balance-weighted across every public trust, plus breakdowns by property type, vintage, and state. That is far more specific than the title alone. It does not explicitly contrast itself with loan-level siblings like get_loan or search_loans, but the aggregate-index framing is distinct enough that an agent can place it.

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: the market-wide, balance-weighted framing signals this is the tool for aggregate distress trends rather than a single loan or trust lookup. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., 'use get_loan for individual loan status'). An agent has to infer the 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 the operation read-only, idempotent, closed-world, and non-destructive. The description adds useful behavioral context by identifying the data source ('from the latest trustee report') and listing the certificate attributes returned, though it does not describe not-found 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 definition is a single, front-loaded sentence with no redundant wording. It presents the lookup key, resource type, and returned fields efficiently.

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 one-parameter lookup with no output schema, the description gives enough context about the data source and returned fields for an agent to call it correctly. It falls short only on edge-case behavior such as missing or invalid CUSIPs.

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 single parameter is fully documented in the input schema. The description adds only that the CUSIP identifies a CMBS certificate class, which is modest value beyond the schema.

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

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

The description states a specific verb and resource: 'Look up a CMBS certificate class by CUSIP.' It also enumerates the key fields returned, making the tool's scope clear against siblings such as get_trust and search_loans.

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

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

The description implies when to use the tool: when you have a CUSIP and need certificate-level CMBS data from the latest trustee report. It does not explicitly name alternatives or state when not to use it, leaving routing between siblings largely 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 safety (readOnly, idempotent, closed-world), and the description adds real behavior on top: conditional disclosure rules ('special servicer is named only when one trust holds the whole loan and its report names one') and entitlement gating (Pro/Team keys unlock extra fields). It does not say what happens if the slug is unknown or whether null fields are omitted.

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 returned payload and followed by the tier-gated additions. Dense but every clause names a distinct data element; only slight cost is that the field list reads as a run-on with no grouping.

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, so the description must carry the return contract, and it does so exhaustively including conditional fields and tier-based availability. For a single-parameter read tool this is as complete as an agent needs to decide and 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 coverage is 100% and the slug parameter is already documented as 'the last part of its cmbs.news URL, from search_loans', so the description adds no parameter meaning. Baseline 3 applies since the schema carries the param semantics fully.

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 enumerates exactly what a single-loan lookup returns: terms, status, coverage, occupancy, three largest tenants, watch flags, trust holdings, trustee-report facts. That enumeration plus the 'One loan' scope cleanly separates it from search_loans (discovery), get_loan_history, get_loan_parties, and get_trust.

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: the promise that 'A Pro or Team key adds the 12-month history' hints this is the aggregate view rather than the history endpoint, but the description never states when to call this vs get_loan_history or get_loan_parties, nor any prerequisite such as obtaining the slug from search_loans.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the description correctly spends its words elsewhere: plan-tier gating, the behavior without a key, and the earliest data horizon ('late 2016 at the earliest'). The phrase 'it says how to get it' is a bit vague about exactly what is returned, which keeps this 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?

Two sentences, front-loaded with the plan gate and scope, and the field enumeration is dense but earns its place by describing the payload in the absence of an output schema. The final clause about the loan page is slightly compressed but still readable.

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 carries the return-value burden and does so by listing the report fields, the historical depth, and the auth prerequisite. Nothing an agent needs in order to call it correctly or anticipate failure appears to be 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?

There is one required parameter with full schema coverage, including a description that ties the slug to the cmbs.news URL and points at search_loans for obtaining it. The prose adds nothing beyond that, so the baseline of 3 is appropriate.

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

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

The description names a concrete verb and resource ('every monthly report for one loan back to its first filing') and enumerates the returned fields (balance, payment status, special servicing, workout strategy, modification, coverage, occupancy). It also distinguishes itself from the sibling loan view by noting 'the loan page shows the last six months'.

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 discloses the access condition ('Pro and Team') and the fallback when no key is supplied, and it implies when to prefer it over the recent-only loan page. It stops short of naming get_loan directly as the alternative, so the routing is implied rather than explicit.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real value beyond them: it discloses provenance (Annex A-1, 10-D filings), that each party is returned with a link to its filing, and the licensing/paywall behavior when no API key is present ('says how many are on file and how to get them').

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, with the resource definition front-loaded and the no-key fallback stated last. Every clause carries information an agent would otherwise have to guess.

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, this covers what the agent needs: what entities come back, where they come from, that results include filing links, and what happens without credentials. Only the absence of explicit sibling routing keeps it short of complete.

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

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

Schema description coverage is 100% and the single slug parameter is already documented as the trailing segment of a cmbs.news URL sourced from search_loans. The description only reinforces the per-loan scope, adding little semantic detail beyond the schema — baseline 3 is appropriate.

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

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

The description names a specific resource set — guarantors, named parties, and contacts for a single loan — and anchors it to concrete source documents (prospectus Annex A-1, the trust's 10-D). That distinguishes it from get_loan and get_trust, though the phrasing is nominal rather than a clear verb+resource statement and the leading 'Pro and Team:' tier tag is unexplained.

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: the 'for one loan' scoping and the mention of 'search_loans' in the schema indicate this is a per-loan follow-up call. The description never states when to prefer this over get_loan or get_trust, nor any prerequisite beyond having the slug.

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, and non-destructive, so the safety profile is covered; the description adds real substance with no output schema present by specifying the payload: balance and distress, named parties, every certificate class with CUSIP/coupon/losses/credit support, and liquidated loans with severity. It stops short of behavior on edge cases, such as what happens when a name fragment matches multiple trusts or when nothing matches.

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 dense sentence, front-loaded with the resource and the lookup key, followed by the payload inventory in a logical order. The trailing list is long but every item earns its place by telling the agent what fields come back; only the missing leading verb costs it a point.

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 required string parameter fully documented and no output schema, the description's main job is to convey what a call returns, and it does so thoroughly — parties, certificate classes, losses, credit support, liquidated loans. Combined with annotations that carry the read-only safety profile, an agent has everything needed to decide to call it and interpret 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?

Schema coverage is 100% and the single parameter already documents both slug ('benchmark-2018-b8') and fragment ('BANK 2019-BNK16') forms with examples, so the description's 'by slug or name fragment' is largely redundant. The enumerated return contents are valuable but they describe output, not the parameter, 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 resource ('A trust (deal)'), the lookup key ('by slug or name fragment'), and enumerates the record's contents, which lets an agent distinguish it from get_loan or get_loan_parties. What it lacks is an explicit verb — it reads as a noun phrase describing returned data rather than 'Retrieves a single CMBS trust' — and it never names list_trusts as the browse alternative.

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 mention of siblings such as list_trusts (browse all trusts) or get_loan (loan-level detail). The only usage-adjacent information is the accepted key format, which is already covered by the schema, leaving the agent to infer routing from the tool name alone.

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 read-only, idempotent, closed-world behavior, so the safety profile is covered. The description adds genuinely new behavior not in the schema: the default ordering ('most distressed first', with the metric defined as share of balance delinquent or with the special servicer). It omits pagination behavior and the default limit value, which would round it out.

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: resource first, then ordering rationale, then the optional filter. Nothing is redundant or padded.

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 two-parameter, read-only list tool with annotations and fully described schema, the description covers scope, ordering, and filtering. The only gap is the lack of any hint about result set size or pagination, which matters mildly since there is no 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 coverage is 100%, so both parameters are already documented with examples and quota limits. The description only restates that filtering by name is optional, adding no syntax or format detail beyond the schema — 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 precisely ('Public CMBS trusts') and its scope, implying a list operation that pairs with the tool name. It is distinguishable from get_trust (single trust) and search_loans (loans) by resource, though it never explicitly contrasts 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?

It states the optional name filter, which implies when the 'q' parameter is relevant, but gives no explicit cue about when to call this vs. get_trust or distress_index. Usage is inferred rather than directed.

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, so safety is covered. The description adds the default ordering ('largest first by default') and what comes back (loans, total count, balance), which the annotations cannot convey; paging and rate limits are left to 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 short sentences, zero filler, with the scope stated first and the return shape last. Every clause carries information an agent needs.

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 23-filter read-only search with no output schema, the description covers scope, filter combination, default ordering, and payload contents. It could add a note on paging limits at the description level, but the schema already documents those.

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 the AND-combination semantics of the 23 filters and the default sort order, neither of which the schema states. That is genuine additive meaning beyond the parameter 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 resource ('Find loans in public CMBS trusts'), which cleanly separates it from the singular get_loan and from list_trusts. It does not explicitly name or route against a sibling, so it falls just 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?

'All filters are optional and combine' tells the agent filters are ANDed and none are required, which is real usage guidance. There is no when-not-to-use guidance and no pointer to alternatives like get_loan or tenant_exposure for narrower lookups.

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, idempotence and closed-world scope are settled and the description needn't restate them. The description does add domain behavior beyond annotations: the top-three-tenant ranking criterion, the fallback ranking mode when no tenant is supplied, and the extra lease-end field for the largest tenant. It does not disclose ordering, pagination, or what a no-match result 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?

Two sentences with no filler, and the primary mode is stated first, which is good front-loading. But the second clause of sentence one ("coverage and lease end where it is the largest tenant") is compressed into near-unreadability, so the density costs comprehension rather than saving it.

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?

Only two optional parameters and no output schema, so the bar is modest, and the description does enumerate the returned fields. What is missing is how results are ordered and capped in practice, and the two operational modes are only half-explained, leaving an agent unsure what a tenant-less call actually produces.

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

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

Schema coverage is 100%, so baseline is 3; the description earns an extra point because it explains the consequence of omitting the optional 'tenant' parameter, switching the tool into a ranked top-exposure listing mode, which the schema alone does not convey. It also clarifies that 'limit' bounds "tenants or loans listed" depending on mode, disambiguating an otherwise ambiguous unit.

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 concrete resource (loans where a tenant ranks in the top three at a property) and the fields returned (balance, status, coverage, lease end), which is more specific than the title. However, it never uses a clear verb like "list" or "return" in the main clause, and the phrasing "with balance, status, coverage and lease end where it is the largest tenant" is grammatically tangled, forcing the agent to parse what is returned under which mode.

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 statement and no named alternative among siblings such as search_loans, get_loan_parties, or comps, even though those clearly overlap with tenant/loan exposure lookups. The only routing signal is implicit: supplying 'tenant' narrows to that tenant, omitting it lists top-exposure tenants, which the agent must infer.

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 behavior, so the safety profile is covered. The description adds useful context about ordering ('largest first') and tiered access ('A Pro or Team key adds the comment excerpts'), but does not mention rate limits, authentication requirements beyond the key, or pagination details.

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

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

The description is two sentences, front-loaded with the resource and content list, followed by tier information. It is efficient and wastes little space, though the content list is dense and could arguably be structured more readably.

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 read-only retrieval tool with two optional parameters, rich annotations, and no output schema, the description covers what the tool returns, how results are ordered, and tiered access. The main gap is not stating what happens when the section parameter is omitted (presumably all sections), but otherwise it provides enough 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 100%, so the schema already documents both parameters thoroughly. The description clarifies the meaning of each section (e.g., 'transfers' = loans transferred to special servicing) and adds ordering information ('largest first'), but does not explain the default behavior when section is omitted.

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 (the latest monthly Wire) and enumerates the exact content categories (transfers, returns, delinquent, etc.), making clear what the tool returns. However, it does not explicitly differentiate this tool from any sibling, 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 explicit guidance on when to use this tool versus alternatives like distress_index or search_loans. The description only states what the tool returns and includes a note about Pro/Team keys, leaving the agent to infer usage.

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