Ecwid MCP by usefulapi

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

Annotations only supply destructiveHint=true; the description goes further by stressing that it modifies live store data, explaining the delta direction, and disclosing the return shape {updateCount, warning?}. That return detail is especially valuable since no output schema exists.

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

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

Front-loaded with the action and its destructive nature, then semantics, then the API mapping. Dense and nearly waste-free, though the REST endpoint/body detail is marginal for an agent choosing a tool.

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

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

For a simple 2-parameter mutation with only destructiveHint available, the description covers effect, direction, and return value. Nothing essential for correct invocation is missing, though permission/rate-limit context is absent.

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

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

Schema description coverage is 100%, so both parameters are already documented by the schema, and the description largely restates the delta convention. Baseline 3 applies since the schema 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?

States a specific verb (adjusts), resource (product in-stock quantity), and the mechanism (by a delta). This is clearly distinguishable from the get/list/search/update siblings, and the delta semantics are immediately understandable.

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 'this MODIFIES live store data' and the positive/negative delta convention, which tells the agent when the tool applies. However, no alternative is named (e.g. setting absolute stock) and no prerequisites, auth, or when-not guidance is given.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description goes beyond that by disclosing the content of the result (name, parent, product ids, images) and mapping to the underlying REST endpoint GET /categories/{categoryId}, which is useful for an agent with no output schema.

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

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

Two short sentences, front-loaded with the core action and ending with the REST mapping. No filler or redundancy; every clause earns its place.

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

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

For a single-parameter read tool with readOnlyHint and no output schema, the description covers what is fetched and where it maps in the API. Missing only error/not-found or id-sourcing notes that would round it out.

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

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

Schema description coverage is 100% with a single required parameter ('Category id.'), so the schema carries the load. The description adds no syntax, format, or id-sourcing guidance beyond the schema, making the baseline 3 appropriate.

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

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

States a specific verb+resource with scope qualifiers: 'Get a single category by id', and enumerates the returned fields (name, parent, product ids, images). This clearly separates it from the sibling ecwid_list_categories, which returns many rather than one.

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 'a single category by id' implies the lookup case and implicitly contrasts with the list sibling, but the description never states when to use this versus ecwid_list_categories or what happens for a missing/invalid id. Usage is 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?

Annotations already declare readOnlyHint=true, so safety is covered structurally; the description adds genuinely new behavioral context by specifying the returned fields (contact details, addresses, customer group) and pinning the underlying REST call GET /customers/{customerId}. It stops short of noting error behavior for a missing id or auth/permission requirements.

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

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

Two compact sentences, front-loaded with what is returned and followed by the REST mapping. No filler or redundancy.

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-only getter with no output schema, the description carries the return-value burden adequately by naming the returned field groups and the endpoint. Missing only edge-case guidance (not-found handling, whether the full customer object is returned).

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% for the single customer_id parameter, so the baseline is 3. The description adds only the phrase 'by id', which conveys no format, range, or source-of-truth information beyond what the schema already documents.

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 (a single customer by id) and enumerates the payload contents (contact details, addresses, customer group). It is clear on its own, but it never names or contrasts with the obvious sibling ecwid_search_customers, so an agent must infer the single-vs-list distinction.

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 'by id' — the agent can infer this is the direct-lookup path and search_customers is the discovery path, but neither the condition nor the alternative tool is stated. No prerequisites or exclusions are given.

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

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

The readOnlyHint annotation already declares this a safe read, so the bar is lower. The description usefully adds the shape of the payload (totals, customer, payment/fulfillment status), but says nothing about not-found behavior, permissions, or rate limits.

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

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

Two tight sentences, front-loaded with the core purpose and payload, with the REST endpoint mapping appended as compact reference. No filler or repetition.

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

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

For a one-param read tool with a readOnlyHint annotation and no output schema, the description covers purpose and return content well enough to call correctly. The only real gap is routing guidance against the sibling search 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 coverage is 100% for the single parameter, and the schema already documents order_number as 'the store-visible order id'. The description's 'by its order number' adds no syntax, format, or lookup nuance beyond that, so baseline 3 applies.

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

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

The description gives a specific verb and resource ('Get a single order'), scoped by identifier ('by its order number'), and enumerates the included data (line items, totals, customer, payment/fulfillment status). It implicitly distinguishes itself from the sibling ecwid_search_orders via 'single' and 'by its order number', but never names that sibling explicitly.

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

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

Usage is implied: fetch when you already hold the order number. There is no explicit statement of when to use this versus ecwid_search_orders (lookup by known id vs. discovery/filtering), so the agent must infer the boundary 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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds useful return-content context and the underlying REST mapping (GET /products/{productId}), but says nothing about error behavior for missing ids or rate limits.

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

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

Two compact sentences: the purpose and payload first, the API mapping second. No filler, no redundancy, correctly front-loaded.

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

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

For a one-parameter read tool, the enumeration of returned fields substitutes well for the absent output schema. Only edge-case behavior (product not found, permissions) is unstated, which is a minor gap for a simple getter.

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?

There is a single parameter with 100% schema description coverage, so the schema fully documents product_id. The description adds no syntax, format, or sourcing detail beyond it; 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 ('Get a single product by its id') and enumerates the payload contents (price, stock, options, images, category assignments), which clearly distinguishes it from ecwid_search_products or ecwid_list_categories. An agent can identify it without opening the schema.

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

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

The phrase 'single product by its id' implies this is the lookup path when you already have an id, as opposed to the search sibling, but the description never states that contrast explicitly or names an alternative. Usage is inferable rather than instructed.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description usefully adds that the payload spans general info, company details, and settings, plus the underlying REST endpoint. It stops short of noting auth requirements, currency/locale nuances, or whether store settings are sensitive — modest added value 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?

One sentence plus an endpoint mapping. The content summary is front-loaded, nothing is repeated from the title, and every clause 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?

No output schema exists, so the description must sketch the return shape — it does so by naming the three content categories (general info, company details, settings). For a zero-parameter read tool this is nearly sufficient; finer detail on field contents is absent but not essential to 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?

The schema has zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly avoids inventing parameters; the GET /profile mapping is a small bonus.

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 ('the store's profile') and enumerates the content categories returned — general info, company details, settings. No sibling tool touches store-level profile data, so an agent can route here unambiguously.

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: there are no parameters and the tool is unmistakably the only profile accessor, so when-to-use is nearly self-evident. However, the description offers no explicit trigger conditions, no mention of when profile data is preferable to other calls, and no alternatives — nothing that rises above inference.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds useful context beyond that: it returns a paged collection and maps to Ecwid REST GET /categories, but says nothing about default page size, sort order, 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?

Three tight sentences with the core purpose front-loaded, then scope options, return shape, and endpoint mapping. Every sentence carries information with no filler.

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

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

For a read-only list tool with full schema coverage, no output schema, and no required parameters, the description covers purpose, scoping, and pagination adequately. Minor gaps like default sort/return field details are acceptable given the schema does the heavy lifting.

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

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

Schema coverage is 100%, so all four parameters (limit, offset, parent, hidden_categories) are already documented in the schema. The description echoes the parent and hidden semantics but adds no syntax or default values beyond what the schema provides, 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 ('store's product categories') with the scope options, which is far more than a tautology. It does not explicitly contrast with the sibling ecwid_get_category, though the list/get naming makes the distinction reasonably evident.

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 optional parent scoping and hidden-inclusion hints imply when to use it, but there is no explicit when/when-not guidance or named alternative. Usage must be inferred from the parameter framing.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds that the result is a paged collection and names the underlying endpoint, which is genuinely useful context, but it says nothing about auth needs, rate limits, or default page size behavior.

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 filters, ending with the endpoint mapping. No filler and nothing redundant.

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

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

For a zero-required-parameter, read-only list tool with full schema coverage and a paged-return note, the description covers what an agent needs to call it correctly. It could optionally hint at the shape of a returned coupon, but that is a minor gap.

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

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

Schema description coverage is 100%, so all five parameters are already documented with their own descriptions and even example values. The description only restates the filter categories, adding no syntax or format detail beyond the schema; 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 (the store's discount coupons), enumerates the filterable fields, and maps the operation to its REST endpoint (GET /discount_coupons). No sibling tool covers coupons, so the agent can distinguish this from the product/order/customer tools without opening a schema.

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

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

The description frames the tool as a filtered list, which implies usage, but it never states when to reach for it versus another discovery tool, nor any exclusions or prerequisites. Usage is inferable but not spelled out.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds useful non-annotation context – that results come back as a paged collection and that it maps to GET /customers – but says nothing about auth requirements, rate limits, or default page size behavior.

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

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

Two tightly written sentences with the purpose front-loaded and the paging/endpoint facts trailing. The 'Ecwid REST: GET /customers' clause is marginal but cheap and helps ground the call; nothing else is wasted.

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

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

For a read-only, no-required-params list tool with no output schema, the definition covers what it does, its filters, and that results are paged. The only meaningful gap is guidance on which sibling to pick for a single customer.

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. The description only restates the filter categories in parenthetical form, adding no syntax, defaults, or matching semantics beyond what the schema provides.

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

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

States a specific verb (search/list), the resource (the store's customers), and enumerates the filter dimensions, so an agent can distinguish it from the singular ecwid_get_customer sibling without opening either schema. The scope statement is unambiguous.

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

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

The phrase 'with optional filters' implies this is the browse/discovery path and its sibling ecwid_get_customer is the single-record lookup, but neither that alternative nor any when-not condition is stated explicitly. Usage is inferable rather than guided.

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?

Annotation readOnlyHint=true already establishes the safe-read profile, so the description is not the sole bearer of that burden. It does add useful behavior beyond annotations: the result is a paged collection and the underlying REST verb is GET /orders. It is silent on auth requirements, rate limits, and default page 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 tight sentences with the capability and filter scope front-loaded, followed by the return shape and REST mapping. Nothing is padded.

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

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

For a read-only filter-list tool with full schema coverage and an explicit 'paged collection' return note, the description covers what an agent needs to invoke it. Remaining gaps (no output schema, no default limit / pagination semantics beyond what the schema states) are minor.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema, making 3 the baseline. The description groups the filters (keyword, email/id, statuses, coupon, date range), which aids orientation but adds no syntax or semantics beyond the schema.

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

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

States a specific verb ('Search / list') and resource ('the store's orders'), enumerates the filter dimensions, and grounds it in the Ecwid REST endpoint (GET /orders). This is immediately distinguishable from the sibling ecwid_get_order, which fetches a single 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 ('search / list ... with optional filters') and that all filters are optional, but never states when to prefer this over ecwid_get_order or how to drill into a result. No exclusions or alternative-routing guidance are given.

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

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

Annotations already declare readOnlyHint=true, so safety is covered, but the description adds real value beyond that: it discloses the paged envelope ({total, count, offset, limit, items}) and maps the tool to the underlying Ecwid REST endpoint GET /products. It does not mention default page size or rate limits, leaving a small gap.

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

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

Two sentences, front-loaded with the verb and resource, then the return contract and endpoint. No filler, no repetition of the schema, every clause carries information.

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

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

With no output schema present, the description compensates by describing the paged result envelope explicitly. Combined with the 100%-covered input schema and the readOnlyHint annotation, an agent has everything needed to construct a filtered, paginated, sorted query.

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 (sku, limit, offset, sortBy enum, enabled, inStock, keyword, priceFrom/priceTo, category) is already documented in the schema. The description only reconfirms the filter families and sorting, adding no syntax or format detail beyond the structured fields — 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?

Names a specific verb+resource ('Search / list the store's products'), enumerates the filter dimensions it accepts, and states the return shape. This clearly separates it from retrieval siblings like ecwid_get_product, which an agent can infer is the single-item counterpart.

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 'optional filters' implies the tool works with or without narrowing, and the keyword/SKU/category/stock/price list hints at typical use. However, it never states when to prefer this over ecwid_get_product or ecwid_list_categories, and gives 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?

Annotations only declare destructiveHint=true, so the description carries the rest of the burden and does so well: it warns that this MODIFIES live store data, that it may trigger customer notifications, and that it returns {updateCount}. It stops short of stating permission requirements or reversibility of a status change.

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

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

Three short sentences, each earning its place, with the mutation risk and the endpoint front-loaded before the patch instruction and return shape. No filler or repetition of the schema.

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

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

With no output schema, the description correctly discloses the return as {updateCount}, and it covers the mutation/side-effect profile for a destructive write. It omits auth/permission expectations, but for a 4-parameter flat update tool this is close to complete.

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

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

Schema description coverage is 100% and two parameters carry full enums, so the baseline is 3. The description adds genuine value beyond the schema by clarifying that only fields intended for change should be supplied, i.e. partial-update semantics that the schema does not express.

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 (UPDATES) plus the resource (an order) and enumerates the exact mutable fields (payment status, fulfillment status, tracking number). This cleanly separates it from read-oriented siblings like ecwid_get_order and ecwid_search_orders without needing either schema.

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

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

"Provide only the fields you want to change" gives real patch-semantics guidance, which is useful. However, it names no alternatives and gives no when-to-use vs when-not conditions relative to the sibling order tools, so usage is only partially covered.

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