EZRentOut MCP by usefulapi

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so safety is covered. The description adds the HTTP endpoint (POST /assets/<ASSET#>/comments.api.), which confirms the write path, but it says nothing about comment attribution behavior, permissions, or whether comments can later be edited or removed.

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 filler; the action is front-loaded and the endpoint follows as supporting detail.

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 low-complexity mutation tool with full schema coverage and annotations, this covers the essentials. However, it omits useful behavioral context such as how asset stock and inventory item numbers map to the asset comments endpoint, and whether the optional created_by_id causes attribution changes.

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 three parameters are already documented in the schema. The description adds no extra meaning about asset_number formats, content limits, or optional created_by_id usage, 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 (Add) and resource (comment) and broadens scope to asset, asset stock, or inventory item. It is easily distinguished from the sibling read operation ezrentout_list_asset_comments.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as listing existing comments. The purpose implies the use case but the description never helps the agent choose this tool over a sibling.

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, idempotentHint=false, destructiveHint=false, so the mutation profile is covered. The description adds the endpoint (PATCH to a basket) and the bundle line-item convention, but says nothing about whether assets are appended vs. replaced, whether inventory availability is validated, or how conflicts with already-booked items are handled.

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

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

Two sentences, front-loaded with the action and the order scope, zero filler. The raw HTTP endpoint in the second sentence is marginal value for an agent but conveys PATCH semantics and the basket resource, so it isn't pure noise.

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 two-parameter write into an order basket, the definition covers the identity of the operation and the bundle syntax, and annotations carry the safety profile. It is still thin on consequences: no statement of success/failure conditions, inventory reservation behavior, or what the caller gets back (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 description coverage is 100%, so both parameters are already documented in the schema. The description's '<id>-b' bundle note duplicates what the asset_numbers schema description and pattern already say, adding no new semantics; 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: adding assets (including bundles as '<id>-b') into an *existing* order. That scope word 'existing' is what separates it from create_order or book_order. It never names those siblings explicitly, so differentiation requires the agent to infer from the sibling list.

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?

Implies the precondition that the order must already exist, which is useful context. But it gives no guidance on when to use this rather than book_order, rent_out_order, or add_order_custom_entry, and no note about what state the order must be in (open vs. booked) for additions to succeed.

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 the mutation profile (readOnly=false, destructive=false, idempotent=false), so the bar is lower. The description still adds real value by disclosing the side effect that it 'raises the order total' and the order-state restrictions, plus the underlying endpoint. It does not say whether calling twice creates duplicate entries, which matters given idempotentHint=false.

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 compact clauses: what it does and the total impact first, then the state restrictions, then the endpoint. No filler, and the most decision-relevant facts are 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 5-parameter mutation with no output schema, the description covers purpose, side effect, and eligibility constraints. It leaves open the return value and duplicate-entry behavior, but the schema fully documents every parameter, so nothing blocking remains.

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

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

Schema description coverage is 100%, so the baseline is 3. The description illustrates the name/amount pair via the delivery-fee example, but says nothing about tax_free or comments, so it adds little beyond the schema's own per-field documentation.

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

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

States a specific verb and resource ('Add a custom line ... to an order') and immediately clarifies what a custom line is with a concrete example (a delivery fee). This distinguishes it cleanly from sibling mutators such as add_assets_to_order, which attach inventory rather than arbitrary named amounts.

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 excludes orders in sold, void, completed or cancelled states, which is the key precondition an agent must check before calling. It stops short of naming an alternative tool (e.g. add_assets_to_order for real inventory) or telling the agent how to verify order status first.

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

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

The description usefully discloses a side effect that annotations do not: EZRentOut may notify the customer depending on account settings. The annotations already flag destructiveHint=true, but the description does not state what a booking changes, whether it is reversible, or what happens if assets are unavailable for the requested period.

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 tight sentences with the purpose front-loaded, followed by the behavioral caveat and the endpoint. Nothing is padding; even the endpoint aids debugging.

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 5-parameter mutation tool with no output schema, the description covers what it does and the notification side effect. It does not cover the resulting state change, failure modes (e.g., assets already reserved), or the response, so the definition is 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 coverage is 100%, so the schema already documents every parameter: date formats, time formats, and the order number. The description adds no further detail on date ranges, time zones, or how from/to combine with from_time/to_time, so this is the 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 gives a specific verb and resource: "Reserve an order's assets for a period (books the order)", plus the underlying endpoint PATCH /baskets/<ORDER#>/reservation.api. However, there is no differentiation from close siblings such as ezrentout_rent_out_order, ezrentout_create_order, or ezrentout_add_assets_to_order.

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 guidance on when to use this tool instead of ezrentout_rent_out_order or ezrentout_create_order, and none on prerequisites such as what state the order must be in or whether the assets need to be available. An agent must infer this 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?

Annotations already declare destructiveHint=true, and the description adds real value beyond that: it discloses the downstream side effect that associated assets may become available again, plus the concrete PATCH endpoint. It stops short of stating whether completion is reversible or what happens on repeat calls.

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 clauses, front-loaded with the action and its consequence, followed by the endpoint. Every sentence carries information and nothing is padded.

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

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

For a one-parameter mutation with no output schema, the description covers purpose, side effect on assets, and the HTTP endpoint. It omits error behavior (e.g. already-complete) and any note on irreversibility, which would make it fully 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?

Only one parameter and schema coverage is 100%, so the schema already fully documents work_order_number, including its accepted formats. The description only echoes the parameter inside the endpoint path; 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?

Specific verb+resource ("Mark a work order complete") that is inherently distinguishable from siblings like start_work_order, create_work_order, and get_work_order. It does not explicitly name or contrast with those siblings, but the operation 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 implied by the verb and the note that assets may become available again hints at when the effect matters. There is no explicit when-to-use vs. alternative guidance, no prerequisites, and no statement about what to do if the work order is already complete.

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 non-read-only, non-idempotent, non-destructive, so the safety profile is covered, and the description adds the concrete endpoint (POST /customers.api) and the order-scope caveat. However, it does not disclose anything about duplicate-email handling, auth requirements, or what is returned on success.

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 earning its place: the action, the requirement, and the scope boundary. The key constraint is front-loaded with no filler.

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

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

For a 10-parameter mutation with no output schema and idempotentHint false, the description is adequate but thin: it never explains whether a duplicate customer is created or how to recover the new customer's ID, which an agent calling this really needs.

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 schema already marks first_name and last_name as required, so the description's note about the required names is redundant. It adds no format or constraint 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 the specific verb and resource ('Create a customer') and defines what a customer is ('a person who rents'), which disambiguates it from order and work-order creation. The added 'Does not create an order' clause explicitly separates it from the create_order sibling.

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

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

It gives a useful boundary ('Does not create an order') and states the required fields, but never says when to use this versus list_customers/get_customer or search_member_by_email, nor what to do if the customer already exists. Usage 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 non-read-only, non-idempotent, non-destructive. The description adds real behavioral value beyond that: the result is a draft, no rental or charge occurs, and the backing endpoint (POST /baskets.api) is disclosed. It omits what happens on duplicate calls, which matters given idempotentHint=false.

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

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

Four tight sentences: what it creates and its state first, the conditional parameter second, the negative scope third, the endpoint last. No filler and the most decision-relevant facts are 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 7-parameter creation tool with no output schema, the description covers scope, draft state, and side-effect exclusions well. It does not say what the call returns (presumably the new order id), which is the main remaining gap since 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 description coverage is 100%, so the baseline is 3. The description only adds a conditional hint for business_id ('If the customer belongs to several businesses'), which closely mirrors the schema text, and gestures at optional assets and dates without new syntax 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 ('Create a new rental order') plus the lifecycle state it lands in ('a draft until it is booked or rented out'). This cleanly separates it from sibling tools like book_order, rent_out_order, and record_order_payment.

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 frames when to use it (customer with optional assets and dates, business_id when the contact spans businesses) and when not to: 'Does not rent anything out and does not charge.' It stops short of naming the sibling that does those things, so the agent must infer book_order/rent_out_order.

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 safety profile is covered; the description earns credit for disclosing a real side effect beyond annotations — linked assets are marked unavailable and cannot be rented while the work order is open — plus the underlying POST endpoint. It stops short of describing failure modes (invalid task_type, unknown asset numbers).

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

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

Two sentences, front-loaded with the operation and required fields, followed by the side-effect caveat and endpoint. No redundant field enumeration; only marginal content ('POST /tasks.api') that some agents won't need.

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 mutation tool with no output schema, the description covers inputs and the key side effect but never indicates what the caller gets back (e.g., a work order identifier needed to chain into ezrentout_start_work_order or ezrentout_complete_work_order). That return-value gap is the main incompleteness.

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

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

Schema description coverage is 100%, so the schema already carries title, due_date format, priority enum, task_type source, and the mark_items_unavailable default semantics. The description adds only the optionality of assets and repeats the unavailability default, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Create a work order') and names the three required inputs plus optional asset linking, which clearly separates it from read-side siblings like ezrentout_get_work_order and ezrentout_list_work_orders. It does not explicitly distinguish itself from the other state-changing siblings (ezrentout_start_work_order, ezrentout_complete_work_order), but 'create' vs 'start'/'complete' is reasonably inferable.

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 field-level requirement that task_type come 'from ezrentout_list_work_order_types', which is a useful prerequisite hint. However, the description never states when to use this versus ezrentout_start_work_order or ezrentout_complete_work_order, nor does it say what must exist beforehand (assets, work order types).

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 low. The description adds the GET /assets/filter.api endpoint, a clarification that checked_out means currently rented out, and per-filter parameter requirements — real behavioral context. It says nothing about pagination or result shape, leaving return behavior to the schema/sibling conventions.

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 compact sentences plus an endpoint reference, with the core operation front-loaded. The status enumeration largely duplicates the schema enum, but it earns its place as the filter menu an agent must choose from.

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 filtered-list tool with a fully documented 4-parameter schema and no output schema, the description covers what to filter on, what the filter values must be, and the underlying endpoint. Only the relationship to the sibling list/search tools is absent.

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 baseline would be 3, but the description goes further: it explains that filter_param_val is needed for group/location/user/email/model/order filters, that availability_range takes two dates joined by '~', and that five statuses need no value. That is meaningful semantics the schema does not encode.

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?

It states the resource (assets) and the discriminating operation (filtering by a status enum) and reproduces the enum values, so an agent knows exactly what the tool returns. It does not name or contrast with the obvious alternatives (ezrentout_list_assets, ezrentout_search_assets), so the purpose is clear but sibling differentiation is left implicit.

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 useful conditional guidance on which filters require filter_param_val and which do not, which is genuine usage help. It never says when to choose this over ezrentout_list_assets or ezrentout_search_assets, so the routing decision 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?

readOnlyHint=true already tells the agent this is a safe read, so the burden is lower. The description adds value by naming the underlying endpoint (GET /assets/<ASSET#>.api) and roughly what fields are returned, but gives no auth requirements, error behavior, or detail on what 'details' means.

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 clause that leads with the resource and scope, backed by the endpoint. It is a sentence fragment rather than prose, but 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?

For a simple single-record read with fully documented parameters and no output schema, the description covers what is fetched and what optional extras exist. Only marginal gaps remain (no field-level return detail, no error/missing-asset 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 coverage is 100%, including the asset_number pattern and a pointer to ezrentout_list_assets, so the schema carries the parameter semantics. The description only echoes that service details and custom fields are optional inclusions, adding little beyond what the booleans already say.

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 ('One fixed asset by its asset number') and enumerates what comes back (details, group, location, status, rental prices). It implicitly distinguishes itself from the plural siblings (list_assets, filter_assets, search_assets), though it never names 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: fetch a single asset when you already have its asset number. There is no explicit guidance about when to use this versus get_asset_history, get_asset_booked_dates, get_asset_stock, or search_assets, and no prerequisites 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, so the description carries a lighter burden. It adds that the same endpoint answers for assets, inventory items, and asset stock, which is meaningful behavioral scope, but says nothing about return shape, date formatting, or whether past and future bookings are both included.

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 purpose front-loaded and no filler. The raw endpoint path 'GET /assets/<ASSET#>/booked_dates.api' is of marginal value to an agent that already has a typed schema, but it is harmless and compact.

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 this is close to sufficient, and annotations cover the safety profile. However, with no output schema, the description should say what the returned dates look like (list of date pairs? ranges?), which it leaves 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?

Schema coverage is 100%, so the schema already documents asset_number as the Asset# and enforces its type/pattern. The description adds a small but real clarification that this ID may refer to an asset, an inventory item, or asset stock, which goes beyond the schema's 'item number' phrasing. Baseline 3 applies.

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

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

The description names the resource (booked/reserved dates) and the entity it applies to (asset, inventory item, or asset stock), so an agent knows exactly what it retrieves. It does not contrast with neighbors such as get_asset_history or get_asset, which is the only thing keeping 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?

There is no statement of when to call this versus alternatives, no prerequisites, and no mention of what the date range or output covers. The agent has to infer usage entirely from the one-line purpose.

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 the safe-read nature. The description adds useful behavioral detail by saying the history includes check-in/check-out and change events and is paginated at 5 entries per page, but it does not discuss permissions, time coverage, or return shape.

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

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

The description is two short sentences with the core purpose front-loaded and no wasted language. The endpoint reference is compact and does not obscure the main point.

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 tool with full schema coverage and a readOnlyHint, the description covers what the tool returns conceptually and notes pagination size. It could be stronger by mentioning the entry fields or time scope, but it is adequate 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 both parameters are already documented. The description adds one useful detail not in the schema: the page size of 5 entries, but it does not otherwise enrich parameter meaning.

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

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

The description clearly identifies the resource and content: the check-in/check-out and change history of one asset. It is distinguishable from most siblings by the asset-history scope, but it does not explicitly differentiate itself from related history or asset-detail tools such as get_inventory_history or get_asset.

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 phrase 'history of one asset,' but the description gives no explicit when-to-use guidance or alternatives. It does not say, for example, to use get_asset for current details or get_inventory_history for inventory-level history.

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

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

The readOnlyHint annotation already establishes that this is a safe read, so the description only needs to add context — but it adds almost none beyond restating the endpoint path. It says nothing about behavior when the number does not exist (error vs empty), whether auth/permissions are required, 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 terse fragments with zero filler and the key qualifier ('one ... item by number') front-loaded. It is arguably too terse rather than bloated, but every word earns its place.

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

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

For a simple single-record read with full schema coverage and no output schema, the description is minimally sufficient. It is missing the disambiguation from ezrentout_get_asset and any note about missing-record behavior, which are the remaining gaps an agent would need.

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

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

Schema coverage is 100%, so both parameters are fully documented in the schema; the description's 'by number' merely restates asset_number. It adds no meaning for include_custom_fields or for accepted number formats beyond what the schema's pattern already specifies, so the baseline 3 applies.

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

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

The description states a specific resource — a single asset stock item retrieved by number — and even cites the underlying endpoint, so the singular-fetch semantics are explicit. However, it does not differentiate this from the similarly named sibling ezrentout_get_asset or from ezrentout_list_asset_stock, leaving the agent to infer when 'stock asset' differs from 'asset'.

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 when-to-use guidance, no mention of prerequisites, and no pointer to alternatives such as ezrentout_list_asset_stock or ezrentout_filter_assets. The agent must infer usage 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?

readOnlyHint=true already covers the safety profile, so the description's added value is the return shape ('with its items') and the underlying endpoint, which matters since no output schema exists. It stops short of describing error behavior for missing bundles.

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 clauses with zero filler: operation and return content first, endpoint second.

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 with no output schema, telling the agent the response includes the bundle's items is the key missing piece it supplies. Only a note about not-found behavior 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?

Schema coverage is 100% for the single bundle_id parameter, which the schema already describes. The description only echoes placement in the REST path (GET /bundles/<BUNDLE#>.api), adding no format or range nuance 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-less but unambiguous operation: fetch a single bundle by id, including its items. It is clearly a single-record read, distinct from list_bundles, though it never names the 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?

Usage is only implied by 'One bundle by id' and the required bundle_id. There is no explicit statement of when to choose this over list_bundles or other get_* tools, nor any note on handling invalid/unknown ids.

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 only needs to add context — but it adds almost nothing beyond restating the endpoint. It says nothing about behavior when the id does not exist (error vs empty), nor about what fields come back, 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?

Two terse fragments, front-loaded with the resource and scope; nothing is padded. The endpoint path is marginal but does confirm the method is a GET.

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 this is close to adequate, but with no output schema the description could at least indicate the shape of a returned business record or the not-found behavior. It is 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 business_id parameter is documented with its source (ezrentout_list_businesses). The description's "by id" and "<BUSINESS#>" only echo that, so the baseline of 3 is appropriate.

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

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

The phrase "One business customer by id" names the resource and makes the singular scope explicit, which separates it from the list_businesses sibling. It stops short of a full verb phrase ("retrieve a single business record"), but the 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?

There is no statement of when to use this versus ezrentout_list_businesses, ezrentout_get_business_contact, or the other get_* siblings; the only routing hint (the id comes from list_businesses) lives in the schema, not the description. An agent must infer that this is the single-record lookup path.

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, but the description adds almost nothing beyond the raw endpoint path. It says nothing about behavior for a missing/invalid id, permissions, or rate limits.

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

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

Two short fragments with the resource and scope front-loaded; nothing is padded. It is borderline terse rather than wasteful, and the raw HTTP path is the least useful sentence.

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?

There is no output schema, so the description is the only place the return shape could be described, and it says nothing about what a contact record contains or how errors surface. For an otherwise simple one-param read this leaves 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 100%, and the schema already documents contact_id as coming from the list tool plus its integer/string format. 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 the resource (business contact) and a single-record scope ('by id'), which distinguishes it from ezrentout_list_business_contacts. The verb is only implied ('One business contact by id') rather than stated, and no sibling is named in the description 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?

No explicit when-to-use guidance or exclusions. The agent must infer from 'by id' that this is the single-record counterpart of the list tool, and the schema's parameter note ('from ezrentout_list_business_contacts') is the only routing hint.

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 by enumerating the returned fields and citing the underlying REST endpoint (GET /customers/<CUSTOMER_ID>.api), which tells the agent the response is a single object, not a collection. Missing are error behaviour for unknown ids and any note on expandable/nested sub-resources (e.g. whether addresses are inline or require list_customer_addresses).

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 fragments, front-loaded with the cardinality plus resource and followed by the payload summary; every token carries information and there is no preamble or repetition.

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

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

For a one-param read tool with annotations covering safety and no output schema, the field enumeration in the description effectively substitutes for a return-value spec. It would be complete at 5 if it noted the not-found behaviour or clarified whether addresses/custom fields are inline versus requiring separate calls.

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 param already documents both the type (integer or numeric string) and its provenance ("from ezrentout_list_customers"). The description's "by id" adds nothing beyond that, so the schema is doing all the work – the 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?

"One customer by id" is a specific verb+resource with an explicit cardinality, which separates it from the many list_* siblings without naming them. It also enumerates the returned fields (name, email, phone, addresses, status, custom fields), so an agent knows exactly what it gets back. It stops short of naming the alternative (ezrentout_list_customers / search_member_by_email) explicitly.

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

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

Usage is only implied: you need a customer_id, and the sibling list of tools makes clear this is the single-record counterpart to ezrentout_list_customers. There is no explicit "use this when you already have an id, use list_customers when you don't" statement, and no mention of what happens when the id is unknown.

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 a safe read, so the bar is lower; the description adds that the payload is a list of movement records of three types, which is real context given there is no output schema. It says nothing about pagination behavior at the description level or whether data is scoped to current location, so the addition 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 with the purpose front-loaded and no filler. The trailing HTTP path adds little for an agent selecting the tool, 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?

For a two-parameter read tool with a fully documented schema and readOnlyHint, the essentials are covered. The notable gap is disambiguation from the crowded stock/asset-history sibling set, which the description never addresses.

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 both parameters are documented in-schema (page with default/next-page guidance, asset_number format). The description's <ASSET#> notation merely echoes the required parameter without adding format or constraint detail, 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: returns the stock movements of one inventory item, with the movement kinds enumerated (added, sold, transferred). It does not, however, distinguish itself from near-siblings like get_asset_history, get_asset_stock, or list_asset_stock, leaving the agent to guess which history/stock tool applies.

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, no prerequisites, and no named alternative despite several overlapping sibling tools (get_asset_history, get_asset_stock, list_asset_stock). The agent must infer selection from the tool 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that stock is included in the response and cites the underlying endpoint (GET /inventory/<ASSET#>), but says nothing about behavior on a missing/invalid asset number or about the shape of what comes back.

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 fragments with zero padding, and the core purpose is front-loaded before the endpoint reference. The endpoint string is arguably filler since the agent cannot use it, but it 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?

There is no output schema, so the description carries more burden than a thin read tool normally would; it only tells the agent that stock is included, not what other fields the item record contains (e.g., custom fields). Adequate to call correctly, but not fully informative about the result.

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 both asset_number and include_custom_fields are already documented in the schema. The description reinforces the item-number identifier but adds no meaning beyond the schema, and it never mentions the custom-fields flag.

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: retrieves a single inventory item by item number, including its stock. This distinguishes it from list_inventory and search_inventory, though it doesn't differentiate itself from get_asset or get_asset_stock, which sound like near-neighbors.

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 instead of list_inventory, search_inventory, get_asset, or get_asset_stock. The agent must infer the selection rule purely from the tool name and the one-line purpose.

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 description carries a lower burden; however it adds almost nothing beyond that. The raw endpoint template (GET /locations/<LOCATION#>.api) is marginal value, and there is no mention of behavior when the id is unknown, what is returned, or any access requirements.

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?

It is short and front-loaded with the purpose, but the second sentence (the HTTP path template) earns little for an agent that never needs the raw route, while guidance that would matter is absent. Brevity here tips into under-specification.

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 with full schema coverage and a readOnly annotation, the basics are covered and no output schema needs explaining. Still missing is sibling routing (list vs single fetch) and failure behavior for a bad id, which an agent would want.

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 in-schema, so the baseline is 3. "By id" in the description merely restates the parameter without adding format, range, or lookup 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?

"One location by id" states a specific verb (retrieve) and resource (location) plus cardinality, and the endpoint template reinforces it as a single-record fetch. It does not name any sibling, but the word "one" implicitly contrasts with list_locations.

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 guidance on when to call this versus list_locations or get_location_quantities, and no statement of prerequisites. The only hint is "by id", leaving the agent to infer that it needs an id already in hand.

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 communicates that this is a safe read operation. The description adds useful scope by naming the item types covered and includes the raw endpoint path, but it does not explain the response structure or any access constraints.

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

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

The definition is two compact sentences with the key scope statement front-loaded. The endpoint path is moderately useful but slightly technical overhead; overall it is efficient with no wasted prose.

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 tool with read-only annotations, the description provides enough to invoke it correctly. However, with no output schema, it does not describe the return shape or the distinction from similar quantity-related siblings.

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

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

Schema description coverage is 100%, so the single location_id parameter is already fully documented by the schema. The description only reinforces that the operation applies to one location and adds no further format or constraints 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 clearly states the resource and scope: quantities of every asset, asset-stock, and inventory item at one location. It is specific enough to identify the operation, but it does not differentiate from the similarly named sibling ezrentout_get_quantity_by_location.

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 alternatives such as ezrentout_get_quantity_by_location, ezrentout_get_asset_stock, or ezrentout_get_location. Usage must be inferred from the name and description 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?

readOnlyHint=true already establishes the safety profile, so the description only needs to add operational context, and it does: it discloses exactly which data domains come back plus the underlying endpoint GET /baskets/<ORDER#>.api. It does not mention error behavior for an invalid/unknown order number, which is the main remaining gap.

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

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

Two compact sentences, front-loaded with the resource and scope, then the payload contents. The trailing endpoint is slightly jargon-heavy but is short and informative rather than 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?

There is no output schema, so the description carries the burden of telling the agent what comes back, and it does so by listing the main field groups. Combined with a fully documented single required parameter and readOnly annotations, only failure-mode behavior is unaddressed.

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 already documents order_number, its integer-or-numeric-string forms, and its source. The description adds nothing beyond repeating 'by its order number', 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?

States a specific verb and resource ('One order by its order number') and enumerates the returned content (customer, status, dates, line items, sub-rents, totals, payments). The singular 'One order' implicitly contrasts with ezrentout_list_orders but does not name it, so the sibling differentiation is only suggestive 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?

Usage is implied by the schema note 'from ezrentout_list_orders' and by the singular scope, but the description itself gives no when-to-use/when-not guidance or mention of near-neighbors like ezrentout_get_order_history. An agent can infer the pattern, but nothing 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, so the description owes additional context — but it only restates the title and appends the raw endpoint GET /baskets/<ORDER#>/history.api. Nothing is said about what a history entry contains, whether results are paginated or bounded, or whether check-ins and check-outs are separate records.

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 purpose is front-loaded ahead of the endpoint reference. Slightly terse to the point of being a fragment, but 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?

No output schema exists, so the description carries the burden of explaining the return shape — yet it never says what the history consists of (event list, timestamps, quantities, ordering) or how large it may be. For a tool whose whole value is the returned history, that is 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?

With one parameter at 100% schema description coverage, the schema already defines order_number including its integer-or-numeric-string pattern. The description adds only the '<ORDER#>' placeholder, which duplicates the schema; 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 resource and scope: the check-out/check-in history of a single order, which separates it from ezrentout_get_order (order details) and ezrentout_get_asset_history (asset-centric). It doesn't explicitly name those siblings, but the resource is unambiguous.

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

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

There is no guidance on when to use this versus ezrentout_get_order or ezrentout_get_asset_history, nor any prerequisites. The only implied usage comes from the words 'one order', leaving the agent to infer routing from the tool 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?

readOnlyHint=true already tells the agent this is a safe read. The description adds only that the response includes line items, plus the raw HTTP path, which is implementation detail rather than behavioral context. Nothing about not-found handling, permissions, or response shape beyond the brief 'with its items'.

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?

Extremely short and front-loaded with the payload description. The trailing 'GET /purchase_orders/<PO#>.api' is marginally redundant with the name but does not bury the key 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 no output schema, the description ideally would say something about what an order record and its items contain, and what happens if the PO number is invalid. 'With its items' hints at the structure but the return payload remains largely 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?

Schema coverage is 100% and the single parameter is fully documented with a pattern constraint, so the schema does the heavy lifting. The description's '<PO#>' mirrors the schema without adding format or example 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?

The description names the specific resource ('One purchase order with its items'), which implicitly contrasts with the sibling list_purchase_orders by emphasizing a single record. It is clear what the tool returns, though no explicit verb is stated in the description itself (the title carries 'Get').

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 versus ezrentout_list_purchase_orders or other get_* siblings, and no stated preconditions (e.g., the PO must exist). 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?

The annotations already declare readOnlyHint=true, and the description reinforces this by naming a GET endpoint. However, it adds no further behavioral context such as response format, error conditions, or permission requirements. With annotations covering the safety profile, this is minimally 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?

The description is two short fragments, front-loading the resource description and then the endpoint. It is efficient, though the endpoint path is of limited value to an agent that already knows the tool name.

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 two-parameter read tool with full schema coverage and a readOnly annotation, this is nearly complete. The main minor gap is that the description does not explicitly say what is returned — presumably a quantity — but the phrase 'The stock of...' strongly implies it.

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 both asset_id and location_id are already documented, including the useful pointer that location_id comes from ezrentout_list_locations. The description adds no parameter syntax or format details, so baseline 3 is appropriate.

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

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

The description states a specific resource state — the stock of an inventory or asset-stock item at one location — which maps directly to the tool name. It does not differentiate from related siblings such as ezrentout_get_location_quantities or ezrentout_get_asset_stock, 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?

There is no guidance on when to use this tool versus alternatives like ezrentout_get_location_quantities or ezrentout_get_asset_stock. The endpoint path is present, but the agent is left to infer the selection context.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description's burden is low. It adds the underlying endpoint path (GET /members/<USER_ID>.api), which is mildly useful for debugging, but says nothing about response shape, error behavior for missing ids, or permissions.

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 fragments with zero filler and the core purpose front-loaded. It is efficient, though so compressed that it reads like a docstring stub rather than guidance.

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 readOnly annotation, only lightweight description is required. Still, there is no output schema, so the description could have noted what a user record contains or how a missing id behaves; that gap leaves it merely adequate.

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 already documents that the id comes from ezrentout_list_users and accepts either an integer or numeric string. The description adds no meaning 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 resource and retrieval semantics ('One user by id'), which is clearly distinguishable from the sibling ezrentout_list_users. It omits an explicit verb like 'fetch' and only implies single-record retrieval via 'One user', but the 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: a single-record fetch from an id that the schema says comes from ezrentout_list_users. There is no explicit statement of when to prefer this over list_users or search_member_by_email, which are adjacent lookups an agent might confuse it with.

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

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

Adds genuinely non-obvious behavior beyond the annotations: the vendor API exposes this read via PUT, and the endpoint/pagination shape is given. That prevents an agent from treating the PUT as a mutation, and it does not contradict readOnlyHint=true.

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 what is returned, then the API quirk. Nothing is redundant, though the endpoint notation is a little dense.

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?

No output schema, but the description says what is returned and the page parameter documents the total-pages convention, so an agent has enough to call and paginate. A note on item_type defaults or resulting item shape would complete it.

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 baseline is 3, but the description adds routing detail the schema cannot convey: page is a query parameter while item_type travels in the form body, which matters for constructing the request.

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/scope: 'the assets currently checked out to one user'. That is clearly distinct from the asset-listing siblings, though no sibling is named explicitly as an alternative.

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

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

Usage is only implied by the per-user scope; there is no statement of when to prefer this over e.g. list_assets or search_assets, nor any prerequisite.

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 description owes added context: what happens for an unknown work order number, whether soft-deleted/closed work orders are returned, or any pagination/expansion behavior. Instead it only restates the HTTP endpoint (GET /tasks/<Work_Order#>.api), which adds no decision-useful information for 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?

Two short fragments, front-loaded with the core purpose. The endpoint path in the second sentence is questionable value but costs little 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?

A one-parameter read-only lookup with full schema coverage and no output schema is nearly self-explanatory; annotations cover safety. Only the not-found/closed-record behavior is left unstated, which is a minor gap for a tool this simple.

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 already documents 'The work order number' with an integer-or-numeric-string pattern. The description adds nothing beyond 'by number', 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 fragment 'One work order by number' states both the verb (retrieve exactly one) and the resource (work order), and the singular 'One' implicitly distinguishes it from list_work_orders and the sibling create/complete/start work-order tools. It is terse but an agent can tell what the tool returns 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?

There is no when-to-use statement, no prerequisites, and no named alternative. The agent must infer from 'One ... by number' that this is the single-record lookup versus list_work_orders. That inference is easy but not 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 declares the safety profile, so the description's burden is lower. It adds genuinely new behavioral detail not in the schema — a 25-per-page cap — plus the underlying endpoint, but says nothing about ordering or what a comment 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 page size and the user filter. The trailing raw endpoint path (GET /assets/<ASSET#>/comments.api) is marginal value but small enough not to hurt readability.

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

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

With a fully described 3-parameter schema and no output schema, the definition is workable but thin. It never characterizes the returned comments (fields, ordering, how pagination terminates), which matters when there is no output schema to fall back on.

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

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

Schema coverage is 100%, so all three parameters are already documented, including the 1-based page semantics and the created_by_id filter. The description's only added value is the 25-per-page figure, which is baseline-plus rather than a real semantic gain.

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 resource (comments) and scope (one item, optionally one user), which is enough to separate it from the sibling ezrentout_add_asset_comment and the broader list_* tools. It doesn't explicitly name a sibling or contrast with one, 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?

Usage is only implied: you need an asset number and may narrow to a single user. There is no explicit statement of when to use this versus ezrentout_get_asset_history or other per-asset reads, and no exclusions or 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 establishes the safety profile. The description adds genuinely useful context not in the annotations: the fixed page size of 25 and that each item carries group, location, and status. It does not mention ordering, total counts, or limits beyond the paging note in the 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?

A single tight sentence front-loads the resource, the clarification of what an asset is, and the payload fields; the endpoint suffix is compact. No wasted clauses, though the trailing 'GET /assets.api' is marginal value for an agent.

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, zero-required-parameter read with full schema coverage and readOnlyHint, the description covers what is returned and how results are paged. Absent an output schema, it could say more about the response envelope (e.g., total pages), but the essentials are present.

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

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

Schema coverage is 100% with clear per-parameter text for page and both boolean toggles, so the baseline of 3 applies. The description's '25 per page' reinforces the page parameter but adds no syntax or format 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?

States a specific verb and resource and disambiguates 'assets' as individually tracked rental items, plus names page size and endpoint. It does not distinguish itself from siblings like filter_assets, search_assets, or list_assets_in_service, so an agent must infer that this is the unfiltered 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: the bare 'list' verb suggests fetching everything, while siblings handle filtering and searching. No explicit when-to-use or when-not-to-use statement is provided, and the alternative tools are never 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, so the safety profile is covered. The description adds useful context beyond that: a fixed page size of 25 per page and the exact default filter (for_service=true, status=assets_being_serviced), which tells the agent this is a scoped read rather than a general asset listing.

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 compact sentences, front-loaded with the scope and pagination. The raw endpoint string is somewhat technical noise but still reinforces the filter semantics, so it earns most of its 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 read-only, zero-required-parameter listing tool with fully documented schema and no output schema, the description supplies the scope, page size, and default filter needed to call it correctly. Remaining gaps (exact return fields) are acceptable given no output schema must be explained.

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 each parameter is already documented. The description reiterates that service_type and service_state narrow results and confirms pagination, but adds no format or syntax detail beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific resource (assets currently in maintenance/being serviced) and explicitly encodes the underlying filter scope (for_service=true, status=assets_being_serviced), which sets it apart from the broad list_assets and filter_assets siblings. It doesn't explicitly name those siblings, keeping it just short of a 5.

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

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

It says the tool returns assets in service and can be optionally narrowed by type or state, but gives no guidance on when to prefer this over list_assets, filter_assets, or search_assets. The agent must infer the choice from the tool 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely useful behavioral detail: fixed 25-per-page pagination and the underlying endpoint (GET /stock_assets.api). No auth or return-shape detail, but for a read-only list tool this is solid added 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?

Two compact clauses that front-load the purpose and then the pagination/endpoint facts. No filler; every element earns its place.

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

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

For a read-only, two-parameter list tool with full schema coverage and no output schema, the description covers purpose, pagination, and endpoint adequately. It could briefly note what each returned item represents, but that is 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%, with both 'page' and 'include_custom_fields' fully documented in the schema. The description's '25 per page' complements the page parameter but adds no other parameter semantics, so the baseline of 3 is appropriate.

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

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

Clear verb ('List') and resource ('asset stock'), with a parenthetical clarifying that these are bulk items tracked by quantity per location. This distinguishes it from ezrentout_list_assets (individual assets), though it doesn't explicitly name that sibling. The purpose is unambiguous but sibling routing is only implied.

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

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

The description implies this is a paginated listing operation, but gives no explicit guidance on when to use it versus ezrentout_get_asset_stock (single lookup) or ezrentout_list_inventory/ezrentout_search_inventory. Usage context is inferred from the name 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?

readOnlyHint=true already declares the safety profile, so the description only needs to add context. It contributes the 25-per-page batch size and the endpoint hint, but says nothing about ordering, auth requirements, or what happens at the last page.

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 fragments, no waste, with the resource definition and pagination fact front-loaded. Nothing could be removed 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?

A simple single-parameter read tool with no output schema and full schema coverage does not need much description. The only meaningful gap is that return shape beyond pagination is not hinted at, which is acceptable at this complexity.

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 page parameter is fully documented in the schema, including the 1-based indexing and how to advance pages. The description's '25 per page' is a small reinforcement but adds little 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 the resource (bundles) and defines it parenthetically as items rented together, plus the page size. The 'list' verb is carried by the name/title rather than the description text, and it never explicitly contrasts with the sibling ezrentout_get_bundle, but the intended operation 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 no when-to-use guidance and no exclusions. An agent must infer that this is the paginated enumeration path versus ezrentout_get_bundle for a single bundle, or the many other list_* siblings.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds the endpoint path and clarifies that the result concerns shipping/billing addresses, but it does not describe auth needs, rate limits, or response behavior. 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?

The definition is two short fragments and front-loads the resource being returned. The endpoint path is useful but slightly redundant; overall it is efficient with no filler.

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

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

For a simple read-only list tool with complete parameter schemas and no output schema, the description is adequate but minimal. It does not mention the response envelope or pagination, though the page parameter schema partially compensates by explaining total pages.

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

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

Schema description coverage is 100%, with both business_id and page fully documented in the schema. The description does not add meaning beyond the schema and effectively relies on it for parameter interpretation, which is the correct baseline.

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

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

The description clearly identifies the resource as a single business's addresses and adds that they are shipping/billing addresses. It does not explicitly use a verb like 'list' and does not differentiate from siblings such as list_customer_addresses, but the core purpose is clear.

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

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

There is no explicit guidance on when to use this tool versus alternatives like get_business, list_business_contacts, or list_customer_addresses. The phrase 'of one business' gives context but does not tell the agent when this tool is the right choice.

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

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

Annotations already declare readOnlyHint=true, so safety is covered by structured data. The description does add a genuinely useful trait beyond annotations — a fixed page size of 25 — plus the underlying endpoint. It says nothing about ordering, whether all contacts across all businesses are returned, or whether filtering is possible.

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 clauses, front-loaded with the verb and resource, with the page size and endpoint trailing. Efficient; the raw endpoint path is of marginal value to an agent but takes almost no 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?

A simple read-only list tool with one optional parameter, full schema coverage and no output schema, so the description needn't explain return fields. The page-size and pagination hint makes it callable; only the absence of ordering/filtering scope keeps it from being fully 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?

With a single parameter at 100% schema description coverage, the schema already explains the 1-based page number and the total-page reply. The description only adds the page size, which helps interpret pagination but does not otherwise 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?

States a specific verb and resource: 'List the contact persons of business customers.' That distinguishes it from ezrentout_get_business_contact (single contact) and ezrentout_list_businesses (the businesses themselves), though it never names those siblings 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?

No guidance on when to choose this over ezrentout_list_businesses or ezrentout_get_business_contact, and no prerequisites or scoping conditions are given. The intended use is only inferred from the wording.

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, so the bar is lower. The description does add a useful behavioral detail not in the structured fields — a fixed page size of 20 — plus the filter_val dependency, but it says nothing about ordering, rate limits, or what a page of results 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?

Dense and front-loaded: the resource and page size come first, then the filter set, then the endpoint. No filler sentences, though the inline filter list is long and slightly duplicates the schema enum.

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, zero-required-parameter list tool with full schema coverage and no output schema, the description covers the essentials: what it returns, pagination size, and filter semantics. Only the sibling-choice question is left unanswered.

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 three parameters are already documented, including the '> 50' example for filter_val. The description largely restates the enum and the filter_val example, adding no new semantics beyond the schema; 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 business customers') and names the underlying endpoint, so the agent knows exactly what it retrieves. It doesn't explicitly distinguish itself from near-siblings like ezrentout_list_customers or ezrentout_get_business, but the 'businesses' resource is clear enough to route on.

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 enumerates the valid filter values and flags the one case needing extra input (completed_orders needs filter_val), which is genuine usage guidance. However, it never says when to reach for this instead of ezrentout_list_customers or ezrentout_get_business, and gives no exclusion guidance.

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

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

The readOnlyHint annotation already establishes that this is a safe read, so the bar is lower, but the description adds almost nothing beyond that: no pagination behavior, no whether inactive/expired coupons are included, and no return shape. The endpoint path is the only additional detail and it is redundant with the tool's nature.

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 fragments with no waste. It is terse to the point of being telegraphic, but nothing needs to be cut.

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 list tool with no output schema, the description covers the minimum: what entity is returned. It omits what a pricing coupon actually represents in this domain and whether the list is scoped to the company or broader, which would help an agent decide relevance.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and the absence of filters is implicitly consistent with the empty 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 the specific resource (pricing coupons of the company), and the endpoint path 'GET /pricing_coupons.api' confirms it is a read. It does not distinguish this from sibling list tools such as list_payment_options, so the agent must infer from the name that this returns discount/pricing coupons rather than payment methods.

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 call this tool, what it is useful for, or whether any alternative exists. The agent gets a resource label and nothing about the conditions that select this tool over the other list_* siblings.

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

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

The readOnlyHint=true annotation already establishes the safety profile, and the GET endpoint path corroborates it. The description adds modest value by saying both shipping and billing addresses are covered, but it does not resolve the tension with the endpoint name (shipping_addresses.api) or describe return shape or result limits.

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

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

Two short, front-loaded sentences with no filler; the resource and scope come first. The only weakness is that the first sentence is a fragment rather than a complete statement of the action.

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

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

With no output schema, the description carries some burden for describing what comes back, and it only says 'shipping/billing addresses' without field detail. The shipping-vs-billing ambiguity against the shipping_addresses.api path is left unresolved, which could confuse an agent expecting only shipping addresses.

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 both customer_id and page are already documented in the schema, including pagination semantics. The description adds nothing beyond that, which is acceptable but not additive.

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 identifies the resource (addresses) and the scope (one customer), and the endpoint path reinforces that it is a read of customer addresses. However, it is a noun phrase rather than a verb+resource statement, and the only differentiation from the sibling ezrentout_list_business_addresses is the implicit phrase 'of one customer.' An agent can infer the purpose, but it has to work at it.

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

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

There is no guidance on when to call this versus ezrentout_get_customer (which may also carry address data) or ezrentout_list_business_addresses. No prerequisites are stated, such as obtaining customer_id from ezrentout_list_customers first. Usage is left 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 genuine behavioral context beyond that: fixed page size of 25 and the underlying GET /customers.api endpoint, which helps an agent reason about pagination cost and caching. It stops short of describing error behavior for malformed filter_val or what a customer 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?

Front-loaded with the core action and page size, then the filtering rules — two dense clauses with no filler. Minor waste in re-listing all ten filter names that the schema enum already carries.

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, zero-required-parameter list tool with no output schema and fully documented params, this covers what an agent needs to make a correct call. The remaining gap is the failure mode when a valueless filter is passed, 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 coverage is 100%, so the individual parameter meanings are already documented and baseline would be 3. The description earns above baseline by stating the cross-parameter constraint the schema never encodes: email, category, account_name and completed_orders require filter_val, including the "> 50" comparison syntax. It slightly duplicates the enum list that the schema already enumerates.

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 customers") plus the page size and the filterable surface, so an agent knows exactly what it retrieves. It never names the sibling it is not — get_customer (single record) or search_member_by_email — so the boundary is left implicit.

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?

"Optional filter" plus the list of permitted filter names and which of them require filter_val gives real guidance on how to drive the tool. However there is no when-to-use/when-not guidance relative to get_customer or search_member_by_email, and no statement of what happens if filter is supplied without filter_val.

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 description only needs to add context. It contributes the source endpoint (GET /assets/custom_attributes.api) and the shape of the returned data ('names and ids'), which is useful given there is no output schema. It says nothing about whether fields are per-asset-type, scoped by business, or paginated.

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 no filler. The trailing API-path sentence earns its place only as a behavioral hint, which keeps it just short of 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 zero-parameter read-only lookup, the description supplies what the annotations and empty schema cannot: what the returned records contain. Without an output schema, however, it could have said more about the return structure (e.g. whether ids are usable as field keys elsewhere).

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

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

The tool takes zero parameters, so the schema imposes no documentation burden and the baseline of 4 applies. The description correctly implies no input is required.

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 resource: the custom fields defined for items, and narrows the payload to names and ids. An agent can tell it apart from the other list_* siblings (locations, groups, coupons) because no sibling touches custom attributes. It stops short of a clear verb, but 'List custom fields' in the title plus the description makes the operation 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?

No when-to-use guidance and no alternative tool is named. The parenthetical '(names and ids)' hints that this is a lookup to obtain field identifiers, but the description never says so, nor does it mention any prerequisite or follow-up 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 as a safe read operation, so the description's main added value is naming the returned fields. It does not mention result ordering, pagination, or whether reports are scoped to the current user/business, leaving some behavioral context 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?

The description is a single compact sentence with returned fields front-loaded. The trailing raw endpoint ('GET /reports/list_custom_reports.api') is mildly extraneous but does not obscure the core 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 zero-parameter read-only listing tool with no output schema, the description gives enough to call it and to know the shape of the returned items. It could be more complete by noting result scoping or ordering, but nothing essential is missing.

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

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

The tool takes no parameters, so the baseline is 4; there is no parameter behavior to clarify. The description correctly does not invent parameters.

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

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

The description names the specific resource ('saved custom reports') and the fields returned ('id, name, description'), which lets an agent distinguish it from asset/order/report-adjacent siblings. The verb is only implied by the tool name and title rather than stated in the description, keeping 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?

There is no explicit guidance on when to use this tool versus alternatives, nor any stated preconditions or exclusions. With no parameters, usage is nearly self-evident, but the description provides no contextual routing information.

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, and the description adds the genuinely useful behavioral facts that the result is 25 records per page and that each group carries its items (so responses can be large). It says nothing about permissions, ordering, or rate limits beyond that.

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 clauses plus the raw endpoint; the resource-and-nesting fact is front-loaded and nothing is padded. The size is well matched to a trivial single-parameter list call.

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 listing tool with annotations and no output schema, the description supplies the essential shape of the return (groups containing items, paged by 25). The main residual gap is the relationship to list_subgroups, which leaves the agent guessing between two near-identical list endpoints.

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 a single parameter at 100% schema description coverage, the schema already explains the 1-based paging and the total-pages reply. The description only adds the page size of 25, which the schema omits – a small but real supplement, so baseline 3 is right.

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 asset groups (categories, 25 per page) with their items" clearly names the resource and disambiguates the terminology (groups = categories) while noting that items are nested inside. It stops short of distinguishing this from the sibling ezrentout_list_subgroups, which is the most likely source of misfires.

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, when-not-to-use, or alternative is mentioned; the sibling list_subgroups goes unmentioned despite being an obvious confusable. The only procedural hint is the per-page count, which is a capacity note rather than selection guidance.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description contributes one genuinely new behavioral fact — a fixed page size of 25 per page — which goes slightly beyond the schema's pagination wording. It says nothing about result shape, sort order, or whether the list is bounded, which is useful but not critical for a read-only lister.

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, front-loaded with the resource definition, then the pagination fact and endpoint. No filler, nothing repeated from 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 two-parameter read-only lister with full schema coverage and annotations, this is close to sufficient — no output schema means return values need not be described. The remaining gap is sibling routing against search_inventory, which matters given how many inventory-adjacent tools exist.

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

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

Schema coverage is 100%, so both page and include_custom_fields are fully documented in structured form and the baseline applies. The description only reinforces the pagination dimension by stating 25 items per page; it says nothing about include_custom_fields and adds no syntax 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 plus a genuine disambiguation: inventory means 'consumable items tracked by quantity', which separates it from the many asset-oriented siblings. It does not, however, distinguish itself from the sibling ezrentout_search_inventory, so a routing decision between the two is left unexplained.

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 verb 'List' implies full enumeration versus targeted lookup, and the description supplies the GET endpoint. But it never says when to prefer this over ezrentout_search_inventory or ezrentout_get_inventory_item, and it gives no prerequisites or 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely new behavioral facts: a fixed page size of 25 and the backing endpoint GET /locations/get_line_item_locations.api. It says nothing about ordering, total counts, or what a location 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 fragments with the resource front-loaded and no filler. The 'status all, active or inactive' clause is slightly telegraphic and the raw endpoint path is arguably noise for an agent that cannot call URLs directly.

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 two-parameter read-only list tool with no output schema and no required parameters, the description covers pagination size and filtering, which is most of what is needed. It stops short of describing what a returned location looks like or how pagination metadata is surfaced, which matters 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 coverage is 100%, so baseline is 3, but the description contributes the page size ('25 per page') which the schema never states and which directly determines how many page calls an agent needs. It also restates the status enum values, giving no extra syntax or default detail beyond the schema, hence not a 5.

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 the resource ('The company's locations') and its shape (paginated list with a status filter), which is enough to separate it from single-resource siblings like ezrentout_get_location. It never uses an explicit verb, relying on the title 'List locations' to carry that, and it does not distinguish itself from adjacent list tools such as ezrentout_get_location_quantities.

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 statement of when to use this versus ezrentout_get_location, ezrentout_get_location_quantities, or the many other list_* tools. The only hint is the status filter, which implies browsing active/inactive locations, but no alternative or exclusion 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, so safety is covered; the description usefully adds the fixed 25-per-page size and the response fields. It stops short of saying how to detect the last page or that total page count is returned (which the schema mentions), and gives no sense of result volume 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?

Three tight sentences with the resource and page size front-loaded before the paging rule. The trailing 'GET /baskets.api' is mildly extraneous for an agent that doesn't call HTTP directly, but the rest earns its 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 one-parameter, read-only list tool with no output schema, the description supplies what the schema can't: the page size and the shape of each record. What remains missing (sort order, filtering capability) is minor at this complexity level.

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 already explains 1-based paging, the default of 1, and the total-pages reply. The description repeats the increment-by-one rule without adding anything the schema lacks, 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?

Specific verb+resource ('List all rental orders') with concrete qualifiers: page size of 25, the fields returned (status, customer, dates), and the underlying endpoint. It is clearly distinct from get_order and the write-oriented order siblings, though it doesn't explicitly name those alternatives.

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

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

'List all' plus pagination instructions implies the broad-enumeration use case, and an agent can infer get_order is the single-record counterpart. However, there is no explicit when-to-use/when-not statement or named alternative (e.g., filtering by customer or status) anywhere in the text.

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 that this is a GET endpoint returning a fixed enumeration of values (cash, check, ...). It does not say whether the list is static or business-specific, nor the return format, which is the main behavioral gap for a lookup 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 clauses: the return content is front-loaded, followed by the sibling linkage and endpoint. Nothing 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 trivial parameterless lookup with no output schema, the description gives enough to call it and know what comes back (payment option values) and why. It lacks only detail on whether results vary by business/account, which is minor here.

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 and the schema is empty, so there is nothing to mis-document; the description correctly implies a parameterless GET call. Baseline 4 applies for a 0-param tool.

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

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

States a specific verb and resource ('the payment options ... that ezrentout_record_order_payment accepts') and explicitly ties it to the sibling tool that consumes the result, so an agent can distinguish it from other list_* tools at a glance.

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 makes the usage implicit-but-clear: call this to obtain valid values before calling ezrentout_record_order_payment. It does not state exclusions or prerequisites (e.g., auth, whether options are per-business), so it stops short of a full when/when-not 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?

The readOnlyHint annotation already tells the agent this is a safe read, so the description's burden is lighter, but it still discloses nothing about result volume, pagination, or whether the response is capped. A bare endpoint path carries no behavioral information an agent could act on.

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?

Extremely short and front-loaded, so nothing is wasted, but the second sentence (the raw HTTP path) is implementation detail that does not earn its place for an agent. Brevity here comes at the cost of substance rather than from tight editing.

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 0-param list tool with no output schema, minimal description is tolerable, and the readOnlyHint covers the safety profile. However, with no output schema the agent gets no hint about what a purchase order record contains or how results are bounded, 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a 0-param schema is 4. The description does not misrepresent or invent parameters.

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

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

"All purchase orders" essentially restates the tool name and title without adding scope detail (no filter, pagination, or ordering semantics). The raw endpoint string GET /purchase_orders.api is a restatement of implementation, not a clarification. It gives no differentiation from the sibling ezrentout_get_purchase_order.

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 ezrentout_get_purchase_order (single PO) or the other list_* tools. The word "All" faintly implies an unfiltered bulk fetch, but there are no explicit conditions, prerequisites, or 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=true already establishes the safety profile, so the description's main addition is the raw endpoint GET /groups/get_sub_groups.api, which confirms a read call but adds little operational meaning. It says nothing about pagination, result ordering, or whether subgroups are returned flat or nested.

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 scoping behavior front-loaded; nothing is padded. The trailing REST endpoint path is marginally useful noise but doesn't undermine clarity.

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

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

For a one-optional-param list tool with no output schema, the description covers the call semantics adequately, but it never characterizes the return value (e.g., a flat list of subgroup records) or volume, which is the remaining gap for an agent deciding how to consume 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 coverage is 100% and the single optional parameter is fully documented as 'Only the subgroups of this group.' The description's 'those of one group' restates rather than extends 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 names the resource (subgroups) and its scope (all subgroups, or those of one group), which is a specific and unambiguous read operation. It doesn't explicitly contrast with ezrentout_list_groups, though the 'sub' qualifier makes the distinction reasonably inferable.

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?

'All subgroups, or those of one group' implies the two usage modes (unfiltered vs. filtered by group_id) but gives no explicit when-to-use guidance or pointer to the sibling list_groups tool. The agent must infer that omitting group_id returns everything.

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 only declare readOnlyHint=true, and the description adds real behavioral context on top: a fixed page size of 25, the backing HTTP endpoint, and the concrete allowed filter values. It does not mention auth or rate limits, but the page-size and filter-value disclosures are exactly the kind of operational detail annotations cannot carry.

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 what the resource is and how big a page is, then the filter options. The trailing 'GET /members.api' is mildly redundant reference detail 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 three-parameter, zero-required read tool with no output schema, the description covers scope, page size, filter mechanics, and the enum of filter values. Pagination behavior is delegated to the page parameter's schema text, which is acceptable since that text explicitly explains total pages.

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

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

Schema coverage is 100%, so the baseline would be 3; the description earns above that by enumerating the valid filter_val values (active, inactive, login, non_login, all), which the schema leaves as an unconstrained string. It also ties the three filter names to filter_val as a pair, clarifying the coupling between the two parameters.

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

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

States a specific verb (list) and resource (the company's users, staff/admins) plus scope details like 25 per page and the backing endpoint GET /members.api. It is clearly distinguishable from the singular get_user sibling, though it never names that sibling explicitly to reinforce the split.

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

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

Usage is only implied: the description indicates this is the enumeration endpoint and that filtering is available, so an agent can infer 'use this to find users'. It gives no explicit when-to-use versus ezrentout_get_user or ezrentout_search_member_by_email, and no guidance on when filtering is required vs. browsing pages.

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 description's main added value is the page size ('25 per page') and the underlying endpoint. It doesn't discuss ordering, total-page metadata in the response, or empty-result behavior beyond what the schema's page description already states.

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 fragments, front-loaded with the resource and page size; nothing is wasted. It is arguably over-compressed, but every element present is relevant.

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 trivial read-only, one-parameter list tool with full schema coverage and annotations, the description is barely sufficient: an agent can call it correctly, but it never states explicitly that the call returns a paginated collection of vendor records.

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 'page' parameter is fully documented in the schema (1-based, defaults to 1, total pages returned). The description adds only the page size, which the schema does not mention, so it sits at the baseline for a well-documented single-parameter tool.

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

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

The description names the resource ('The company's vendors/suppliers') and implies retrieval, but never uses a clear verb like 'list' or 'retrieve' — the agent relies on the tool name and the GET endpoint string to infer the action. It is distinguishable from siblings only because none of them concern vendors.

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 guidance on when to use this tool versus alternatives. There is no sibling vendor-listing tool to disambiguate against, but the description also says nothing about prerequisites (e.g., that it is a read-only paginated browse) or when to prefer another listing endpoint.

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 new behavior — a fixed page size of 25 and the underlying endpoint GET /tasks.api. The '[sic, as the vendor spells it]' note on 'in_progess' prevents a caller from silently correcting the value into an error.

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 resource and page size, followed by the filter options and endpoint. The bracketed spelling aside is slightly heavy but earns its place by preventing a wrong enum value.

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 three-parameter, zero-required, read-only list tool with no output schema, the description covers page size, filter dimensions, valid statuses, and the endpoint. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100% and every parameter is already documented, including the status list and the pointer to list_work_order_types. The description repeats the filter values and adds the 25-per-page fact, but contributes no syntax or format detail beyond what the schema provides, 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 ('Maintenance work orders'), plus the pagination model and available filters, which clearly separates it from ezrentout_get_work_order and ezrentout_create_work_order. It never names those siblings explicitly, so differentiation is inferred from the verb 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?

'Optionally by status filter ... or by work order type' implies when the filters apply, but there is no statement of when to reach for this tool versus get_work_order or list_work_order_types, and no exclusions. The routing hint ('from ezrentout_list_work_order_types') lives in the schema, not 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 description only adds the raw endpoint path (GET /task_types.api). It says nothing about whether the list is company-scoped only, whether it is paginated, or whether it includes archived/inactive types.

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 very short fragments with no padding — the resource is front-loaded. The endpoint path is mildly useful but the phrasing is telegraphic rather than structured prose.

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?

There is no output schema, so the description carries the burden of describing what comes back, and it does not — no indication of fields (id, name, etc.) or whether the payload is a bare array. For a simple no-param list tool that is a real gap, though a small one.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify; the baseline for a parameterless tool applies. The only shortfall is that no filters (e.g., by active status) are mentioned as absent.

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 identifies the resource ('work order types of the company') and the underlying endpoint, so an agent can infer it returns a reference list. However, it is a noun fragment rather than a verb+resource statement, and it does nothing to distinguish itself from siblings such as list_work_orders or list_custom_fields.

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 call this versus alternatives, no mention of prerequisites, and no note about whether the result is needed to interpret work-order fields elsewhere. 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?

Annotations already declare it is a non-readonly, non-idempotent, non-destructive write. The description adds real behavioral context beyond that: the call records money in the system but performs no card charge because credit card payments are not supported by the API. It does not disclose what happens on repeated invocation (relevant given idempotentHint=false), which keeps 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?

Four short sentences, front-loaded with the core action and its most important caveat (no card charge), followed by the parameter-source hint and the underlying endpoint. 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 3-parameter write tool with no output schema, it covers the essential unknowns: what it does and does not do, and where to get a valid payment method. Missing only edge-case behavior such as duplicate calls or required order state.

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

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

Schema coverage is 100%, so the baseline is 3. The description nonetheless adds meaning by directing the agent to the source of valid payment_method_name values via ezrentout_list_payment_options, which the schema does not convey.

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 ("Record a payment received for an order (a prepayment)") and immediately bounds the scope by clarifying it only records the amount in EZRentOut and does not charge a card. This makes it distinguishable from other order-mutation siblings like rent_out_order or add_order_custom_entry.

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 concrete routing guidance for the payment_method_name value ("Use a payment_method_name from ezrentout_list_payment_options"), which is a clear prerequisite. It does not explicitly name conditions where this tool should be avoided (e.g., already-paid orders or non-prepayment flows), so it stops short of a 5.

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

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

Annotations only supply destructiveHint=true; the description adds real behavioral context beyond that — billing starts, the rental clock starts, and EZRentOut may email the customer per account settings. It does not cover prerequisites (what order state is required) or error behavior, keeping it below 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 the outcome and side effects, then the parameter rule, then the endpoint. Every sentence carries information an agent needs; nothing is padded.

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

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

For a destructive, billing-triggering mutation with no output schema, the description covers effects, email side effect, and the key either/or parameter rule. It stops short of saying what the call returns (e.g., updated order) or whether the action can be undone via return_order, which an agent would want.

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 baseline is 3, but the description adds a genuine cross-parameter rule the schema cannot express: supply rentout_date and return_date, or use use_current_datetime. It also ties the call to the order number in the endpoint path.

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 ("Check an order out") and immediately defines the effect: assets go to the customer, rental clock and billing start. This clearly separates it from siblings like book_order, return_order, or create_order without needing schema inspection.

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?

Implies the right context (an existing order being handed to a customer) and gives conditional parameter guidance ("Give rentout_date and return_date, or use_current_datetime"), but never names a sibling alternative or exclusion such as return_order for reversal or book_order for reservations.

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?

With only destructiveHint=true in annotations, the description adds real value: it discloses that billing ends, assets are released, no partial returns are supported, late fees/payments are excluded, and EZRentOut may email the customer per account settings. It omits whether the action is reversible or what happens on an already-checked-in order.

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?

Front-loaded with the state transition, then the parameter modes, then scope caveats, then the sibling escape hatch. Dense but every clause carries information; the endpoint reference at the end is a compact anchor.

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?

No output schema exists, and the description does not state what the call returns (the checked-in order object?). Everything else an agent needs to invoke it correctly — timing options, scope limits, side effects — is present.

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%, but the description still adds the either-or relationship between return_date/return_time and use_current_datetime, which the schema presents only as independent fields. It does not add format details beyond the schema's patterns.

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 (check in) and resource (order), and immediately explains the consequence: billing ends and assets become available. This clearly distinguishes it from ezrentout_rent_out_order and ezrentout_get_order.

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 covers the two invocation modes (return_date/return_time vs. use_current_datetime) and the scope restriction (whole order, no partial returns). It also names the correct sibling for fees/payments: ezrentout_record_order_payment.

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, so the description only needs to add context. It discloses the backing call ('GET /search.api, facet FixedAsset') and the query prefixes, but says nothing about matching semantics (prefix vs substring), empty-result behavior, or what the response looks like beyond the pagination hint in the 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?

A single front-loaded sentence that leads with the matching rules; nothing is padded. The trailing 'GET /search.api (facet FixedAsset)' is implementation detail of marginal value to an agent choosing a tool, but it 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?

With only two parameters and annotations present, the basics are covered, but there is no output schema and the description never indicates what comes back (a list of asset records?) or how it differs from the several sibling search/list/filter tools. An agent can call it, but not confidently instead of the alternatives.

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

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

Schema coverage is 100%, so the baseline is 3. The description largely repeats the schema's own text ('Name, #<item number> or @<identification number>'), with the one genuinely new constraint being the '3+ characters' minimum, which notably conflicts with the schema's minLength of 1.

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 (search) and resource (assets) plus the accepted query syntaxes, so the agent knows exactly what the tool matches on. It does not distinguish itself from near-neighbors like ezrentout_filter_assets, ezrentout_list_assets, or ezrentout_search_inventory, which is the only thing keeping 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?

No guidance on when to use this versus filter_assets (structured filtering) or list_assets (enumeration) or search_inventory (non-asset items). The usage is only implied by the syntax description, and there are no stated exclusions or alternatives.

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 operation. The description adds the endpoint and facet (VolatileAsset), which is useful, but it does not describe pagination behavior, result shape, or search limitations beyond what the schema and annotations already 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?

The description is extremely concise and front-loaded: one sentence defines the search syntax, followed by the endpoint and facet. Every element earns its place with no wasted wording.

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

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

For a simple two-parameter read-only search tool with complete schema coverage and annotations, the description provides enough to invoke it correctly. The main remaining gap is that without an output schema it does not describe the result format, though the tool name and search semantics make the return type reasonably clear.

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 both parameters are already documented in the input schema. The description restates the search parameter syntax but adds no meaningful detail beyond the schema, including no additional context for the page parameter.

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

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

The description states a specific verb and resource: searching inventory items by name, item number, or identification number. It clearly distinguishes this as a search operation rather than a general list operation, though it does not explicitly differentiate from siblings like list_inventory or search_assets.

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

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

The description implies usage through the accepted search syntax, but it gives no explicit guidance on when to use this tool versus list_inventory, filter_assets, or search_assets. There are no exclusions or alternative-routing instructions.

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 profile, so the bar is lower. The description adds some value by implying the result may be any of three entity types (customer, contact, or business), which affects how the agent interprets the response, but it says nothing about multiple matches, no-match behavior, or case sensitivity.

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 lookup intent front-loaded. The trailing raw endpoint path is moderately useful filler and doesn't crowd out the substance, but it earns less than the first sentence does.

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 no output schema, the essentials are covered: what it finds and the key input. The notable remaining gap is the return shape — whether the polymorphic result is a single record or a list, and what an empty result looks like.

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 schema coverage is 100%, so the schema fully documents it (type, length bounds, meaning). The description's 'has an email address' adds no syntax, format, or matching-behavior detail beyond that. 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 ('Look up') and resource set ('customer, business contact or business') keyed on email, which distinguishes it from the list_* and get_* siblings that take IDs or filters. It stops short of naming which sibling to use when you don't have an email, so it isn't a full 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 condition 'has an email address' implies when to use it, but there is no explicit guidance such as 'use when you only have an email; otherwise use get_customer'. No exclusions or alternatives are named despite many overlapping lookup siblings (get_customer, get_business_contact, get_business).

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

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

Annotations already declare destructiveHint=true, and the description adds the concrete HTTP method (PATCH) and the endpoint path, which is useful context. However it does not state whether the transition is reversible, what happens to the work order's status afterwards, or any permission requirements — modest value added over the 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?

Two short sentences, front-loaded with the action and followed by the endpoint. Nothing extraneous; every element earns its place.

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

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

For a single-parameter mutation with no output schema, the description is minimally sufficient: it says what changes and how it is invoked. It nonetheless leaves out return behavior, reversibility, and what 'in progress' means in the workflow, which an agent would want for a destructive state change.

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, so the schema carries the load. The description only restates the parameter via the <Work_Order#> path token, adding no format or constraint detail beyond what the schema provides — 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+resource: 'Mark a work order in progress' names both the action and the object, and the PATCH path reinforces it. It is distinguishable from siblings like complete_work_order and create_work_order by the state transition it performs, though it never explicitly contrasts with them.

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

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

There is no explicit guidance on when to use this versus complete_work_order, get_work_order, or create_work_order. The usage is only implied by the tool name and the state-change verb, leaving the agent to infer prerequisites.

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