Provides tools for creating tasks, listing tasks in a project, and updating task status in Asana, allowing an agent to manage fulfillment and operational tasks.
Provides tools for searching Odoo models, looking up stock levels, and creating sale orders, enabling integration with Odoo's ERP/accounting and inventory systems.
Provides tools for retrieving Shopify orders and inventory levels, enabling an agent to read storefront order data and stock information.
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., "@ecom-ops-mcp Fulfill Shopify order #1042 and create the Odoo sale order and Asana task"
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.
One MCP server that bridges Shopify, Odoo, and Asana for e-commerce operations, plus Excel export, so an AI agent (Claude, etc.) can run fulfillment ops across all three without you copy-pasting between tabs.
Official MCP servers exist for each tool individually. This one adds the piece none of them have: a cross-system workflow tool (fulfill_shopify_order) that pulls a Shopify order, creates the matching Odoo sale order, and opens the Asana fulfillment task, in one call.
Small e-commerce ops teams run Shopify (storefront), Odoo (accounting/inventory), and Asana (task tracking) as three disconnected systems. Every order means manually re-typing the same data three times. This MCP server lets an AI agent do that handoff correctly, every time.
Related MCP server: Shopify Agentic MCP Gateway
Tool | Description |
| List Shopify orders |
| Get one Shopify order |
| Get Shopify inventory levels |
| Generic search_read against any Odoo model |
| Look up stock for a product |
| Create an Odoo sale order |
| Create an Asana task |
| List tasks in an Asana project |
| Complete/reopen an Asana task |
| Export any tabular result to |
| The hub flow: Shopify order → Odoo sale order → Asana task, one call |
npm install
cp .env.example .env # fill in your credentials
npm run buildAdd to your MCP config:
{
"mcpServers": {
"ecom-ops": {
"command": "node",
"args": ["/absolute/path/to/ecom-ops-mcp/dist/index.js"],
"env": {
"SHOPIFY_STORE_DOMAIN": "your-store.myshopify.com",
"SHOPIFY_ACCESS_TOKEN": "shpat_xxx",
"ODOO_URL": "https://your-instance.odoo.com",
"ODOO_DB": "your-db",
"ODOO_USERNAME": "you@example.com",
"ODOO_API_KEY": "your-key",
"ASANA_ACCESS_TOKEN": "your-pat"
}
}
}
}npm run dev # run with tsx, no build stepEarly / actively developed. Credentials required per-service; each client module works independently if you only need one integration (e.g. just Odoo + Asana).
MIT
Create an Asana task in a project
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| dueOn | No | ||
| notes | No | ||
| projectId | Yes | ||
| assigneeId | 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. It states that a task is created, implying mutation, but gives no information about side effects, required permissions, duplicate behavior, or response format. This is a significant gap for a write operation.
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 with no filler or repetition. It is front-loaded and immediately readable.
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, 0% schema description coverage, and five parameters, this one-sentence description is not complete enough for an agent to confidently call the tool. It omits parameter meaning, return value expectations, and guidance on selecting this tool over related Asana tools.
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 the schema's lack of parameter explanations. It only adds context for projectId via 'in a project' and leaves name, dueOn, notes, and assigneeId semantically underspecified. The property names are somewhat self-explanatory, but the description does not meaningfully explain them.
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 and resource: 'Create an Asana task in a project.' It is specific enough to distinguish creation from sibling read/update tools like asana_get_tasks and asana_update_task_status, though it does not explicitly name those alternatives.
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 usage guidance is provided. The description does not say when to prefer this tool over asana_update_task_status or asana_get_tasks, nor does it mention any prerequisites or exclusions. The intended context must be inferred entirely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks in an Asana project
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | ||
| completedSince | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of indicating that this is a read-only list operation, which 'List' does convey. However, it adds no details about pagination, optional filters, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the action and resource, with no wasted words. The description is easy to scan and digest.
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 tool with no output schema and no annotations, this is under-specified: the optional `completedSince` parameter is unexplained, and there is no indication of what the returned tasks look like. A minimally viable description should at least clarify the required project scope and the optional filter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not mention `projectId` or `completedSince`. 'project' hints at `projectId`, but the optional filter and its expected format are left completely unspecified.
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 ('tasks') with a clear scope ('in an Asana project'). This cleanly separates it from the create/update Asana siblings and from the Odoo/Shopify tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The statement 'List tasks in an Asana project' provides clear context for the intended use: retrieving tasks for a project. It does not explicitly name alternatives or exclusion conditions, but the use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark an Asana task complete or incomplete
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | ||
| completed | Yes |
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. The phrase 'Mark complete or incomplete' implies a mutation, but it does not disclose side effects, permission requirements, reversibility, or any error behavior. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately front-loaded with the core action. While it could be more informative, it is not verbose or redundant, earning a high score for conciseness.
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 low complexity (2 params, no output schema), the description is still under-specified. It does not describe what happens after the update (e.g., return value, success/failure indications), nor does it mention any prerequisites or edge cases. With no annotations and no output schema, the description should provide more context to make the tool reliably callable, but it falls short.
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. The description only hints at the 'completed' parameter by mentioning complete/incomplete, but it does not explain the meaning of 'taskId' or clarify that 'completed' is a boolean flag. It fails to add meaningful semantics beyond the parameter names and types, leaving the agent without guidance on how to fill the parameters 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 clearly states the verb 'Mark' and the resource 'Asana task', with the specific state change 'complete or incomplete'. It distinguishes from sibling tools like asana_create_task and asana_get_tasks, as it focuses on updating status rather than creating or listing. However, it could be more explicit that this is an update operation on an existing task, but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating task status but does not explicitly contrast it with alternatives. No mention of when to use this tool versus creating a task or fetching tasks. While the context is clear, there is no explicit guidance on exclusions or alternatives, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export tabular data (e.g. combined order/stock/task data) to an .xlsx file on disk
| Name | Required | Description | Default |
|---|---|---|---|
| rows | Yes | ||
| columns | Yes | ||
| filename | Yes | ||
| sheetName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states it writes to a file, but does not mention whether it overwrites existing files, handles errors, requires permissions, or returns any confirmation. For a write operation, this is a significant omission.
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 concise sentence with no fluff. It front-loads the core purpose and gives an example. However, it could have used the space to include parameter details or behavioral notes while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 required parameters, no output schema, and no annotations, the description is grossly incomplete. It does not explain what the parameters represent, what happens to existing files, or what the tool returns. An agent cannot reliably call this tool without additional external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning the description must explain the parameters. It does not mention filename, sheetName, columns, or rows at all. The agent would have to infer from the schema alone, which lacks descriptions. The description adds no parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports tabular data to an .xlsx file on disk. It uses a specific verb ('export') and resource (tabular data to .xlsx file). This distinguishes it from sibling tools which are all about retrieving or creating data in other systems, not generating Excel files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case ('combined order/stock/task data') but does not explicitly state when to use this tool versus alternatives. Since there is no sibling that performs Excel export, the guidance is implicit rather than explicit. It lacks clear 'when not to use' or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The ops-hub flow: pull a Shopify order, create the matching Odoo sale order, open an Asana fulfillment task, and return a combined summary. This is the one-call replacement for manually copying an order across three tools.
| Name | Required | Description | Default |
|---|---|---|---|
| dueOn | No | ||
| asanaProjectId | Yes | ||
| shopifyOrderId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the main steps (pull, create, open, return) and implies mutations, but does not mention failure modes, partial execution behavior, or authentication prerequisites across the three systems.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste, front-loading the core flow. Lacks structured breakdown but remains efficient and readable.
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 multi-step orchestrator with no output schema and no annotations, the description omits parameter semantics, return format, and error handling. An agent cannot reliably invoke it without guessing parameter meanings and expected output.
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 gives no meaning for shopifyOrderId, asanaProjectId, or dueOn. Since it is a composite tool, it is critical to know which ID belongs to which system; the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific composite operation: pulls a Shopify order, creates an Odoo sale order, opens an Asana fulfillment task, and returns a combined summary. Clearly distinguishes from individual sibling tools by describing a multi-step flow.
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?
Explicitly positions this as the one-call replacement for three tools, implying it should be used when the full flow is needed. However, it does not state when to prefer individual tools or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a sale order in Odoo for a customer with line items
| Name | Required | Description | Default |
|---|---|---|---|
| lines | Yes | ||
| reference | No | ||
| partnerName | Yes | ||
| partnerEmail | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must shoulder the burden of behavioral disclosure. It only says 'Create', which indicates mutation, but does not explain what happens on success (e.g., returns the order ID), whether it is idempotent, or if it requires specific permissions. It also does not disclose side effects such as order confirmation or inventory changes. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, which is highly concise and front-loaded with the primary action. There is no extraneous information, and every word contributes to the core purpose. This is an example of efficient, effective brevity.
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 that the tool has 4 parameters, no output schema, and no annotations, the description is woefully incomplete. An agent would need to know the meaning of each parameter, the expected return value, and any prerequisites (e.g., customer existence). The description covers only the broad purpose intervene, leaving many operational details unanswered.
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 description coverage is 0%, so the description must compensate for parameter meaning. However, the description explicitly mentions 'line items', which clarifies the 'lines' parameter structure somewhat. It also says 'for a customer', which hints at 'partnerName'. But it does not describe 'reference' or 'partnerEmail', leaving those ambiguous. Given the 0% coverage, the description does provide some semantic value but not enough to fully compensate.
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 ('Create') and resource ('sale order in Odoo') and mentions 'for a customer with line items', which gives a basic sense of scope. It does not explicitly differentiate it from siblings like odoo_search_read or odoo_get_stock_level, but those are clearly different operations (reading vs. creating). The description is not tautological and provides a useful one-liner.
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. For example, it does not say to use this when creating a sale order, or to use odoo_search_read to check existing customers. The description implies a use case (creating a sale order) but lacks explicit context or exclusions. It could have mentioned that it is for sales transactions, not other Odoo models.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up available/forecast stock for a product by (partial) name
| Name | Required | Description | Default |
|---|---|---|---|
| productName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does mention that the lookup accepts a 'partial' name, which is a useful behavioral detail. However, it does not explain what 'available/forecast' means in terms of real-time data, whether the results are cached, or if any authorization is needed. The description partially covers the behavioral burden but leaves room for clarification.
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, concise sentence that is front-loaded with the key action and resource. It efficiently conveys the core purpose without extra words. However, it could have added brief usage guidance or a note about the forecast aspect, but overall it is well-structured and easy to scan.
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?
It is a relatively simple tool with only one parameter and no output schema, so the description covers most necessary aspects. It mentions the lookup type (available/forecast) and the partial name behavior. However, it does not explain what the output format is (e.g., a number, a list, units) or any error conditions (e.g., product not found). Given the simplicity, the description is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the parameter. The description says the lookup is by 'name' and mentions 'partial' matching, which adds meaning beyond the bare parameter name 'productName'. However, it doesn't specify whether the name is case-sensitive or if exact matches are preferred. The description provides some additional semantics, but not extensive detail, so a 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 uses a specific verb ('Look up') and resource ('stock level for a product') and clearly mentions a key behavior (partial name match). It distinguishes itself from siblings like odoo_search_read and odoo_create_sale_order by focusing on stock lookup rather than generic read or write operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a specific use case: checking stock for a product. It does not explicitly state when to use this versus alternatives like shopify_get_inventory (which is for Shopify) or odoo_search_read (which is generic Odoo records). No exclusions are mentioned, so the agent must infer that this is the Odoo-specific stock lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a search_read against any Odoo model (e.g. sale.order, res.partner, product.product)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| model | Yes | ||
| domain | No | ||
| fields | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden of behavioral disclosure. It only says 'search_read' which implies a read operation, but it does not mention side effects, permissions, pagination, error handling, or any operational traits. This is a significant gap for a generic data access tool.
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, concise sentence with no wasted words. It is front-loaded with the action and resource, making it easy to parse. However, it is so brief that it sacrifices essential detail, but for conciseness and structure alone it scores well.
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 generic nature (any model) and four parameters with no schema descriptions, no output schema, and no annotations, the description is severely incomplete. It lacks guidance on domain syntax, field selection, limit behavior, return format, and edge cases. An agent would struggle to use this tool correctly based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameter descriptions (coverage 0%), and the description does not explain any of the four parameters (model, domain, fields, limit). The examples mention model values but not the semantics of the other parameters, leaving the agent with no guidance on how to construct a valid domain or interpret the limit.
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 action ('Run a search_read') against a specific resource (any Odoo model), with examples. It distinguishes from sibling tools by being generic while siblings are model-specific, though it doesn't explicitly name alternatives.
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 provided on when to use this tool versus the siblings like odoo_get_stock_level or odoo_create_sale_order. The description only states what it does, not when it should be chosen over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Shopify inventory levels, optionally filtered by location
| Name | Required | Description | Default |
|---|---|---|---|
| locationId | No |
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 only says 'Get inventory levels' and offers an optional filter. It does not state whether the operation is read-only (likely, but unconfirmed), whether it returns all inventory items or paginates, or if any permissions are required. This is a significant gap for a tool that mutates nothing but still needs to convey response shape and constraints.
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 primary action ('Get Shopify inventory levels') and mentions the optional filter. There is no fluff or redundancy. It could be more informative without losing conciseness, but as written, it is appropriately brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single optional parameter and no output schema, the description should still convey what the agent can expect in terms of response (e.g., list of items, counts, pagination) and default behavior when locationId is omitted. None of this is covered. For a simple tool, the description is minimal but leaves the agent guessing about the output structure and edge cases.
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 only parameter is locationId (string). The description adds that filtering by location is optional, which gives some meaning to locationId. However, it does not explain the format of the locationId (e.g., numeric string, a resource ID), what happens if omitted, or how the response is affected. With low coverage, the description should compensate more thoroughly, but it only offers a brief hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb+resource: 'Get Shopify inventory levels'. The purpose is unambiguous and the tool name aligns. However, it does not differentiate from siblings like odoo_get_stock_level, which could also retrieve inventory (though for a different system). Since the name itself implies Shopify, and the description confirms it, it's clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions an optional filter ('optionally filtered by location') but provides no guidance on when to choose this tool over alternatives such as odoo_get_stock_level or when locationId should be provided. There are no exclusions or context about scenarios where this tool is preferred. An agent would have to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single Shopify order by ID
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes |
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-only operation, but the description does not mention authentication needs, error behavior for missing orders, response contents, or any rate limits. Minimal behavioral detail is provided.
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 redundant information. Every word contributes to identifying the operation.
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 very simple one-parameter retrieval tool, the description is minimally viable. However, with no annotations, no output schema, and 0% parameter coverage, the agent receives no information about return shape, failure modes, or authorization, leaving notable contextual gaps.
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 only says 'by ID', which adds little beyond the already self-explanatory parameter name 'orderId'. No format, source, or interpretation of the ID is provided, so the description does not compensate for the schema's lack of detail.
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'), a specific resource ('a single Shopify order'), and a clear identifier ('by ID'). It distinguishes itself from the sibling shopify_get_orders by explicitly indicating singular 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 usage is implied: use this tool when retrieving one specific order by its ID. There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named, but for a get-by-ID tool the intended context is reasonably inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Shopify orders (any/open/closed/cancelled)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, but it only says 'List', implying a read operation. It does not state pagination, default limit/status behavior, response shape, or whether any statuses are mutually exclusive.
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 with the key resource and status options front-loaded. It is concise to the point of being terse, but avoids 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?
The tool has two parameters, no annotations, and no output schema; the description is too minimal to fully guide invocation. An agent would still need to infer status handling, limit semantics, pagination, and return format.
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 adds possible status values (any/open/closed/cancelled) for the status parameter, but says nothing about the limit parameter or its default/constraints.
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 action ('List') and resource ('Shopify orders'), with a parenthetical of status scopes. It is arguably set apart from the singular sibling shopify_get_order by pluralization, but it does not explicitly name or contrast that 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?
No when-to-use guidance is given, nor are alternatives or exclusions mentioned. The status parenthetical hints at filtering but does not explain when to choose this over shopify_get_order or fulfill_shopify_order.
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.0asana_create_taskasana_get_tasksasana_update_task_statusexport_report_to_excelfulfill_shopify_orderodoo_create_sale_orderodoo_get_stock_levelodoo_search_readshopify_get_inventoryshopify_get_ordershopify_get_ordersScored across 11 tools
Most tools are clearly separated by system prefix and resource, but odoo_search_read is a generic fallback that overlaps with odoo_get_stock_levelanding fulfill_shopify_order duplicates the multi-tool workflow, creating some selection ambiguity for agents.
Naming follows a mostly verb_noun pattern with system prefixes, but conventions differ: shopify_get_orders vs odoo_search_read, export_report_to_excel lacks a system prefix, and fulfill_shopify_order inverts the prefix order. This mixed style is readable but not fully consistent.
Eleven tools cover three external systems plus reporting and a composite workflow without feeling bloated. Each tool has a clear niche, and the count aligns well with the server's multi-system e-commerce operations scope.
The core order-to-fulfillment lifecycle is covered: fetch Shopify orders, create Odoo sale orders, manage Asana tasks, and export data. Minor gaps exist—no Shopify order updates, no single Asana task detail, and no Odoo sale order modification—but the generic odoo_search_read and composite fulfill tool mitigate most dead ends.
Agentic commerce gateway: discovery, search, checkout across Shopify/Woo/Odoo/PrestaShop.
Odoo ERP for AI agents: hosted OAuth endpoint, gated writes, one endpoint for every instance.
An AI agent that runs your online business: products, orders, customers, email, and sites.
Manage your NanoCart store from any AI agent: products, orders, coupons, subscribers, reports.
