Current RMS MCP by usefulapi

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

Annotations already declare readOnlyHint=true, but the description adds non-obvious behavior: the API surface is POST yet the operation is read-only, and the returned period granularity varies (hour / quarter / half / day) based on the range and a system setting. It does not cover auth needs, rate limits, or result-size 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?

Purpose and scope are front-loaded in the first clause; the em-dash aside listing returned arrays is dense but information-bearing, and the second sentence delivers the POST clarification crisply. Slightly long single sentence but no wasted 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?

With no output schema, the description carries the return-value burden and does so well by naming each returned array and the linked opportunities. It is thin only on error behavior, result limits, and how store_ids scopes the response.

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

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

Schema coverage is 100%, so the baseline is 3; the description still adds meaning by making the single-product constraint explicit and by tying starts_at plus days_period to the resulting period granularity — a behavior of the date-range pair the schema fields alone do not convey. It adds nothing further for store_ids.

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 ('Rental availability'), pins the scope to exactly ONE product over a date range, and enumerates the returned quantities — enough to separate it from sibling list tools like list_stock_levels and list_product_inventories without opening a 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 single-product, date-range framing rather than stated: there is no explicit 'use this when... use X instead' guidance against the stock-level or product-inventory list tools. The 'Read-only, even though the API uses POST' note is useful context but is not usage routing.

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 supply only destructiveHint=true, which the description does not explain or confirm (e.g., what side effects a logged activity has on linked records, whether participants are notified, or whether calendar/notification fan-out occurs). It does correctly convey that this is a write/POST operation, but adds no auth requirements, side effects, or reversibility detail.

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 verb and resource; the endpoint mapping is a short trailing clause. Nothing extraneous, nothing buried.

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

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

For a 14-parameter mutation with no output schema, the description says nothing about the required 'subject' field, what the call returns (e.g., a new activity id), or error/validation behavior. The high schema coverage and the destructiveHint annotation carry most of the load, leaving this adequate but thin.

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% across all 14 parameters, so the schema already documents each field including enum-like values (time_status, priority 1-5). The description only vaguely gestures at targeting ('against a member, opportunity or project') and participants, adding nothing the schema lacks; 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 ('Log an activity') plus the resource, with the activity kinds (call, meeting, task, note) and the records it attaches to (member, opportunity, project) spelled out. An agent can immediately separate this from the read-only sibling current_rms_list_activities.

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 never states when to use this versus alternatives, and no update_activity sibling exists, so the agent gets no routing rule. Only implied usage is conveyed by the word 'Log', with no prerequisites, sequencing, or when-not-to-use guidance.

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

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

Annotations already declare destructiveHint=true and give the title, so the write/mutation nature is covered. The description adds the underlying API call ('POST /members'), which is mildly useful context for an agent working against the Current RMS API. It does not disclose auth requirements, side effects on linked records, or rate limits, so it adds little 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?

Three short sentences, front-loaded with the core action and followed by the one non-obvious linking rule and the endpoint reference. No filler, no repetition of schema content.

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 creation tool with nested objects and no output schema, the description covers the essentials (entity types, the linking case) but omits what the call returns — notably whether the new member's id comes back — and says nothing about required fields or the destructive/creation side effects. Adequate but with real gaps for a mutation tool.

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

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

Schema description coverage is 100%, so every one of the 10 parameters is already documented in the schema, and the description's parent_member_id note largely restates the schema text. Baseline 3 applies; the description adds no new format, constraint, or default information 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 ('Create an Organisation, Contact or Venue') and names the membership_type values, so the agent knows exactly what entity is produced. It is clearly distinguishable from create_activity and create_opportunity by resource. It stops short of explicitly contrasting with update_member or list_members, but the purpose 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?

It provides one useful usage instruction — pass parent_member_id to link a new Contact to its Organisation — which is genuine when/how guidance. However there is no guidance on when to use this vs. update_member, no mention of prerequisites or permissions, and no exclusions. Usage is implied rather than framed.

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 (mutation covered), so the description's main added value is the disclosure that line items cannot be supplied here and must be added in Current RMS, plus the POST /opportunities endpoint. It does not say what the call returns or whether partial failures are possible, leaving meaningful behavioral gaps for a 22-param create.

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 tightly packed sentences that front-load the create action and required parameter before the housekeeping notes. The trailing 'Current RMS: POST /opportunities.' is largely inert for an agent 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 22-parameter mutation with no output schema, the description covers the required field and the critical line-items caveat, which is the most important workflow fact. It stops short of telling the agent what identifier comes back, which matters because line items are added separately and presumably need 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 every field including the state enum mapping is already documented in structured data. The description only restates the store_id/member_id/date trio and adds no format or constraint detail beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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?

Using a specific verb+resource ('Create an opportunity') and glossing the domain term ('a rental job'), it clearly separates this tool from siblings like current_rms_create_member or current_rms_create_activity. The Enquiry/Draft/Quotation states further pin down what is actually being created.

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 prerequisites: store_id is required with a pointer to current_rms_list_stores, member_id identifies the customer, and starts_at/ends_at carry the job dates. However, it never states when to prefer this over current_rms_update_opportunity or how it relates to current_rms_get_opportunity, so routing guidance is only implied.

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

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

The readOnlyHint annotation already establishes the safety profile, so the description only needs to add context. It does disclose the returned data shape (status, due date, totals) and the underlying GET /invoices/{id} call, which is useful, but it says nothing about auth requirements, not-found behavior, or whether credit notes are fetched through the same 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?

A single compact sentence front-loads the operation and the key returned fields, with the endpoint reference appended as a useful footnote. No filler, nothing redundant.

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 compensates by naming the fields the agent will receive, and the include hint covers the embedding option. It is nearly complete for a simple read tool; only the credit-note distinction and pagination/embedding caveats are 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 description coverage is 100%, so both parameters are already documented in the schema, including the enum list for include. The description's mention of include:invoice_items slightly reinforces the schema but adds no syntax or semantics beyond it, making the baseline 3 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 ("Fetch one invoice or credit note") and enumerates the returned facets (status, due date, totals). The word "one" distinguishes it from the sibling list_invoices, though the sibling is never named outright.

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?

"Fetch one invoice" implies a single-record lookup versus the list tool, and the hint to "include invoice_items for the lines" suggests when to populate the include parameter. However, there is no explicit when-to-use/when-not guidance and no alternative tool named, so 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 readOnlyHint=true, so the safety profile is covered, but the description adds valuable detail about what the response contains (addresses, emails, phones, links, parent/child members, custom fields). It does not mention error behavior such as a missing/unknown id, which keeps 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?

One sentence plus the API endpoint reference, front-loading the verb and resource with zero filler. Every clause earns its place by naming retrievable sub-fields.

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 usefully enumerates the returned payload components, which is exactly the compensation needed for a single-param read tool. It is nearly complete; only error/not-found semantics are 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 sole parameter member_id is documented in the schema, so the structured field already carries the meaning. The description's GET /members/{id} restatement adds no syntax or format detail beyond what the schema provides, making the baseline 3 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 (Fetch) and resource (one member) and enumerates the entity types it covers (organisation, contact, venue, user). The 'one member' framing clearly distinguishes it from the sibling list_members and create/update_member tools.

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

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

The singular resource implies 'use when you have a known member id', which is adequate for a by-id getter, but it never explicitly contrasts with list_members or states the precondition that a valid member_id must already be known. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: the include-gated association loading and the meaning of the state codes (0 Enquiry, 1 Draft, 2 Quotation, 3 Order), which the agent would otherwise have to guess.

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

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

Two tight sentences with the core retrieval facts front-loaded and the include caveat immediately after. No filler and the API mapping is appended compactly.

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 the return-shape burden and does so by naming the returned fields and the association-inclusion rule. Nothing an agent needs to call this 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%, so the baseline is 3. The description nonetheless adds meaning beyond the schema by explaining that associations such as customer, venue, line items, assets, and participants are only present when explicitly named in include, clarifying the effect of the include 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?

States a specific verb (Fetch) and resource (one opportunity) and enumerates the fields returned (dates, state, status, charge/cost totals). This clearly distinguishes it from list_opportunities and the update/create siblings in the same namespace.

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

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

The sentence about associations only being returned when named in include gives concrete guidance on how to call it for a fuller payload. It implies single-record retrieval vs. the list sibling but never names list_opportunities as the alternative, so there is no explicit when-not routing.

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 description only needs to add context. It does usefully disclose the payload shape (rates, stock settings, custom fields) and the underlying endpoint, but says nothing about the include parameter's behavior, auth requirements, or missing-record handling.

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 with zero waste; the payload scope is front-loaded and the endpoint reference trails as supplementary 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?

With no output schema, the description partially compensates by naming the returned sections. For a two-parameter read tool with full schema coverage and a readOnly annotation, this is nearly sufficient, though error/not-found 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 description coverage is 100%, so product_id and include are already documented in the schema and the baseline is 3. The description adds the endpoint template GET /products/{id}, which only lightly reinforces the required id parameter and gives no detail on the include enum.

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) and names the returned payload (rates, stock settings, custom fields), which implicitly separates it from current_rms_list_products. It does not explicitly name that sibling, so differentiation is inferred 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?

Singular 'one product' implies retrieval by id for a single item rather than a listing, giving implied guidance. There is no explicit when-to-use statement, no exclusion, and no pointer to current_rms_list_products as the alternative for browsing.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the upstream endpoint (GET /activities) and filtermode semantics, but says nothing about result volume, pagination defaults, or ordering determinism — details that matter for a list endpoint and are only partly 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?

Front-loaded with the verb/resource/scope, then filtermode, then a single concrete example. The example JSON is bulky but earns its place by showing operator syntax. No filler sentences.

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

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

For a read-only list tool with full schema coverage and annotations carrying the safety signal, this covers what the agent needs to invoke correctly. With no output schema, it still leaves the returned shape and pagination behavior implicit rather than stated.

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 a 3 is the baseline. The description exceeds it by explaining filtermode's three values and by demonstrating a non-obvious filter construction (time_status_eq + starts_at_lt + ends_at_gteq with an array participant key) that the schema's generic filters examples do not illustrate.

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 (activities), and goes further by enumerating what an activity is — calls, meetings, tasks, notes — and the entities they attach to (members, opportunities, projects). That scope cleanly separates it from the other list_* siblings, though it never names an alternative tool to route against.

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 real usage signal: the filtermode values (pending/completed/all) and a worked example for the common 'one person's busy time in a window' query, which tells the agent how to combine time_status with starts_at/ends_at and participants_member_id. It stops short of explicit when-not-to-use-this or naming a competing 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?

readOnlyHint=true already establishes the safety profile, and the description layers on useful context: which fields are returned, what free-text search covers, the filtermode semantics, and the upstream endpoint (GET /invoices). It omits pagination/rate-limit behavior, but the essential read-only semantics and result shape are disclosed.

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?

Purpose and returned fields are front-loaded, and the opportunity-filter tip is dense and high value. Some sentences duplicate schema content (search scope, filtermode enum values) and the trailing 'Current RMS: GET /invoices' is low-information, but overall the length is proportionate.

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 usefully states the returned fields, which an agent needs before calling a list tool. Given 8 params, a nested filters object, and no required args, the description covers the main retrieval paths; pagination/sort behavior is left entirely to the schema, which is acceptable since page/per_page/sort are documented there.

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 3 baseline applies, but the description adds meaning beyond the schema by giving a concrete filters recipe (invoice_items_source_type_eq=Opportunity, invoice_items_source_id_eq=<id>) combined with filtermode all, which the generic filters description does not explain.

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

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

States a specific verb+resource ('List invoices and credit notes') and enumerates the fields returned (number, dates, status, totals), which is more than the title alone. It does not explicitly contrast with the list-vs-get sibling (current_rms_get_invoice), but 'List' vs 'get' makes the scope 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 concrete, actionable usage context: it names the free-text search fields and gives an exact filter payload for the non-obvious 'one opportunity's invoices' scenario with filtermode all. It stops short of when-not-to-use guidance or explicitly routing to current_rms_get_invoice for single-record lookups.

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=true already covering the safety profile, the description adds genuinely useful behavior: the default-to-active-records filtering (a subtle trap an agent would otherwise miss), the exact fields search hits, and the full set of filtermode options beyond the schema's example list. It does not mention pagination limits or rate limiting.

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-loads the purpose and entity definition, then packs search scope, defaults, and filter modes into one dense but readable sentence. The filtermode enumeration partially duplicates the schema, which is the only mild waste.

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 no output schema, the description covers the critical unknown (default active-only filtering), the search surface, and the filter vocabulary. Sort, paging, and per_page are fully documented in the schema, so nothing an agent needs to call this 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%, so baseline is 3, but the description earns extra credit by enumerating filtermode values (with_pending_activities, with_live_opportunities, bookable) that the schema description only hints at with 'e.g.', and by restating which fields search matches.

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 members') and goes further by defining what a member is in this system — Current RMS's single record type covering Organisations, Contacts, Venues and Users — which is essential domain context an agent cannot infer. Implicitly distinct from the get_member/create_member/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?

Gives strong operational context: free-text search covers specific fields, results default to active records, and the filtermode values enumerate the ways to widen or narrow scope. It does not explicitly state when to prefer get_member instead, but the list-vs-single-record distinction is clear from the name.

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

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

readOnlyHint=true already covers the safety profile, and the description adds genuinely useful behavior beyond it: a hard 25-records-per-page cap, the fact that line items are omitted from results, and which fields free-text search actually scans. It does not mention any auth/permission constraints or how the API responds on unknown predicates, but for a read-only list endpoint the disclosed behavior is above 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?

Front-loaded with the resource definition, then search scope, filtermode values, the line-item exclusion and the pagination cap – every sentence carries operational information. The trailing 'Current RMS: GET /opportunities' is provenance rather than usage guidance, a minor piece of low-value text, but the overall structure is tight.

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, nested-object list tool with no output schema, the description covers what is returned in outline (dates, state, charge totals), what is deliberately missing (line items), pagination limits and alternative tools. The complex filters/sort/include parameters rely wholly on the schema, which documents them well, so only the return-shape detail is thin.

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 earns an extra point by expanding the filtermode enumeration well beyond the schema's 'live, all, quotations, orders, not_invoiced' (adding inactive, enquiries, drafts, invoiced, not_invoiced, needing_prep) and by restating search coverage, both of which help an agent pick valid values without guessing.

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

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

Opens with a specific verb+resource and immediately disambiguates the domain term: opportunities are 'the enquiries, drafts, quotations and orders for a rental job'. It also delineates scope against siblings by stating line items are excluded and naming current_rms_get_opportunity / current_rms_list_opportunity_items as the alternatives, so an agent can separate it from other list tools without reading their schemas.

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

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

Clearly frames the tool as the paginated browse/search entry point and explicitly routes line-item needs to two named siblings, plus enumeration of filtermode values signals the filtering scenarios it supports. It stops short of a full when-when-not statement (e.g. when to prefer get_opportunity by id over listing), but the practical context is unambiguous.

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 safe-read profile is covered. The description adds useful behavioral context by disclosing the returned line-item fields and the underlying GET endpoint, though it omits pagination behavior and authorization 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?

Two tightly written sentences with zero filler. The core purpose and returned contents are front-loaded, and the endpoint reference is supplementary rather than padding.

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

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

For a read-only list tool without an output schema, the description supplies the essential purpose, scope, and return contents while annotations cover safety and the schema covers pagination and include options. The only minor gap is that pagination behavior and association embedding could be explicitly acknowledged, but the schema sufficiently compensates.

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 page, per_page, include, and opportunity_id. The description repeats the opportunity_id concept in the endpoint but adds no parameter-level syntax, defaults, or embedding semantics 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 the specific verb 'List' and the exact resource 'line items on one opportunity', then enumerates the contained fields (products, services, groups, quantity, rate, discount, dates, charge totals). No sibling tool lists opportunity line items, so an agent can distinguish it immediately from get_opportunity or list_opportunities.

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

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

The description gives clear context—one opportunity, line-item contents—which implies usage when an agent needs those details. However, it never states when to use this tool versus get_opportunity or list_opportunities, and offers no exclusions or 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds real behavioral context beyond the schema: availability defaults to today unless a date range is supplied, and filtermode selects built-in active/inactive/all/rental/sale subsets. It does not disclose pagination defaults or response shape, but the added semantics are substantive.

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 its returned fields, then usage for the date/store params, then filtermode. Dense with facts and little waste, though the endpoint suffix is minor 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-param read-only list with nested filters and no output schema, the description conveys the essential return content and the two most consequential param behaviors, while the fully-described schema handles the rest. It could say more about combined date+store filtering and pagination, but 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?

With 100% schema coverage the baseline is 3, but the description adds meaning the schema lacks: it explains the semantic effect of starts_at/ends_at (recompute rental availability for a job's dates instead of today) and enumerates filtermode values not listed as an enum in the schema. Other params (sort, search, filters, view_id, page, per_page) are only covered by 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 concrete resource ('stock snapshot per product') and enumerates exactly what is returned: rental held, booked, unavailable, sub-rent, AVAILABLE, plus sale stock and prices. It even names the underlying endpoint (GET /product_inventories), so an agent can distinguish it from siblings like list_stock_levels or check_product_availability.

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 key usage choice: pass starts_at/ends_at to compute availability for a job's dates vs defaulting to today, and store_id to narrow to one store. It does not contrast against sibling tools (e.g. check_product_availability, list_stock_levels), so it stops short of full when-not guidance.

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

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

Annotations already declare readOnlyHint=true, and 'Current RMS: GET /products' confirms the read-only nature. The description adds nothing about pagination behavior, default page size interaction, or rate limits; against annotations that carry the safety profile, this is a minimal-value addition.

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 compact sentences, front-loaded with what the tool returns before the search/filter notes and the API endpoint. Nothing is redundant enough to waste space, though the trailing endpoint reference is informational rather than actionable.

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 no output schema, the description usefully enumerates the returnable fields (group, stock method, rates, weight, barcode) and the searchable fields, which compensates for the missing output schema. Pagination defaults beyond per_page are left to the schema, which is 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%, so all seven parameters are already documented, including search's covered fields and the sort pattern. The description does add one piece of value by stating that filtermode defaults to 'active', which the schema's enum description does not, but otherwise it largely restates schema content.

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 clear verb+resource ('List products') and adds scope by parenthetically naming the domain ('rental and sale items') and the fields returned. This distinguishes it from the singular get_product sibling, though it never names that sibling explicitly, so differentiation is implied 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?

Usage is implied by the definition of the resource and by 'filtermode: active (default), inactive, all', which tells the agent how to broaden or narrow the listing. There is no explicit when-to-use vs. an alternative (e.g., list_product_inventories or get_product) or any 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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds real behavioral value by disclosing the default filtermode and the exact fields free-text search spans, but says nothing about pagination limits, result ordering, or response 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?

Two compact sentences, front-loaded with the resource definition followed by the two facts that affect invocation (search scope, filtermode default). The trailing 'Current RMS: GET /projects' endpoint note is mild filler but not disruptive.

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

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

The tool has 7 optional params including a nested free-form filters object and no output schema, so the description could say more about pagination and what a project record contains. The schema carries most of the load, leaving the description adequate but not complete for a list tool with no declared return shape.

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 contributes the default value for filtermode (active) and restates search scope, but adds little beyond the schema, which already documents page, sort, filters, view_id and per_page in 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+resource (list projects) and adds a definition of what a project is ('groups of related opportunities for one customer or event'), which helps an agent distinguish it from the many list_* siblings. It stops short of explicitly naming which sibling to use instead, but the resource nouns are distinct enough that confusion is unlikely.

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 useful operational context (search covers name/customer/tags; filtermode defaults to active), which implies when to reach for this tool. However, there is no explicit when-to-use vs alternatives guidance and no stated exclusions, so 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 readOnlyHint=true, so the read-only nature is covered. The description adds the underlying REST endpoints, which is modestly useful context, but says nothing about result volume, pagination limits, or what 'bulk stock quantities' returns versus serialised assets beyond the initial gloss.

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 resource definition before the usage instructions, with no filler. The trailing endpoint notation (GET /stock_levels or GET /products/{product_id}/stock_levels) is marginally redundant but cheap and accurate.

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 6-parameter, zero-required list tool with no output schema and read-only annotations, the description covers scope, the two calling modes, and the key filter idiom. Return-shape and pagination expectations are the only meaningful omission, and the tool name plus schema imply a paged 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 description coverage is 100%, so every parameter is already documented in the schema, making 3 the baseline. The description reinforces product_id and offers a filter example (asset_number_eq), but adds no format or constraint detail beyond what the schema and its examples already provide.

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 (stock levels), then immediately defines what a stock level is: individual serialised assets (asset number, serial number, location, store) or bulk stock quantities. This distinguishes it from siblings like list_product_inventories and check_product_availability without needing their schemas.

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

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

Gives concrete usage paths: pass product_id for a single product's stock, or use filters like {"asset_number_eq": "ABC-1234"} to locate an asset. It lacks explicit when-not guidance or a named alternative (e.g. check_product_availability) for the case where an agent wants availability rather than inventory listing.

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, non-mutating read, so the description's main addition is the underlying endpoint (GET /stores) and the returned fields. It says nothing about pagination, result size, or auth scope, but with annotations covering the safety profile this is adequate if 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?

A single front-loaded sentence delivers the resource, the returned content, and the downstream use case, followed by a terse endpoint reference. No sentence 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?

With no output schema, the description must describe what comes back, and it does — ids and addresses. For a zero-parameter list tool with a readOnly annotation, 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?

The tool takes zero parameters, so the schema carries no semantics to supplement and the baseline is 4. The mention of store_id is about a downstream consumer of this output rather than an input here, so it adds no parameter meaning but also costs nothing.

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 account's stores), disambiguated as 'warehouses/depots', and even previews the returned data (ids and addresses). An agent can distinguish this from list_products/list_members/list_invoices without inspecting 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?

Gives a concrete when-to-use trigger — you need this to obtain store_id when creating an opportunity — which directly links it to a sibling workflow. It stops short of naming the alternative tool or stating any exclusions, so it is clear context rather than full routing 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 only annotation is destructiveHint=true, so the description carries most of the burden and does so well: it discloses partial-patch semantics and that email/phone entries are ADDED rather than replacing existing values. It does not explain merge-vs-replace behavior for custom_fields or any permission 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?

Four short sentences, zero filler, with the most important constraint (partial update) and the unusual additive/additive/coupling behaviors front-loaded ahead of the API endpoint reference.

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 with no output schema, the description covers the non-obvious semantics well. Minor gaps remain on permission/auth requirements and how custom_fields values merge, but nothing essential to invoking 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?

With 100% schema coverage the baseline is 3, but the description adds real meaning beyond the schema: the additive nature of emails/phones and the cross-parameter dependency that custom_fields requires membership_type. That coupling is the key operational detail an agent needs.

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'), and 'existing' implicitly separates it from the sibling create_member. It does not explicitly name or contrast with update_opportunity or other siblings, so it stops short of full differentiation.

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 operating context: only passed fields are sent (partial update), emails/phones are additive, and custom_fields updates require membership_type. No explicit when-not-to-use or alternative-tool routing is provided, so it is strong but not 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 destructiveHint=true, so the mutation risk is covered. The description adds value beyond that: partial-update semantics (unpassed fields untouched) and the deliberate exclusion of state changes, which is important behavioural context an agent would otherwise guess at. Auth/permission and reversibility details remain 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?

Three tight sentences, zero filler, and the primary action and partial-update rule are front-loaded before the exclusions and endpoint. Every sentence 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?

For a 22-parameter mutation with no output schema, the description covers the essentials: scope, partial-update behaviour, and excluded operations. It could say more about permissions or failure modes, but nothing critical to calling 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% across 22 parameters, so the schema already documents each field with its own description. The description's field-family summary ('subject, customer, venue, dates, reference, instructions, tags, custom fields') is a useful grouping but adds no semantics beyond what the schema provides, 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 ('Update header fields on an existing opportunity') and enumerates the field families affected. It also explicitly carves out what the tool is not (state transitions like convert/cancel/mark lost), which separates it from the create and get 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?

Gives clear usage context: 'Only the fields you pass are sent' tells the agent this is a partial update, and it explicitly excludes state changes. It stops short of naming which sibling to use for those excluded operations, so it is not a full when/when-not/alternative statement.

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