Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Dicker Data MCP Server What's the live price and stock for product code AP-1234?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Dicker Data's B2B partner/reseller REST API - pricing and stock lookup, order placement and tracking, and invoices, for AI assistants and the WYRE Conduit gateway.
Dicker Data does not offer self-serve API signup. Request access from integration.support@dickerdata.com.au or services.sales@dickerdata.com.au to receive a long-lived AccountCode + AccessToken pair.
Every real API call additionally requires a short-lived AccessKey, obtained by exchanging the AccountCode/AccessToken via POST /api/AccessKeyRequest. This server handles that exchange (and its refresh, on expiry) internally - callers only ever need to supply the long-lived credentials.
Related MCP server: MCP Salesforce Revenue Cloud
Env var | Description |
| Long-lived account code issued by Dicker Data. |
| Long-lived access token issued by Dicker Data. |
|
|
|
|
| When set, the HTTP transport requires a valid |
|
|
dickerdata_get_pricing - live pricing + stock-on-hand for one or more product codes.
dickerdata_get_price - detailed pricing for a single product code at a given quantity.
dickerdata_create_order - place a purchase order.
dickerdata_get_order_details - look up a single order.
dickerdata_list_orders - list orders matching account code / order / backorder / PO number.
dickerdata_get_order_serials - shipped serial numbers for an order.
dickerdata_get_consignment_status - shipping/tracking status for a consignment.
dickerdata_list_invoices - invoices within a date range.
dickerdata_get_invoice_details - line-item detail for a sales order/invoice.
This is a v1 / MVP surface covering the core distributor workflow (pricing, ordering, tracking, invoicing). Explicitly out of scope for now: Microsoft CSP/ESD subscription management, Autodesk subscriptions, and annuity-order endpoints - these are much larger, vendor-specific surfaces distinct from core distribution. They can be added as a follow-up if there's demand.
npm install
npm run build
npm test
npm run lint # tsc --noEmitdocker build -t dicker-data-mcp .
docker run -p 8080:8080 -e DICKERDATA_ACCOUNT_CODE=... -e DICKERDATA_ACCESS_TOKEN=... dicker-data-mcpPlace a new purchase order with Dicker Data for one or more products.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Products to order. | |
| notes | No | Order-level notes. | |
| customerPORef | No | Your own purchase-order reference for this order. | |
| deliveryAddress | No | Delivery address. Omit to ship to the account default address. | |
| deliveryAttention | No | Attention line for delivery. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action of placing an order and gives no details about side effects, order submission flow, confirmation/order ID response, reversibility, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and object. Every word earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with five parameters, a nested deliveryAddress object, no output schema, and no annotations. The description does not explain what happens after the order is placed, what the response contains, or how errors are surfaced, leaving a significant gap for an agent invoking a side-effecting operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters. The description adds minimal semantic value beyond restating that products are ordered; it does not explain edge cases like price overrides or delivery address defaults beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Place') and resource ('a new purchase order with Dicker Data') and specifies the object ('one or more products'). This clearly distinguishes it from the read-oriented sibling tools like get_pricing, list_orders, and get_order_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when creating an order, but it does not explicitly state when to use it versus alternatives or mention any prerequisites such as checking pricing or stock first. There is no explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get shipping/tracking status for a Dicker Data consignment number.
| Name | Required | Description | Default |
|---|---|---|---|
| consignmentNumber | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, but it only says 'Get shipping/tracking status.' It does not disclose what the returned status looks like, whether this is a read-only lookup, or what happens for invalid or unknown consignment numbers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is efficient and immediately communicates the core action, though it is terse enough that some behavioral context is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a low-coverage input schema, the description leaves important gaps: it never explains the response format, error behavior, or usage context. The single required parameter is identified, but overall the description is only barely adequate for a one-parameter lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description merely restates 'consignment number' without adding format, examples, length constraints, or any domain-specific meaning beyond the property name. It does not compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), a specific resource ('shipping/tracking status'), and the exact input ('a Dicker Data consignment number'). It is immediately distinguishable from sibling tools covering pricing, orders, and invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever shipping/tracking status for a consignment number is needed. However, it does not explicitly state when not to use it or mention any alternative, though no sibling tool overlaps with this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get line-item detail for a Dicker Data sales order / invoice.
| Name | Required | Description | Default |
|---|---|---|---|
| salesOrderNumber | Yes | ||
| salesOrderNumberSuffix | No | ||
| includeCustomerQualification | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but the description does not mention response format, pagination, authentication requirements, or any constraints on the sales order / invoice relationship. This leaves important behavior undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It is concise, though the brevity comes at the cost of parameter and usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and parameter descriptions, this minimal description is not enough for an agent to fully understand what the tool returns or how optional parameters behave. It identifies the core purpose but leaves important invocation details unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters. In particular, 'salesOrderNumberSuffix' and 'includeCustomerQualification' are not self-explanatory, and the description provides no compensating context. This is a significant gap for an agent trying to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('line-item detail for a Dicker Data sales order / invoice'), so an agent can tell this is a detail-level retrieval tool. It does not explicitly contrast itself with siblings like dickerdata_get_order_details, but the line-item focus gives reasonable differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as dickerdata_get_order_details, dickerdata_list_invoices, or dickerdata_get_order_serials. No exclusions or selection conditions are provided, so usage context must be inferred entirely from the tool name and terse description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a single Dicker Data order by order number, account code, or your PO reference.
| Name | Required | Description | Default |
|---|---|---|---|
| accountCode | No | ||
| orderNumber | No | ||
| customerPORef | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'Get', implying a read operation, but does not confirm read-only behavior, mention authorization requirements, rate limits, or how the three parameters interact (e.g., precedence, requiredness). It also omits any error behavior or response format. This is a significant gap for a tool with no annotation safety net.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the core action and resource, then lists the identifier options. There is no redundancy or filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 optional parameters, no output schema, no annotations, and no parameter descriptions), the one-sentence description is incomplete. It omits whether any parameter is required, how parameters interact, what 'details' include, and any usage constraints. An agent would lack sufficient guidance to reliably construct a correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaning by stating the three parameters are alternative identifiers ('by order number, account code, or your PO reference'), but it does not clarify whether at least one is required, how they combine (OR vs AND), or provide any format guidance. This minimal explanation is insufficient given zero schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'details for a single Dicker Data order', and enumerates three identifiers (order number, account code, PO reference). It implicitly distinguishes from sibling tools like list_orders by focusing on a single order, but does not explicitly name alternatives or contrast with them, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have one of the three identifiers and need order details, but it does not explicitly state when to prefer this over siblings (e.g., list_orders for multiple orders, get_order_serials for serials). No exclusions or alternative routing are provided, leaving the agent to infer the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the shipped serial numbers for a Dicker Data order.
| Name | Required | Description | Default |
|---|---|---|---|
| orderNumber | Yes | ||
| orderSuffix | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'Get' signals a read-only operation and 'shipped serial numbers' narrows the data scope, which is useful. However, it says nothing about failure behavior, authentication requirements, or what happens when an order has no shipped serials.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; every word contributes to stating what the tool returns. This is appropriately concise for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup, the basic selection and invocation context is present: the resource is clear, and the schema supplies the required orderNumber. However, the missing meaning of orderSuffix and lack of sibling differentiation are clear gaps that keep it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for both parameters. It only provides the loose hint that the operation concerns an order, giving some meaning to orderNumber but leaving orderSuffix entirely unexplained in both the schema and the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a precise resource ('shipped serial numbers for a Dicker Data order'), so an agent can tell this tool returns serials rather than general order data. It does not explicitly contrast with siblings like dickerdata_get_order_details, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus dickerdata_get_order_details or dickerdata_list_orders, and no prerequisites are stated. The word 'shipped' weakly implies the order must have shipped, but that is not made explicit enough to count as meaningful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed pricing for a single Dicker Data product code at a given quantity.
| Name | Required | Description | Default |
|---|---|---|---|
| quantity | No | Quantity to price at. Defaults to 1 if omitted. | |
| productCode | Yes | The Dicker Data product/part number to price. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The verb 'Get' conveys that this is a read-only pricing lookup, but the description does not disclose error behavior, authentication needs, data freshness, or whether the returned pricing is indicative or guaranteed. It is minimally transparent for a simple read operation but not richly detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no filler. It front-loads the action and resource, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two parameters and full schema coverage, the description is largely sufficient for an agent to invoke it correctly. The main gap is the lack of explicit differentiation from the similarly named sibling dickerdata_get_pricing, and there is no output schema to clarify the return shape, but the core call is well-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description's mention of 'a single product code' and 'a given quantity' aligns with the parameters but adds no meaning beyond what the schema provides. The baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('detailed pricing for a single Dicker Data product code at a given quantity'), so an agent knows what the tool operates on. However, it does not explicitly distinguish itself from the sibling dickerdata_get_pricing, despite the word 'single' implying a narrower scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pricing a single product code at a specified quantity, which gives some context. It does not explicitly state when to use this tool versus dickerdata_get_pricing or any other sibling, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up live pricing and stock-on-hand for one or more Dicker Data product codes (part numbers).
| Name | Required | Description | Default |
|---|---|---|---|
| productCodes | Yes | One or more Dicker Data product/part numbers to price and check stock for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Look up live pricing and stock-on-hand' makes the read-only nature and freshness of data reasonably clear, but it does not describe output structure, error behavior, or limits on the number of product codes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every phrase contributes meaning, and it is immediately clear what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup tool, the description is largely complete: it names the input type and the two key output aspects (pricing and stock). Minor gaps such as maximum number of codes or response format are not critical for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter. The description only restates that one or more product codes are accepted and adds little meaning beyond the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Look up') and names the resource ('live pricing and stock-on-hand for Dicker Data product codes'). It is clear and hints at differentiation from dickerdata_get_price by including stock-on-hand and supporting multiple codes, but it does not explicitly distinguish itself from that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus dickerdata_get_price or other siblings. There are no explicit conditions, prerequisites, or exclusions, so an agent must infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Dicker Data account invoices within a date range.
| Name | Required | Description | Default |
|---|---|---|---|
| endDate | No | End date, e.g. 2026-01-31. | |
| startDate | No | Start date, e.g. 2026-01-01. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral burden itself. It conveys a read-style 'list' operation and a date filter, but it doesn't disclose whether the operation is non-mutating, how results are returned or paginated, or any edge-case behavior with the date range.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient, front-loaded sentence with no filler or redundant phrasing. It is appropriately sized for a simple two-parameter list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list of invoices with two optional date parameters, the description is minimally viable, but because there is no output schema and no annotations, it leaves gaps around the response shape, pagination, and explicit routing to sibling tools. It is adequate, not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters at 100% coverage with concrete examples, and the description's 'within a date range' maps naturally to startDate and endDate. The description adds no parameter semantics beyond what the schema provides, so it earns the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('Dicker Data account invoices'), and adds a date-range scope, which makes the tool's core action unambiguous. It is distinguishable from close siblings such as dickerdata_get_invoice_details by the list-vs-detail contrast, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The date-range wording implies this is for fetching a batch of invoices over a period, but there is no explicit guidance on when to choose it over related tools like dickerdata_get_invoice_details or how it relates to dickerdata_list_orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Dicker Data orders matching an account code, order number, backorder number, or customer PO number.
| Name | Required | Description | Default |
|---|---|---|---|
| accountCode | No | ||
| orderNumber | No | ||
| backorderNumber | No | ||
| customerPONumber | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior, but it only restates the query filters. It does not mention authentication, read-only behavior, result format, pagination, or the effect of providing no parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the action and resource, then lists the criteria. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and four optional-looking parameters, the description leaves important invocation details unstated: whether a filter is required, whether multiple filters combine, and what the returned list contains. It is minimally usable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must supply parameter meaning. It does name all four filter fields and indicates they are matching keys, but it gives no detail about format, exact-match behavior, or whether at least one must be provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('Dicker Data orders') and enumerates four precise matching criteria. It clearly communicates the tool's scoped purpose, though it does not explicitly contrast with sibling tools like dickerdata_get_order_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for listing orders by various identifiers but gives no guidance on when to choose this tool over alternatives, such as dickerdata_get_order_details, or whether the filters are alternatives or required. An agent cannot tell from this text which sibling to call for a single order's full details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0dickerdata_create_orderdickerdata_get_consignment_statusdickerdata_get_invoice_detailsdickerdata_get_order_detailsdickerdata_get_order_serialsdickerdata_get_pricedickerdata_get_pricingdickerdata_list_invoicesdickerdata_list_ordersScored across 9 tools
Most tools target distinct resources and actions, but get_pricing and get_price overlap in purpose; their descriptions clarify one is multi-product live pricing with stock and the other is single-product quantity-based pricing. Order and invoice tools are clearly separated by resource and operation.
All tools follow a consistent dickerdata_ prefix with a verb_noun pattern: get_, list_, or create_. Naming is uniform and predictable across pricing, orders, invoices, and shipping.
Nine tools is a well-scoped set for a distributor-focused server covering pricing, ordering, shipping, and invoicing. Each tool serves a distinct operational need without unnecessary bloat.
The server covers the main distributor workflow: pricing lookup, order creation, order tracking, serials, shipping status, and invoices. Minor gaps exist such as order updates/cancellations and product catalog search, but core operations are well covered.
Enable AI assistants to interact seamlessly with Feeef e-commerce stores, products, and orders usi…
Deep purchase intelligence for agents and apps: live prices, landed cost, trust scores. Free.
Global B2B intelligence for AI agents: 35M+ companies, 1.6M sanctions, KYB pack. 78 tools.
Directory of APIs, merchants, and tools AI agents can actually use.
