Discover Algerian COD stores on Mystoq, or manage your own: products, prices, shipping/fraud tools.
Scored across 12 tools
Most tools target distinct resources and actions: product lifecycle (create/delete/publish/set_price), store operations (create/get/search), and analytics (cod_profit/order_risk/yalidine_delivery). Slight overlap exists among the delivery/return-related analytics tools, but descriptions clarify their different purposes.
CRUD tools follow a verb_noun pattern (create_product, delete_product, get_store, list_plans), but several analytics tools use noun phrases (cod_profit, order_risk, platform_stats) and 'publish' lacks a noun object. The pattern is readable but not consistently applied.
With 12 tools covering store management, product operations, and e-commerce analytics, the set is well-scoped for an Algerian e-commerce platform. Each tool earns its place without being overwhelming or redundant.
Product management lacks read/update operations (no get_product or list_products), and store management has create/get/search but no update/delete. Analytics coverage is good, but lifecycle coverage has notable gaps that agents may need to work around.
Compute true CAC and net cash-on-delivery profit for an Algerian online store, accounting for the return/refusal rate. Returns base and confirmation-call scenarios.
| Name | Required | Description | Default |
|---|---|---|---|
| return_cost | No | DZD lost per refused/returned parcel (default 600). | |
| product_cost | Yes | Product cost (DZD). | |
| selling_price | Yes | Selling price per order (DZD). | |
| return_rate_pct | No | Percent of confirmed orders refused/undelivered (e.g. 25 for 25%). | |
| ad_cost_per_order | Yes | Ad spend to acquire one confirmed order (DZD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds value by disclosing computational behavior (true CAC, net profit, two scenarios) without contradicting 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, no wasted words. First sentence states purpose, second adds detail on scenarios.
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, so description should hint at return format. It mentions 'returns base and confirmation-call scenarios' but lacks explicit output details. Adequate but not 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 coverage is 100%, so baseline is 3. Description does not add extra meaning beyond schema; it only mentions return/refusal rate broadly.
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?
Description clearly states it computes 'true CAC and net cash-on-delivery profit' for an Algerian online store, accounting for return/refusal rate. It distinguishes itself from possible sibling tools by specifying the context and scenarios.
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?
Implies usage when needing profit with returns, but no explicit when-to-use or alternatives among siblings (e.g., order_risk). Lacks guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a product in the authenticated merchant's store. Requires Bearer token. WRITE.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Product name. | |
| price | Yes | Price in DZD. | |
| stock | No | Stock quantity (optional). | |
| status | No | active | draft | archived (default draft). | |
| is_demo | No | Mark as an ephemeral demo product (server auto-deletes it after auto_delete_at). | |
| description | No | Description. | |
| translations | No | Optional {ar|fr|en:{name,description}}. | |
| compare_price | No | Strikethrough/old price (optional). | |
| auto_delete_at | No | ISO timestamp after which a demo product is auto-deleted server-side. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=false, so 'WRITE' adds no new info. Does not disclose idempotency, rate limits, or side effects beyond creation. Missing details on return value or error cases.
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?
Extremely concise with only two sentences. Every sentence serves a purpose; no wasted 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?
Despite complex nested objects and 9 parameters, description provides no context on output, error handling, or sequential behavior. Lacks completeness for a creation 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% with detailed parameter descriptions. Description does not add extra meaning beyond schema; baseline score 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?
Description clearly states 'Create a product in the authenticated merchant's store.' Uses specific verb and resource, and distinguishes from sibling tools like delete_product.
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?
Mentions authentication requirement ('Requires Bearer token') but no explicit guidance on when to use this tool versus alternatives like get_store or publish.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a NEW Mystoq store (tenant). Returns the store id, slug and an access token. No auth needed. WRITE.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Store name. | |
| slug | No | Desired store address, the <slug>.mystoq.com part. Optional: derived from the store name when omitted. Latin letters, digits and hyphens, 3-30 chars. | |
| Yes | Owner email. | ||
| phone | Yes | Owner phone in Algeria (e.g. 0555123456). Required — a cash-on-delivery store cannot take an order without one. | |
| password | Yes | Account password (min 8). | |
| wilaya_id | No | Wilaya code 1-69 (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false). The description adds value by specifying 'No auth needed' and the return payload (store id, slug, access token), which are not covered by annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with only two sentences and no fluff. It states the purpose, key return values, and auth requirement efficiently. Every token 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?
Given six parameters and no output schema, the description adequately covers the core behavior, return values, and auth. It doesn't describe error cases or exact response format, but provides enough for a straightforward registration 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?
The input schema provides 100% parameter descriptions, so the description does not need to elaborate on parameters. Baseline 3 applies; the description adds no parameter-specific meaning 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?
The description explicitly states 'Register a NEW Mystoq store (tenant)' with a clear verb and resource. It distinguishes from siblings like create_product and get_store by specifying the store registration action and tenant context.
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 clearly implies usage for creating a new store and notes 'No auth needed,' which is a usage condition. It does not explicitly exclude alternatives, but the sibling tools are distinct enough that the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a product from the authenticated store (reversible cleanup — used by the agent's ephemeral live-demo). Requires Bearer token; only the owner's own product. WRITE/DESTRUCTIVE.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Product id to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only nature. The description adds critical context: the operation is reversible for demo purposes, requires authentication, and is scoped to the owner's product. This goes beyond annotations to inform the agent of important behavioral traits.
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 concise (two sentences) and front-loaded with the core purpose and context. Every sentence adds necessary information without redundancy or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with one parameter, the description covers purpose, authentication, scope, and additional context (reversible demo). It lacks details about the return value or error states, but given the simplicity, it is sufficiently 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?
The input schema covers the single parameter 'product_id' with a description. The tool description does not add any additional semantic meaning beyond what the schema already provides. Therefore, the description contributes no extra value for parameter understanding.
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 clearly states the action ('Delete a product'), the resource ('from the authenticated store'), and provides context ('reversible cleanup — used by the agent's ephemeral live-demo'). It distinguishes the tool from siblings like 'create_product' or 'publish' that have different purposes.
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 specifies requirements ('Requires Bearer token; only the owner's own product') and hints at the use case (ephemeral demo), but does not explicitly state when not to use or suggest alternatives. The context strongly implies usage within the demo, making it clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a public Mystoq store by its slug: name, wilaya, storefront URL, plan tier and member-since. Public info only.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Store slug, e.g. "islem-uk". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true and idempotent=true. The description adds that only public info is returned, which is a useful behavioral constraint beyond annotations. No contradictions.
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 a single sentence that is front-loaded and contains no extraneous information. Every part is necessary.
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 retrieval tool with one parameter and no output schema, the description provides all necessary context: purpose, input, and returned fields. The public info note further clarifies scope.
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 has 100% coverage with a clear description. The tool description reiterates the slug parameter but adds no new semantics beyond stating 'by its slug'. Baseline score 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 clearly states it retrieves a public Mystoq store by slug and specifies the fields returned. It distinguishes from siblings like search_stores by being single-store specific.
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 for fetching a single store by slug but does not explicitly mention when to avoid it (e.g., for private info) or compare with sibling search_stores. Guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Mystoq subscription plans with monthly/yearly/lifetime prices (DZD) — useful to answer "how much does Mystoq cost".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description carries less burden. It adds that prices are in DZD and includes plan types, which is useful context beyond the annotations. No contradictions.
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 a single, front-loaded sentence with no unnecessary words. Every part adds value: the action, the resource, the pricing details, and the example use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is fully adequate. It clearly conveys what the tool returns and its purpose, making it easy for an AI agent to invoke 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?
The tool has zero parameters, so the baseline score is 4. The description does not need to add parameter meaning since none exist, and the schema coverage is 100%.
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?
Description clearly states the tool lists subscription plans with pricing (monthly/yearly/lifetime in DZD). It provides a specific verb-resource combination and distinguishes from siblings by being the only listing tool among CRUD tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case (answering 'how much does Mystoq cost?'), which implies when to use it. However, it does not explicitly state when not to use it or compare to alternatives, though siblings are sufficiently different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score the fraud/return risk of an Algerian COD order from its signals (phone, history, etc.) — Mystoq FakeShield logic.
| Name | Required | Description | Default |
|---|---|---|---|
| hour | No | Hour the order was placed, 0-23. | |
| name | No | Customer full name. | |
| phone | No | Customer phone (Algerian mobile). | |
| wilaya | No | Destination wilaya. | |
| address | No | Delivery address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true; the description adds context about the specific logic (Mystoq FakeShield) and geographic scope (Algerian COD). No contradictions.
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 a single clear sentence, front-loaded with key information. Slightly more structure could improve readability, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool's inputs are well-covered, the lack of output schema and description of the score's format or range leaves a gap. Usage guidance is also missing, making it moderately complete for a safe, read-only 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?
All 5 parameters are fully described in the schema (100% coverage). The description mentions 'signals (phone, history, etc.)' but does not add new semantic meaning 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?
The description clearly states the action 'Score' and the resource 'fraud/return risk of an Algerian COD order', with specific signals mentioned. It distinguishes itself from siblings like 'cod_profit' by focusing on risk scoring.
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 for fraud/return risk assessment but does not provide explicit guidance on when to use this tool over alternatives like 'cod_profit' or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mystoq network statistics: number of active stores and wilayas covered.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by specifying the actual data returned (active stores and wilayas), providing context beyond annotations. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the tool's purpose without any extraneous words or repetition. It is front-loaded with the key term 'Mystoq network statistics' and includes the two metrics.
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?
While the description mentions the two statistics, it lacks details on output format (e.g., types, example values) since no output schema exists. An agent might need clearer expectations of the response structure for a tool with no parameters.
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 has zero parameters, and schema coverage is 100% (vacuous). The description naturally adds no parameter-specific meaning since none exist, which is acceptable. Baseline score of 4 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 clearly states the tool provides 'Mystoq network statistics' with specific metrics: 'number of active stores and wilayas covered'. This is a distinct verb+resource combination not replicated by any sibling tool, as no other tool offers statistics.
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 when network-level aggregate data is needed, but does not explicitly state when not to use it or mention alternatives. However, given there are no sibling tools with similar stats, the context is clear enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a product (set status=active) so it shows on the storefront. Requires Bearer token. WRITE.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | Product id to publish. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds context by specifying 'set status=active' and 'Requires Bearer token', which goes beyond annotations. No contradictions.
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 very concise at 18 words, front-loaded with the main action, and every word adds value. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no nested objects), the description covers all necessary aspects: action, auth, effect. Complete for its purpose.
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 'product_id', which already has a description. The description adds no new information about the parameter 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 clearly states the verb 'Publish', the resource 'product', and the effect 'set status=active' and 'shows on the storefront'. It distinguishes from siblings like 'create_product' and 'delete_product' by specifying the action of making a product active.
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 mentions the authentication requirement ('Requires Bearer token') and the type of operation ('WRITE'), but does not explicitly state when to use this tool versus alternatives like 'set_price' or 'create_product'. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the public Mystoq store directory (Algerian online shops). Filter by keyword (store name), wilaya, or plan. Returns store name, wilaya, storefront URL and plan tier. Public business listings only — no merchant personal data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-25, default 12). | |
| query | No | Keyword in the store name. | |
| offset | No | Pagination offset (default 0). | |
| wilaya | No | Wilaya filter: code (1-69) or name (e.g. "16", "Alger", "الجزائر"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only and non-destructive, and the description adds useful context about public listings and exclusion of merchant personal data. However, it incorrectly states a 'plan' filter that does not exist in the schema, misleading about capabilities. This reduces transparency despite good intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main verb and object, and each sentence serves a purpose: stating the action, the filters, and the return data/scope. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return fields, scope, and privacy constraints, which is good given no output schema. However, it inaccurately mentions a 'plan' filter, and it does not explicitly note pagination via offset or defaults (though the schema covers these). The inaccuracy creates a completeness 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% for all parameters, so the schema already explains limit, query, offset, and wilaya. The description adds minimal semantic value beyond that and introduces a non-existent 'plan' parameter, which creates confusion rather than clarifying parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (search), the resource (public Mystoq store directory), and the scope (Algerian online shops). It differentiates from siblings like get_store by emphasizing search and filtering, and lists return fields, making the purpose explicit and 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 description clearly implies when to use: when searching/filtering stores. It provides context about public vs. private data and filters, but does not explicitly mention alternatives or when-not-to-use, such as 'use get_store for a single known store.' This is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a product's price (and optional compare_price) in the authenticated store. Requires Bearer token. WRITE.
| Name | Required | Description | Default |
|---|---|---|---|
| price | Yes | New price in DZD. | |
| product_id | Yes | Product id. | |
| compare_price | No | Optional old/compare price. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (write), idempotentHint=true, destructiveHint=false. Description adds 'Requires Bearer token' and reaffirms 'WRITE', but no new behavioral traits beyond annotations. For a mutation tool, this is adequate but not exceptional.
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 action verb. No redundancy or unnecessary words. Efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema, the description covers the essential action, authentication, and write context. It does not mention return values or success confirmation, but given the tool's simplicity, this 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% with clear descriptions for each parameter (e.g., 'New price in DZD.'). The description does not add meaning beyond the schema; it only mentions 'optional compare_price' which is already documented. Baseline 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?
Clearly states 'Update a product's price (and optional compare_price) in the authenticated store.' The verb 'Update' and resource 'product's price' are specific, and the scope is well-defined. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides authentication requirement ('Requires Bearer token') and hints at write operation ('WRITE'). However, no explicit guidance on when to use versus siblings or when not to use. Missing exclusions or alternative tool suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate delivery success/return rate and typical delivery time for a destination wilaya in Algeria (region-based network estimate).
| Name | Required | Description | Default |
|---|---|---|---|
| wilaya | Yes | Destination wilaya: slug, name or number (e.g. "oran", "Alger", "31"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about estimating success/return rate and typical delivery time, which aligns with annotations. However, it does not disclose any additional behavioral traits beyond what annotations imply.
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?
Single sentence that front-loads the main purpose. No extraneous words; every part contributes 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?
Given no output schema, the description hints at output (success/return rate, typical time) but lacks specificity on format or structure. For a simple tool with one parameter, it is adequate but could be more explicit.
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% (wilaya parameter well-described with examples). The description reiterates 'destination wilaya' but adds no new semantics beyond the schema. Baseline 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 specifies a clear verb ('Estimate') and resource ('delivery success/return rate and typical delivery time') for a specific location (Algerian wilaya). It is distinct from siblings like order_risk and cod_profit, which serve different purposes.
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 for delivery estimation but does not explicitly state when to prefer this tool over siblings or provide exclusion criteria. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_store1 field changedInput schema / properties / wilaya_id / descriptionPrevious value: -"Wilaya code 1-58 (optional)."New value: +"Wilaya code 1-69 (optional)."search_stores1 field changedInput schema / properties / wilaya / descriptionPrevious value: -"Wilaya filter: code (1-58) or name (e.g. \"16\", \"Alger\", \"الجزائر\")."New value: +"Wilaya filter: code (1-69) or name (e.g. \"16\", \"Alger\", \"الجزائر\")."create_store3 fields changedInput schema / properties / phone / descriptionPrevious value: -"Phone (optional)."New value: +"Owner phone in Algeria (e.g. 0555123456). Required — a cash-on-delivery store cannot take an order without one."Input schema / properties / slugAdded value: +{
+ "description": "Desired store address, the <slug>.mystoq.com part. Optional: derived from the store name when omitted. Latin letters, digits and hyphens, 3-30 chars.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "name",
- "email",
- "password"
-]New value: +[
+ "name",
+ "email",
+ "password",
+ "phone"
+]cod_profit5 fields changedInput schema / properties / return_costAdded value: +{
+ "description": "DZD lost per refused/returned parcel (default 600).",
+ "type": "number"
+}Input schema / properties / return_rateRemoved value: -{
- "description": "Return/refusal rate (0-1, e.g. 0.25).",
- "type": "number"
-}Input schema / properties / return_rate_pctAdded value: +{
+ "description": "Percent of confirmed orders refused/undelivered (e.g. 25 for 25%).",
+ "type": "number"
+}Input schema / properties / shipping_costRemoved value: -{
- "description": "Shipping/delivery cost (DZD).",
- "type": "number"
-}Input schema / requiredAdded value: +[
+ "selling_price",
+ "product_cost",
+ "ad_cost_per_order"
+]order_risk5 fields changedInput schema / properties / addressAdded value: +{
+ "description": "Delivery address.",
+ "type": "string"
+}Input schema / properties / hourAdded value: +{
+ "description": "Hour the order was placed, 0-23.",
+ "type": "integer"
+}Input schema / properties / nameAdded value: +{
+ "description": "Customer full name.",
+ "type": "string"
+}Input schema / properties / phoneAdded value: +{
+ "description": "Customer phone (Algerian mobile).",
+ "type": "string"
+}Input schema / properties / wilayaAdded value: +{
+ "description": "Destination wilaya.",
+ "type": "string"
+}yalidine_delivery6 fields changedInput schema / properties / from_wilayaRemoved value: -{
- "description": "Origin wilaya (code or name).",
- "type": "string"
-}Input schema / properties / modeRemoved value: -{
- "description": "\"home\" or \"stopdesk\".",
- "type": "string"
-}Input schema / properties / to_wilayaRemoved value: -{
- "description": "Destination wilaya (code or name).",
- "type": "string"
-}Input schema / properties / weightRemoved value: -{
- "description": "Parcel weight (kg).",
- "type": "number"
-}Input schema / properties / wilayaAdded value: +{
+ "description": "Destination wilaya: slug, name or number (e.g. \"oran\", \"Alger\", \"31\").",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "wilaya"
+]cod_profitcreate_productcreate_storedelete_productget_storelist_plansorder_riskplatform_statspublishsearch_storesset_priceyalidine_deliveryShop Algeria's marketplace or manage seller products, orders, and storefronts securely.
Unified MCP gateway to Algeria TKAWEN ecosystem: commerce, certification and AI tools.
Product intel: Amazon, AliExpress, Shopify, TikTok Shop, ads and search interest.
Verify Algerian digital certificates and find certified professionals for hiring in Algeria.
Add one secure layer between your agents and this server.
