jumia-vendor-center

by damurka

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools map cleanly to distinct resource+action pairs, with the update_products/update_price/update_stock boundaries explicitly carved out. The main overlap risk is pack_orders vs pack_orders_v2, though the versioned descriptions and get_shipment_providers guidance largely disambiguate them. The two find_* heuristic tools share a style but target clearly different outcomes (duplicates vs outdated).
Naming Consistency4/5
The set follows a strong snake_case verb_noun convention throughout (list_*, get_*, create_*, update_*, find_*, deactivate_*). Minor deviations include the pack_orders_v2 version suffix and an inconsistent get_/list_ split between similar read operations (list_orders vs get_order_items). Overall the pattern is predictable enough for an agent to guess tool names.
Tool Count4/5
At 27 tools the server is on the heavy side, but it spans multiple distinct sub-domains — product catalog, order fulfillment, consignments, and payouts — making the per-domain count reasonable. Each tool earns its place with a genuine distinct operation rather than redundant variants, aside from the pack_orders v1/v2 pair.
Completeness4/5
Product lifecycle coverage is strong: create, list, update mutable fields, update price/stock, deactivate, plus duplicate/outdated heuristics and a sync orchestration tool. Order fulfillment covers pack, label, ready-to-ship, and cancel, but there is no returns/refunds surface. Consignment support has create/update/stock-check but no way to list or fetch a single consignment, a workable minor gap.
Average 3.8/5 across 27 of 27 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only says 'update' and gives a date format; it does not explain whether unspecified fields are left unchanged, whether updates are reversible, or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core action, and contains no filler. The second sentence about date format earns its place, though the overall terseness leaves major gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With seven parameters, zero schema descriptions, no annotations, and no output schema, this description is massively under-specified. An agent has no way to know what each field means, which field is the required identifier, or what the API returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It adds a date format for date-like fields but never maps 'shipping status' to is_shipped or explains name_of_3pl, tracking_number, delivery_agent_phone_number, or the date fields individually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Update a consignment's shipping status.' It is easy to tell this from creation or read tools like create_consignment or get_consignment_stock. It does not explicitly name sibling alternatives, but the action is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus create_consignment, mark_ready_to_ship, or pack_orders. The only hint is the word 'Update', which implies an existing consignment, but prerequisites such as needing purchase_order_number are not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose one meaningful behavioral trait: the result is a single page, suggesting pagination. 'GET' also implies a read-only operation. However, it does not mention response shape, continuation-token behavior, required permissions, or any side effects, so behavioral transparency remains limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence with no repetition or filler, and the key idea is front-loaded. It is arguably under-specified, but as a concise statement of the operation and pagination behavior, it earns its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There are no annotations, no output schema, and three parameters with zero schema description coverage. The description only gives the endpoint and pagination hint, leaving return values, parameter meanings, and pagination mechanics undocumented. This is far from complete for an AI agent deciding how to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the three parameters: size, token, and product_sids. It does not even hint at how pagination or filtering works, so an agent cannot infer parameter semantics without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact resource and operation: GET /catalog/stock, with the added detail that it returns one page. This clearly distinguishes it from mutation siblings like update_stock or get_consignment_stock by endpoint. It could be clearer about what 'stock' data actually contains, but the core purpose is not ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as get_consignment_stock, update_stock, or list_products. The word 'GET' implies a read operation, but no explicit selection criteria, prerequisites, or exclusion conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly starts with 'GET,' which signals a read-only operation, and there are no annotations to rely on. However, it does not describe what the response looks like, whether pagination or filtering behavior applies, or any edge cases. For a simple retrieval tool, the GET method provides a basic behavioral disclosure but nothing more.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. It is front-loaded with the HTTP method and resource path, but it is also terse enough that some necessary detail is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no annotations, and no output schema, the description is incomplete. It does not explain the two optional parameters, the response format, or any operational context. An agent would not be able to confidently use this tool for non-trivial calls without opening the schema or guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate for the undocumented parameters. It only hints that order_id identifies the specific order, leaving status and shop_id unexplained. The description gives minimal added meaning for one parameter and none for the other two.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb (GET) and resource (order items) and adds the scoping phrase 'for a specific order,' which clarifies that it retrieves items belonging to one order. However, it does not explicitly differentiate it from sibling tools like list_orders or cancel_order_items beyond naming a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. The description implies it is for retrieving order items, but it does not mention exclusions, prerequisites, or why it should be chosen over list_orders or other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. The 'NOT financial/tax advice - just the raw statement data' clause genuinely adds value by setting output expectations: the agent learns this returns uninterpreted data suitable for reconciliation, not analysis or guidance. However, it discloses nothing about pagination behavior, the filtering semantics of the 'paid' boolean, or the required date format for created_after — meaningful behavioral traits for a 6-parameter query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler: the verb+resource is front-loaded, the purpose is packed into a tight parenthetical, and the disclaimer earns its place by preventing the tool from being misused as financial advice. The mid-sentence capitalized 'NOT' is stylistically awkward but not confusing. It is appropriately sized for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 6-parameter tool with zero required fields, zero annotations, and no output schema, yet the description only covers purpose and output nature. Filter semantics, pagination, and response shape are all left undocumented, so an agent cannot fully predict what will happen when it calls the tool. Like the update_drive calibration case, a tool with this little structured metadata needs to say more to be safely invoked autonomously.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description references none of the six parameters, so it fails to compensate for the uncovered schema. page, size, country, and currency are reasonably self-evident from their names, but 'paid' (does true mean only settled statements?) and created_after (which date format?) remain genuinely ambiguous. An agent would have to guess at the semantics of two of the six parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a specific verb ('List') with a concrete resource ('payout statements') and anchors it with a real-world purpose: reconciling Jumia payouts against the user's own books. The resource is clearly distinct from sibling list_* tools (orders, products, shops, brands), so an agent can disambiguate without opening the schema. It earns a 4 rather than 5 because it never explicitly names a sibling or states what it is not in relation to another tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'for reconciling what Jumia has paid out against your own books' gives a concrete, matchable use case that tells an agent when this tool is the right call. No alternatives or when-not-to-use exclusions are stated, but among the 26 siblings there is no competing payout-statement tool, so the exclusion gap is minor. These two sentences deliver clear context without going as far as naming an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It communicates a state change from 'packed' to 'ready to ship,' but it does not explain side effects, prerequisites, idempotency, or what happens if items are not actually packed. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. Every word earns its place, and the core action and target resource are immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple schema, this is a state-changing tool with no annotations and no output schema. The description does not explain return values, error conditions, or the operational context needed to invoke it reliably. It is adequate as a label but incomplete as standalone guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not mention the order_item_ids parameter or any constraints beyond what the parameter name suggests. The schema provides only the type and requiredness, leaving the agent to infer ID format, cardinality limits, and whether the items must already be packed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark'), the resource ('packed order items'), and the resulting state ('ready to ship'). This distinguishes it from siblings like pack_orders, cancel_order_items, and print_shipping_labels, which cover different stages of the fulfillment flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The term 'packed order items' implies the tool should be used after packing and before shipping, but the description does not explicitly state when to use it versus alternatives like pack_orders or create_consignment. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of revealing behavior. It clearly conveys a read-only checking operation and specifies exactly which stock states are covered. It does not describe response format or scope limitations, but for a simple query tool the core behavioral intent is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action, names the resource, and enumerates the relevant statuses without filler. Every part of the sentence contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and zero parameter documentation, but the description only covers the high-level purpose. It does not explain what the returned counts look like, whether results are filtered by date or warehouse, or how the two required parameters should be supplied. This is enough to recognize the tool but not enough to invoke it confidently in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain business_client_code and sku, but it does not. The parameter names are somewhat self-explanatory, but the description adds no real semantic detail about what values are expected, how they relate to the stock counts, or any format/combination requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Check...counts') and a specific resource ('stock sent to a Jumia warehouse'), and enumerates the status categories covered (received/quarantined/defective/canceled/returned/failed). This is clear, though it does not explicitly differentiate itself from the sibling get_stock tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied by the 'consignment' framing and the list of status counts, but the description gives no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives such as get_stock or update_stock, so an agent must infer when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description needs to carry the behavioral burden. It discloses pagination via token and implies read-only via GET, but it does not describe response shape, error behavior, or side effects (or lack thereof) beyond the implied GET.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: endpoint, page semantics, and pagination instruction are front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 undocumented parameters and no output schema, the description is not complete enough for reliable invocation beyond a plain unparameterized call. An agent cannot learn what the filters mean or what the response page looks like from this definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains token ('use token from the previous response to get the next page') and refers vaguely to 'documented filters' without enumerating status, shop_id, qc_status, seller_sku, category_code, or size semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific endpoint ('GET /catalog/products') and states the operation returns one page of products with filters, which distinguishes it from product-mutation siblings like create_products/update_products. However, 'documented filters' is vague and it does not explicitly contrast with list_shops/list_brands or other read tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for use: get a page of products and pass the returned token for the next page. It does not explicitly say when to prefer list_products over find_duplicate_products or list_orders, but the read/list purpose is clear from the endpoint phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose that the update is processed via an async feed and explains the non-obvious rule that clearing a sale price requires sending nulls rather than omitting salePrice. However, it does not describe overwrite semantics, side effects, permission requirements, or how the async result is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences with no filler. The async feed nature and item structure are front-loaded, and the sale-price clearing rule is a critical operational detail that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives enough to construct a valid-looking payload, which is significant given the schema is so thin. But because this is an async mutation with no output schema and no annotations, it leaves gaps around feed response semantics, status checking, field requirements, and error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the schema only says products is an array of generic objects, so the description must compensate. It does by providing the full item shape including sellerSku, id, category, nested price/salePrice objects, and businessClients. It adds substantial meaning but leaves field types and requiredness implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the verb and resource ('Update price') and adds that it is an async feed, making the core operation clear. It is specific about what is updated and gives the item structure, but it does not explicitly differentiate from siblings like update_products or update_stock, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as update_products, update_stock, or create_products. The only usage hint is the sale-price clearing rule, which is more about parameter behavior than about selecting the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does reveal a key behavior: the update is asynchronous ('async feed'). However, it does not disclose submission semantics, validation behavior, whether the feed replaces or patches stock, or how to check processing status. This is a useful but partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact: two sentences that front-load the action, convey async behavior, and communicate the item structure. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one required parameter and no annotations or output schema, so the description must cover the invocation contract. It does enough for a basic call (products array with sellerSku/id/stock), but it leaves out required field semantics, stock value typing, and how to track the async feed, so it is not fully complete for safe autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names the three meaningful item properties (sellerSku, id, stock), which is helpful, but it omits types, requiredness, and value constraints (e.g., stock as integer vs string) and gives no explicit contract for the products array beyond those keys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Update stock'), resource (stock), and operational mode ('async feed'). It also enumerates the item fields (sellerSku, id, stock), which disambiguates it from sibling read tools like get_stock and broader product/price updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool instead of alternatives such as sync_products, get_stock, or update_products. It does not mention prerequisites, whether this is the preferred batch path for stock changes, or how the async feed relates to get_feed_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It does disclose that the operation is a list (read-style) and that results are paginated, which is useful. It does not cover pagination mechanics, response structure, or access requirements, but the core behavior is reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler. The key action, resource, output fields, and pagination note are front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter list tool, the description covers the essential what and output fields. However, there is no output schema and no annotation coverage, so the description leaves gaps around pagination semantics (page size, page indexing, response format) that an agent would need for robust invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema gives no description for the single optional 'page' parameter, and schema description coverage is 0%. The description's mention of 'paginated' adds context that page is likely a page number, but it does not specify indexing, page size, defaults, or how pagination metadata is returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('brand codes/names known to the catalog'), which clearly distinguishes it from sibling tools like list_shops and list_categories. It also adds a useful scope qualifier ('known to the catalog').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever brand codes/names from the catalog are needed. However, it does not explicitly state when not to use it or mention alternatives, so the guidance is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It surfaces meaningful traits: pagination via 'one page', the absence of an 'ALL' status value, and valid country-code restrictions. It does not describe response format or rate limits, but it covers the most relevant quirks for a read-only listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two terse sentences front-load the core behavior before diving into filter details. Every sentence provides useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no schema descriptions, no annotations, and no output schema, the description is not fully self-contained. It documents the distinctive filters well but leaves date formats, token semantics, and valid status values unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds real meaning for status and country by explaining comma-separated lists, the no-'ALL' behavior, and valid codes. However, size, token, shop_id, created_after, and created_before remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as retrieving one page of GET /orders, with a specific resource and pagination scope. It does not explicitly contrast itself with sibling order-related tools like get_order_items, but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful filtering context: status/country are comma-separated, omitting status returns every status, and valid country codes are listed. However, it does not state when to prefer list_orders over alternatives 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It usefully reveals that the output contains `attributeSet.sid` and how that value is used downstream. However, it does not state read-only behavior, pagination semantics, the effect of the `attribute_set_name` parameter, or the overall response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the core action and follows with workflow-relevant context. Every clause earns its place, and there is no filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description at least identifies the critical output field (`attributeSet.sid`) and connects it to the next step in the workflow. It is missing response format details, pagination behavior, and parameter semantics, but for a simple list tool with an obvious follow-up path, it is adequate rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain `page`, `size`, or `attribute_set_name`. The parameter names hint at basic semantics, but the description adds no detail about defaults, filtering behavior, or valid values, leaving the agent to guess at those aspects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('List categories') and immediately adds a distinguishing detail: each category includes `attributeSet.sid`. This makes its purpose clear and separates it from related tools like `get_attribute_set`, which consumes that value rather than listing categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when this tool is needed: before `create_products`/`update_products` for a product in a category, with the `attributeSet.sid` then passed to `get_attribute_set`. It does not name exclusion cases or alternatives, but it gives a clear workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, but it only states that the tool packs order items and when it is required. It does not disclose side effects such as status changes, validation requirements, whether it creates shipments, or any destructive/irreversible behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with the purpose and use condition in the first clause followed by a compact JSON example. It loses one point because the example is terse and the orderItems field is left as an undefined ellipsis.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is adequate for understanding the basic call shape, but it leaves gaps: no detail on what orderItems entries should be, whether all nested fields are required, and what the operation does beyond the pack action. For a simple one-parameter tool, this is a minimum passing level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no property descriptions (0% coverage), so the inline JSON example is essential and adds real meaning: packages is an array of objects containing orderItems, shipmentProviderId, and trackingCode. It does not specify types or requiredness of those nested fields, but it compensates for the empty schema better than most.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Pack order items') and a resource (order items), and distinguishes this v2 from its siblings by the caller-supplied tracking code requirement. This makes it immediately identifiable against pack_orders and other shipping-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'required when the shipment provider needs a caller-supplied tracking code' gives a clear invocation condition. It does not explicitly name the alternative (likely pack_orders) or state when not to use the tool, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It is transparent about the exact response shape not being guaranteed and instructs the agent to inspect a real response before making assumptions. It does not explicitly state whether the operation has side effects, but the disclosure about schema uncertainty is valuable and honest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both necessary. The first states the operation directly, and the second provides a concise, front-loaded warning about the response format. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description covers the input purpose, the output shape (success.labels[] with a label field), and the key caveat about encoding. It omits side-effect and prerequisite details, but is reasonably complete for a simple retrieval-like operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It connects the single parameter to 'order items' and clarifies that labels are returned per item. However, it does not add detail about array size limits, ID format, or how invalid IDs are handled, though the parameter name is fairly self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('printable shipping labels for order items'). It is not a tautology and precisely identifies what the tool does, distinguishing it from the order and packing-related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like create_consignment, pack_orders_v2, or get_order_items. The description says what the tool returns but does not mention prerequisites, exclusions, or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral disclosure burden. It adds meaningful details beyond the raw schema: a warning that shipping_date is not ISO-8601 despite appearances, and a note that the call returns {purchaseOrderNumber}. It does not mention failure modes or side effects, but the core behavior is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. Every sentence adds value: the definition, the products shape, the date-format warning, and the return value. There is no filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tricky parameters and the return value, but with no annotations and no output schema, the agent is still left to infer the meaning of required parameters like business_client_code. It is adequate for a straightforward call if the agent can infer the rest from parameter names, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies the structure of the `products` array with sku, quantity, and labelCode, and explains the shipping_date format. However, it leaves shop_id, business_client_code, and comment semantically unexplained, relying on their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and a clear resource ('consignment') with an explanatory parenthetical ('inbound stock shipment to a Jumia warehouse'). This distinguishes it from sibling tools like update_consignment and clearly communicates the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by defining a consignment as an inbound stock shipment to a warehouse. However, it does not explicitly mention alternatives or when not to use it, such as using update_consignment for modifying an existing consignment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description takes on the full burden and adds real behavioral context: it calls out the required role, the absence of a cancellation-reason field, and the fact that the audit log only records who/when, not the business reason. It does not explicitly disclose whether cancellation is irreversible or how it affects order state, but it covers the most important operational caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the action is front-loaded, then the role requirement, then the meaningful caveat about the audit log and business reason. Every clause earns its place and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description is reasonably complete: it states the operation, the role requirement, and an important reporting caveat. It could additionally note whether cancellation is reversible or what response/error behavior to expect, but those are less critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The phrase 'one or more order items' implies the order_item_ids array must contain at least one valid item ID, and the reference to no cancellation-reason field clarifies an absent parameter. Still, the description does not explicitly explain the format or source of order_item_ids, leaving some semantics to be inferred from the property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact operation ('Cancel one or more order items') with a specific verb and resource. This clearly distinguishes it from sibling tools like get_order_items, pack_orders, and mark_ready_to_ship, which are read or status-transition operations rather than cancellations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear prerequisite (VC - Order Manager role) and a context around the cancellation reason, which is helpful for deciding applicability. However, it does not explicitly mention when not to use this tool or point to an alternative (e.g., retrieving items first via get_order_items), so some guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly signals a read-only, account-scoped enumeration, which is useful, but it does not disclose return format, pagination, ordering, or behavior when no shops exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no filler. The key qualifiers ('every shop' and 'authenticated Vendor Center account') are front-loaded and immediately useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation, the description is largely complete: an agent can invoke it without needing further input. The absence of an output schema and any note about the returned shop fields or pagination leaves minor ambiguity, but the tool's low complexity keeps this from being a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and full description coverage, so there is nothing for the description to add about parameter handling. This matches the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('List') and a precise resource ('every shop under the authenticated Vendor Center account'). This clearly separates it from sibling list tools such as list_brands and list_categories, so an agent can identify what it does without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: call this tool when you need the shops belonging to the authenticated account. However, there is no explicit guidance about when not to use it, no mention of alternatives, and no hint about common follow-up steps such as obtaining shop IDs for other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it succeeds. It reveals that the tool only reports clusters, suggests a canonical listing based on ACTIVE + QC APPROVED on any business client with oldest winning, and explains the expensive full-scan behavior. It also warns that Jumia has no merge endpoint, which prevents the agent from expecting one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but mostly front-loaded: the first sentence states the core purpose, and subsequent sentences add caveats and usage context. All sentences carry useful information, though the middle sentence is long and could be cleaned up, so it does not quite earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The behavior, canonical-listing logic, and cost trade-off are well covered, and the mention of 'reports clusters' gives some idea of the output. However, with no output schema and several undocumented parameters, the description leaves gaps about the exact return shape and the meaning of max_products_scanned and name_similarity_threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only explains category_code. The other parameters (shop_id, max_products_scanned, name_similarity_threshold) are left entirely to the agent's inference from names and schema defaults, which is insufficient for a tool with four unrestricted parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Flag products that look like the same real-world item listed more than once', then details exact matching criteria (GTIN/EAN/barcode or brand+category+images near-identical name). It also distinguishes itself from deactivate_products by explicitly stating it only reports clusters and that deactivation is a separate later step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear practical guidance: narrow with category_code for large catalogs, and warns that a full paginated scan is expensive across multi-country catalogs. It notes there is no merge endpoint and that resolution happens via deactivate_products, giving a workflow direction, though it does not explicitly contrast with sibling tools like find_outdated_products or list_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose key behavior: repeated polling, terminal statuses, and extra extraction for PRODUCT_CREATION feeds. However, it omits practical details such as polling cadence, what a FAILED response contains, and whether the feed result is consumed/destroyed on completion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences front-load the action and expected loop, then add the one special case an agent needs to know. Every clause earns its place with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter polling tool, the description covers the call pattern, termination conditions, and the special PRODUCT_CREATION result extraction. It does not describe the output shape for other feed types or failure payloads, but given no output schema these are minor gaps rather than blockers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining that feed_id comes from the named async operations, giving the parameter meaningful provenance and role. For a single string parameter this is sufficient semantic grounding, even without format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Poll'), a specific resource ('async feed'), and explicitly ties the feed to five mutation tools, making it unmistakable which operation this is for. It also distinguishes itself from all sibling tools, none of which serve this polling role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly tells when to use the tool: after invoking one of the listed async product operations, and it specifies the expected loop until COMPLETED or FAILED. It does not explicitly state when not to use it, but no sibling tool offers equivalent polling behavior, so the context is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and 'List' does signal a read-only listing operation. It also surfaces a non-obvious output behavior (per-provider tracking-code requirement), but it does not explicitly address side effects, permissions, or failure behavior, which a full-burden description would ideally include.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence front-loads the core operation and packs the conditional routing into a parenthetical. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter listing tool with no output schema, the description covers the operation, the parameter context, and the key output trait (whether tracking code is caller-supplied). It is complete enough to call correctly, though it does not describe response shape or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds key semantic context by saying the tool lists providers 'for an order item', which clarifies that order_item_id identifies the order item in question. It does not provide format or source details beyond that, but for a single self-descriptive parameter this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a precise resource, 'shipment providers available for an order item', immediately identifying the operation. It also distinguishes itself by adding the tracking-code requirement and naming pack_orders_v2 as the alternative, so an agent can tell it apart from sibling tools like pack_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(use pack_orders_v2 if so)' explicitly names the sibling tool and states the condition that should send the agent there. This gives clear when-to-use guidance relative to the alternatives rather than leaving it to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It gives a payload example and a version routing hint, but does not state what packing actually changes, whether the operation is reversible, if permissions are required, or what side effects occur. This is a significant gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact: two sentences, one for the operation and payload shape, and one for the version decision rule. Every sentence earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter legacy tool, the description provides the essential payload shape, a version marker, and an explicit routing rule to pack_orders_v2. It does not explain the return value or side effects, but the call can be constructed and the appropriate sibling selected from the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0% and the schema treating order_items as an arbitrary object array, the description's example is the only real parameter documentation. It supplies the exact keys `id` and `shipmentProviderId` and shows the expected array structure. It leaves some details like optionality and value formats implicit, but it goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation (pack order items), identifies the version (v1), and immediately distinguishes itself from pack_orders_v2. Even without title context, the tool's scope and the intended resource are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names pack_orders_v2 as the alternative and provides a concrete criterion: use v2 when get_shipment_providers reports trackingCodeRequired=true. This explicitly tells an agent when not to use this tool and why.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden — and it delivers. It discloses that the call is non-mutating ('Nothing is changed'), explains the heuristic nature and lack of a native 'outdated' concept in the Vendor Center API, and describes the return structure including the flattened listing rows with variation_id, seller_sku, and business_client_code. This is exemplary behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused paragraph with three distinct sections: what the scan finds, the heuristic caveat and non-mutating guarantee, and the exact return format including how rows map to deactivate_products inputs. Every sentence adds essential guidance; there is no filler. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 unannotated parameters, no output schema), the description covers the operation-level behavior and return shape thoroughly, but it leaves parameter semantics completely undocumented. It explains what the tool does and what the output looks like, but not how to tune the scan thresholds or scope it to a shop/category. The core value is strong; the missing parameter context is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the eight parameters by name. While the prose mentions the broad heuristic criteria (QC-rejected, zero stock, stale ACTIVE), it never ties these to parameters like zero_stock_grace_days, qc_rejected_grace_days, stale_active_grace_days, max_products_scanned, shop_id, or category_code. The schema provides no descriptions, so the agent is left to infer parameter meaning from names alone, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Scan the catalog') and clearly defines the resource and criteria: QC-rejected and never fixed, ACTIVE with zero stock for a long time, or ACTIVE and untouched for a very long time. It also clarifies that the tool is a heuristic scan, not a deletion queue, which distinguishes it from deactivate_products and other sibling tools. The 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states that calling this tool changes nothing, and instructs the agent to pair it with deactivate_products() after human (or deliberate AI) review. It also warns against treating the output as an automatic deletion queue, which is a clear guideline for when and how to use the tool. No alternatives are named, but the pairing and cautionary note provide strong usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'List' clearly signals a read-only operation, and the description specifies the content of the result: required status, allowed values/options, and validation rules. It does not mention error behavior or response format, but the core behavioral traits are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two efficient sentences. The first states the action and result details; the second provides a vital input-source tip. There is no fluff or redundant repetition of the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with no output schema, the description covers what the call returns and where the required input comes from. It could add response structure or failure behavior, but nothing essential for selecting and invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines attribute_set_id as a string with 0% coverage. The description compensates by explaining that the ID belongs to a category's attribute set and specifically where to obtain it: list_categories()'s attributeSet.sid field. This gives actionable semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it 'List[s] the attributes' for a category's attribute set. It further clarifies what is returned—required or not, allowed values/options, validation rules—which distinguishes it from sibling tools like list_categories and list_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit source for the required parameter: 'Get attribute_set_id from list_categories()'s attributeSet.sid field.' This tells the agent when and how to call the tool in a workflow. It does not enumerate alternatives, but no clear alternative tool exists for retrieving attribute metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the async-feed nature, the immutable subset, and the requirement for product `id`. It does not detail error handling, idempotency, or feed-status checking, but the most important behavioral constraints are clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by constraints and item requirements. There is slight redundancy in restating the immutable fields, but overall every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a generic input schema, the description covers the essential invocation details: async behavior, mutable fields, immutable fields, alternatives, and required `id`. It could mention checking get_feed_status for async results, but the description is otherwise sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is nearly empty (array of arbitrary objects), so the description must compensate. It explains that each item needs the product `id` (productSid) plus the fields being changed, and lists the mutable field categories. Exact property names and value formats are still ambiguous, but the description adds substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Update the MUTABLE subset of product fields (async feed)', then enumerates exactly which fields can be changed and which cannot. This clearly distinguishes the tool from siblings like update_price, update_stock, and create_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit routing guidance: use update_price / update_stock for price and stock, and states that main image, main category, and parent SKU are not changeable via this API at all. This tells an agent exactly when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it looks up sellerSku via list_products, diffs against desired, defaults to dry_run=true without side effects, and only submits batched feeds when dry_run=false. The return shape is also specified, so an agent understands what will happen and what it will get back.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured: purpose, example, execution behavior, and return format are all present. It is somewhat dense with parenthetical asides, but every part contributes useful operational context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The absence of both annotations and an output schema means the description alone must cover behavior and returns. It does so well for a complex sync/diff tool, though shop_id semantics and failure/error behavior are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It thoroughly explains the desired array with a JSON example and clarifies dry_run semantics, but it does not explicitly describe shop_id. This is a minor gap because the key required parameter is well-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: reconcile a source of truth against Jumia and push only changed fields. It distinguishes itself from separate create/update/price/stock calls, making its role among the siblings clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames the tool as a replacement for hand-writing separate create/update/price/stock calls and notes the dry_run-first workflow. It also signals when to extend to update_products diffing, giving practical when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the async result flow, the requirement to poll, the quirk that parentSku is required despite the schema marking it optional, shared-image constraints for variants, and the ~1000-item cap with no auto-chunking. This goes well beyond the tool name and schema to prevent incorrect invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense; each section earns its place. It is front-loaded with the async workflow, then parameter semantics, then sourcing policy and chunking guidance, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex creation tool with an empty schema, no output schema, and no annotations, the description covers invocation flow, required follow-up, dangerous assumptions, data sourcing, error-avoidance, and chunking. An agent has enough context to call this correctly and understand the lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates thoroughly: it documents the structure of each products item, gives concrete JSON examples for name, description, price, images, stock, attributes, and businessClients, and flags parentSku as required. The only parameter not expanded is shop_id, which is self-explanatory in this context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action 'Create new products' and immediately identifies it as an async feed, which distinguishes it from synchronous siblings like update_products and sync_products. The scope is clear: creation, not modification or synchronization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow conditions: poll get_feed_status until COMPLETED, then learn productSid and QC status before updating stock/price/status; call get_attribute_set and list_categories first; chunk lists because there is no auto-chunking. It does not explicitly contrast with sibling tools such as update_products, but the create-vs-update boundary is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It discloses that the tool only sets INACTIVE, does not delete, there is no delete endpoint, and the listing becomes unsellable/hidden. It also notes that every call is logged to the local audit log, adding operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and the critical 'does not delete' caveat. Every sentence provides distinct value: scope, limitation, parameter format, and logging. The code block is compact and illustrative, not filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested parameter, no annotations, no output schema), the description leaves no critical gap. It covers the action, side effects, limitations, parameter mapping, and relation to a sibling tool's output. An agent can correctly select and invoke this tool with the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does thoroughly. It explains the products array structure, the meaning of id (productSid/variation_id), the optional business_client_codes array, and the convenience singular business_client_code. It even maps find_outdated_products row fields directly to the expected parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('sets status to INACTIVE per business client') and the resource ('product'). It explicitly distinguishes itself from deletion, which prevents confusion with any implied 'remove' semantics. The contrast with 'no delete endpoint' makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use this tool (when the intent is to hide/unsell a listing) and when not to (when permanent removal is needed, in which case the account manager is the alternative). It also connects the input format to find_outdated_products output, giving clear invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

jumia-vendor-center MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![jumia-vendor-center MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/damurka/jumia-vendor-mcp/badges/card.svg)](https://glama.ai/mcp/servers/damurka/jumia-vendor-mcp)

Score Badge

Copy to your README.md:

[![jumia-vendor-center MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/damurka/jumia-vendor-mcp/badges/score.svg)](https://glama.ai/mcp/servers/damurka/jumia-vendor-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/damurka/jumia-vendor-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server