Average Rent

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds non-obvious behavior beyond that: the call is free with respect to the data allowance, and the reset date is UTC-based. It does not describe pagination or response shape, but neither is relevant for a zero-parameter read.

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 resource list, then the one actionable conditional, then the cost caveat. Every sentence carries distinct information and nothing is repeated from the schema 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?

With no output schema, the description carries the burden of telling the agent what comes back, and it does so by naming the five data categories including the actionable commercial_use_allowed flag. It does not describe value formats or units for allowance/usage, which is a minor gap for a simple read tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool applies. The description instead spends its words on the returned fields, which is the right use of space here.

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 opens with a specific verb ('Read') and enumerates the exact resources returned: account plan, data-use license, shared data call allowance, usage, and UTC reset date. That is far more precise than the name alone and cannot be confused with any sibling (market stats, property, rent history).

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 concrete usage trigger — 'Check commercial_use_allowed when the user states a commercial purpose' — and removes a common hesitation by stating the call does not consume the data allowance. It stops short of naming alternatives or explicit when-not-to-call conditions, so it 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 establish this as a safe, read-only, closed-world operation, so the description only needs to add context beyond that. It does disclose the data returned (asking rent figures plus bedroom-type breakdowns), which is useful since there is no output schema, but says nothing about time period, snapshot recency, or coverage 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?

One tight sentence with the data type and scope front-loaded and no filler. Its only shortfall is that the brevity leaves behavioral questions unanswered rather than that it wastes 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?

For a one-parameter read tool with full annotation coverage and no output schema, the definition covers the essentials but omits timeframe (current snapshot vs historical), the unit/currency of the figures, and how bedroom breakdowns are represented. Those gaps matter because no output schema documents the shape.

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 'city' parameter is already documented with its slug pattern and the list_covered_cities resolution instruction. The description adds no further meaning to 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 a specific verb ('Read') and resource ('asking rent statistics and bedroom breakdowns') scoped to a 'tracked city'. That separates it reasonably from siblings like get_rent_history (time series) and get_national_summary (national scope), 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?

'for a tracked city' hints that only covered cities are valid, and the schema points at list_covered_cities for resolution, but the description itself gives no explicit when-to-use vs get_rent_history or get_national_summary guidance. Usage is implied 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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only that the data is a 'tracked national rent sample' – it does not disclose what metrics or time period are returned, how current the sample is, or whether a missing state yields an error or a national-only response.

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

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

Two short sentences with the resource stated first and the optional parameter behavior second – nothing superfluous. Slightly more precision on 'tracked' would have cost nothing, but there is no wasted wording.

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 single optional-parameter read tool with annotations and no output schema, the definition is serviceable but leaves the return content undescribed – an agent cannot tell what figures a 'national summary' contains or over what period, which matters given the absence of an output schema.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does explain that the state parameter is optional and that supplying it triggers a state-vs-national comparison. The two-letter format is conveyed by the schema pattern, and the description supplies the semantics the schema lacks.

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

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

Names a specific verb and resource: 'Read the tracked national rent sample,' with the added scope note that a state can be compared against it. It is clearly distinct in subject matter from most siblings, though it does not explicitly contrast itself with the closest alternative, get_market_stats.

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 phrase 'Optionally compare one state with the national sample' implies that supplying a state switches to comparison mode and that the call is valid without any argument. There is no explicit guidance on when to prefer this over get_market_stats or get_rent_history.

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, non-destructive, closed-world), so the bar is lower, and the description still adds two real traits: the observation window is seven days, and the data is observed asking rents that do not guarantee current availability. It does not disclose result volume, the effect of 'limit', or whether cities with no cuts return an empty set.

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

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

Two short sentences, scope stated first and the data caveat second; every clause carries information and nothing is 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?

With no output schema, the description carries the burden of explaining what an observation record contains and how many come back, and it says nothing about return shape or the limit cap. It is adequate to know what the tool fetches and to trust the data appropriately, but thin for a tool with an undocumented parameter and no output contract.

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 only 50%: 'city' is well documented in the schema (slug format, resolved via list_covered_cities) but 'limit' has no description at all, only a 1-100 range. The description never mentions either parameter, so it does not compensate for the undocumented cap or clarify what limit actually bounds (records? properties? days?).

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 ('Read observed asking rent reductions') plus a precise scope: last seven days, one tracked city. An agent can distinguish it from get_rent_history and get_market_stats by the 'reductions in a city over 7 days' framing, though no sibling is named explicitly.

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 seven-day/single-city scoping tells the agent roughly when this fits, but there is no explicit when-to-use or when-to-prefer get_rent_history / get_market_stats guidance. The availability caveat is a data-qualification note, not 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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds that the result is scoped to the authenticated caller and that the identity is "stable" (useful for caching/ID reuse), but says nothing about auth failure behavior or whether the value can change over time.

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

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

A single front-loaded sentence with zero filler — the subject (authenticated account identity) arrives immediately. There is nothing that could be trimmed without losing meaning.

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-argument read tool with full annotation coverage and an output schema that documents the returned fields, the description supplies what the agent needs: scope (this caller) and nature of the payload (identity). Only the auth-prerequisite is left implicit.

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 meaning for the description to supply; the baseline for a parameterless schema applies. Nothing is missing in this dimension.

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?

"Return the stable identity of this authenticated Average Rent account" gives a specific verb (return) and a specific resource (the caller's account identity). It is clearly separable from siblings like get_account_usage or get_rent_history, though it never names an alternative explicitly.

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: "this authenticated ... account" plus the zero-parameter schema makes applicability self-evident (no arguments to choose, so it always targets the caller). There is no explicit statement of when to prefer it over get_account_usage or any exclusion.

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 and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context with 'last-known' (data may be stale) and 'verification date' (freshness signal), but 'Respect no_current_availability' is undefined jargon that the agent cannot act on without guessing.

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 verb and resource, with no padding. The second sentence is compact to the point of being cryptic rather than wasteful.

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

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

With no output schema and a rich payload (prices, fees, concessions, verification date) enumerated in the description, the core is covered. Missing are not-found behavior, what 'no_current_availability' actually means, and unit-level versus building-level granularity.

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 a single required parameter with 0% schema description coverage, so the description must carry the meaning. 'Read one building' implies property_id identifies a building, which is some help, but no format, source, or example is given and nothing indicates error behavior for an unknown ID.

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

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

Names a specific verb and resource ('Read one building') and enumerates what comes back: unit prices, fees, concessions, and a verification date. That clearly separates it from sibling list/search tools like search_apartments, though it never explicitly names an 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?

The phrase 'Read one building' implies single-record lookup keyed by an ID, which positions it against the bulk siblings, but there is no explicit when-to-use or when-not-to-use statement. The directive 'Respect no_current_availability' is a usage hint that is never explained, so the agent must guess what it entails.

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 a safe, closed, read-only operation, so the description's main addition is the caveat that sample changes can affect market trends. That is useful context but vague—it doesn't say how the sample changes, whether history is restated, or what the default/lookback behavior 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?

Three short sentences, front-loaded with the core action and followed by the key constraint and a caveat. Nothing is padded, though the caveat sentence is slightly cryptic and could be sharper.

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 convey the return granularity ('daily' rent history) and the two scope options, which covers most of what an agent needs. The remaining gap is the unexplained `days` parameter and lack of any note on output shape or limits.

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 only 33%, and the undocumented parameter is `days`, whose meaning (lookback window vs. forward window, default) is never explained in the description. The one genuinely helpful parameter note ('exactly one of city or property_id') largely restates the schema's oneOf, so the description adds little beyond the structured fields.

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

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

The description gives a specific verb and resource ('Read daily asking rent history') plus the two supported scopes (a city or a property), which is enough for an agent to know what it returns. It does not explicitly distinguish itself from siblings like get_market_stats or get_national_summary, 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?

It states the selection constraint ('Supply exactly one of city or property_id'), but that rule is already encoded in the schema's oneOf. There is no guidance on when to prefer this over get_market_stats or get_national_summary, and no note on prerequisites such as resolving a city via list_covered_cities (which only appears in 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds the kind of content returned (sample counts, observation dates, source links), which is useful, but says nothing about result size, ordering, or whether coverage is global or partial.

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

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

A single front-loaded sentence with no filler; every listed field is informative. It is a field enumeration rather than prose, but nothing is wasteful.

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 tool with no output schema, describing the returned fields is exactly the right compensation. Only the missing note on scope/ordering 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?

The tool takes zero parameters, so the baseline is 4; there are no parameter semantics to explain and the description correctly avoids inventing any.

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

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

States a specific verb and resource ('List tracked city slugs') plus the record fields returned. It is clearly distinguishable from all listed siblings (market stats, national summary, property lookup, search), though it never explicitly names an 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?

No explicit when-to-use or when-not-to-use guidance. The purpose implies a discovery/coverage-check step before searching apartments, but the agent must infer that sequencing on its own.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower, and the description still adds real substance: results are described as including asking rents, verification dates, and source links, which substitutes for the absent output schema. It is silent on pagination behavior and defaults for limit/offset, 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?

Five short sentences, zero filler, front-loaded with purpose before input rules and result contents. Each sentence adds a distinct fact (what it finds, how to address it, constraint, ID guidance, return fields).

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

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

For a 10-parameter search tool with no output schema and near-zero schema descriptions, the definition covers input addressing and output fields reasonably well. But pagination, the meaning of limit/offset, and the bedrooms filter are never addressed, so an agent still has to guess at several call-shaping details.

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 only 10% across 10 parameters, so the description carries heavy burden and does partially compensate: it clarifies that a property name goes in query, that neighborhood depends on city, and that rents have an ordering constraint. However, limit, offset, bedrooms, and the ZIP format receive no explanation anywhere, leaving a third of the parameters undocumented end to end.

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?

"Find last-verified apartment listings" gives a specific verb and resource, and the mention of multiple building names matching plus returned IDs signals this is a search/list tool rather than a detail fetch like get_property. It stops short of naming a sibling explicitly, so the boundary with get_property or get_market_stats is inferable but not 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 description gives concrete invocation conditions: supply a city, state, ZIP, or property name, and a neighborhood requires its city. It also sets an input constraint (min_rent must not exceed max_rent) and a follow-up rule (use returned IDs when multiple buildings match). It offers no explicit when-not guidance or named alternative tool.

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