DoorLoop MCP by usefulapi

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

Annotations only carry destructiveHint=true, so the description does real work: it discloses that each invocation produces a new record (non-idempotent, duplicate-prone) and that notification flags default to off unless explicitly set, which prevents silent no-ops. It stops short of stating permission requirements or what the response contains.

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?

Very compact and front-loaded: the write intent and endpoint lead, followed by the highest-risk conditional rules. The telegraphic phrasing ('INTERNAL_TASK needs requested_by_user') is efficient, though slightly terse for an unfamiliar caller.

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 16 parameters, no output schema, and thin annotations, the description covers the highest-risk unknowns: per-type required fields, notification defaults, and non-idempotency. It does not cover the three globally required fields or what identifier a successful create returns, which matters for chaining into doorloop_get_task.

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 75%, and the description compensates for part of the gap by spelling out the cross-field dependency that the schema itself does not encode (requested_by_user/tenant/owner, assigned_to_vendor per type). It also adds the default semantics for the notify flags. It leaves the type enum values and priority/status choices unexplained 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?

Opens with an explicit verb+resource ('WRITE: create a task in DoorLoop') plus the backing endpoint (POST /tasks), which cleanly separates it from the read siblings (doorloop_get_task, doorloop_list_tasks) and from doorloop_post_task_update. An agent can identify the operation 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?

It supplies the key conditional rule for choosing which of the four type values to use and which companion field each demands, plus a warning that 'each call creates a new task' (duplication risk). However, it never explicitly contrasts with doorloop_post_task_update or states when an update should be preferred over a fresh create, so the alternative routing is only 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=true, so safety is covered; the description adds that the returned record is the API-key owner and that this is a connectivity smoke test, which is real behavioral context beyond the annotation. It doesn't mention error/auth-failure behavior, keeping it short of a 5.

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

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

Three brief sentences: what it returns, why to call it, and the underlying endpoint. Nothing redundant, and the core purpose 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?

For a zero-parameter read with annotations covering safety and no output schema, the description is nearly complete. The only minor gap is it doesn't hint at what fields the user object contains, though an agent can reasonably expect a standard user record.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly implies no input is needed by framing it as a self-lookup.

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 ('Get the DoorLoop user that created this API key') and pins down the exact identity being returned, which distinguishes it from the sibling doorloop_list_users. An agent can tell immediately this is the single authenticated principal, not a user listing.

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 recommends itself as a 'Good first call to confirm the connection', giving a clear usage context and sequencing cue. It doesn't name an alternative for other scenarios, but the no-parameter, self-referential nature of the call leaves little 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?

The readOnlyHint annotation already declares this is a safe read. The description adds only the REST endpoint mapping, which is mildly useful for tracing but says nothing about error behavior for missing/unauthorized leases or what fields come back. With annotations covering the safety profile, this is adequate but thin.

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

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

Two short sentences with the operation front-loaded and zero filler. The endpoint sentence is slightly redundant for the agent's decision-making, but it costs almost nothing.

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 one-parameter read tool with annotations covering safety and no output schema is a simple case, but a 'get' tool with no output schema still benefits from a hint about what a lease record contains. The definition is callable as written but leaves the agent with no picture of the response.

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

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

Schema coverage is 100% and the schema itself explains where lease_id comes from, so the description correctly leaves parameter detail to the schema. It adds no syntax, format, or id-prefix guidance beyond it, so baseline 3 applies.

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

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

States a specific verb and resource ("Get one lease by id") and even cites the underlying endpoint, so the single-record fetch is unambiguous. It doesn't explicitly name doorloop_list_leases as the contrasting sibling, but the singular 'one lease by id' framing differentiates it well enough.

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

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

Usage is only implied: an agent can infer this is the tool for a known lease_id, and the schema note "from the matching list tool" hints at the list-then-get pattern. There is no explicit when-to-use or when-not-to-use guidance and no mention of what to do without a valid id.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description carries a lighter burden. What it adds is only the REST endpoint mapping (GET /properties/{propertyId}); it says nothing about not-found/error behavior or what the returned property object contains, which is the main remaining ambiguity for a getter.

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

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

Two short sentences, front-loaded with the operative verb and resource, then the endpoint mapping. No filler or repetition; every clause earns its place.

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

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

For a simple one-parameter read, the definition plus annotations is minimally sufficient to invoke it correctly. However, with no output schema and no mention of the returned property shape or failure modes, the description leaves the agent guessing about the result — a gap it could have closed in a sentence.

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

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

There is a single parameter with 100% schema description coverage ('The property_id (from the matching list tool)'), so the schema already does the work. The description adds no format, validation, or sourcing detail beyond restating that lookup is by id, which matches the baseline 3 for full 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 and resource ('Get one property') and the singular 'one ... by id' implicitly contrasts with the sibling doorloop_list_properties. It stops short of naming the sibling or clarifying scope differences explicitly, but an agent can still tell retrieval-by-id from listing.

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

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

Usage is only implied: fetch a single property when you already have its id. There is no explicit statement of when to prefer this over doorloop_list_properties, and no mention of what to do if the id is unknown — though the schema parameter hints at sourcing ids from the matching list 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?

The readOnlyHint annotation already establishes this is a safe read, so the description's burden is light. It contributes the API endpoint mapping, which helps with error interpretation, but says nothing about behavior on a missing or malformed id, nor what the returned payload contains. Adequate with annotations, but no extra behavioral depth.

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, zero filler, with the primary statement of purpose front-loaded. The endpoint reference is compact and diagnostically useful rather than redundant padding.

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 tool whose safety profile is carried by annotations and whose parameter is fully documented in the schema, this is close to complete. The only meaningful omission is a note on what the response contains or what happens when the id does not resolve.

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 one required parameter and 100% schema description coverage, the baseline of 3 applies. The description adds no semantics for task_id beyond echoing it in the endpoint path, and the schema already tells the agent where to obtain the value.

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

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

The description names a specific verb and resource ("Get one task by id") and adds the underlying API route, so there is no ambiguity about what the tool returns. It is clear it fetches a single record, which implicitly separates it from doorloop_list_tasks, but it never names that sibling or any other to make the contrast explicit.

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

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

Usage is only implied: fetch a task when you have its id. The description gives no explicit guidance on when to prefer this over doorloop_list_tasks, and no prerequisite or failure condition (e.g. an unknown id) is mentioned. The only real routing hint, "from the matching list tool", lives in the schema rather than the description.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower; the description adds the underlying endpoint (GET /tenants/{tenantId}), which corroborates read-only semantics. It does not disclose behavior for a missing/unknown tenant_id or anything about the returned shape, so value beyond annotations 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?

Two short sentences, front-loaded with the action, with zero filler; the endpoint sentence is compact and useful for API-literate agents. Slightly under-specified rather than verbose.

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

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

For a one-parameter read-only lookup with no output schema, the description covers what the tool does and how it maps to the API. It omits what is returned and how errors manifest, which an agent would want before calling it, leaving it minimally viable rather than complete.

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

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

Schema description coverage is 100% and the single parameter is documented with its provenance ('from the matching list tool'), so the schema carries parameter meaning. The description merely restates 'by id' and adds no format, prefix, or validation detail.

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 ('Get one tenant by id') and maps it to the underlying REST endpoint, so an agent knows this is a single-resource read. It never explicitly names doorloop_list_tenants as the plural alternative, so sibling differentiation is only implicit in 'one tenant'.

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

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

No when-to-use guidance is given beyond 'by id'; the description never says to use this after listing tenants or when not to use it. The routing hint ('from the matching list tool') lives in the schema, not the description, so the description itself offers no alternatives framing.

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?

readOnlyHint=true already tells the agent this is a safe read, so the description is off the hook for safety. It adds only the underlying API path; nothing about behavior when the id is unknown (404/empty), auth requirements, or what the response contains.

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, purpose front-loaded, no filler. The endpoint clause is marginal but aids debugging/mapping to the DoorLoop API.

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

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

For a one-parameter read tool with annotations covering safety, this is close to sufficient, but with no output schema the agent gets no hint about what a 'unit' record returns and no error behavior is described.

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 already documents that unit_id comes 'from the matching list tool' (i.e., doorloop_list_units). The description adds nothing beyond that, which is acceptable given the schema already carries the semantics — baseline 3.

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

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

States a specific verb and resource ('Get one unit by id'), and the 'one' plus the required id makes it distinguishable from doorloop_list_units. The underlying endpoint (GET /units/{unitId}) reinforces that this is a single-resource read, though the sibling is never named explicitly.

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

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

The implication is that this is the detail-fetch counterpart to doorloop_list_units, but the description never says so or states when-not to use it. Usage is inferable from 'by id' rather than explained.

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 the description's "DoorLoop API: GET /accounts" merely restates that this is a read. It adds no behavioral context beyond the annotation — nothing about pagination behavior, ordering defaults, or result shape. With annotations covering the safety profile, 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?

Two short sentences, zero filler, with the resource identified first and the API mapping second. Front-loaded and easy to parse, though the endpoint clause carries marginal value for an agent that only needs to call the tool.

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

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

For a simple read-only list tool with full schema coverage and a readOnly hint, the definition is minimally sufficient. However, with no output schema, the description says nothing about what a returned account looks like or how results are paginated, leaving the agent to discover the response shape empirically.

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% with all six optional parameters documented inline (type, sort_by, page_size, page_number, leaseChargeItem, sort_descending). The description adds no parameter meaning beyond the schema, so the baseline of 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?

Names a specific verb and resource ("List chart-of-accounts entries"), and the phrase "chart-of-accounts" usefully disambiguates from siblings like doorloop_list_users or doorloop_list_owners that also deal with "accounts"-adjacent concepts. Clear enough to act on, though no sibling is named explicitly.

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

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

The description gives no when-to-use guidance, no prerequisites, and no exclusions or alternatives. The only hint is the bare endpoint reference, leaving selection between this and the many other list_* siblings entirely to inference.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the underlying endpoint (GET /lease-charges) and the charge taxonomy, but says nothing about pagination behavior, result volume, or ordering defaults—minor gaps given the read-only annotation.

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

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

Three short sentences, front-loaded with what the tool returns and immediately followed by the highest-value usage tip. The trailing endpoint reference is slightly filler but costs little.

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 12-parameter read tool with no output schema, the description covers purpose and one filter trick, and the schema carries the rest. It stops short of clarifying the charges-vs-payments boundary or how date/lease filters combine, which matters 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 all 12 parameters are self-documented and the baseline is 3. The description's only parameter reference (totalBalanceGreaterThan) essentially restates the schema text 'Only charges with a remaining balance above this amount' rather than adding syntax or 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?

States a specific verb and resource ('List charges ... billed on leases') and enumerates what a charge is (rent, fees, late fees). However, it never distinguishes charges from the closely named sibling doorloop_list_lease_payments, so an agent can't fully disambiguate the two without reading schemas.

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?

One concrete usage hint is given: 'Use totalBalanceGreaterThan to find unpaid charges.' That is a real task-to-parameter mapping, but there is no guidance on when to use this versus doorloop_list_lease_payments or how to narrow by lease/property, leaving selection largely inferred.

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?

readOnlyHint=true already declares the safety profile, so the bar is lower. The description adds that these are payments actually received (as opposed to charges or scheduled amounts), a meaningful behavioral distinction, but says nothing about result ordering, pagination behavior beyond the schema defaults, or volume/rate characteristics.

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

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

Two short sentences with the resource scope front-loaded and zero filler. The endpoint-mapping sentence is marginally useful for agents reasoning about the API but is close to redundant with the title.

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

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

For a read-only list tool with fully documented parameters and a clear readOnlyHint, the basics are covered. But with no output schema, the description should have said something about the shape of a returned payment record or pagination envelope, and it omits any differentiation from lease charges.

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%, with every one of the nine optional filters documented in the schema itself (lease, owner, property, date_from/date_to, sort fields, paging). The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ("List rent payments received on leases") plus the underlying endpoint, so the agent knows exactly what is returned. However, it never distinguishes itself from the close sibling doorloop_list_lease_charges, which an agent could easily confuse with lease payments (charges/invoices vs. received payments).

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

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

There is no guidance on when to use this tool versus doorloop_list_lease_charges or the other list endpoints. No prerequisites, no filtering recommendations, no exclusions — the agent must infer usage entirely 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?

readOnlyHint=true already tells the agent this is a safe read, so the description's main added value is the endpoint mapping 'GET /leases'. It says nothing about pagination behavior, result caps, or ordering defaults beyond what the schema's page_size/sort_descending already declare.

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

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

Three short sentences, zero waste, with the resource and return payload front-loaded before the filtering tip. Nothing could be cut without losing information.

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

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

With 21 optional parameters and no output schema, the description usefully names the returned fields and points at the two most decision-relevant filters. Missing is any mention of paging through results or what a default listing returns, a minor gap for a read-only list 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 coverage is 100% across 21 parameters, so the schema carries the semantics. The description adds a small amount by explaining that calculatedStatus/situation target at-risk or late leases, which enriches an otherwise terse 'Collections stage' field, but it leaves the other 19 filters unexplained. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('List leases') and previews the returned fields (dates, rent, status, outstanding balance), which separates it from the singular doorloop_get_lease. It does not name a sibling explicitly, so it falls short of a 5.

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

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

The sentence 'Use calculatedStatus or situation to find at-risk or late leases' gives a concrete filter-selection hint. However, there is no guidance on when to use this list versus doorloop_list_lease_tenants or doorloop_get_lease, and no statement of exclusions.

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?

readOnlyHint already declares this a safe read, and the description adds that results are a tenant-lease join including dates, plus the underlying GET /leases/tenants endpoint for cross-referencing docs. It does not describe whether records are join objects vs. nested tenants, nor anything about pagination semantics (page_size/page_number appear only in schema).

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

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

Three compact sentences with zero filler: purpose first, selection benefit second, endpoint last. Every sentence earns its place and nothing is buried.

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 11 optional params, 100% schema coverage, no output schema and readOnly annotations, the description covers what an agent needs to decide and call. Minor gap: no hint about result shape beyond dates (e.g., whether tenant fields are inlined).

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 all 11 filtering/sorting/paging parameters are already documented. The description adds no extra semantics beyond noting dates exist, so the baseline 3 applies.

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

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

States a specific verb+resource ('List tenants joined to their leases') and names the returned attributes (move-in/move-out dates). The phrase 'Best way to map tenants to leases' implicitly distinguishes it from sibling list_tenants and list_leases without naming them explicitly.

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

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

'Best way to map tenants to leases' gives a positive selection cue, but there is no explicit when-not guidance nor any named alternative such as doorloop_list_tenants or doorloop_get_lease. An agent must infer the boundary 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 declare readOnlyHint=true, so the safety profile is covered. The description adds only the underlying API endpoint (GET /owners); it does not describe the return shape, pagination behavior, default result set when no filters are supplied, or any rate limits. This is thin behavioral context for an 8-parameter list 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?

Two short sentences with zero waste, and the core purpose is front-loaded. The API endpoint note is compact and useful metadata.

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 schema fully documents all parameters and annotations cover the read-only nature, but there is no output schema and the description does not explain what the tool returns or that unfiltered calls list all owners. It is minimally adequate but leaves gaps for an agent to infer.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema. The description adds no additional meaning about how filters interact or what combinations are useful, 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 clear verb and resource: 'List property owners.' This is specific enough to distinguish it from sibling tools such as list_properties, list_tenants, and list_users. However, it does not explicitly contrast with those siblings or name alternatives, which keeps it from a 5.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives, nor does it state prerequisites such as authentication or scope. Usage is only implied by the bare purpose 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 declare readOnlyHint=true, so safety is covered. The description adds only the raw endpoint mapping; it says nothing about result size, pagination behavior, sorting defaults beyond what the schema documents, or what a portfolio record contains.

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

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

Two short sentences, front-loaded with the purpose and the clarifying synonym. No filler, though the endpoint reference is marginally useful to an agent versus behavioral detail that could occupy the same space.

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

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

For a simple read-only list tool with fully documented parameters and safety annotations, this is barely adequate; there is no output schema, so a hint about what a portfolio includes (fields, count/ordering) would round it out.

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 four parameters are fully documented in the schema (100% coverage), including defaults and max page size, so the description needn't restate them. Baseline 3 applies since the schema carries the semantic load.

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 verb and resource ("List portfolios") and adds a clarifying synonym "(property groups)" plus the backing endpoint GET /property-groups. That distinguishes it reasonably from doorloop_list_properties, though the description doesn't explicitly say how portfolios differ from properties as a domain concept.

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

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

No statement of when to use this versus doorloop_list_properties or the other list tools, and no mention of pagination strategy or when to page through results. The agent must infer purpose from the name alone.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation, lowering the disclosure burden. The description adds the underlying GET endpoint and names some returned fields, but does not mention pagination behavior, filtering semantics, or rate limits beyond what the schema already covers.

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 filler, and the core purpose is front-loaded before the API endpoint reference. Every phrase contributes either identification or API context.

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 list tool with eight fully documented optional parameters and no output schema, the description gives enough to call it correctly: the resource, the API endpoint, and a sample of returned fields. It omits pagination or result-shape details, but those are largely covered by schema parameter descriptions.

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 all eight optional parameters are already documented in the input schema. The description adds no parameter-specific meaning beyond listing address, class, and portfolio as data dimensions.

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 properties') and clarifies the domain object as buildings, plus the fields address, class, and portfolio. It does not explicitly distinguish itself from the sibling doorloop_get_property, so it falls short of a 5.

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

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

The word 'List' implies enumeration rather than retrieval of a single property, but the description never states when to use this instead of doorloop_get_property. Usage is only implied through the tool name and verb.

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, so the safety profile is covered. The description adds genuine value by disclosing that a single endpoint returns four distinct entity types, which an agent cannot infer from the type enum alone. It does not mention pagination behavior or the shape of the response, which matters for a 15-parameter list call.

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, zero filler, resource scope front-loaded before the API reference. Nothing here is redundant or padded.

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

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

For a 15-parameter list tool with no output schema, the description says nothing about pagination defaults, result limits, or what a response contains. The schema carries the parameters well and the annotation covers safety, but an agent gets no sense of return volume or behavior at page boundaries.

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 all 15 filters, date ranges, sorting and paging parameters are documented in the schema itself. The description adds no extra semantics such as how date ranges are combined or whether filters AND together, so baseline 3 applies.

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

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

States a specific verb (List) and enumerates the four resource kinds returned (tasks, work orders, tenant requests, owner requests), which maps directly to the type enum. It clearly differs from doorloop_get_task (singular fetch) by naming, though the description never explicitly contrasts 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?

Usage is only implied by the verb 'List' and the endpoint GET /tasks. There is no statement of when to prefer this over doorloop_get_task for a single record, no prerequisites, and no exclusions. Adequate for a self-evident list operation but not informative.

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, so the safety profile is covered. The description adds that prospects are included alongside lease tenants and that contact details are returned, plus the underlying endpoint, but says nothing about pagination totals, maximum result sets, or ordering defaults beyond what the schema documents.

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, front-loaded sentences with the resource and scope stated immediately. The trailing 'DoorLoop API: GET /tenants' is mild filler for an agent but is harmless and grounds the tool in the vendor API.

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

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

With no output schema, the description should at least sketch the return shape; 'contact details' is a partial hint but doesn't cover the tenant record structure or pagination metadata. For a read-only list tool with fully documented parameters this is adequate but incomplete.

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

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

Schema description coverage is 100%, so every filter, page_size bounds, and sort flags are already documented in the schema. The description adds no additional semantics about filtering or how filters combine (AND vs OR), which is the one gap the schema leaves.

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

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

States a specific verb and resource ('List tenants and prospects'), and adds what the results contain ('contact details'), which goes beyond the title. It does not distinguish itself from the close sibling doorloop_list_lease_tenants, so an agent could still hesitate between the two.

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

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

Usage is only implied through the available filters; there is no statement of when to use this versus doorloop_get_tenant (single lookup) or doorloop_list_lease_tenants (tenants on a lease). For a tool with 10 optional filters and several near-neighbor siblings, that omission leaves real 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, so safety is covered. The description adds a genuinely valuable gotcha (default returns active units only) plus the underlying endpoint, but it refers to 'filter_active', a parameter name that does not exist in the schema (the actual parameter is 'active'), which can mislead an agent.

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

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

Three short sentences, front-loaded with the resource and its key caveat, then the endpoint. Nothing is padding.

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 9 fully documented optional parameters, no output schema, and a read-only annotation, the description covers the essential default-behavior trap. It omits pagination behavior and sort semantics, which are documented in the schema, so the gap is minor.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes slightly beyond the schema by disclosing that the status filter defaults to active-only, a default the 'active' enum description does not state. It adds little else about the other eight filters.

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

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

States a specific verb and resource ('List rental units') and previews the returned fields (rent, bedrooms, status), which distinguishes it from doorloop_get_unit. It does not explicitly name the sibling it contrasts with, so it stops short of a 5.

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

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

'Without filter_active the API returns active units only' implies when the default behavior applies, which is useful. But there is no explicit when-to-use guidance versus doorloop_get_unit or doorloop_list_properties, and no statement of when not 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds only the underlying endpoint ('GET /users'), which is mildly useful for debugging but says nothing about pagination behavior, result size, or required auth beyond what the schema implies.

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

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

Two short sentences with the core purpose front-loaded and no padding. The API endpoint sentence is marginally useful rather than wasteful, though it could have been spent on usage guidance instead.

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

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

For a simple read-only list tool with fully documented parameters and a readOnlyHint annotation, the definition is adequate. It still leaves an agent guessing about result contents and pagination strategy, which matters since there is no output schema.

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

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

Schema description coverage is 100% — all four parameters (sort_by, page_size, page_number, sort_descending) are documented in the schema with defaults and bounds. The description adds nothing beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource: 'List DoorLoop users of the company.' The 'of the company' qualifier implicitly separates it from the single-user sibling doorloop_get_current_user, but no sibling is named explicitly.

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

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

Usage is implied by the plain list semantics rather than stated. There is no guidance on when to prefer this over doorloop_get_current_user, nor any note about paginating through large result sets.

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?

readOnlyHint=true already declares the safe read nature, so the bar is low, but the description adds almost nothing beyond the endpoint string. It omits return shape, pagination behavior (despite page_size/page_number params), and default ordering, which are exactly the sort of traits annotations do not cover.

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 terse sentences with zero padding, and the purpose is front-loaded before the API reference. Brevity here edges toward under-specification rather than waste, but nothing is superfluous.

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?

Annotations cover the safety profile and the schema fully documents all parameters, so the essentials are present for a simple filtered list. However, nothing is said about what a vendor record contains or how results paginate, leaving the description minimally viable rather than complete.

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

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

Schema description coverage is 100%, with all eight parameters individually documented including defaults and max values. The description adds no filtering or sorting semantics beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific verb ('List') and resource ('maintenance vendors'), and the API endpoint confirms it is a read of /vendors. It is distinguishable from siblings like doorloop_list_owners or doorloop_list_tenants by resource, though it does nothing explicit to differentiate itself.

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

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

There is no guidance on when to use this tool, what prerequisites exist, or what alternatives might apply. An agent must infer that this is the listing endpoint for vendors purely 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?

Only destructiveHint=true is supplied, so the description does real work: it discloses that the operation is additive ('Each call adds a new update'), that notifications are opt-in and off by default, and the underlying endpoint POST /tasks/update. The notable gap is that it never explains why the call is destructive — e.g. whether assigned_to_users replaces the existing assignee set — nor what permissions are required.

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 with the operation type front-loaded ('WRITE:'), followed by scope and the two non-obvious behavioral facts. No filler, and the most decision-relevant information comes first.

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 8-parameter mutation with no output schema and only a destructiveHint annotation, the description covers the essentials: what is written, that calls accumulate, and the notification default. The remaining hole is assignee-replacement semantics and permission/auth requirements, which an agent would need before mutating a task's assignment.

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 75%, so the baseline is 3, but the description adds value by enumerating the mutable fields (status, priority, due date, assignees) and by explicitly restating the notification default, which matters because notify_tenant/notify_assignees silently default to no. It stops short of clarifying replace-vs-append semantics for assigned_to_users.

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 'WRITE:' marker and states a specific verb and resource: 'post a message on an existing task and optionally change its status, priority, due date or assignees.' The phrase 'existing task' plus 'Each call adds a new update' separates it from doorloop_create_task and from the read-only doorloop_get_task without needing 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?

Usage is implied rather than stated: it's for adding commentary or mutating fields on an already-created task. There is no explicit when-to-use/when-not guidance, no mention of choosing doorloop_create_task for new tasks, and no prerequisites such as needing a task_id from doorloop_list_tasks (that only appears in the schema).

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