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

Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds concrete behavioral context: DELETE requires confirm=true, all_pages controls pagination, and write guardrails depend on the active mode (fixtures vs production). It also warns about large responses and how to trim them. This meaningfully informs the agent about side effects and constraints.

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 structured and front-loaded with the core purpose. Parameter explanations are concise and use examples, and the guardrails note is essential. It is a bit long, but every sentence adds value for a tool with 7 parameters and safety requirements.

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

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

Given the complexity (7 params, generic endpoint caller), the description covers all parameters, safety constraints, and references buildium_health for the active mode. An output schema exists, so return format is not needed. It is sufficiently complete for correct invocation, though it could mention error handling or rate 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 description coverage is 0%, so the description must fully compensate. It does so excellently: every parameter (method, path, query, body, fields, confirm, all_pages) is explained with examples and usage notes, going far beyond the bare schema.

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

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

States a specific verb and resource ('Call any Buildium endpoint') and clearly differentiates from the sibling tools by being the generic raw API accessor. The parameter explanations reinforce the scope, making it unmistakable what the tool does.

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 it is the universal fallback for endpoints not covered by dedicated tools, but it never explicitly says 'prefer the specific tools when available' or lists exclusions. It gives parameter-level usage advice (e.g., all_pages for counting) but no tool-level comparison to siblings.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true, and the description is consistent. It adds a non-obvious side effect: the tool appends to created-records.log, which is beyond the annotations. It also explains the purpose of that side effect (cleanup after the process), providing valuable behavioral disclosure.

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 core purpose, and immediately follows with the critical usage context and side-effect. No fluff or redundancy; every sentence earns its place.

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

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

With no parameters, an output schema present, and annotations covering safety, the description adds the essential context about fixtures mode, permitted operations, and log behavior. The agent has everything needed to decide when to call this tool and what to expect.

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 has zero parameters, so schema coverage is trivially 100%. The description adds no parameter-specific detail, but none is needed. The baseline for 0 params is 4, and the description fully suffices; there is no missing parameter meaning to compensate for.

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 ('List') and resource ('records created during this session'), and clarifies the grouping by collection. It clearly differentiates from siblings like buildium_list_tenants or buildium_list_leases by focusing on session-created fixtures, which is a distinct scope.

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

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

The description explicitly states when this tool is relevant: 'These are the only records that updates and deletes are permitted against in fixtures mode.' This tells the agent when to consult this list before performing updates/deletes, and implicitly that other tools are for different operations. It also mentions the log append for cleanup, adding practical context.

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 readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds that $refs are resolved, which is a behavioral detail beyond the schema. It also implies the tool does not execute the endpoint, but this is not explicitly stated, leaving a minor gap.

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

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

The description is two concise sentences. The first front-loads the core purpose, and the second provides targeted usage guidance. No filler or redundant 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?

The tool has an output schema, so the description need not explain return values. It covers the essential information an agent needs: what the tool does, when to use it, and the fact that it resolves $refs. Given the annotations and schema, the description is complete for an agent to decide and invoke correctly.

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

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

The input schema has no descriptions for 'method' and 'path' (0% coverage), so the description should compensate. It implies these identify the endpoint via 'one endpoint', but does not explicitly explain that 'method' is an HTTP verb (e.g., GET, POST) or that 'path' is the URL path. The names are self-explanatory, but the description does not fully clarify expected formats or constraints.

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 explicitly states the tool shows the full contract for one endpoint (parameters, request body schema, success response schema, with $refs resolved). This clearly identifies the verb and resource, and differentiates it from siblings like buildium_call_endpoint (which executes) and buildium_search_endpoints (which searches).

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 direct guidance: 'Call this before buildium_call_endpoint on anything non-trivial — especially writes...' It names the specific sibling and the conditions for use, leaving no ambiguity about when to invoke this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context about expanding schemas after a depth-limit failure, but it does not clarify behavior such as recursive ref expansion, error behavior for unknown names, or output granularity.

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 written sentences with no filler: the action, example, and trigger condition are front-loaded. Every clause adds useful 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 simple one-parameter read-only introspection tool with an output schema and rich annotations, the description is nearly complete. It gives the input example and the workflow context; the only minor gap is leaving the exact meaning of 'expand' (e.g., resolves nested references fully or not) 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?

With 0% schema description coverage and only a 'name' type string in the schema, the description compensates by giving an example ('LeasePostMessage') and specifying the name comes from the spec. It could list more examples or naming rules, but the single parameter is otherwise self-explanatory.

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 uses a specific verb ('Expand') and resource ('a named schema from the spec') and gives a concrete example ('LeasePostMessage'). It also differentiates itself from buildium_describe_endpoint by tying its purpose to that tool's depth-limit failure 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?

The description explicitly says to use this tool when buildium_describe_endpoint hit its depth limit and emitted a bare $ref, which is clear contextual guidance. It names the relevant sibling, though it does not explicitly state when-not-to-use it or describe alternative scenarios.

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?

Reveals the underlying two-step flow, the five-minute URL expiration, the transport-layer POST blocking in production-readonly mode, and the constraint to seven download-request endpoints. These go well beyond the annotations' read-only/idempotent hints and describe real 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?

The description is organized into a short lede, a rationale paragraph, a caveat paragraph, and a parameter list. Every sentence conveys a distinct constraint or fact, 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?

All necessary operating constraints are present: when it works, when it is refused, why buildium_call_endpoint won't work, what the parameters mean, and which endpoints are accepted. Output schema covers return values, so nothing material is missing.

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

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

Despite zero schema description coverage, the description documents each parameter meaningfully: file_id's origin, save_to's destination, and download_path's optional role with an example and endpoint restriction.

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 the action (download), target (Buildium file), destination (this machine), and disambiguates from buildium_call_endpoint by explaining why that sibling cannot do it. The two-step nature is referenced and the resource scope is clear.

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 says when to use this tool instead of buildium_call_endpoint (expiring URL, separate storage), warns about production-readonly mode where it is refused, and notes that metadata reads via GET still work. This is precise 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 and idempotentHint=true, so the safety profile is covered. The description adds that tenants and rent terms are included, which gives some expectation of the response content. It does not mention any rate limits, auth prerequisites, or pagination, but for a read-only single-resource fetch this is acceptable given the annotations cover the main behavioral traits.

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 a single, focused sentence that states the resource, the operation, and the key included content. No wasted words, and the most important information (get by ID) is front-loaded. It is appropriately minimal for a simple CRUD operation.

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

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

Given the tool is a simple get-by-ID and an output schema exists (defining the return shape), the description covers the primary action and response scope. However, the lack of any explanation for the 'fields' parameter is a notable gap, as an agent cannot know how to narrow the response. Additionally, no mention of error handling or edge cases, though these are often implicit in read-only get operations. Overall, functional but incomplete around the optional parameter.

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 has two parameters: lease_id (required integer) and fields (optional array of strings or null). The description does not explain the 'fields' parameter at all, and with 0% schema description coverage, the burden is on the description. 'lease_id' is self-explanatory from its name, but 'fields' – which likely filters which fields to return – is completely undocumented. This leaves the agent guessing about a non-required but potentially useful 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 clearly states it gets a single lease by ID and mentions the included details (tenants, rent terms). This is specific and distinguishes it from sibling tools like buildium_list_leases (plural, no ID) and buildium_get_rental (different resource).

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 tool's purpose is straightforward for a get-by-ID operation, and the description implies usage when you need a specific lease's details. However, it provides no explicit guidance on when to prefer this over sibling tools, such as when you need transaction history (buildium_list_lease_transactions) or a roster (buildium_lease_roster). Absence of explicit exclusions leaves some ambiguity.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond the schema, such as return format or error behavior, but with strong annotations the bar is lower. No contradiction with annotations.

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

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

A single sentence with zero waste. The essential information (get one rental by ID) is front-loaded and complete. Nothing extraneous.

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-by-ID tool with strong annotations and an output schema, the description is nearly complete. The only minor gap is not explaining the optional 'fields' parameter's behavior (e.g., projection), but the parameter name and output schema likely cover that. The tool is simple enough that this description suffices.

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

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

Schema description coverage is 0%, so the description carries the burden for parameter meaning. However, the description's 'by ID' directly maps to the required rental_id parameter, and the optional fields parameter is self-explanatory as a field selector. The description adds minimal value beyond the schema, but the parameter names are clear enough.

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 'Get one rental property by ID' clearly states the verb (get), resource (rental property), and scope (one by ID). It distinguishes from siblings like buildium_list_rentals (which lists multiple) and buildium_get_lease (different resource), though it doesn't explicitly name 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?

The description implies usage: use when you need a single rental property by ID, not a list. It doesn't explicitly state when not to use it or name alternatives, but the 'by ID' qualifier and sibling names provide enough context for an agent to infer the right choice.

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 description adds material behavioral context beyond the annotations: it is deliberately not wrapped by _guarded, is the one tool that must answer when everything else cannot, and reports status rather than raising. This is valuable information an agent would not infer from readOnlyHint or idempotentHint alone.

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 with no wasted words: the first states what it reports, the second states when it is needed, and the third explains its deliberate exception behavior. The most important information is front-loaded.

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 description covers purpose, usage conditions, output scope, and resilience behavior, and an output schema exists to document return values. Nothing an agent needs to decide whether to call this tool is missing.

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

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

With zero parameters and an empty input schema, there is no parameter burden for the description to carry. The description focuses on what the tool reports rather than input semantics, matching the baseline for parameterless tools.

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 ('Report') and enumerates the exact resource and outputs: Buildium environment, write mode, indexed operation count, and configuration guidance. This clearly distinguishes it from the sibling list/call/upload/download tools.

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 when to use the tool ('before a WRITE', 'environment is genuinely in doubt', 'another tool reports a startup problem') and when not to use it ('Read-only questions do not require it'). This provides clear selection guidance without needing to name a specific 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?

Beyond the annotations, the description discloses meaningful behavior: it fetches tenants once and inverts the mapping locally, handles fixture records, and warns that fixtures accumulate permanently because Buildium only supports DELETE on 14 of 462 operations. It also says the response flags fixture presence so counts are never silently wrong.

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

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

The description is front-loaded with a one-line thesis, followed by usage, rationale, and parameter guidance. Every sentence earns its place, including the detailed fixture caveat, which is decision-relevant for accurate counting.

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

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

With an output schema present and annotations covering the read-only, idempotent, non-destructive profile, the description covers purpose, usage, parameter semantics, and data-quality caveats. Nothing critical is missing for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, but the description adds semantics for lease_id, property_id, and exclude_fixtures, explaining restriction behavior and what fixture exclusion means. It omits any explanation of the limit parameter, though its default value and type are present in 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 opening line states the exact resource and operation: 'Who is on which lease — the lease-to-tenant join, done in one call.' It also distinguishes the tool from siblings by explaining that lease lists don't reliably populate tenant names and the tenant endpoint has no lease filter.

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

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

The description explicitly says to use this for 'who lives in / who is on lease X' questions and for counting co-tenants. It gives clear context about why direct alternatives are awkward, but it does not name sibling tools explicitly or give a formal 'when not to use' statement.

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 via readOnlyHint, idempotentHint, and destructiveHint. The description adds the all_pages hint and downstream ID purpose, but does not elaborate on pagination behavior, field filtering, or fixture exclusion. No contradiction with annotations.

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

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

Two sentences with no filler: the first states the core purpose and why it matters, the second gives a single actionable parameter rule. The key information is front-loaded and every sentence 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 read-only list tool, the purpose and the important all_pages behavior are covered, and the annotations plus output schema supply the safety and return-value context. The unexplained auxiliary parameters prevent a 5, but the description is sufficient for basic correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate, but only all_pages gets semantic guidance. The other parameters — limit, offset, fields, and exclude_fixtures — are left to their names and defaults, which is a clear gap for a five-parameter 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?

Description leads with a specific verb and resource ('List general ledger accounts') and immediately clarifies the downstream use ('You need these IDs to post rent charges and other financial transactions'). This differentiates it from sibling list tools by domain and purpose.

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 second sentence gives a clear conditional usage instruction: 'Set all_pages=true when counting or aggregating.' This provides actionable context for a key parameter, but it does not discuss when to avoid this tool or point to alternatives, 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 indicate read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond those annotations, such as rent terms being included in AccountDetails and the pagination intent behind all_pages=true. No contradiction with the annotations.

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

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

The main purpose is front-loaded, and every subsequent sentence earns its place by either clarifying row contents, routing to a sibling tool, or giving pagination guidance. There is 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?

The output schema covers return values and annotations cover the safety profile, so the description doesn't need to restate those. It covers status values, row contents, pagination intent, and sibling routing well; the only minor gap is the lack of explanation for exclude_fixtures and fields.

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

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

Schema description coverage is 0%, so the description must compensate. It explains lease_status values and clarifies all_pages usage, but leaves property_id, exclude_fixtures, fields, limit, and offset without added meaning. This is partial compensation rather than full 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 the exact operation and resource: 'List leases.' It also names the lease_status filter values (Active, Future, Past, Expired) and clarifies what each row contains, so an agent can distinguish this from get_lease, list_lease_transactions, and lease_roster.

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

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

Provides explicit routing guidance: buildium_list_lease_transactions is for posted charges/payments, buildium_lease_roster is for occupants, and all_pages=true is recommended when counting or aggregating. This is exactly the when-to-use vs alternative information an agent needs.

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, idempotentHint=true. The description adds context about what is listed (charges and payments) and a hint about pagination behavior for totalling. No contradiction, and the extra hints are useful.

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 with no filler. The core purpose is front-loaded, followed by the alternative and a targeted usage hint. Every sentence 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?

Covers the main purpose and a key usage scenario, and an output schema exists for return format. However, several parameters (fields, exclude_fixtures) remain unexplained, and the description does not fully compensate for the lack of schema documentation.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions lease_id implicitly and explains all_pages, but leaves limit, offset, fields, and exclude_fixtures unexplained. This is insufficient for a 6-parameter tool with zero schema documentation.

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

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

States a specific verb (list), resource (financial transactions), and scope (for a lease). Clearly distinguishes from sibling buildium_list_leases by noting that recurring rent is available there. An agent can immediately know what this tool does.

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 provides an alternative (buildium_list_leases) for recurring rent and explains why, plus gives a concrete usage rule for totalling a ledger (set all_pages=true). Strong 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?

The annotations already mark the tool as read-only, idempotent, and non-destructive, so the description's main behavioral contribution is pagination context: a single page is limited to the first 50 records, and `all_pages=true` follows pagination to the end. It also warns about the incorrectness of counts taken from a single page, which is valuable behavioral detail beyond the annotations.

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

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

The description is short, front-loaded with the core purpose, and every sentence earns its place. The pagination warning is dense but highly relevant, and there is no filler or repetition of annotation values.

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 output schema exists and the annotations cover the read-only/idempotent safety profile, so the description does not need to explain return values or mutation risks. However, with five optional parameters and zero schema descriptions, the lack of any explanation for `exclude_fixtures` leaves a notable gap in the information needed to use the tool fully.

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 bears the burden of explaining parameters, but it only covers `fields` and `all_pages`. `limit`, `offset`, and particularly `exclude_fixtures` receive no semantic explanation, leaving an agent without enough context to confidently set those parameters.

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 clear verb and resource, 'List rental properties,' which unambiguously states the tool's core purpose. It does not explicitly differentiate from sibling tools like list_units or list_leases, but the resource noun 'rental properties' is distinct enough to avoid significant confusion.

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, actionable guidance: pass `fields` to narrow large records and set `all_pages=true` when counting or aggregating, explaining that a single page is only the first 50 records. It does not mention when to choose this tool over named alternatives, but it clearly explains when the pagination option should be used versus avoided.

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

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

Annotations already cover the safety profile: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the scope of the operation (comprehensive resource-area listing with operation counts) but does not disclose further behavioral details such as output size or pagination. With annotations carrying the safety burden, this is acceptable but not exceptional.

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 short sentences with no filler. The core action and output are stated first, and the usage guidance is appended in a clear directive. Every sentence 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 zero-parameter, read-only orientation tool with an output schema present, the description covers the essential context: what it lists, what each item includes, and when to use it. Nothing critical is missing for an agent 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?

The tool has zero parameters and the schema is empty, so there is no parameter information that the description must supply. The baseline of 4 applies because no parameter documentation burden exists; the description does not need to compensate for anything.

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 ('List') and resource ('every resource area in the Buildium API with its operation count'), with concrete examples. It distinguishes itself from search-oriented siblings by framing itself as an orientation tool rather than a search/discovery tool.

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 to orient before searching' gives clear usage context and timing. It does not explicitly name alternatives or state when not to use the tool, but the guidance is unambiguous enough for an agent to select it in the intended workflow.

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 disclose readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a pagination-related hint about all_pages, but discloses no further behavioral details such as response shape or fixture-exclusion semantics, so the added value is modest.

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 short sentences with the core purpose first and the key pagination caveat separated into its own line. Every sentence earns its place and no filler is present.

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?

A default call is easy to make since all five parameters are optional and annotations plus output schema cover safety and return values. However, the description leaves several parameter semantics unexplained, notably exclude_fixtures and fields, so it is not fully complete for a 5-parameter 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?

Input schema has 0% description coverage, and the tool description compensates for only all_pages ('Set all_pages=true when counting or aggregating'). The meaning of limit, offset, fields, and especially exclude_fixtures is left undocumented, so an agent must guess at their semantics.

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 clear verb and resource: 'List rental tenants.' This unambiguously identifies the operation and distinguishes it from listing leases or GL accounts, though it does not explicitly contrast it with the sibling buildium_list_rentals/buildium_list_units tools.

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 all_pages instruction gives explicit situational guidance for counting or aggregating, which is useful. However, the description never says when to prefer this tool over related siblings such as buildium_list_rentals, leaving tool selection to inference from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations by warning that pagination means one page is not the whole collection, which is critical for counting/aggregation tasks. This is a valuable disclosure that the annotations do not provide.

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 with no filler. The core purpose is front-loaded, and the pagination warning is placed second where it can influence invocation behavior. Every sentence 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 read-only list tool with strong annotations and an output schema, the description covers the main behavioral caveat (pagination) and the primary filter (property_id). It does not explain the remaining parameters, but the schema provides names, types, and defaults, and the output schema covers return structure. The description is complete enough for correct invocation in most cases.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. The description mentions 'optionally filtered to one property' which maps to property_id, and 'all_pages=true' which maps to the all_pages parameter. However, it does not explain limit, offset, fields, or exclude_fixtures, leaving those to the schema's names and defaults. The description adds some value but does not fully compensate for the 0% 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?

The description states a specific verb and resource ('List rental units') and notes an optional filter to one property, which distinguishes it from sibling tools like buildium_list_tenants or buildium_list_rentals. It does not explicitly name a sibling alternative, but the resource and filter scope are clear enough for an agent to select 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?

The description gives clear context for when to use the tool: listing rental units, optionally filtered by property. It also provides a specific usage directive: set all_pages=true when counting or aggregating, because one page is not the whole collection. It does not explicitly state when not to use it or name alternatives, but the guidance is actionable and context-rich.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds value by disclosing pagination behavior through the all_pages instruction, which is not visible in the annotations.

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

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

The description is two short sentences with no filler. The purpose is front-loaded, and the all_pages guidance earns its place as a critical usage note.

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 has an output schema and safety-bearing annotations, and a default no-argument call is possible. However, with five optional parameters and zero schema-level descriptions, the description leaves fields and exclude_fixtures underspecified for an agent that needs those options.

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

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

Schema description coverage is 0%, so the description must compensate for explaining parameters. It only addresses all_pages, while fields, limit, offset, and exclude_fixtures remain unexplained beyond their names and defaults.

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

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

The description uses a specific verb and resource—"List work orders"—and clarifies the domain term with "maintenance jobs." It is unambiguous about what the tool does, though it does not explicitly contrast with the sibling list tools.

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 clear operational guidance: set all_pages=true when counting or aggregating, which prevents incorrect results from default pagination. It does not discuss alternatives or when not to use the tool, but the context is clear for the main use case.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool's safety profile is covered and the description isn't responsible for it. The description adds useful scope detail (462 operations, searched fields) but doesn't disclose behavior like limit truncation, pagination, or result ordering. With annotations carrying the safety burden, a 3 reflects the modest behavioral value added.

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 is front-loaded in the first sentence, followed by scope, usage guidance, and compact parameter notes. Every sentence earns its place with no filler or redundancy — efficiently structured within four short lines.

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 search tool with a read-only annotation profile and an output schema present, the description covers purpose, scope, and two of three parameters. The omission of limit behavior and result-count semantics is the main gap, but given the output schema handles return values, this is nearly complete for agent invocation.

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

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

Schema description coverage is 0%, so the description carries full responsibility for documenting parameters. It does explain query ('natural keywords, e.g. "work orders", "lease transactions", "gl accounts"') and method ('optionally restrict to get/post/put/patch/delete'), adding real meaning beyond the bare schema. However, the 'limit' parameter (integer, default 25) is never mentioned — a genuine gap given the 0% schema 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+resource ('Find Buildium API endpoints by keyword') and details the search scope ('paths, summaries, tags, and operation IDs across all 462 operations'). It distinguishes itself from siblings by declaring it's the discovery tool used when you don't know the exact path, contrasting with buildium_describe_endpoint.

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

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

Gives explicit context: 'Start here when you don't already know the exact path' signals the tool's role in the discovery workflow and implies the alternative (describe_endpoint) when the path is known. It doesn't name the alternative explicitly, but the directional guidance is clear enough for an agent to route correctly.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds valuable behavioral context: it explains the two-step flow (presigned URL), the requirement for a real category_id, and the constraint on upload_path endpoints. It does not contradict any annotation and enriches understanding beyond the flags.

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 appropriately sized for a complex two-step upload. It front-loads the key behavioral insight (presigned URL) and then uses a clean bullet-style layout for parameters. While it is long, every sentence adds necessary information—no fluff—though it could be slightly tightened without losing clarity.

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

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

Given the tool's complexity (7 parameters, two-step upload flow, specific constraints), the description is comprehensive. It explains the mechanism, the required category, the accepted upload_paths, and parameter meanings. The output schema exists to document return values, so the description does not need to cover that. Nothing an agent needs to correctly invoke the tool is missing.

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

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

With schema description coverage at 0%, the description must compensate, and it does so for 6 of 7 parameters. It explains file_path, title, category_id, entity_type, entity_id, and upload_path with meaning and constraints (e.g., category_id required and must come from GET /v1/files/categories). The 'description' parameter is not mentioned, but it is optional and self-explanatory, so the coverage is strong overall.

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 the exact verb and resource: 'Upload a local file to Buildium, handling both steps of its upload flow.' It explicitly differentiates from the sibling buildium_call_endpoint by explaining why that tool cannot perform the upload, making the purpose unmistakable and distinguishing it from alternatives.

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 provides explicit when-to-use guidance: 'Doing that by hand with buildium_call_endpoint does not work... Use this instead.' It also details the presigned URL flow and the constraint that only Buildium's seven upload-request endpoints are accepted, giving clear conditions for correct usage.

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