Bind ERP MCP by usefulapi

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

Adds real information beyond the annotations: the comment becomes part of the record's history and cannot be removed through this API, which tells the agent the write is persistent and irreversible via the surface it has. This doesn't contradict destructiveHint=false (no existing data is overwritten), but the description doesn't mention auth/permission needs or what is returned.

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

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

Three short sentences, front-loaded with the action and scope, then the persistence caveat, then the endpoint. Nothing is redundant or padded.

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

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

For a two-parameter mutation with full schema coverage and no output schema, the description covers purpose, target, and the key durability caveat. Only minor gaps remain (no mention of what the call returns or any permission requirements).

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 (comment text, external_id) are already fully documented in the schema, including the GUID pattern and length bounds. The description only restates that the record is identified by a GUID, adding no new syntax or constraint detail.

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

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

States a specific verb and resource ('Add a comment to a Bind ERP record') plus the identifier type (GUID) and the endpoint. No sibling tool handles comments, so the agent can immediately tell this apart from the create_*/get_* family.

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 usage context is implied by 'Add a comment to a record' and the examples (client, prospect, order), but there is no explicit when-to-use or when-not-to-use guidance and no named alternative. Since no sibling competes for this action, the omission is mild rather than harmful.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, but the description adds genuinely useful behavioral context beyond them: the record includes credit terms, the operation is not deduplicated, no message is sent, and the RFC must pass tax-authority validation. These details materially affect how an agent should sequence calls and what side effects to expect.

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, each earning its place: purpose, write behavior and non-deduplication, the dedup check, the RFC rule, the side-effect note, catalog sourcing, and endpoint. The critical caveat (not deduplicated) is front-loaded near the start.

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 13-parameter mutation tool with no output schema and a nested address object, the description covers the key behavioral risks: non-idempotency, no messaging side effect, catalog dependencies, and RFC constraints. It could be slightly more complete by mentioning what the call returns (e.g., the created client id) or permission requirements, but the essential invocation guidance is present.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description still adds value by naming the sibling catalogs that supply price_list_id and location_id and by explaining the RFC validation rule and the generic RFC fallback, though it does not cover all 13 parameters at the same depth.

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

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

States a specific verb and resource ('Create a customer in Bind ERP') and immediately distinguishes it from related operations by naming the deduplication check against binderp_list_clients and the catalog lookups needed. An agent can tell this apart from binderp_create_prospect or binderp_create_order 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?

Gives explicit preconditions and alternatives: check binderp_list_clients for the RFC first because the operation is not deduplicated, pull price_list_id and location_id from binderp_list_catalog, and ensure the RFC is valid or use the generic XAXX010101000. This is clear when-to-use guidance with concrete routing to sibling tools.

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

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

Adds real side-effect disclosure beyond the annotations: the order reserves stock and appears in the sales pipeline, and no email is sent. This is the kind of consequence an agent needs before a non-idempotent write. It stops short of mentioning auth requirements, failure modes, or what is returned.

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

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

Three dense sentences, front-loaded with the identity and the not-an-invoice clarification, then prerequisites, then id sources, then the endpoint. No filler and nothing buried at the end.

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?

Covers the mutation's consequences and the prerequisite lookups well for a 12-parameter write tool. The notable gap is that, with no output schema, the description never says whether the call returns the new order id or total, which matters for chaining.

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, including the GUID formats and the source list tools. The description adds only the general instruction to fetch ids from the list tools, which largely duplicates the schema notes. 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 ('Create a customer order') and immediately disambiguates from the nearest confusing sibling by clarifying it is a pedido, not an invoice, and that nothing is stamped or emailed. An agent can tell exactly what this produces versus binderp_get_invoice or quote 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?

Gives concrete preconditions ('confirm client, prices and quantities first') and explicitly routes the agent to the lookup tools for each id (binderp_list_clients, binderp_get_client_addresses, binderp_list_catalog, binderp_list_products). It does not spell out when to choose an order over a quote/purchase order, so it stops short of full alternative 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 already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the write/safety profile is known. The description adds genuinely new behavioral facts: the record is team-wide visible, it is not deduplicated, and no message is dispatched to the prospect. It does not say what the response contains (e.g., the new prospect ID), which is the remaining gap.

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

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

Three short sentences, front-loaded with the action and followed by the two most decision-relevant caveats (no dedup, no notification) plus the endpoint. No filler.

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

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

For a non-idempotent, open-world create with no output schema, the description covers visibility, dedup behavior and side effects. It leaves open what is returned and whether the prospect must be unique by email, but the essentials for a correct call are present.

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

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

Schema description coverage is 100% with clear per-field descriptions, so the schema already carries parameter meaning. The description adds nothing field-specific beyond the implied 'name' requirement and the is_public/team-visibility hint, 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 ('Create a sales prospect (lead) in Bind ERP') and implicitly distinguishes the record type from the sibling create_client/create_order tools. An agent can tell exactly what object is 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?

Explicitly routes the agent through binderp_list_prospects first, which is a concrete pre-call check. It stops short of naming when to use binderp_create_client instead (e.g., a company that is already a customer), so the alternative pathway 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that the scope is the calling key's own account, which is genuinely useful context, but says nothing about behavior on an invalid/expired key, permissions, or caching/rate limits on these profile endpoints.

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 listing exactly the covered fields, followed by the two backing endpoints. The endpoint paths (GET /api/UserProfile and /api/CompanyProfile) are mildly redundant for an agent and border on filler, but the sentence itself is efficient and non-repetitive.

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 it well by enumerating user name, email, roles, branches, company name, RFC, legal/commercial name, fiscal type and address. What's missing is edge-case behavior (no key, invalid key) and whether branches/roles are returned as arrays — minor for a simple 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?

The tool takes zero parameters, so there is no schema semantics to compensate for; the baseline for a no-param tool applies. The description correctly implies the account is determined implicitly by the API key rather than by any argument.

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

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

States a specific resource (the user and company the current API key belongs to) and enumerates the fields returned. No sibling tool covers account/profile data, so an agent can tell immediately that this is the identity endpoint rather than a client/order/invoice lookup.

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

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

Usage is only implied: an agent infers it should call this to learn who the key belongs to or which company/branch context applies. There is no explicit when-to-use statement, no pruning against alternatives, and no note about when it should be called (e.g., before creating orders that need branch/RFC data).

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered externally. The description adds value by enumerating the returned fields (credit terms, price list, contacts, addresses), effectively describing the payload despite no output schema. It does not mention not-found behavior, auth requirements, or whether related entities are embedded or referenced by id.

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 and no filler, but the first is a verbless noun phrase that reads like a response-field dump rather than a purpose statement. A front-loaded 'Fetch a single client by GUID' would have made the intent clear in the first few words.

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

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

For a one-parameter read tool with full annotation coverage and no output schema, listing the returned fields is the main missing piece and the description supplies it. The remaining gaps (not-found behavior, whether addresses are embedded) are 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 coverage is 100%: client_id is documented as a GUID produced by the list tools, with a UUID pattern. The description adds nothing about the parameter beyond the URL template. Baseline 3 is appropriate when the schema already carries the semantics.

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

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

The description enumerates what a client record contains and appends the endpoint GET /api/Clients/{id}, so an agent can infer this fetches a single customer. However, it never states a verb like 'retrieve' or 'fetch', and the phrase 'One customer' is the only signal that it is singular. It does not contrast itself with binderp_list_clients or binderp_get_client_addresses, so sibling differentiation is left to inference.

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

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

There is no guidance on when to use this tool versus binderp_list_clients (for finding clients) or binderp_get_client_addresses (for address-only lookups). No prerequisites or exclusions are stated. The only implicit cue is the URL template, which an agent must decode itself.

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 establish that this is a read-only, non-destructive operation. The description adds that it is a GET endpoint under /api/Clients/{id}/Addresses, but it does not discuss authentication, pagination, empty results, or the shape of the returned addresses.

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

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

Two short sentences with no waste. The core purpose and the key return-value caveat are front-loaded, followed by the endpoint for completeness.

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 operation with annotations covering safety, the description is nearly complete: it says what is returned and why the ids matter. It stops short of describing the returned address fields or whether multiple addresses are expected, which would help since no output schema exists.

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

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

Schema coverage is 100%, so the single client_id parameter is already documented in the schema. The description adds only the path template GET /api/Clients/{id}/Addresses, which confirms the parameter's role but does not add meaningful 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 resource (addresses of a customer) and adds useful semantic context: the ids are what an order needs as address_id. It is clear what it does, but it does not explicitly distinguish itself from siblings such as binderp_get_client or binderp_list_clients.

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

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

The phrase 'the ids that an order needs as address_id' signals the practical use case: retrieving address identifiers before creating an order. However, it does not explicitly state when not to use it or name an alternative for related 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds real value beyond that: it names the underlying endpoint (GET /api/Inventory?warehouseID=) and spells out the returned fields, which is important since there is no output schema. It omits any pagination note, though the schema hints at it via next_skip.

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 returned-field inventory is front-loaded and the filter hint follows. The trailing 'GET /api/Inventory?warehouseID=.' is slightly awkward but carries endpoint information rather than being 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 correctly compensates by listing what each row contains, and the schema fully covers paging and filter syntax. A brief note on pagination behavior or warehouse-scope caveats would make it fully complete, but nothing essential is missing for a read-only listing call.

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 five parameters are already documented, including the OData filter syntax. The description only echoes the filter example already in the schema and adds no new meaning for top/skip/orderby, so the baseline 3 applies.

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

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

States a specific verb+resource+scope: stock of every product in one warehouse, and enumerates the returned measures (inventory, balance, client/purchase order quantities, value, SKU). It does not explicitly distinguish itself from the nearby sibling binderp_list_products_with_price_and_stock, so it stops short of a 5.

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

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

Usage context is implied by the filter example ('CurrentInventory lt 5 for low stock'), which shows when the tool is handy, but there is no explicit when-to-use/when-not guidance and no named alternative among siblings such as list_products_with_price_and_stock.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine value by enumerating the returned fields (payments, credit notes, product/service lines) in the absence of an output schema, but says nothing about auth requirements, error behavior for a missing invoice, or pagination/size of 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 compact sentences plus an endpoint reference, with the payload contents front-loaded. The opening noun phrase lacks a verb, so it reads as a field list rather than a stated action, but nothing is padded or 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 enumeration of returned data is the key compensating detail, and it is present. What remains thin is behavioral context around failures and identity resolution (GUID vs number precedence), which matters for an open-world lookup 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%, and the description's 'Takes the invoice GUID or its number' restates the schema field description almost verbatim rather than adding format hints (e.g., typical invoice number pattern). With a single fully documented parameter, the baseline 3 applies.

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

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

The description states the resource (a single invoice/sale) and enumerates the payload it carries (client, status, payment terms, totals, lines), which is specific. The implied verb is 'retrieve one' rather than list, which distinguishes it functionally from list_invoices, but sibling tools like get_order and get_quote are never named or differentiated.

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

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

Usage is only implied: 'One sale' signals a single-record fetch in contrast to the list_* siblings, and the GUID-or-number note hints at lookup by either key. There is no explicit 'use this when…' statement, no exclusion of alternatives such as list_invoices, and no mention of what to do if the identifier 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 readOnly=true, destructive=false and openWorld=true, so the safety profile is covered. The description adds real value beyond them by enumerating the returned payload (address, status, totals, product and service lines), which is important since there is no output schema. It does not mention behavior for a missing or invalid order id.

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

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

Two short clauses, front-loaded with the resource and its payload contents, followed by the underlying endpoint. Nothing is redundant and every phrase earns its place.

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

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

With no output schema, the description correctly compensates by listing what the response contains, and the annotations cover the safety profile, so an agent can call it competently. The only missing piece is error or not-found behavior on an unknown order id.

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

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

Schema description coverage is 100%: the single order_id parameter already documents the GUID pattern and that ids come from the list tools. The description adds no further parameter guidance, so the baseline of 3 applies.

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

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

States the specific resource and scope: 'One customer order with address, status, totals and its product and service lines,' which clearly separates it from binderp_list_orders and the create/update siblings. The verb is only implied by the tool name and the embedded 'GET /api/Orders/{id}' path rather than stated directly, so it falls 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 only implied: 'one' order versus the list siblings suggests fetch-by-id, and the schema's 'as returned by the list tools' hints at the follow-up flow. There is no explicit statement of when to use this instead of binderp_list_orders or the related binderp_get_invoice / binderp_get_quote tools.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine value by disclosing payload composition — that prices are broken out per price list and inventory per warehouse — which tells the agent it can answer pricing/stock questions without separate get_inventory calls.

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

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

Two compact sentences, front-loaded with the returned content rather than the endpoint. The REST path is slightly redundant but cheap and useful for debugging; nothing else could be cut.

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

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

No output schema exists, so the description must carry the return-value burden, and it does so reasonably well by naming the four payload sections. Gaps remain (pagination irrelevant here, but no note on error behavior or whether missing products return empty vs. 404).

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%: the single product_id parameter is documented with type, a GUID pattern, and a note that it is 'as returned by the list tools'. The description adds nothing further about the identifier, so the baseline 3 applies.

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

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

Specific verb+resource ('One product') plus an enumeration of exactly what the payload contains (prices per price list, inventory per warehouse, categories, alternative units). 'One' implicitly contrasts with the sibling list_products / list_products_with_price_and_stock, but the contrast is never stated, so it stops short of a 5.

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

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

Usage is only implied: fetching detail for a single known product_id. There is no explicit when-to-use guidance and no mention of the overlapping sibling list_products_with_price_and_stock, which returns the same price/stock information but for many products — a distinction the agent must infer.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned field set and the underlying endpoint, but says nothing about behavior on a missing/invalid ID or any auth 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 compact sentences with the resource and field list front-loaded; the endpoint path is marginally useful as a lookup aid. Nothing is padded, though an explicit verb would have cost nothing.

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

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

With only one parameter and no output schema, listing the returned fields is exactly the compensation needed so an agent knows what comes back. Missing only error/not-found behavior and a pointer to list_prospects for ID discovery.

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

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

Schema description coverage is 100% and the single parameter already documents the GUID format and provenance ('as returned by the list tools'). The description adds no parameter detail beyond the schema, so the baseline 3 applies.

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

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

States the specific resource and that it returns a single prospect, then enumerates the returned fields, which distinguishes it from the sibling list_prospects. It never uses an explicit verb like 'retrieve', relying on 'One prospect:' to convey the operation.

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

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

No when-to-use guidance and no mention of alternatives such as list_prospects for finding IDs or get_client for converted prospects. The agent must infer that this is the fetch-by-id path from the name and the endpoint string alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered externally. The description adds the response composition (lines, received quantities, totals) and the underlying route, but says nothing about not-found behavior, error shape, or live-data freshness despite openWorldHint=true.

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

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

Two short, front-loaded sentences with no filler; the payload summary leads and the endpoint trails as supporting context. Slightly telegraphic phrasing ('One purchase order with...') costs a little clarity but nothing is wasted.

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

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

With no output schema, the description must carry the return shape and does sketch it (lines, received quantities, totals). For a single-record getter it still omits failure behavior (missing id, permission errors) that an openWorldHint read tool would warrant.

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

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

Schema description coverage is 100% and the single parameter is fully documented, including its GUID pattern and provenance ('as returned by the list tools'). The description adds no parameter information beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource (fetch one purchase order by id) and enumerates the returned payload: product lines, quantities received, and totals. That distinguishes it from binderp_list_purchase_orders without naming the sibling, so it stops 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?

There is no explicit when-to-use statement or named alternative. Usage is only implied by the singular 'One purchase order' plus the required id, which an agent can infer means 'use after a list tool gives you a GUID' — but nothing in the text says so.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is clear. The description adds useful behavioral context by describing what data is returned: client/prospect, totals, and line items. It stops short of covering error behavior or authorization details, which is acceptable given the simple read-only nature.

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

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

The description is two compact sentences with no filler. The core return content is front-loaded, followed by the endpoint reference, making it easy to scan.

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

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

For a single-parameter read tool with full schema coverage and clear annotations, the description provides enough context: it specifies the resource, identifies the parameter type through the schema, and summarizes the returned data. No output schema exists, but the description sufficiently communicates the key return contents.

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

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

Schema description coverage is 100%, and the quote_id parameter is documented as a GUID returned by list tools. The description does not add meaning beyond the schema, but the schema already handles parameter semantics adequately, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb-resource pair, 'Get quote', and states the returned content: a single quote with client or prospect, totals, and line items. It implicitly distinguishes itself from list_quotes by saying 'One quote', but does not explicitly name the sibling or contrast the use cases.

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 operation: retrieve one quote by id. However, the description does not explicitly say when to use this instead of list_quotes or other quote-related tools, nor does it state any preconditions or exclusions.

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

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

Annotations already declare readOnly=true, destructive=false and openWorld=true, so the safety profile is covered. The description adds real context beyond that: it names the backing endpoint (GET /api/Activities) and enumerates the shape of each returned row, which matters since no output schema exists. It does not discuss rate limits, page-size caps, or total counts, but the schema covers paging.

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 the resource and returned fields front-loaded and zero filler. The trailing "GET /api/Activities" is marginally useful endpoint trivia but not wasteful enough to hurt.

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

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

For a read-only, zero-required-parameter list tool with full schema coverage, the definition gives the entity scope, the returned fields, and the endpoint. Since no output schema exists, listing the fields is the key compensation, and it is done. Only the filtering/paging workflow and usage routing remain unstated, which the schema largely handles.

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

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

Schema description coverage is 100%, with top/skip/filter/orderby each fully documented including OData syntax examples, so the baseline of 3 applies. The description contributes nothing about the parameters, not even that filter can target Done or client fields, which would have been a useful hint given the listed 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 CRM activities") and enumerates the entity types and the fields returned (title, start/end, owner, done flag, type, related client/prospect), which an agent can use to tell it apart from the other list_* siblings that cover different resources. It stops short of any explicit contrast with a sibling, but no sibling covers activities, so ambiguity is low.

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

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

Usage is only implied by the verb "List" and the mention of client/prospect association. There is no guidance on when to prefer this over binderp_get_client or binderp_list_prospects, nor any note that it supports server-side filtering to narrow to one client's activities. An agent must infer its role from the name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral detail — bank_accounts come back with balances — but says nothing about pagination semantics beyond the schema, result size, or that catalogs are large reference sets. Adequate but thin on top of 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?

Two sentences, front-loaded with purpose, then the endpoint mapping. The endpoint list is partially redundant with the enum but is short and serves as a mental model for what each catalog contains. No wasted prose.

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

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

For a read-only paginated lookup with fully documented parameters and annotations, the description covers the essentials: which catalogs exist, why you'd fetch them, and that one catalog carries balances. Without an output schema, it could have sketched the returned fields per catalog, but nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema already documents top/skip/filter/orderby in detail. The description earns one notch above baseline by explicitly enumerating the catalog values and mapping them to REST endpoints (/api/Locations, /api/Warehouses, ...), plus the branches/employees alias that the raw enum does not convey.

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

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

States a specific verb and resource ('List one of the reference catalogs') and immediately scopes it to the set of lookup tables whose ids other tools need, which cleanly separates it from the sibling list tools that return clients, orders, invoices, etc. The parenthetical aliases ('locations (branches)', 'users (employees)') resolve name mismatches with the title.

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?

'whose ids other tools need' gives a clear reason to call this (resolving foreign-key ids before create/get calls), which is real usage context rather than a bare restatement. It does not state when not to call it or name a concrete alternative tool, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the underlying endpoint (GET /api/Clients) and the returned field set, which is useful, but says nothing about pagination behavior or result volume beyond what the schema documents.

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

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

Two dense, front-loaded sentences plus the endpoint: the field list leads, the filtering hint follows, and nothing is wasted. Every clause carries information an agent can use.

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, listing the returned fields is exactly the right compensation, and the filter syntax example rounds it out. Pagination via top/skip/next_skip is covered by the schema, so the only mild gap is not mentioning it at all in the description.

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 each of the four parameters is well documented there, so the baseline is 3. The description's OData example duplicates the schema's filter example rather than adding new semantics such as how orderby interacts with filtering.

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

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

States a specific verb and resource ('List customers') and enumerates the returned fields, so an agent understands exactly what it gets back. It doesn't explicitly differentiate from siblings like binderp_get_client or binderp_list_prospects, but the plural list shape is clear enough. Minor terminology drift (customers vs. clients) is harmless.

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

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

Usage is only implied: the OData filter example shows how to narrow results, but there is no statement of when to use this versus binderp_get_client (single record) or binderp_list_prospects. An agent can infer context but must reason about alternatives on its own.

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 this a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description goes beyond that by disclosing the returned fields (date, account, amount, status, registrant), which matters because there is no output schema. Pagination behavior is left to the schema, so it is not fully complete but well above the annotation baseline.

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 the tool returns, then the endpoint. Every clause carries information; nothing is redundant or padded.

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

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

For a simple read-only list with no output schema, the description supplies the result fields and the scoping entity, while paging and ordering are fully covered by the schema. Only minor gaps remain, such as default ordering of payments.

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 all four parameters — including top/skip paging and OData orderby syntax — are documented in the schema. The description only reinforces that invoice_id scopes the lookup to a single invoice, adding little beyond structured data. 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: lists payments registered against a single invoice, with the field set enumerated. This is clearly distinct from binderp_get_invoice (invoice header) and binderp_list_invoices (all invoices), though it does not name those siblings explicitly.

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

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

"Against one invoice" implies the tool is used once you have an invoice id, and the required invoice_id parameter reinforces that. But there is no explicit when-to-use vs get_invoice/list_invoices guidance and no exclusions or prerequisites stated.

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

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

Annotations already establish that this is a read-only, non-destructive, open-world operation, so the description correctly focuses on added context. It discloses the endpoint, the returned invoice fields, and the open-balance calculation, which meaningfully exceeds the annotations without contradicting them.

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 and compact: the first sentence defines the operation and returned data, and the second adds a specific calculation note. There is no filler.

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

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

Because there is no output schema, the description appropriately lists the invoice fields and explains open balance. It still omits the response envelope and pagination details such as next_skip, which would help complete the picture for a list endpoint.

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

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

Schema description coverage is 100%, so the schema already carries the parameter documentation burden. The description adds a useful filter strategy for open balances, but it does not add meaning beyond the schema for top, skip, or orderby.

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 sales invoices') and enumerates the returned fields. It is clearly a list operation rather than a single-invoice get, though it does not explicitly distinguish itself from siblings like binderp_get_invoice or binderp_list_invoice_payments.

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

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

Usage is mostly implied by 'List sales invoices'; there is no explicit guidance on when to use this instead of binderp_get_invoice or binderp_list_invoice_payments. The open-balance filtering hint is useful operational guidance but is not tool-selection guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned field set, which is genuinely useful given there is no output schema, but says nothing about pagination limits, rate limits, or auth expectations beyond what the schema states.

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

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

Two short fragments with the resource and the field list front-loaded; every clause carries information. It is terse to the point of reading as documentation shorthand rather than prose, but nothing is wasted.

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

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

With no output schema, enumerating the returned columns is the key completeness win. The remaining gap is guidance on filtering/ordering strategy and paging, which the schema covers, so an agent can 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% — top, skip, filter and orderby are all documented in the schema, including OData syntax and the next_skip paging hint. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a clear verb+resource ('List customer orders (pedidos)') and enumerates the returned fields, which distinguishes it from binderp_get_order and binderp_create_order by implication. It never names a sibling explicitly, 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?

No guidance on when to use this versus binderp_get_order (single order), binderp_list_quotes or binderp_list_invoices. Usage is only implied by the verb 'List' and the HTTP route, with no exclusions or prerequisites.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the returned field set and the endpoint, but says nothing about pagination behavior (beyond what the skip param carries) or default result volume. With annotations doing the heavy lifting, a 3 is right.

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 tight field list, a concrete filter example, and the endpoint, all front-loaded with no filler. Slightly dense prose style but every element earns its place.

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

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

With no output schema, the description compensates by enumerating the returned fields (id, code, title, SKU, cost, inventory, etc.), which is exactly what an agent needs to judge relevance. Pagination semantics live in the schema, so only the sibling-differentiation gap remains.

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

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

Schema description coverage is 100%, so top/skip/filter/orderby are all fully documented in structured fields, including the OData syntax and quoting rules. The description's only parameter-related content (the substringof example) duplicates the schema, adding no new meaning. Baseline 3 applies.

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

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

States a specific verb+resource ('List products'), enumerates the returned fields, and gives the underlying endpoint, so an agent knows exactly what this does. It does not, however, differentiate itself from the sibling binderp_list_products_with_price_and_stock, which an agent must choose between.

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

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

The description implies usage by showing an OData filter example ('substringof('tornillo', Title)'), which helps an agent act, but it gives no guidance on when to prefer this over binderp_list_products_with_price_and_stock or binderp_get_product. Any 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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds the useful scope constraint that prices come from a single price list and stock from a single warehouse, plus the underlying GET endpoint for traceability.

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

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

Three short sentences, front-loaded with what the data view contains; the prerequisite and endpoint follow. The opening sentence is dense with field names but every clause carries meaning.

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

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

With no output schema, the description compensates by naming the returned content (price, stock, VAT/IEPS, min/max, volume prices), and pagination is fully specified in the schema. An agent has enough to call 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% and already documents all four parameters including pagination and GUID formats. The description reinforces the singular scope of warehouse_id and price_list_id but adds no new format, default or constraint information 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 resource (products) and what it carries (price from one price list, stock in one warehouse, VAT/IEPS, min/max and volume prices), so the agent knows it is a combined price+inventory view rather than a plain product list. It does not explicitly contrast with the sibling binderp_list_products, which the 'with price and stock' qualifier only implies.

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?

'Get the ids from binderp_list_catalog' gives an explicit prerequisite and names the sibling that supplies warehouse_id and price_list_id, which is exactly the routing an agent needs. It stops short of saying when to prefer this over binderp_list_products or binderp_get_inventory.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the concrete response shape (id, name, company, email, phone, salesperson) and the underlying GET endpoint, which is useful because there is no output schema, but it says nothing about paging limits or result size.

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

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

Two short sentences with zero redundancy; the resource and returned fields are front-loaded before the endpoint reference. Nothing could be cut without losing information.

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

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

For a simple read-only list tool with no output schema, naming the returned fields is the key missing piece and it is present; pagination and filtering details are fully covered by the schema. Only a pointer to the sibling single-record tool would make it 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% — top, skip, filter and orderby each carry detailed OData syntax documentation in the schema. The description adds no parameter meaning at all, 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 sales prospects (leads)') and enumerates the returned fields, so an agent knows exactly what this returns. It does not explicitly contrast itself with binderp_get_prospect or binderp_list_clients, though the list-vs-get naming pattern makes the distinction reasonably inferable.

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

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

Usage is only implied: 'List' plus the field list suggests browsing the prospect collection rather than fetching one record. There is no explicit statement of when to prefer this over binderp_get_prospect, nor any note about paging through results (that guidance lives only in the schema).

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 destructiveHint=false, so the safety profile is covered. The description adds the endpoint path and the returned field set, but says nothing about pagination semantics (next_skip), total counts, or volume limits, which are the behaviors an agent actually needs here.

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

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

Two short clauses with the resource and the payload fields front-loaded, then the endpoint. Nothing is wasted, though the field enumeration is slightly dense and the endpoint path adds little for an agent that cannot use it.

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 field list (id, number, name, legal name, RFC, email, phone, city) is the only disclosure of return shape and is genuinely useful. Annotations cover the safety profile and the schema covers all parameters, so the remaining gap is minor — pagination behavior 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 description coverage is 100% — top, skip, filter and orderby are each documented in detail, including OData syntax. The description adds no parameter meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb (list) and resource (suppliers/providers), enumerates the returned fields, and names the backing endpoint. The resource name is enough to distinguish it from list_clients, list_prospects and the other list_* siblings, though it never explicitly says so.

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

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

Usage is only implied by the verb and resource: an agent can infer 'call this to enumerate suppliers.' There is no explicit when-to-use, no exclusion of alternative tools, and no note that filtering/paging is optional.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned field set and the backing endpoint, but says nothing about result volume, pagination expectations, or filter cost that an agent would want before calling.

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 listing the resource and its fields, with no padding. The trailing endpoint string ('GET /api/Purchases/GetPurchaseOrders') is mildly useful for tracing but is the only element not directly serving tool selection.

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

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

There is no output schema, and the description compensates by enumerating the returned fields (number, warehouse, provider, date, status, quantities, total, currency). Combined with the fully documented input schema and read-only annotations, an agent has nearly everything needed, though pagination behavior is only discoverable in 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 description coverage is 100%, and the schema itself documents top/skip paging, OData $filter syntax with worked examples, and $orderby. The description adds nothing about any of the four parameters, so baseline 3 applies.

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

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

States a specific verb and resource ('List purchase orders to suppliers') and enumerates the fields returned, which separates it from binderp_get_purchase_order (single record) and binderp_list_orders (sales orders). It never explicitly names those siblings, but the resource naming does the distinguishing work.

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

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

No when-to-use guidance, no exclusions, and no pointer to the single-record sibling binderp_get_purchase_order or to binderp_list_orders for the buy-side counterpart. The agent must infer usage entirely from the tool name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that this is a plain GET collection endpoint and enumerates what each row contains, but says nothing about pagination limits, default page size, or volume/rate behavior beyond what the schema states.

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

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

Two compact sentences, front-loaded with the resource and its returned fields, with zero filler. The trailing "GET /api/Quotes" is marginally redundant but still useful for agents mapping to the REST surface.

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 fields (number, date, client, branch, comments, total, currency, status), which is the main thing an agent needs. It stops short of explaining the paged response envelope the skip parameter references (next_skip).

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

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

Schema description coverage is 100%, with top, skip, filter and orderby each documented in detail including OData syntax examples. The description adds no parameter meaning of its own, 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 quotes (cotizaciones)") plus the exact fields returned and the underlying endpoint GET /api/Quotes. It is clearly distinct from get_quote in name and semantics, though it does not explicitly contrast itself with siblings like list_orders or get_quote.

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

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

There is no guidance on when to use this versus binderp_get_quote (single quote) or the other list_* tools, and no mention of prerequisites such as authentication or scope. Usage must be inferred entirely from the tool name and the presence of paging parameters.

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