prestashop-mcp-connector

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by enumerating the returned data groups (addresses, purchase stats, unpaid orders), but says nothing about lookup behavior when an identifier matches nothing or how the two keys interact.

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

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

A single front-loaded sentence that enumerates the payload with no filler. It is appropriately sized for a simple lookup, though the enumerations are dense.

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

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

An output schema exists, so return values need no explanation. However, for a tool whose parameters are both optional, the definition never clarifies that a caller must provide one of the two keys, leaving a real gap.

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

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

Schema description coverage is 100%, so both email and id_customer are already documented in the schema. The description adds no extra semantics about their usage, 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 resource (customer record) and enumerates what it contains: contact details, addresses, purchase stats, recent orders, unpaid amounts. It reads as a retrieval tool, distinct from list/search siblings, though it never uses an explicit retrieval verb.

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 search_customers or the other get_* tools, and no mention of the prerequisite that at least one of email/id_customer must be supplied despite zero required parameters.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's enumeration of returned content is largely redundant with the existing output schema and adds no new behavioral context such as not-found handling or 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?

A single compact noun phrase with the resource front-loaded and no filler. It is efficient, though as a fragment it lacks the connective structure that would route an agent toward or away from 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 an output schema present, the return shape need not be explained, and annotations cover the safety profile, so the remaining gap is the lack of differentiation from search_invoices and no mention of error/not-found behavior. The definition is adequate but leaves a sibling-routing ambiguity unresolved.

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

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

Schema coverage is 100% and the single 'number' parameter is documented as accepting an invoice number with or without prefix. The description adds no syntax, format, or lookup-behavior detail beyond what the schema already 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?

The description names the resource ('une facture') and enumerates what the detail contains (lignes, ventilation de la TVA, adresse de facturation, paiement), which is more specific than the title alone. It does not, however, contrast itself with the sibling search_invoices, so an agent must infer that this is the single-record lookup rather than a listing.

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

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

There is no statement of when to use this tool versus search_invoices or report_unsupported_request. The only signal is the required 'number' parameter in the schema, so usage must be inferred entirely from structure rather than from the description.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the composition of the returned payload, which is already conveyed by the output schema; it says nothing about permissions, error behavior when neither identifier matches, or rate limits.

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

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

A single front-loaded sentence listing the payload contents, with no filler or repetition. Every clause names a distinct part of the result.

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?

An output schema exists, so return values need not be re-explained (and the description's list is partly redundant with it). The real gap is that both parameters are optional, yet the description gives no indication that at least one identifier is needed to resolve a single order.

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 id_order and reference are already documented in the schema, which sets the baseline at 3. The description adds no meaning beyond that, notably no guidance on which identifier to prefer or what happens if both are given.

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

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

States a specific verb (get) and resource (order) plus a scoped enumeration of what the detail contains: lines, billing/shipping addresses, status history, payment, invoice. It is clearly a single-order detail fetch, but it never names the siblings it is not (search_orders, list_unpaid_orders), so 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 when-to-use or when-not guidance and no mention of the alternatives in the sibling list (search_orders, list_unpaid_orders). It also never says that either id_order or reference must be supplied, which matters because zero parameters are required.

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, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-structured context: the returned fields (ancienneté, coordonnées client) and the crucial note that nothing is actually sent. It does not discuss pagination defaults, though the schema handles that.

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

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

Two sentences, front-loaded with scope and followed by the disambiguating negative. No filler, though the second sentence could be tightened slightly.

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 an output schema present and full annotation coverage, the description need not explain returns or safety. It nonetheless conveys scope, intended workflow, and the key non-action, leaving no meaningful gap for a zero-required-parameter listing 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% with all nine parameters documented, including enum values and formats, so the description is not required to explain parameters. It only echoes payment method and age concepts already present in the schema, adding no new syntax or filtering 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 names a precise resource and scope — orders awaiting payment by cheque, wire, or cash-on-delivery — and states what comes back (age, customer contact details). It is clearly distinct from generic siblings like search_orders, though it does not explicitly name and contrast an alternative tool.

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

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

It gives a clear use context ('pour préparer des relances') and an explicit negative: it does not send reminders itself, the user must do that. That prevents a common mis-invocation. It stops short of naming a sibling tool or stating exclusion conditions for overlapping search 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 declare readOnlyHint=false and destructiveHint=false, and the description adds real value beyond them: the call persists a record for connector improvement, and there is a hard prohibition on including personal data. It does not cover permissions or rate limits, but the write-with-side-effect nature and the PII constraint are the important behaviors 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?

Three short sentences: trigger first, persistence effect second, data-safety and follow-up third. Every sentence carries an actionable instruction and none is padding.

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

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

With two parameters, full schema coverage, and an output schema handling return values, the description supplies everything an agent needs: when to call, what to send, what to avoid sending, and what to tell the user afterward.

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

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

Schema coverage is 100%, so both parameters are already documented, including the no-personal-data constraint on 'request'. The description reinforces that constraint but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific action (reporting an unhandled user request) and enumerates the three concrete cases that trigger it (missing function, unexposed data, disallowed action). This clearly distinguishes it from all sibling tools, which are read/lookup tools.

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

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

It gives an explicit when-to-use condition ('quand une demande ne peut pas être traitée avec les autres outils') and names explicit alternatives implicitly by pointing at all other tools. It also prescribes post-invocation behavior (explain the limitation to the user), leaving nothing 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, idempotentHint, and non-destructive behavior, lowering the bar. The description adds one meaningful behavioral fact – that only validated orders are counted – but says nothing about permissions, result size limits (relevant given the 'top' parameter), or how the default period interacts with explicit dates.

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 that front-load the metric and grouping dimensions, then add the one caveat (validated orders only). No filler, though the enumeration of group_by values slightly duplicates the schema enum.

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

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

With a full output schema present, the description needn't explain return values, and it covers metric, dimensions, default period, and the validated-orders filter. The main gap is guidance on when to use it versus the search_* siblings and behavior around the 'top' cap.

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 each of the 9 parameters individually documented (partial search, accent-insensitivity, enum values, ISO codes). The description lists the group_by options narratively but adds no syntax or format detail beyond the schema, so the schema carries the load.

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 clearly what the tool computes (revenue and order count) and the dimensions of aggregation, plus the default period. It doesn't name a specific sibling or explain how it differs from list_unpaid_orders or search_orders, but the reporting purpose is unmistakable.

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 a reporting/aggregation use case through 'regroupés par' and the 12-month default, but it never says when to prefer this tool over the order/invoice sibling tools or what happens if no filters are provided. Usage is implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered elsewhere. The description adds one genuinely useful behavioral detail — that the location filter matches ANY of a customer's addresses — but says nothing about pagination limits or result shape, so it is merely additive rather than rich.

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

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

Two sentences, no filler, with the capability statement front-loaded and the use case trailing it. The list of filter dimensions is long but each item is a distinct capability, so it earns its space.

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

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

For a 14-parameter filter tool with 100% schema coverage and an output schema, the description covers purpose, filter axes and a use case adequately. It omits any mention of pagination behavior or default/max result limits, which the schema carries but the agent might benefit from seeing alongside the capability summary.

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%, including enum values for sort, so baseline is 3. The description helpfully groups the semantic axes (location, spend, order count, recency, unpaid) without adding syntax or format detail beyond the schema, which already documents every 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+resource ('Recherche des clients') and enumerates the searchable dimensions (nom, e-mail, société, lieu, nombre de commandes, montant dépensé, ancienneté, impayés), which lets an agent distinguish it from the single-record get_customer sibling. It does not explicitly name any sibling, so it falls short of a 5.

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

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

The second sentence supplies one concrete use case ('cibler une relance commerciale'), which implies when the tool is appropriate. However, there is no explicit when-not guidance and no named alternative (e.g. list_unpaid_orders for unpaid-only queries), so usage remains inferable rather than stated.

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

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

The annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is not the primary carrier here. It adds that results include HT, TVA and TTC amounts plus totals, which is useful but largely overlaps the existing output schema.

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

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

Two sentences, no filler, with the searchable dimensions front-loaded and the return payload named last. Nothing in it is redundant padding.

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

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

With an output schema present and annotations covering safety, the description only needs to frame the search surface and return shape, which it does. It omits how multiple filters combine and the relevance/ordering default, but the rich schema and output schema limit the practical gap.

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

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

Schema description coverage is 100%, so every one of the 16 parameters is already documented with type, format examples and defaults. The description's enumeration of searchable fields mirrors the schema rather than adding syntax or combination semantics (e.g. whether filters are ANDed).

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 ('Recherche des factures') and enumerates the searchable axes (numéro, période, client, société, montant, produit, lieu de facturation), which makes clear this is a flexible query rather than a single-invoice lookup. It does not explicitly contrast itself with the singular sibling get_invoice, so it falls just short of full sibling 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?

There is no statement of when to use this tool versus search_orders, search_customers, or get_invoice, and no mention of prerequisites or when results might be empty. Usage must be inferred entirely from the name and parameter list.

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 cover readOnly, idempotent, non-destructive, and closed-world. The description adds genuinely useful behavioral context beyond that: the address=delivery nuance for the location filter and the fact that it returns a total count and cumulative amount. Auth and rate-limit details remain unstated, but the bar is lower given full annotation coverage.

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 searchable dimensions. It is dense and low-waste, though the return-value sentence is somewhat redundant given an output schema exists.

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 17-parameter, zero-required search tool with a full output schema and rich annotations, the description is adequately complete. Its main omission is routing guidance relative to siblings, which does not undermine correct invocation.

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

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

Schema description coverage is 100%, so all 17 parameters are already documented in the schema. The description restates the filter categories and adds the invoice/delivery distinction for location, but contributes little syntax or format detail beyond what the schema provides, warranting the baseline 3.

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

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

States a specific verb (Recherche) and resource (commandes) and enumerates the exact filter dimensions (référence, client, statut, période, montant, produit, lieu). This clearly distinguishes it from siblings like search_customers, search_invoices, search_products, and get_order.

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

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

The description implies usage by listing searchable criteria but never states when to prefer this over get_order (single lookup) or list_unpaid_orders (a filtered subset). No explicit when-not or alternative routing is given, so usage is only inferable.

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, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds meaningful context by naming the returned data (price, stock per variant, 30/90-day sales, estimated coverage days), which goes beyond the annotation safety profile and helps an agent understand the analytical output.

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

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

One front-loaded sentence with no filler. Every element—verb, resource, and returned metrics—is informative and 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 annotations covering safety, an output schema documenting return values, and full schema coverage, the description is largely sufficient for correct invocation. The main omission is usage guidance relative to sibling search tools, which keeps it from being fully complete.

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

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

Schema description coverage is 100%, so the input schema already documents all four parameters. The description adds no additional parameter syntax, formats, or constraints, so the baseline score 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 (Recherche) and resource (produits), and lists the enriched fields returned (prix, stock par déclinaison, ventes des 30/90 derniers jours, couverture de stock). It is clearly about product search, though it does not explicitly distinguish itself from sibling search tools like search_customers or search_orders.

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

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance. An agent must infer that this is the product-specific search from the tool name alone.

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