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

Annotations already carry destructiveHint=true and readOnlyHint=false, but the description goes well beyond them by detailing fixture-prefix requirements for names in create payloads, session-scoped updates/deletes, and the sandbox/production differences. This materially clarifies what happens at write time without contradicting 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 front-loaded with purpose and the read/write split, then packs in dense guardrail rules. It earns most of its length, though the final sentence about updates/deletes and creates under existing records is somewhat convoluted and could be clearer.

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 broad scope and high parameter count, the description covers the essentials: when to use it, when not to, the active guardrail mode, fixture-prefix rules, session restrictions, and sandbox/production differences. With an output schema present and annotations carrying the destructive/read-only profile, nothing critical 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic constraints on payload values: every name in a create payload must carry the fixture prefix, nested ones included, and creates with no name field behave differently on sandbox vs. production. This supplements the schema's generic body description.

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 'Call any Buildium endpoint: the tool for writes,' which names a clear verb and resource and immediately positions it as the write-oriented counterpart to read tools. It further distinguishes itself from buildium_get by explicitly labeling that tool as read-only.

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 states 'For reads use buildium_get' and notes that GET also works but buildium_get is the preferred read tool. It also directs the agent to buildium_health for the active write-guardrail mode and explains sandbox-versus-production restrictions, giving concrete when-to-use 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 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the useful detail that $refs are resolved, but otherwise it mostly restates the tool's purpose rather than revealing additional behavioral traits such as auth needs, rate limits, or edge cases.

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, both purposefulcars. The core contract is front-loaded, and the usage guidance follows naturally. No filler or redundant restatement of the tool name exists.

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 an introspection tool with only two fully documented parameters, a strong usage pointer, and an output schema present, the description covers everything needed. There is no missing context that would prevent an agent from invoking it correctly.

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

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

Schema description coverage is 100%, so the input schema already explains both parameters well: path includes an example and method lists allowed HTTP verbs. The description adds no additional parameter-level meaning beyond calling them 'parameters,' so the baseline 3 applies.

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

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

The description states a specific verb ('Show'), a clear resource ('the full contract for one endpoint'), and enumerates exactly what is included: parameters, request body schema, and success response schema with $refs resolved. It is clearly distinguishable from sibling tools like buildium_describe_schema by focusing on an endpoint's full contract.

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 provides explicit, actionable guidance: 'Call this before buildium_call_endpoint on anything non-trivial — especially writes.' It names the relevant sibling tool and gives a concrete condition for when this tool is the right choice, which is exactly what 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, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds the behavioral context of resolving a depth-limit artifact, which is useful beyond the annotations. It does not mention output format or error handling, but the presence of an output schema reduces the burden.

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 no redundant wording. The primary action is front-loaded, and the usage condition is placed in the second sentence. Every word 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 single-parameter, read-only tool with annotations covering safety and an output schema, the description provides the purpose and the exact scenario. Nothing an agent needs to decide when to invoke it 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?

The single parameter 'name' is fully described in the input schema (100% coverage) with an example, so the schema carries the meaning. The tool description does not add extra parameter details, but that is not necessary given the high schema coverage. 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 states a clear action ('Expand a named schema from the spec') and ties it to a specific need: when buildium_describe_endpoint hits its depth limit and emits a bare $ref. This distinctly separates it from the sibling describe_endpoint tool and conveys the resource (schema) and the operation.

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 an explicit trigger condition: use this when buildium_describe_endpoint has a depth limit and returns a bare $ref. This implicitly names the alternative (describe_endpoint) and clearly defines when to use this tool instead. No other tool is needed for this scenario.

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

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

Goes well beyond the annotations: explains the two-step download flow, file location (~/Downloads/Buildium), overwrite semantics tied to destructiveHint=true, and the transport-layer POST block. No contradiction with annotations; it adds meaningful behavioral context the annotations cannot convey.

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?

Every sentence earns its place. The main purpose is front-loaded, then constraints and exceptions are layered logically. It is detailed but not redundant; no filler.

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

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

For a tool with a two-step flow, special mode restrictions, and an output schema, the description covers all essentials: how the flow works, where files go, overwrite behavior, and failure modes. The presence of an output schema relieves it from describing return values, and nothing an agent needs to call it correctly 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?

Although schema coverage is 100%, the description enriches each parameter: save_to's default naming and relative path handling, download_path's constraint to seven endpoints, and overwrite's default false. This is genuine added meaning beyond the schema.

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

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

The description opens with a clear verb and resource: 'Download a Buildium file to this machine,' and immediately differentiates from buildium_get by explaining why that tool cannot be used (expiring URL, separate storage). This unambiguously identifies the tool's purpose and distinguishes it from a close sibling.

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 states that buildium_get cannot handle this task and why, giving the agent a clear routing rule. It also discloses the production-readonly mode refusal and notes that metadata reading via GET still works, providing concrete when-to-use and when-not-to-use 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 provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is fully known. The description repeats 'Cannot change anything' and adds the approval-workflow rationale, but it does not add new behavioral detail such as error behavior, rate limits, or response characteristics beyond what schema/annotations already imply.

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 achieve a lot: they state the domain, the safety constraint, the usage rule, and the distinguishing rationale versus the write-capable sibling. There is no filler or repetition that does meaningful work.

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 generic endpoint-reading tool with 5 richly described parameters, an output schema, and strong annotations, the description is complete enough. It would be hard for an agent to misuse this tool for a read when a curated shortcut is available, or to confuse it with the write-capable endpoint 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?

Schema description coverage is 100%, so the parameters are already well documented. The description adds no parameter-level meaning beyond the schema, which is the expected baseline when the schema carries the full burden.

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: 'Read any Buildium endpoint (GET).' It immediately distinguishes itself from curated read shortcuts and from buildium_call_endpoint, so an agent can tell exactly what this tool is for. The phrase 'Cannot change anything' reinforces the read-only 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?

It gives explicit when-to-use guidance: 'Use this for every read that has no curated shortcut.' It also explains the split from buildium_call_endpoint in terms of client approval of reads versus writes. This clearly routes an agent between generic reads, curated reads, and write calls.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, fully covering safety and idempotency. The description adds minimal behavioral context beyond 'including tenants and rent terms', which relates to response content rather than side effects. With annotations present, the bar is lower, and this modest addition earns a 3.

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, focused sentence that conveys the core purpose without redundancy. It is front-loaded with the action and resource, making it easy to scan. No wasted 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?

Given that an output schema exists (so return structure is defined), the annotations cover safety, and the schema documents parameters fully, the description is sufficient for an agent to invoke the tool correctly. It states exactly what the tool does, and the schema fills in the rest. Nothing critical 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?

Schema coverage is 100%, so both parameters (lease_id and fields) are already described in the schema. The fields parameter's schema description is notably detailed, explaining its purpose and why it's useful. The tool description itself does not add any parameter-specific information, but since the schema carries the burden, 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 clearly states the action ('Get'), the specific resource ('one lease'), and the key included details ('tenants and rent terms'). It is distinguishable from siblings like buildium_list_leases, which implies retrieving multiple leases, and from buildium_get_rental, which targets a 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 description implies usage: use this when you need a single lease by ID. It does not explicitly name alternatives or exclusions, but the phrase 'one lease by ID' sets clear context. A slight gap is the lack of guidance on when to prefer list_leases or other tools, but the purpose is clear enough for most agents.

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 report read-only, idempotent, and non-destructive behavior, so the description does not need to repeat them. The main text adds no behavioral detail; only the schema's fields description notes that Buildium records can be large and carry sensitive fields, which is modest additional context. 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 front-loaded sentence with no filler. It conveys the essential operation and selection criterion immediately, and every word 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 simple one-by-ID read tool, the description, together with the fully described parameters, output schema, and read-only/idempotent annotations, gives an agent everything needed to call it correctly. The only optional improvement would be explicit sibling routing, but this is not required for correctness.

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 rental_id and fields. The description's 'by ID' only reinforces rental_id and adds no meaning beyond the schema; the helpful fields guidance lives in the schema, not the tool description, so 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 states a specific action ('Get'), a precise resource ('one rental property'), and the selection criterion ('by ID'). It distinguishes itself from sibling buildium_list_rentals by emphasizing a single record lookup, so an agent can select it without opening the schema.

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

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

The phrase 'one rental property by ID' establishes clear context: use this when the agent has a rental_id and needs a single entity. It does not explicitly name alternatives or exclusions (e.g., buildium_list_rentals for multiple properties), so it stops short of full explicit 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, and the description adds useful context about what the report contains, including startup misconfiguration and exact settings to apply. It does not contradict the annotations and gives enough behavioral detail for a zero-parameter health check.

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 compact and front-loaded: the first sentence enumerates the report contents, and the second sentence gives crisp usage guidance. Every sentence earns its place with 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?

Given that the tool has no parameters, an output schema exists, and annotations already cover safety and idempotency, the description is complete. It explains what the tool returns, when to call it, and what it will do if the server is not configured.

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 the schema fully covers inputs by construction. The description's detail about what the report covers compensates for any need to explain parameter context, earning the baseline of 4.

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 ('Report') and names the exact resource: the Buildium environment binding, write mode, indexed operation count, download location, and configuration guidance. This clearly distinguishes it from the data-access and endpoint siblings like buildium_get and buildium_list_rentals.

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 when to use the tool: before a write, when the environment is in doubt, or after a startup problem. It also gives a clear exclusion (read-only questions do not require it), though it does not name a specific alternative tool to use instead.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond these by disclosing pagination behavior: 'Every matching tenant is read, following pagination; `complete` says whether that covered them all.' It also reveals a threshold: 'Above 300 leases only the counts are returned (multi_tenant_lease_count and friends); narrow with property_id or lease_id for lease ids and names.' This is valuable behavioral context that the annotations alone do not provide, and it does not contradict 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?

The description is a single paragraph of about 120 words. It is front-loaded with the core purpose and usage, then provides background on Buildium's limitations, and finally describes behavior. Every sentence carries information; there is no fluff. However, it is slightly longer than necessary—the Buildium explanation, while useful, could be condensed. Overall, it is well-structured and concise enough for its complexity.

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 (though not shown here), and the description covers key output details like the `complete` flag and the count fields (multi_tenant_lease_count). It also explains edge cases (300-lease threshold, fixture exclusion) and how parameters affect behavior. Given the tool's complexity (joining leases and tenants, pagination, limits), the description is complete enough for an agent to understand what to expect and how to call it correctly. No important gaps are apparent.

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

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

Schema coverage is 100%, so the baseline is 3. The description mentions 'narrow with property_id or lease_id' but this is already stated in the schema descriptions. It adds no new parameter meaning beyond what the schema provides. For example, the `limit` parameter's schema already explains it is a page size and does not cap the roster; the description repeats this implicitly but does not add extra detail. Thus, the description does not compensate for any gap because there is none, but it also does not add 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 opens with a precise statement of what the tool does: 'Who is on which lease — the lease-to-tenant join, done in one call.' It clearly identifies the resource (leases and tenants) and the operation (joining them). It also distinguishes itself from siblings by explicitly stating its intended use: 'Use this for any "who lives in / who is on lease X" question, and for counting co-tenants.' This is a specific verb+resource and differentiates from tools like buildium_list_leases or buildium_list_tenants.

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 explicit when-to-use guidance: 'Use this for any "who lives in / who is on lease X" question, and for counting co-tenants.' It also explains why it is needed (Buildium's limitations: lease list doesn't reliably populate tenant names, tenant endpoint has no lease filter). It further instructs on narrowing results: 'narrow with property_id or lease_id for lease ids and names.' This provides clear context for when to use this tool versus alternatives, even if it doesn't name a specific sibling to avoid.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by explaining why you need the IDs (for posting transactions), which goes beyond the annotations. It also mentions that using all_pages for totals is necessary to avoid wrong figures, but it doesn't deeply describe the response format or edge cases like the fixture exclusion behavior, which are partly covered by the parameter descriptions.

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 concise and front-loaded with the main purpose in the first sentence. The second sentence provides critical usage guidance on two key parameters, and the entire description is under 50 words. Every sentence earns its place, with no redundancy.

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

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

Given the complexity of 6 parameters and the presence of an output schema, the description is complete. The parameter descriptions in the schema cover the detailed semantics, and the tool description adds the key context about why the IDs are needed and how to count vs. get totals. The annotations already cover the safety profile, so nothing critical 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?

The input schema has 100% description coverage, so each parameter is already well-documented with details like defaults and usage guidance (e.g., 'Follow pagination and return the records, up to 1000. Use it for totals'). The description adds only a small amount of extra guidance in the body, such as the 'count_only' and 'all_pages' usage hints. Since the schema already does the heavy lifting, the description doesn't need to add much, so a 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 clearly states the tool lists general ledger accounts and that the IDs are needed for posting transactions. It distinguishes itself from siblings by focusing on GL accounts, which is a specific resource type. The verb 'List' is precise and the resource is unambiguous.

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 count_only for counting and all_pages for totals. It clearly indicates the when-not conditions for those two parameters, which is essential for correct usage. This instruction prevents the agent from misusing the default pagination or getting incorrect aggregate figures.

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?

Among the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the read-only safety profile is already disclosed. The description adds useful behavioral context beyond annotations: each row already includes rent under AccountDetails, so no need to open the transaction ledger. It also clarifies pagination behavior by directing to count_only and all_pages. This goes beyond the structured data.

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?

Four tightly written sentences with zero filler. The first sentence states the core action, the next delivers the most useful non-obvious fact (rent is already in AccountDetails), and the following sentences route to alternatives and usage flags. 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 an output schema present and 100% schema coverage, the description needn't explain return fields. It addresses the two most likely mistakes an agent could make (opening the wrong endpoint for rent/occupants, or computing aggregates from a single page) and handles them explicitly. For a list tool of this complexity, this is 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 coverage is 100%, so all 8 parameters are already well documented. The description reinforces the purpose of count_only and all_pages but doesn't introduce new semantic meaning beyond what the schema already provides. It also doesn't mention fields, limit, or property_id, but those are self-explanatory from 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 opens with 'List leases.' — a clear verb plus resource. It then distinguishes itself from siblings by stating that buildium_list_lease_transactions handles actual posted charges and that buildium_lease_roster handles occupants, so an agent can immediately tell this tool apart.

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 explicit when-to-use guidance: use buildium_list_lease_transactions for transactions, buildium_lease_roster for who is on the lease, and count_only/all_pages for counts and totals. It also states when NOT to use this tool (for reading rent, you don't need the ledger). This is model 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 cover read-only, idempotent, and non-destructive behavior, so the description need not repeat those. It adds useful behavioral context by defining the result as posted charges and payments, and by relating pagination modes to user intent. There is 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?

Three short sentences: purpose first, then sibling routing, then pagination guidance. Every sentence earns its place, and the most important scoping 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?

With a rich output schema, detailed parameter descriptions, and strong annotations, the description covers the key decision points an agent needs: what this endpoint returns, when to use a sibling instead, and how to choose between all_pages and count_only. Nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description adds value by explaining the practical difference between all_pages and count_only, and by warning against using a single page for totals. This goes beyond the baseline without needing to restate 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 opens with a specific verb and resource: 'List financial transactions (posted charges and payments) for a lease.' It clarifies what kind of records are returned and distinguishes itself from the sibling buildium_list_leases by explicitly noting that recurring rent belongs to that other 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?

The description directly states when to prefer buildium_list_leases instead (recurring rent amount) and provides concrete conditions for all_pages (totalling a ledger) and count_only (learning only how many transactions exist). This is explicit routing guidance with minimal 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 clear. The description adds a minor behavioral note about narrowing large records via fields, which is useful but not substantial; it doesn't contradict 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 lines with zero fluff. The main purpose is front-loaded, and the additional guidance on count_only/all_pages is relevant. 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?

The tool has 6 parameters and an output schema, so much is already structured. The description is adequate for a simple list operation but lacks sibling routing and any mention of the response structure or when pagination is implicitly required. It's not misleading, but an agent could benefit from knowing how this relates to other list tools.

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

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

Schema description coverage is 100%, and each parameter already has a detailed description explaining its purpose and usage (e.g., offset explains next_offset, all_pages warns about page-figure inaccuracies). The description's one-line tip about fields adds negligible 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 'List rental properties', a clear verb+resource that identifies the tool's function. It differentiates from siblings like buildium_list_units and buildium_list_leases by naming 'rental properties', though it doesn't explicitly call out alternatives as the best examples do.

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 only gives parameter-level guidance ('To count, use count_only; for totals, all_pages') and doesn't explain when to prefer this tool over siblings such as buildium_get_rental or buildium_list_units. There is no mention of context, prerequisites, or exclusion conditions.

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 communicate read-only, open-world, idempotent, and non-destructive behavior, so the description's disclosure burden is low. The description adds little behavioral context beyond a redundant count_only/all_pages hint, but it does not contradict 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 very short and front-loaded: the core purpose comes first, followed by the two most important usage hints. It has no filler, though the second sentence is terse enough that it could be slightly clearer on its own.

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?

Despite the minimal description, the overall tool definition is well covered by rich parameter descriptions, a complete annotation set, and an output schema. The description need not explain return values or parameter behavior further; the main remaining gap is clarifying potential conflicts or exclusions between count_only and all_pages.

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 each parameter already has a detailed description, so the baseline of 3 applies. The description's mention of count_only and all_pages adds no meaning beyond what the input schema already provides.

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 a specific resource ('rental tenants'), which is enough to distinguish it from siblings like buildium_list_units or buildium_list_leases. It does not explicitly differentiate it from buildium_list_rentals or call out scope, so it stops just short of full clarity.

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 explicit parameter-level guidance: use count_only for counting and all_pages for totals. However, it never says when to choose this tool over alternatives or when not to use it, so sibling selection is left mostly to inference from the tool 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 provide readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds behavioral context about pagination via all_pages and count_only, noting limits and that single pages are insufficient for totals. This is valuable but not exhaustive, as it doesn't mention response shape or error cases, but given annotations, a 4 is justified.

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 extremely concise, with two sentences: one states the core purpose, the other directs usage for counts and totals. The key usage guidance is front-loaded. Every word is functional, with no fluff.

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 moderate complexity (7 optional parameters), the description covers the main decision points (when to use count vs totals) and the schema covers parameters in detail. There is an output schema, so return values are not the description's job. The only minor gap is that it doesn't mention the `exclude_fixtures` parameter's role, but the schema and health tool reference cover it, so completeness is high.

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

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

Schema coverage is 100%, with detailed parameter descriptions, so baseline is 3. The description adds value by explaining the purpose of all_pages ('for totals') and count_only ('for how many questions'), and mentions the `fields` parameter in the schema to filter large records. This goes beyond schema basics, justifying a 4.

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 the tool lists rental units with optional filtering by property, using a specific verb ('List') and a resource ('rental units'). It distinguishes itself from siblings like buildium_list_rentals by focusing on units, and from count_only/all_pages modes.

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 specifies when to use count_only for counting and all_pages for totals, and warns against using single-page results for aggregates. This guides the agent on mode selection, though it doesn't explicitly mention alternatives for listing rentals, but the sibling context is implied.

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 established. The description adds little behavioral detail beyond the schema: it restates count and totals guidance already present in parameter descriptions. It does not contradict annotations, and no additional side-effect disclosure is needed for a read-only tool.

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

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

The description is extremely compact: one sentence establishes purpose, and a second sentence highlights the two parameter modes that matter most. There is no filler or redundant detail; every word 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?

The description is sufficient for this tool given the rich input schema, output schema, and annotations. It names the resource and the key usage nuances. It could explicitly mention when to prefer a sibling tool, but the tool name and schema already carry most of the contextual burden.

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 baseline is 3. The description's parameter-related advice ("use count_only", "all_pages") restates what the schema already says rather than adding new meaning. It adds no parameter semantics beyond the structured 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: "List work orders (maintenance jobs)." This clearly identifies what the tool does and distinguishes it from sibling list tools like buildium_list_rentals and buildium_list_units by naming the entity. The parenthetical synonym adds helpful clarity.

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 clear guidance on the two main usage modes: "To count, use count_only; for totals, all_pages." This orients the agent toward the right parameters for the right questions. It does not explicitly compare this tool to alternatives, but the resource-specific name makes the primary use case obvious.

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 the behavioral detail that it searches across all 462 operations and returns matching endpoints, which is useful. It doesn't describe result ranking or pagination, but with annotations covering safety, a 3 is appropriate.

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 zero waste. The primary purpose and usage guidance are front-loaded, and the scope detail ('across all 462 operations') earns its place by conveying breadth. No redundant phrasing.

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 rich output schema, annotations covering safety, and 100% schema parameter coverage, the description is nearly complete. It tells the agent when to use it and what it searches. It could mention that results are endpoint matches rather than data records, but the output schema likely covers that, so nothing critical 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?

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds the example keyword style ('work orders', 'lease transactions') and clarifies that query is natural keywords, which is slightly beyond the schema. However, it doesn't add meaning for limit or method beyond what the schema provides, so baseline 3 is correct.

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 ('Find'), a resource ('Buildium API endpoints'), and a clear scope ('by keyword' across paths, summaries, tags, and operation IDs across all 462 operations). It also explicitly positions itself as the starting point when the exact path is unknown, which distinguishes it from sibling tools like buildium_describe_endpoint and buildium_call_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?

The description gives clear context: 'Start here when you don't already know the exact path.' This implies the alternative is to go directly to a specific endpoint tool when the path is known. It doesn't explicitly name alternatives or exclusions, but the guidance is strong enough for an agent to decide when to use it.

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?

Adds meaningful behavioral context beyond the annotations by disclosing that bytes do not travel through the Buildium API and that the upload uses a short-lived AWS presigned PUT URL. It also warns about the generic endpoint's limitation, which is valuable non-obvious 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?

Three compact sentences deliver the purpose, the underlying mechanism, and the routing guidance away from buildium_call_endpoint. There is no filler or redundant repetition of schema 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?

Given the full schema coverage, the presence of an output schema, and annotations covering safety hints, the description adds the critical non-obvious context about the presigned URL flow. An agent has everything needed to invoke the tool correctly and avoid the common alternative mistake.

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?

All seven parameters already have full descriptions in the input schema, so the description does not need to repeat them. The description adds no parameter-specific details, but the schema fully covers parameter semantics, 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?

States the specific action 'Upload a local file to Buildium' and highlights that it handles both steps of the upload flow. It also distinguishes itself from buildium_call_endpoint by explaining why that alternative cannot complete the upload.

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 names buildium_call_endpoint as the wrong alternative and explains exactly why it fails: it posts metadata and hands you a presigned URL it cannot PUT to. The description then directs the agent to use this tool instead, leaving no ambiguity.

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