current-rms

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

Annotations only declare readOnlyHint=true, but the description adds the notable fact that the API uses POST despite being read-only, which prevents an agent from wrongly treating it as a mutation. It also discloses the return payload structure (per-period quantity arrays plus opportunities), important since there is no output schema. Pagination and error behavior remain undisclosed.

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 resource and scope, then return shape, then the read-only caveat. Every clause carries information, though the em-dash-nested enumeration makes the opening sentence dense and slightly hard to parse.

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 correctly assumes the burden of describing the return value, and it does so at field-family level. Missing are pagination/size limits and how store_ids filters or aggregates results, which an agent would need for edge cases.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the terse schema text: it explains that period granularity (hour, quarter day, half day, day) depends on the range and a system setting, which clarifies the effect of days_period. It does not clarify store_ids aggregation behavior.

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 availability) and resource (rental availability for ONE product over a date range), and enumerates exactly what is returned: held, booked, unavailable, available, on sub-rent and quoted quantities per period, plus the booking opportunities. This is distinguishable from siblings like list_product_inventories or list_stock_levels without opening any schema.

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

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

The 'ONE product over a date range' scoping implies when the tool applies, but no alternatives are named and no when-not-to-use condition is given (e.g., versus list_product_inventories for multi-product stock views). Usage is inferable, 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?

Annotations already declare destructiveHint=true, so the write/mutation profile is covered. The description adds the underlying endpoint (POST /activities) and confirms the activity is associated with a member/opportunity/project, but says nothing about permissions, side effects, or whether the association must pre-exist.

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 names the action and its scope, followed by a brief endpoint note. No filler, though the endpoint reference is marginal value for an agent that cannot read it from the schema.

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 14-parameter mutation tool with no output schema, this description is thin: it never mentions the required 'subject' field, defaults, or what the response returns. It is adequate but leaves real gaps given the tool's 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 coverage is 100% with all 14 parameters documented in the schema, so the baseline is 3. The description only hints at the regarding_* target types and optional participant_member_ids, adding 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 (log) plus resource (activity) and enumerates variants (call, meeting, task, note) and target records (member, opportunity, project). This clearly separates it from siblings like current_rms_list_activities, though it doesn't name that sibling explicitly.

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

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

No when-to-use or when-not-to-use guidance, no prerequisites, and no pointer to alternatives such as current_rms_list_activities for reading. The '(optionally with participants)' clause is the only usage-flavored content.

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 provide destructiveHint=true; the description adds the underlying POST endpoint and the parent-child linking behavior, but omits permissions, duplicate handling, and what is returned or whether the call is idempotent. Because annotations are sparse, this is a moderate but incomplete disclosure.

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

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

Two brief sentences plus the endpoint, front-loaded with the action and the special linkage case. No wasted words; it is appropriately sized for a create tool.

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

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

For a create tool with ten parameters, nested objects, and no output schema, the description is thin: it omits required-field guidance, error behavior, and any indication of the response. The schema covers parameter meaning, but an agent still lacks behavioral context for a mutation.

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

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

Schema description coverage is 100%, so the schema already documents all ten parameters in detail. The description adds only a linking hint for parent_member_id, which is marginal beyond the schema's own description.

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

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

States a specific verb (Create) and resource (Organisation, Contact, Venue), and distinguishes the membership_type options. It is clearly the member-creation tool among siblings, though it does not explicitly name update_member as the alternative for edits.

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?

Explains the three creatable member kinds and gives a concrete linkage rule for parent_member_id when creating a Contact under an Organisation. It does not state when not to use it or point to update_member for modifying existing members.

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 provide destructiveHint=true and a title, so the description should carry more of the behavioral burden. It does add useful context about the created states and that line items are handled outside this tool, but says nothing about permissions, whether the created job is immediately visible, 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 tight sentences, front-loaded with the action and required parameter, with no filler. The trailing 'Current RMS: POST /opportunities' is mildly redundant but harmless context.

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

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

Given a 22-parameter tool with full schema coverage, the description covers the essentials an agent needs to invoke it correctly (required store_id, key customer/date fields, state options). The main gap is that with no output schema, it does not indicate what the call returns (e.g., the new opportunity id).

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

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

Schema description coverage is 100%, so the schema already documents all 22 parameters in detail, establishing a baseline of 3. The description reinforces a few key fields (store_id required, member_id as customer, starts_at/ends_at as job dates) but adds little that the schema does not 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 ('Create an opportunity') and clarifies the domain term with an alias ('a rental job'), plus the selectable initial states. It is clearly distinguishable from sibling tools like current_rms_get_opportunity, current_rms_list_opportunities, and current_rms_update_opportunity.

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 guidance: store_id is required and points to current_rms_list_stores for lookup, and it names member_id and starts_at/ends_at as the fields to set for customer and dates. It also signals scope boundaries ('Line items are added in Current RMS'), though it never states explicit when-not-to-use conditions.

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

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

The readOnlyHint annotation already establishes this as a safe read. The description adds useful context by naming the returned fields (status, due date, totals) and the underlying GET /invoices/{id}, but says nothing about failure behavior (e.g. unknown id) or the include performance cost.

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 compact sentence, front-loaded with the core action and return shape, with the endpoint appended as a useful anchor. 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 two-parameter read tool with annotations covering safety and no output schema, the description covers what is fetched and which associations can be embedded. It could mention error behavior, but nothing essential to a correct call is missing.

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

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

Schema description coverage is 100%, so both invoice_id and the include enum are fully documented in the schema; the description only echoes the invoice_items example. Baseline 3 is appropriate when the schema carries the 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?

States a specific verb (Fetch) and resource (one invoice or credit note) and lists the salient returned fields. The singular framing implicitly separates it from current_rms_list_invoices, but no sibling is named explicitly, which keeps 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?

Usage is implied — retrieve a single invoice by id — but there is no explicit when-to-use versus current_rms_list_invoices, and no prerequisites or exclusions are stated. Adequate but with a clear gap.

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 job is to add context — and it does, by spelling out the response composition (addresses, emails, phones, links, linked parent/child members, custom fields). That payload disclosure is genuinely useful given there is no output schema. It stops short of noting not-found behavior or auth requirements, hence not 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?

One front-loaded sentence giving the payload, followed by a compact endpoint mapping that helps tie the tool to the underlying API docs. Nothing is padded, though the endpoint reference is mildly redundant with 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 one-parameter read tool with no output schema, the description covers what the caller needs: the resource, the identifier semantics, and the returned field groups. Missing only edge-case behavior (unknown id, permissions), which is minor 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 there is a single integer member_id, so the schema already carries the parameter documentation (baseline 3). The description adds no format, range, or sourcing detail beyond what the schema states.

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 (Fetch) plus the exact resource (one member) and enumerates the member varieties (organisation, contact, venue, user). The word 'one' implicitly distinguishes it from the sibling current_rms_list_members, so an agent can route correctly without opening either schema.

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

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

Usage is implied by the GET /members/{id} reference and the single required member_id, which signals a direct lookup by identifier. But no explicit when-to-use framing, no mention of when to prefer the list endpoint instead, and no note about 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real value beyond that by disclosing that associations are only populated when explicitly named in include, and by decoding the state enum values (0 Enquiry ... 3 Order) that would otherwise be opaque in output.

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

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

Two tight sentences plus an API-path reference, with the core fetch semantics front-loaded and no filler. Every clause carries information an agent needs.

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

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

No output schema exists, so the description carries the return-value burden, and it does describe the main returned fields and the include-gated associations. It stops short of covering error behavior or default association omissions beyond the include note, but is largely sufficient for a single-resource read.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further: it explains the behavioral consequence of the include parameter (associations are omitted unless named), which the schema's 'Associations to embed' phrasing only hints at, and it decodes the state field returned.

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 ('Fetch one opportunity') and immediately scopes it to a single record versus the sibling list_opportunities / list_opportunity_items tools. It also names exactly what is returned (dates, state, status, charge/cost totals).

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 — retrieve one opportunity by id — but the description never says when to prefer this over list_opportunities or when the include expansion is warranted. There are no explicit exclusions or alternative-routing statements.

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 usefully adds what is retrieved (rates, stock settings, custom fields), but it discloses nothing further about auth needs, error behavior when the id is absent, or how the optional include affects the result.

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

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

Two tight sentences, front-loaded with the payload description and ending with the underlying REST endpoint. Every clause carries information; nothing is padding.

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

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

With no output schema, the description steps in to name the returned sections (rates, stock settings, custom fields), which is the key missing piece for a read tool. The one gap is the include parameter's behavior, which is left entirely to the 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. The description's mention of rates/stock settings/custom fields loosely hints at what can be embedded, but it never explains the 'include' parameter's accepted values or its effect, adding little beyond the schema text.

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

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

States a specific verb (Fetch) and resource (one product), plus the payload contents (rates, stock settings, custom fields). 'One product' implicitly contrasts with the list_products sibling, but it never names or explicitly distinguishes itself from current_rms_list_products.

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 singular 'one product' and the required product_id. There is no explicit when-to-use, no guidance on when to use this versus current_rms_list_products, and no stated preconditions.

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, covering the safety profile, so the description's addition of 'Current RMS: GET /activities' is consistent but minimal. The description does not disclose pagination behavior, default limits, authentication needs, or return format. With annotations carrying the read-only signal, this is adequate but adds little behavioral context beyond the annotations.

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

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

The description is front-loaded with purpose and then moves efficiently to filtermode and a filter example. The example is the longest element but earns its place by illustrating the complex filter syntax. There is no redundant or empty 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?

Given the tool's complexity (8 params, nested filters object, no required params, no output schema), the description covers purpose, filtermode, and a high-value filter example. The schema already documents all parameters thoroughly, so the description need not repeat them. It leaves out return shape and pagination behavior, which are minor gaps without an output schema, keeping it just short of 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%, so the baseline is 3. The description goes beyond the schema by explaining filtermode and by providing a concrete multi-key filter example (time_status_eq, starts_at_lt, ends_at_gteq, participants_member_id_eq) that demonstrates how to combine predicates for a realistic query. This adds useful semantic meaning, especially for the nested filters object, though it does not clarify all eight 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 states a specific verb and resource ('List activities') and clarifies the scope by enumerating what counts as an activity (calls, meetings, tasks, notes) and the entities they are logged against (members, opportunities, projects). This makes it distinguishable from siblings like list_members or list_opportunities, though it does not explicitly name any alternative. A solid 4: clear and specific, but without explicit sibling routing.

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 the filtermode options and a concrete example filter for 'one person's busy time', which implies a useful usage context. However, it does not state when to use this tool versus alternatives such as create_activity or other list endpoints, nor does it provide exclusions. Usage guidance is implied rather than explicit.

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 real behavioral context beyond that: which fields free-text search covers, the accepted filtermode values, and the sourced filter recipe. It omits pagination defaults and sort determinism notes, which live 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?

Three sentences, front-loaded with the purpose before the search scope and the special-case filter recipe. The inline JSON payload is dense but necessary; no filler sentences are present.

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

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

For an 8-parameter read-only list tool with no output schema and full schema coverage, the description covers purpose, search scope, filter mode, and a tricky filter use case. The returned record contents are only sketched, but with no output schema that is a minor gap rather than a blocking 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?

Schema coverage is 100%, so the baseline is 3, but the description adds a concrete composite-filter example (invoice_items_source_type_eq + invoice_items_source_id_eq) that the schema's generic examples do not cover, plus the filtermode enumeration. That is meaningful semantics beyond the structured fields.

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 invoices and credit notes') and even enumerates the returned fields (number, dates, status, totals), so the agent knows exactly what this yields. It never names the sibling get_invoice to draw the list-vs-single distinction, but 'List' versus 'Get' is unambiguous from the names.

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, actionable guidance for a non-obvious case: finding one opportunity's invoices, including the exact filters payload and filtermode to pass. It does not state when to prefer a sibling (e.g. get_invoice for a single record) or when not to use it, which keeps it 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?

readOnlyHint=true already establishes this is a safe read, and the description adds genuinely useful context beyond that: the default active-records scoping, the free-text search coverage, the full filtermode vocabulary and the underlying GET /members endpoint. It does not mention pagination limits or sorting behavior, but those are covered by 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?

Three dense sentences, front-loaded with the resource definition and search scope before the filter detail. Every clause carries information, though the filtermode enumeration is a long inline list that borders on schema duplication.

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 does not explain the return shape, but it compensates with resource semantics, default scoping and the endpoint. Pagination and sorting are left to the fully-documented schema, so an agent has enough to call this correctly.

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

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

Schema description coverage is 100%, so the baseline would be 3; however the description adds real meaning by listing the searchable fields and the complete set of filtermode values (including with_pending_activities, with_live_opportunities, bookable) that the schema's generic 'e.g.' description omits.

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 (members), and crucially explains that a 'member' is Current RMS's unified record type for Organisations, Contacts, Venues and Users — a semantic clarification an agent cannot infer from the name alone. It is easily distinguishable from get_member, create_member and update_member siblings.

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 states the default behavior ('Defaults to active records') and enumerates the filtermode values, which effectively tells the agent how to scope the query. It does not explicitly contrast this with get_member for single-record retrieval, so it stops short of full when-not/alternatives 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?

With readOnlyHint already declaring the safe-read profile, the description still adds real behavioral context: the 25-record page cap, the exact fields covered by free-text search, the filtermode set, the omission of line items, and the underlying GET /opportunities endpoint. It stops short of describing pagination traversal beyond the cap.

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 purpose, then search scope, filtermode values, sibling routing, and the page cap — each sentence carries information. It is fairly dense, but nothing is redundant enough to cut materially.

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

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

For an 8-parameter, zero-required list tool with no output schema, the description covers what an opportunity is, what comes back, the page limit, and where line items live. The only real gap is guidance on the nested 'filters' query-engine object and the include/view_id interactions.

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 page, sort, search, filters, include, view_id, per_page and filtermode are all self-documented. The description largely restates the search fields and filtermode examples already in the schema, adding only the page-size cap; the complex nested 'filters' predicate object gets no explanation beyond what the schema provides.

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

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

States a specific verb and resource and then defines the domain object ('enquiries, drafts, quotations and orders for a rental job') along with the fields returned (dates, state, charge totals). It also distinguishes itself from the sibling tools that carry line items.

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 routes line-item needs to current_rms_get_opportunity or current_rms_list_opportunity_items, which is a clear alternative-naming exclusion. It also enumerates useful filtermode values, but does not say when to prefer this list over siblings such as list_projects or list_invoices.

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 the underlying Current RMS endpoint and the shape of returned fields, which is useful, but says nothing about pagination limits or empty-result behavior beyond what the schema already encodes.

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

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

Two tight sentences: the core action and returned content come first, then the endpoint reference. 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 read-only list tool with a fully documented paginated schema and no output schema, the description covers purpose and return contents adequately. It could have mentioned pagination or the include associations to be 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?

Schema description coverage is 100%, so page, per_page, include and opportunity_id are all documented in the schema itself. The description adds no parameter-level guidance, 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 (List) and resource (line items on one opportunity) and enumerates the returned content (products, services, groups with quantity, rate, discount, dates, charge totals). This clearly distinguishes it from siblings like current_rms_list_opportunities or current_rms_get_opportunity.

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 scoping to 'one opportunity', but the description never states when to choose this over get_opportunity or the other list tools, nor any prerequisites beyond the required opportunity_id.

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

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

readOnlyHint=true already declares the safety profile, so the description isn't obligated to restate it. It adds genuine value by disclosing the returned breakdown (held/booked/unavailable/on sub-rent/AVAILABLE, sale stock, prices) and the alternate time semantics triggered by starts_at/ends_at, which an agent cannot infer from annotations. Pagination and response envelope are left to 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?

Three tight sentences, front-loaded with what the tool returns, followed by parameter behavior and the API mapping. No filler; each sentence carries distinct information. Slightly dense but appropriate for a 10-parameter list endpoint.

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

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

For a read-only list tool with 10 mostly self-documented parameters, no output schema, and a nested filters object, the description covers what an agent needs: what the payload means, how the date range changes it, and the store scope. It omits pagination/sort behavior, but the schema already documents those, so the gap is minor.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining the semantic effect of starts_at/ends_at (availability computed for a job's dates rather than today) and by extending the filtermode enumerations to active/inactive. store_id's restriction behavior is also restated with intent, not merely the field name.

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+resource ('stock snapshot per product') and enumerates exactly what the snapshot contains (rental quantities held, booked, unavailable, on sub-rent, AVAILABLE, sale stock and prices). It is far more specific than the title, though it never names or contrasts with close siblings like check_product_availability or list_stock_levels.

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 real usage guidance for parameters ('Pass starts_at/ends_at to compute rental availability for a job's dates instead of today, and store_id to restrict to one store'), which tells the agent when the date-window behavior applies. However, it gives no guidance about when to choose this tool over the related availability/stock-level siblings, so the routing decision is left 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 useful context (search covers name/group/tags; the backing endpoint is GET /products) but says nothing about pagination limits, result size, or how the nested filters behave at runtime.

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

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

Three compact sentences, front-loaded with the resource and returned fields, then search behavior, then scope defaults. No filler; every clause carries 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 agent must infer the return shape from the description's field list, which is provided. Combined with a fully documented 7-param schema, the definition is nearly complete; only return/pagination behaviour is left implicit.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, including search scope and the filtermode enum. The description's search and filtermode notes largely restate structured data rather than adding new semantics, 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?

The description states a specific verb ('List') and resource ('products'), and enumerates what is returned (group, stock method, rates, weight, barcode). It implicitly distinguishes itself from the singular current_rms_get_product, but never names an alternative 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?

It clarifies the default scope ('filtermode: active') and what free-text search covers, which implies when to reach for it. However, it gives no guidance on when to use this versus current_rms_get_product, list_product_inventories, or check_product_availability.

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 this as a safe read, so the description only needs to add context. It contributes the search-scope fields and the filtermode default, but says nothing about pagination behavior, result size, or what the listing returns, which are relevant for a 7-parameter list endpoint.

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

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

Three compact sentences plus an endpoint reference; the core purpose and the search/filtermode facts are front-loaded with no filler. The terse 'filtermode: active (default), inactive, all' fragment is slightly telegraphic but efficient.

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

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

For a list tool with readOnly annotations and full schema coverage, the description covers the essentials, but it omits any mention of pagination (page/per_page/sort) and the filters passthrough, which are significant given 7 parameters and a nested filters object. It is adequate 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%, so the schema already documents every parameter in detail, including examples for filters and sort. The only genuine addition is the 'active (default)' value for filtermode, since the enum description does not state the default; the search explanation merely repeats the schema wording.

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 projects') and then defines the domain concept as 'groups of related opportunities for one customer or event', which meaningfully distinguishes it from the sibling current_rms_list_opportunities. It stops short of naming any alternative tool for comparison.

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 resource definition and the filtermode default, so an agent can infer this is the entry point for browsing projects. However, there is no explicit when-to-use/when-not or routing to siblings such as list_opportunities, so guidance remains at the minimum-viable level.

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

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

readOnlyHint=true already declares this is a safe read, so the description need not restate safety. It adds the endpoint mapping and the asset-vs-bulk distinction, but says nothing about result volume, pagination limits, or how the two modes alter the returned shape. With annotations covering the safety profile, this is adequate but not rich.

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 what a stock level is before the routing advice and endpoint citation. Efficient, though the endpoint tail is arguably redundant given the tool name prefix and the schema already carries the filter example.

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 six-parameter read-only list tool with full schema coverage and no output schema, the description supplies the one thing structured fields cannot: what a 'stock level' actually represents. Pagination and nesting are handled by the schema, so nothing critical is missing.

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

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

Schema description coverage is 100%, so page, per_page, sort, filters, include and product_id are all documented in the schema — including the same asset_number_eq filter example. The description's parameter content duplicates 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?

States a specific verb and resource ('List stock levels') and then disambiguates what a stock level is — serialised assets (asset number, serial number, location, store) versus bulk quantities — which no sibling name conveys. It also cites the backing endpoints (GET /stock_levels, GET /products/{product_id}/stock_levels), letting an agent map it against current_rms_list_product_inventories.

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: 'Pass product_id for one product's stock, or use filters such as {"asset_number_eq": "ABC-1234"} to find an asset.' This tells an agent the two main usage modes. It stops short of naming an alternative tool or stating exclusions (e.g., when to prefer current_rms_list_product_inventories), so it is clear context without 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 declares the safety profile, so the description's added value is its disclosure of return content — ids and addresses — which annotations do not cover and which is important since there is no output schema. It also anchors the tool to a concrete API surface ('Current RMS: GET /stores'). No rate limits or auth notes, but for a trivial read that is acceptable.

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 dense sentence front-loads the action and resource, then appends the payoff (the store_id needed downstream) and the API mapping. No filler and nothing repeated from the annotations.

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 parameterless read with no output schema, the description supplies exactly what would otherwise be missing: the return shape (ids and addresses) and the downstream purpose. Nothing an agent needs to call it correctly 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?

The tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. The mention of returning ids is a natural extra, not a parameter concern.

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 account's stores') plus a clarifying gloss ('warehouses/depots'), which disambiguates the domain term. It also names what is returned (ids and addresses), so an agent can distinguish it from sibling list tools like list_products or list_members without opening any 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?

Explicitly gives the selecting condition: this is 'needed for store_id when creating an opportunity', which routes the agent from current_rms_create_opportunity to this tool. It stops short of stating exclusions or alternatives, but the trigger context is clear and actionable.

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 destructiveHint=true already declared, the description earns credit for disclosing the real behaviors that matter: fields are only sent when passed, emails/phones accumulate rather than overwrite, and custom_fields requires membership_type or the API rejects it. It does not cover permissions or rate limits, but it adds substantial context beyond 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?

Five short sentences, front-loaded with the core action and the highest-risk caveats (partial send, additive emails/phones, custom_fields requirement) before the endpoint reference. 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 9-parameter mutation tool with nested objects and no output schema, the description covers the confusing behaviors an agent would otherwise get wrong. The only real gap is not stating that tag_list replaces existing tags, though the schema field description does say 'Replacement tag list.'

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: the additive (not replacing) nature of emails/phones and the membership_type prerequisite for custom_fields. That interpretation guidance is not derivable from the field descriptions alone.

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 ('Update fields on an existing member'), which cleanly separates it from create_member, get_member, and update_opportunity among siblings. It does not explicitly name a sibling to avoid, but the resource scope is unambiguous.

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

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

Gives clear operational context: partial-update semantics ('Only the fields you pass are sent'), that emails/phones are additive rather than replacing, and the coupling of custom_fields with membership_type. It stops short of naming when to prefer a different tool, but the conditions for correct invocation are well stated.

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

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

Annotations declare destructiveHint=true, and the description adds meaningful behavioral context beyond that: partial-update semantics and the exclusion of state transitions (which would otherwise be the most likely accidental mutation). It still doesn't state permission requirements or whether updates are reversible, keeping it short of a 5.

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

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

Three compact sentences: purpose with field list, then the partial-update rule, then the exclusion rule plus API reference. Each sentence carries distinct information and the most important constraint (patch semantics) is front-loaded.

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

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

For a 22-parameter mutation tool with no output schema, the description covers purpose, patch behavior, and exclusions well. It is missing validation/permission notes and a pointer to where state changes are performed, which would complete the picture, but an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description groups parameters by domain (subject, customer, venue, dates, reference, instructions, tags, custom fields), which is mildly helpful for orientation but adds no syntax, format, or edge-case detail beyond the schema.

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

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

States a specific verb (update) and resource (opportunity header fields) and enumerates exactly which fields are editable: subject, customer, venue, dates, reference, instructions, tags, custom fields. It also explicitly distinguishes scope from state changes and maps to the underlying API operation (PUT /opportunities/{id}). An agent can immediately distinguish this from current_rms_create_opportunity or current_rms_get_opportunity.

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

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

Explicitly states patch semantics ('Only the fields you pass are sent') and rules out state transitions ('State changes ... are deliberately not available'), which is strong when-not guidance. However, it does not name which sibling tool to use for those state changes, leaving the agent to search for an alternative.

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