Propertyware MCP by usefulapi

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

Annotations already declare readOnlyHint=false and idempotentHint=false, but the description adds two concrete consequences the annotations cannot express: comments 'may be visible to other users with task access' and repeat calls produce duplicates. What is still missing is any mention of required permissions or the response shape, so it falls 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 short sentences, zero filler, and the operation type plus core action are front-loaded before the visibility and duplicate caveats. Every sentence carries distinct information.

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

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

For a 3-parameter write with annotations and no output schema, the description covers purpose, side-effect visibility, and duplicate behavior, which is the critical context. It stops short of stating permissions requirements or what the call returns (e.g., a new comment ID), leaving a small gap given no output schema exists.

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 a middling 67%: both ID parameters carry the numeric-ID/64-bit precision note and pattern, but the 'text' parameter has only length constraints and no description. The description contributes nothing about any parameter, so the schema does all the work — 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?

The description states a specific verb and resource — 'Add a comment to an existing work order task' — and the 'WRITE:' prefix immediately signals the operation class. It does not name any sibling or state why it is distinct from them, but among the listed siblings (getters and listers plus create_work_order_task) there is no overlapping tool, so ambiguity is low.

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 'existing work order task', which conveys the precondition that the task must already exist. There is no explicit when-to-use/when-not-to-use guidance and no routing to an alternative (e.g., where to go to create the task first or to read comments).

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=false and idempotentHint=false, so the non-idempotency fact is pre-disclosed. The description's value is in the actionable consequence ('do not retry blindly') and the permission prerequisite, but it adds nothing about what the new task record contains or what is returned.

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 'WRITE:' marker and the core action front-loaded ahead of the permission and retry caveats. Nothing is wasted.

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 safety profile, permission requirement, and retry caveat are all covered, which is most of the burden for a mutation tool with no output schema. However, with six parameters at 17% schema coverage, the agent gets no guidance on the task body fields, leaving a real gap.

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

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

Schema description coverage is only 17% (only workOrderId is documented), yet the description mentions no parameters at all. Acceptable optional fields like isPrivate (default true), starred, dueDate format, and tags are left entirely to the bare schema, so the description fails to compensate for the coverage gap.

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 ('Add a task to an existing work order'), which cleanly separates it from sibling tools like propertyware_list_work_order_tasks and propertyware_add_task_comment. It doesn't name those siblings explicitly, so an agent must infer the boundary, keeping it 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?

'Requires WORK ORDERS write permission' gives a clear prerequisite, and 'Creates a new task on each call; do not retry blindly' tells the agent when not to call again. It stops short of naming an alternative tool for listing or commenting, which a 5 would require.

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, but the description adds nothing beyond that: no mention of what happens when the ID doesn't exist, whether it errors or returns null, or what the record contains. For a retrieval tool the not-found behavior is the main thing an agent needs and it is absent.

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

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

A single front-loaded sentence with zero filler, which is appropriately efficient for a one-parameter lookup tool. It is arguably too terse rather than padded, so it loses nothing on structure.

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?

This is a simple read-only single-parameter tool with no output schema, so the burden is light, but the description still omits not-found behavior and any hint about the returned record. Adequate to invoke, incomplete for handling outcomes.

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?

Only one parameter and the schema documents it fully at 100% coverage, including the numeric-string format rationale, so the baseline of 3 applies. The description's 'by ID' merely restates what the schema already says and adds no format or sourcing guidance.

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 (get) and resource (building) with a singular scope ('one ... by ID'), which implicitly contrasts with the sibling propertyware_list_buildings. It doesn't name that sibling explicitly, but the single-record intent 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?

Usage is only implied: an agent can infer this is for fetching a known building ID rather than enumerating, but the description never states when to prefer it over propertyware_list_buildings or what to do if the ID is unknown. No exclusions or prerequisites are given.

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=true annotation already declares this is a safe read, so the description's burden is light. It adds no context about not-found behavior or return shape, but for a single-record fetch with a matched annotation this is adequate.

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

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

One sentence with zero waste, front-loading the verb and resource. It is efficient, though it verges on under-specification rather than exemplary conciseness.

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

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

For a one-parameter read tool with full schema coverage and a matching readOnlyHint annotation, nothing essential is missing; only error/not-found behavior is unstated, a minor gap.

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

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

Schema coverage is 100% and the single 'id' parameter is documented in the schema as a numeric string preserving 64-bit precision. The description adds nothing beyond 'by ID', which is sufficient given the schema already carries the 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 (get) and resource (contact) with the singular scope 'one ... by ID', which implicitly distinguishes it from the sibling list_contacts. The only shortfall is that the differentiation relies on the word 'one' rather than naming the alternative.

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

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

'by ID' implies the caller must already have a contact ID, but there is no explicit guidance on when to use this versus propertyware_list_contacts for lookup, or what to do when the ID is unknown. Usage is inferred rather than stated.

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

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

Annotations already declare readOnlyHint=true and provide the title 'Get lease.' The description adds almost no behavioral context beyond the annotation, such as not-found behavior, permission requirements, or return 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?

The description is a single front-loaded sentence with no wasted wording. For a simple single-record retrieval tool, this is appropriately concise.

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 simple one-parameter schema and read-only annotation, the description is minimally adequate. However, without an output schema, it does not describe what the returned lease contains or any lookup failure behavior.

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 fully documented in the schema. The description only restates that lookup is by ID, so it does not add 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 gives a specific verb and resource: 'Get one Propertyware lease by ID.' The word 'one' implicitly contrasts with list-style siblings such as propertyware_list_leases, but the alternative is not 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?

There is no explicit guidance on when to use this tool versus propertyware_list_leases or other lease-related tools. The only implied usage is when the caller already has a lease 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 declares this is a safe read, and the description adds nothing beyond restating that fact. It doesn't say what happens when the ID doesn't exist or belongs to another record type, nor 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?

A single short sentence with the resource and lookup key front-loaded and zero waste. It is terse to the point of being near-tautological with the title, but nothing in it is 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 one-parameter read tool with a fully described schema and a readOnlyHint annotation, this is nearly enough to call it correctly. The remaining gap is that no output schema exists, so the description could have sketched the returned portfolio fields or the not-found behavior, and it doesn't.

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

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

Schema coverage is 100% and the single parameter is fully documented in the schema, including the string-encoded 64-bit ID rationale. The description adds only "by ID", so the baseline 3 applies with no extra semantic 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?

States a specific verb and resource ("Get one Propertyware portfolio") and adds the lookup key ("by ID"). Combined with the sibling list_portfolios, the singular/ID-based framing implicitly distinguishes it from the plural list variant, though it never names that sibling 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 phrase "by ID" implies you must already have the numeric ID, which suggests using propertyware_list_portfolios first when you don't, but this routing is left to inference. No explicit when-to-use, prerequisites, or alternative is stated.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds nothing beyond that — no note on not-found behavior, error handling, or what the prospect record contains. With annotations doing all the work, the description contributes almost no additional behavioral context.

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

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

A single front-loaded sentence with zero filler. Nothing is wasted and the action and resource are immediately clear.

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 single-record getter, the schema and readOnly annotation cover most needs. However, there is no output schema, so the agent has no information about the shape of the returned prospect record — a modest but real gap the description does not fill.

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%; the id parameter documents its numeric pattern and 64-bit precision rationale. The description says 'by ID' but adds no syntax, format, or sourcing guidance beyond the schema, 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 ('Get') and resource ('one Propertyware prospect') by ID. The resource name distinguishes it from sibling getters like propertyware_get_contact and propertyware_get_lease, though it doesn't explicitly route against propertyware_list_prospects.

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: fetch a single prospect when you already have an ID. There is no explicit statement of when to use this versus propertyware_list_prospects for discovery, and no prerequisites or exclusions are given.

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 nothing beyond that: no behavior for a missing/invalid ID, no note about what the record contains, and no indication of any scoping or permission considerations.

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 wasted words. It is appropriately sized for a trivially simple lookup, though the terseness leaves useful context unstated.

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 and a fully documented schema, the definition is minimally sufficient. It omits what a caller should expect on a missing record, which is the main remaining gap given 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% and the single ID parameter is fully documented in the schema (numeric record ID preserved as a string). The description only restates that the ID identifies the unit, adding no format or edge-case detail 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 names a specific verb and resource ('Get one Propertyware unit') and the lookup key ('by ID'), which distinguishes it from the sibling list tool propertyware_list_units. It stops short of explicitly naming that sibling, so it is clear but not fully differentiated.

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

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

'by ID' implies this is the single-record retrieval path when an identifier is already known, versus listing units to discover IDs. No explicit when-to-use or when-not-to-use guidance is given, and no alternative is named.

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 title "Get vendor", so the safety profile is covered. The description adds nothing beyond that — no information on not-found behavior, permission requirements, or what a vendor record contains — making it essentially a restatement of the annotated title.

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 short sentence with zero filler, front-loading the verb and resource. Nothing could be removed without losing meaning.

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

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

For a simple single-record read with a complete schema and readOnly annotation, the essentials are present, and no output schema exists so return values need not be described. However, an agent gets no signal about not-found handling or which fields come back, leaving a small but real gap.

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?

Only one parameter, and the schema fully documents it at 100% coverage (numeric string ID preserving 64-bit precision). The description adds no syntax or format detail beyond the schema, 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 (get) and resource (vendor) with a retrieval key (by ID), which cleanly separates it from propertyware_list_vendors. It stops short of naming the sibling, but the singular-vs-list distinction is evident.

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 "by ID" implies the precondition (you already have a numeric vendor ID) and usage is inferable, but there is no explicit when-to-use guidance, no mention of the list_vendors alternative for lookup/discovery, and no statement about behavior when the ID does not exist.

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 adds nothing beyond that — no note on behavior when the ID is unknown, whether tasks/comments are included, or rate/permission context. For a trivial read the burden is low, but no extra context is contributed.

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 waste. It is efficient but extremely sparse, leaving no room for the scope or alternative hints that would earn a 5.

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 getter with readOnly annotations, full schema coverage, and no output schema, the description is minimally sufficient. Missing is any indication of what the work order payload contains or what happens on an invalid/missing ID.

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%: the 'id' parameter is documented with format and the string-for-64-bit-precision rationale. The description only repeats 'by ID', adding no syntax or format detail — 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 ('Get') and resource ('work order') with the singular scope 'one ... by ID', which implicitly distinguishes it from propertyware_list_work_orders. It does not name the sibling, so differentiation is inferable rather than 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?

The single-record scope implies this is for fetching one known work order rather than browsing, but there is no explicit when-to-use statement, no mention of propertyware_list_work_orders as the alternative, and no prerequisites.

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 real contribution is the disclosure that the vendor does not paginate this endpoint — genuinely useful behavior that prevents pointless page-looping. What it omits is anything about ordering, size, or what an empty result looks like.

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

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

Two tight sentences with no filler. The purpose statement comes first and the pagination caveat second, which is exactly the right front-loading for a tool this simple.

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 single-parameter list tool with full schema coverage and readOnlyHint, almost everything an agent needs is present, and the no-pagination note closes the main operational gap. The only missing piece is a hint at the return shape (author, timestamp, body fields), which matters slightly more here because no output schema exists.

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

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

Schema coverage is 100% and the single `id` parameter is fully documented in the schema, including the numeric-string precision rationale. The description only reinforces that the id refers to a building; it adds no format or constraint detail beyond the schema, 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 gives a specific verb and resource ("Read notes") scoped to "one Propertyware building," which is enough to separate it from broader list tools like propertyware_list_buildings and from the related propertyware_list_lease_notes. It stops short of naming a sibling explicitly, so it lands just below the top mark.

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 scoping phrase "for one Propertyware building" implies this is the per-building notes lookup rather than a bulk listing, but there is no explicit statement of when to choose this over propertyware_get_building (which may also surface notes) or how it relates to propertyware_list_lease_notes. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds the BUILDINGS read permission requirement and clarifies pagination behavior ('next preserves filters'), which is useful context beyond the annotations. It does not cover rate limits or error behavior, but those are less critical for a read-only 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?

Three short sentences, front-loaded with the core action and followed by pagination and permission notes. Every sentence adds value with no wasted text.

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 11-parameter filtered list operation with very low schema description coverage and no output schema, the description is incomplete. It covers pagination and permissions but omits nearly all parameter meanings and does not describe what the returned page contains.

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 are 11 parameters with only 9% schema description coverage. The description mentions 'filters' generically but does not explain the meaning of name, limit, offset, vacant, address, orderby, category, portfolioID, publishedForRent, or the date range parameters. This leaves most parameter semantics undocumented.

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 Propertyware buildings.' This clearly distinguishes it from the sibling 'get_building' by implying a collection query, though it does not explicitly name alternative tools.

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

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

It provides pagination guidance ('One page; use next...') and a permission prerequisite, but does not explain when to use this tool versus 'get_building', 'list_units', or other list siblings, nor does it give exclusion criteria.

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 genuinely non-obvious behavior: results are paginated to one page, a `next` cursor continues the result set with filters preserved, and the call requires CONTACTS read permission. It does not describe the shape of returned records or what happens with a `limit`/`offset` versus a `next` continuation.

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 action and scope, no filler. The only cost is that the terse phrasing leaves the pagination mechanism ambiguous (is `next` a request param or a response field?) — brevity at the expense of precision.

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 nine undocumented parameters, no output schema, and no annotations beyond readOnlyHint, the description should explain filtering and return behavior. It covers pagination and permissions but leaves filters, defaults, and result contents entirely unspecified, which is thin for a filter-heavy list endpoint.

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

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

Schema description coverage is 0% across nine parameters, so the description carries the full burden and fails to explain any of them: the type enum values, email/name matching semantics (exact vs partial), orderby syntax, the lastModifiedDateTime range, or the interaction of limit/offset. It instead references a `next` token that does not appear in the schema at all, which can confuse an agent trying to page.

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 Propertyware contacts"), which is clearly distinguishable from the sibling propertyware_get_contact (single record) and the type-specific listers like propertyware_list_vendors or propertyware_list_prospects. It stops short of explicitly naming those alternatives, but the scope 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?

Provides real usage guidance for pagination: one page per call, then follow the `next` token, which preserves filters. It also states the CONTACTS read permission prerequisite. However, it gives no guidance on when to use this versus propertyware_get_contact or the other list tools, and doesn't say the filters can be combined.

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, and the description adds a genuinely useful behavioral fact beyond them: the vendor does not paginate this endpoint, meaning a single call returns the full set. It stops short of describing the note fields or ordering.

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 tight sentences with zero waste; the core purpose comes first and the non-pagination caveat follows. Nothing is repeated 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 simple single-parameter read tool with annotations covering safety and the description covering the pagination quirk, this is nearly complete. The only minor gap is the absence of output schema, leaving note contents/ordering unspecified.

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 parameter and 100% schema description coverage, the schema already explains the numeric ID format and precision rationale. The description only reinforces that the ID refers to a lease, adding marginal 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?

States a specific verb and resource ('Read notes for one Propertyware lease') with clear scope of a single lease, which implicitly separates it from propertyware_list_building_notes. It falls short of 5 only because it never names the sibling it displaces or clarifies the note concept further.

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 retrieving notes tied to a known lease ID. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., list_building_notes, get_lease).

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 two things annotations cannot: the result is a single page (not the full set) and a LEASES read permission is required. What is missing is any statement about response shape, default page size behavior, or what 'next' actually is (token, URL, cursor), which matters since there is no output schema.

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

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

Three short sentences, front-loaded with purpose, no filler. The parenthetical '(preserves filters)' is slightly compressed to the point of ambiguity but does not waste 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?

Given 15 parameters, 20% schema coverage, and no output schema, the description leaves the agent without enough to call it well: no filter semantics, no clarification that 'next' appears in the response, and no note about whether limit/offset or 'next' should be preferred. It is adequate for a bare list call and inadequate for a parameterized, paginated query 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?

Fifteen parameters with only 20% schema description coverage, and the description names none of them. It never explains status values, orderby syntax, the four date-range pairs (endDate/startDate/scheduleMoveOutDate/lastModifiedDateTime with Start/End semantics), or how limit/offset interact with the 'next' mechanism. That is exactly the compensation this tool needs and does not get.

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 Propertyware leases') and implicitly distinguishes itself from the singular sibling propertyware_get_lease by being the paged collection endpoint. An agent can pick the right tool 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?

Gives clear when/what-next guidance for pagination ('use next (preserves filters) for the following call'), which is a real usage rule. It does not contrast with propertyware_get_lease or any other sibling, and says nothing about when to filter versus fetch-then-filter, so the guidance is partial.

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 two genuinely new behavioral facts: results are single-page and continuation must go through a next token that preserves filters, plus a required PORTFOLIOS read permission. It stops short of describing default ordering or what an empty/deactivated portfolio looks like.

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

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

Three short sentences, zero padding, with the core action first and the pagination and permission constraints immediately after. Every sentence adds information an agent needs.

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

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

For a 7-parameter tool with no output schema and no annotation coverage of filtering behavior, the description leaves the entire query surface undocumented. An agent knows it lists portfolios one page at a time but not how to filter, sort, or interpret the results.

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

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

Schema description coverage is 0% across 7 parameters, so the description carries the full burden and largely fails: name, orderby, includeDeactivated, and the two lastModifiedDateTime bounds get no explanation of format or semantics. Only the existence of "filters" is hinted at via the pagination sentence.

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 Propertyware portfolios"), which cleanly distinguishes it from the singular sibling propertyware_get_portfolio. It does not name siblings explicitly, but the list/get split is unambiguous from the names alone.

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 page; use next (preserves filters) for the following call" gives real guidance on pagination continuation, and the permission line sets a prerequisite. However, it never says when to use this versus propertyware_get_portfolio, nor when to reach for filters like includeDeactivated or the lastModifiedDateTime range.

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 useful behavioral context by naming the required PROSPECTS read permission and pagination behavior, but 'next' is not defined in the input schema and no output schema clarifies it.

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

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

The description is short, front-loaded, and wastes no words. It communicates the core action, pagination behavior, and permission requirement in three concise sentences.

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 nine optional filter parameters, low schema description coverage, and no output schema, the description is too sparse. It covers pagination and permissions but omits meaningful guidance on filter parameters and leaves 'next' ambiguous.

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

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

Schema description coverage is only 22%, with descriptions present for buildingID and portfolioID only. The description does not explain type, status, orderby, limit, offset, or date filters, so it fails to compensate for the low coverage and leaves most parameters semantically vague.

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 Propertyware prospects.' This clearly distinguishes it from the singular sibling propertyware_get_prospect, though it does not explicitly name alternatives. The purpose is understandable 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 description gives some usage context: it returns one page, says to use 'next' for the following call, and notes the required permission. However, it does not explain when to use this list tool versus filtering alternatives or the singular get_prospect tool.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds two pieces of genuine behavioral context beyond the annotations: the required UNITS read permission and the fact that results are single-page with a 'next' cursor that preserves filters. It does not describe return shape or default paging size, keeping it from a 5.

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

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

Three short sentences, front-loaded with purpose, then pagination and the permission prerequisite. 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?

For a 10-parameter read tool with 20% schema coverage and no output schema, the description leaves the majority of filter semantics undocumented. An agent can call it, but cannot confidently use most parameters.

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

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

Schema description coverage is only 20% (just the two ID fields), so the description must compensate; instead it is silent on limit, offset, vacant, orderby, publishedForRent, includeDeactivated, and the lastModifiedDateTime range. 'One page' hints at pagination but gives no limit/offset 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 (List) and resource (Propertyware units), distinguishably different from the sibling propertyware_get_unit for single-record retrieval. Clear, but it doesn't explicitly name the sibling or scope beyond 'units'.

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

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

Provides real guidance on pagination: 'One page; use next (preserves filters) for the following call.' However, it never says when to use this list tool versus get_unit, nor when the various filters (vacant, publishedForRent, includeDeactivated) are appropriate.

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 covers the safety profile, and the description adds genuinely new context: single-page return semantics, that filter state carries across pagination, and the required VENDORS read permission. That is exactly the kind of pre-call constraint an agent needs and it does not contradict the annotation. Missing detail on page-size defaults or total-count behavior keeps it off 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 short sentences, each doing distinct work: what it does, how to paginate, and what authorization it needs. The pagination constraint is stated before the permission note, and there is 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 7-parameter, unannotated-beyond-readOnly filter tool with no output schema, the description should at minimum acknowledge that filtering by type/active/modified-date is available. As written, an agent knows it lists vendors and paginates, but not that the request can be narrowed at all — a significant gap given zero schema documentation.

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

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

Schema description coverage is 0% across 7 parameters, so the description carries the entire burden and provides essentially nothing: it never mentions type, active, orderby, limit, offset, or the two lastModifiedDateTime bounds. 'Preserves filters' only implies that filters exist. An agent would have to infer the filter semantics entirely from parameter names.

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?

Specific verb+resource ('List Propertyware vendors') that clearly distinguishes the collection endpoint from the sibling propertyware_get_vendor. It does not explicitly name the sibling, so an agent must infer the list-vs-single distinction from the plural form.

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

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

Gives explicit operational guidance: the result is one page and the following page must be fetched via 'next', which preserves filters. This is a real usage rule rather than a restatement. It stops short of saying when-not to use it or pointing at alternative listing tools, and 'next' is not a declared parameter, leaving a small ambiguity about how that call is made.

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 real value beyond that: it discloses single-page semantics, the `next`-cursor pattern with filter preservation, and the WORKORDERS read permission requirement — all things an agent cannot infer from structured fields.

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, each doing distinct work: identity, pagination behavior, and permission prerequisite. Front-loaded with the verb+resource and 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 an 11-parameter filtered-list tool with no output schema and 18% schema coverage, the description should at minimum sketch the available filter dimensions. Pagination and permissions are well handled, but the filtering surface — the main thing an agent needs to call this correctly — is entirely undocumented.

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

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

Schema description coverage is only 18% across 11 parameters, so the description carries the burden of explaining filters — yet it mentions none of status, priority, buildingID, portfolioID, orderby, or the completed/lastModified date ranges. An agent must read the raw schema and guess at filter semantics with no compensating text.

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 Propertyware work orders"), which cleanly separates it from propertyware_get_work_order and propertyware_list_work_order_tasks by implication. It does not explicitly name those siblings, 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?

The description gives one concrete usage instruction: paginate with `next` to preserve filters, which is genuinely useful. It never says when to use this list versus propertyware_get_work_order or the task-level sibling, so the alternative-selection guidance 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 contributes one genuine behavioral detail — that paging through results preserves the filter set — but says nothing about default page size (100), maximum limit (500), or which filters exist, leaving most of the read behavior unstated.

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 states the purpose first, with no filler or repetition. The second clause is compressed to the point of ambiguity ("next" is undefined), which slightly undercuts an otherwise efficient 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?

With 8 parameters, 13% schema coverage and no output schema, the description needs to carry filter and pagination semantics but delivers one line. It omits sorting, date-range filters, completion filtering, and even whether the response envelope supports the referenced "next" cursor.

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

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

Schema description coverage is only 13%; only workOrderId is documented in the schema and the description adds nothing to it. Seven parameters — limit, offset, dueDate, completed, orderby, and the lastModifiedDateTime range — are undocumented in both places, so an agent must guess their semantics and interactions.

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 verb+resource is specific ("List tasks on one work order") and scopes the call to a single parent record, which distinguishes it from propertyware_list_work_orders. It does not explicitly contrast with propertyware_create_work_order_task or the get_* siblings, so differentiation is implicit rather than stated.

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

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

There is no when-to-use guidance or statement of prerequisites beyond the one-work-order scoping. The trailing clause about "next" hints at pagination but never names an alternative tool or a condition that would select it.

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