Click on "Install 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., "@karrito-mcp list all my products"
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 Karrito — the digital catalog builder for WhatsApp sellers in LATAM.
Connect your AI assistant (Claude, Cursor, Windsurf) to Karrito and manage your entire store — products, orders, discounts, reviews, shipping, analytics — without leaving your editor.
npx karrito-mcpclaude mcp add karrito -- npx karrito-mcpclaude_desktop_config.json){
"mcpServers": {
"karrito": {
"command": "npx",
"args": ["karrito-mcp"],
"env": {
"KARRITO_API_KEY": "your-api-key-here"
}
}
}
}Add to your MCP configuration:
{
"karrito": {
"command": "npx",
"args": ["karrito-mcp"],
"env": {
"KARRITO_API_KEY": "your-api-key-here"
}
}
}Related MCP server: ManyContacts MCP Server
Variable | Required | Description |
| For authenticated tools | Your Karrito API key from Settings > API |
| No | Custom API URL (default: |
Static data about Karrito — no authentication required.
Resource | URI | Description |
Pricing |
| Plans, prices, and features comparison |
Features |
| Complete feature list (core, pro, upcoming) |
Niches |
| All 50 available store niches |
Competitors |
| 19 competitors compared with Karrito advantages |
Currencies |
| 6 supported LATAM currencies |
Tool | Description |
| Search public catalogs by keyword |
| Get info about a specific niche |
Tool | Description |
| List products in your catalog |
| Create a new product |
| Update an existing product |
| Delete a product (soft delete) |
Tool | Description |
| List categories in your store |
| Create a new category |
| Update an existing category |
| Delete a category |
Tool | Description |
| List orders with optional status filter |
| Get detailed order info |
| Change order status (confirm, ship, deliver, cancel) |
Tool | Description |
| Get store info (name, slug, currency, stats) |
| Update store settings (name, WhatsApp, currency, etc.) |
| Quickly publish or unpublish your store |
Tool | Description |
| List discount codes |
| Create a discount code (percentage or fixed) |
| Update an existing discount |
| Delete a discount code |
Tool | Description |
| List reviews with optional status filter |
| Approve or reject a review |
| Permanently delete a review |
Tool | Description |
| List customers who have ordered |
| Get customer detail with order history |
Tool | Description |
| Store stats: orders, revenue, products, customers, AOV, popular products |
Tool | Description |
| List shipping options |
| Create a shipping option (delivery, pickup, express) |
| Update a shipping option |
| Delete a shipping option |
"Search for bakery catalogs on Karrito"
The assistant will use search_catalogs with query "bakery" to find matching stores.
"What niches does Karrito support for food businesses?"
The assistant will use get_niche_info to search food-related niches.
"List all my products and add a new one called 'Chocolate Cake' at $15"
The assistant will use list_my_products and create_product (requires KARRITO_API_KEY).
"Show me all pending orders and confirm the first one"
The assistant will use list_my_orders with status filter and update_order_status.
"Create a 20% discount code VERANO20 that expires on December 31"
The assistant will use create_discount with the provided parameters.
"Show me pending reviews and approve the ones with 4+ stars"
The assistant will use list_reviews with status "pending" and moderate_review.
"How is my store performing? Show me the stats"
The assistant will use get_analytics to retrieve store metrics.
"How does Karrito compare to Shopify and TiendaNube?"
The assistant will read the karrito://competitors resource.
git clone https://github.com/curetcore/karrito-mcp
cd karrito-mcp
npm install
npm run devMIT
Create a new category in your Karrito store. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Category name | |
| position | No | Sort order (lower = first) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool requires an environment variable but does not disclose mutation effects, return format, idempotency, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with zero waste. Purpose and a key prerequisite are stated efficiently.
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 create tool with 2 params and no output schema, the description is adequate but could mention what is returned (e.g., created category ID) to improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both 'name' and 'position' having descriptions. The description adds no extra parameter meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and names the resource 'category in your Karrito store', clearly distinguishing from sibling tools like list_categories, update_category, delete_category.
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 a new category is needed but provides no explicit when-to-use vs alternatives. It does mention the prerequisite KARRITO_API_KEY environment variable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new discount code for your Karrito store. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Discount code (e.g., VERANO20) | |
| type | Yes | Discount type: percentage (e.g., 20%) or fixed amount (e.g., $5 off) | |
| value | Yes | Discount value (percentage 0-100 or fixed amount in store currency) | |
| maxUses | No | Maximum number of times this discount can be used | |
| expiresAt | No | Expiration date in ISO 8601 format (e.g., 2026-12-31T23:59:59Z) | |
| minOrderAmount | No | Minimum order amount required to use this discount |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description only mentions env var. Missing: idempotency, uniqueness of code, return value, side effects.
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, minimal waste, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description fails to explain return value or validation behavior. Incomplete for a creation tool with 6 params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with descriptions; description adds no extra param context. Baseline 3.
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?
Clear verb+resource: 'Create a new discount code'. Distinguishes from siblings (list, update, delete) by action.
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 explicit when-to-use vs alternatives; only a prerequisite (KARRITO_API_KEY). Agent relies on tool name for intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new product in your Karrito catalog. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Product name | |
| price | Yes | Product price in store currency | |
| imageUrl | No | Product image URL | |
| categoryId | No | Category ID to assign the product to | |
| description | No | Product description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must disclose behavioral traits. It states the tool creates a product (mutation) and requires an API key, but omits other important aspects such as error handling, idempotency, rate limits, or side effects like overwriting existing products.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences, front-loading the purpose and then stating a requirement. No wasted words, but it could benefit from more structured detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple creation tool, the description should still mention what happens upon success (e.g., returns the created product) or any error states. It is too brief to be fully contextual.
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?
Input schema has 100% description coverage for all 5 parameters, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (create) and the resource (product) within the catalog context, distinguishing it from sibling tools like update_product and delete_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions the required KARRITO_API_KEY environment variable, which is a prerequisite, but does not provide guidance on when to use this tool versus alternatives like update_product or list_my_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new shipping option for your Karrito store (e.g., delivery, pickup, express). Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Shipping option name (e.g., "Delivery", "Pickup in store", "Express") | |
| price | Yes | Shipping price in store currency (0 for free shipping) | |
| isActive | No | Whether this shipping option is active (default: true) | |
| description | No | Description of this shipping option | |
| estimatedDays | No | Estimated delivery time in days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that the tool 'creates' a shipping option and requires an API key. It does not disclose behavioral traits such as whether duplicate names are allowed, whether the creation is idempotent, or any side effects (e.g., impact on existing shipping options).
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 two sentences: the first concisely states the purpose with examples, and the second specifies a critical prerequisite. No superfluous words. Front-loaded with action and resource.
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 5 parameters and no output schema. The description does not mention what the return value looks like (e.g., the created shipping option ID), error handling, or idempotency. Given the complexity (multiple parameters), more context would be helpful, such as linking to list_shipping_options to verify after creation or note that duplicate names might cause errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a clear description. The tool description adds minimal value: it gives examples for the name parameter and mentions '0 for free shipping' for price, but these are already implied or stated in the schema. The description does not explain relationships between parameters or default behaviors beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new shipping option' and provides examples like delivery, pickup, express. It distinguishes from sibling tools update_shipping_option and delete_shipping_option by focusing on creation. However, it doesn't differentiate from other create tools like create_product, but since the resource is clearly 'shipping option', it is sufficiently specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite 'Requires KARRITO_API_KEY environment variable' but does not provide guidance on when to use this tool vs alternatives (e.g., when to create vs update, or any preconditions like checking if shipping options already exist). No explicit 'when-not-to-use' information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a category from your Karrito store. Products in this category will become uncategorized. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Category ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses that products become uncategorized after deletion, a key behavioral trait. Does not mention irreversibility, but the action is standard and side effect is noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence covers action and side effect, second states prerequisite. Highly concise and front-loads essential info.
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 1-parameter, no-output-schema tool with no annotations, the description is nearly complete. It explains the effect and a key prerequisite. Minor omission: could explicitly note that deletion is permanent.
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?
Only one parameter 'id' with schema description 'Category ID to delete'. Description adds no additional meaning beyond schema, but schema coverage is 100%, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete a category' and mentions side effect 'Products will become uncategorized'. Verb and resource are explicit, and it distinguishes from sibling tools like create_category or update_category.
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?
Description states a prerequisite (KARRITO_API_KEY) but provides no explicit guidance on when to use this tool versus alternatives like deactivating or moving categories. Usage context is implied but not directly addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a discount code from your Karrito store. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Discount ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates deletion (destructive) and a prerequisite, but lacks details on permanence, side effects, or error states such as whether an active discount can be deleted.
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 redundancy. It front-loads the action and resource, earning its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no output schema, the description is minimal. It omits behavioral context such as irreversibility, confirmation, or error handling, making it incomplete despite the simple action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (id) described as 'Discount ID to delete'. The description adds no extra meaning beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and resource (discount code) with store context. It is specific but does not explicitly differentiate from sibling delete tools like delete_product, though the resource is distinct.
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?
Only one guideline is provided: the requirement for the KARRITO_API_KEY environment variable. There is no guidance on when to use this tool versus other delete tools, nor any exclusions or alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a product from your Karrito catalog (soft delete). Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Product ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals the soft-delete behavior, which is important. However, it does not mention error handling, idempotency, or side effects beyond the environment variable requirement.
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 extremely concise with two sentences that front-load the action and provide the only essential additional detail (soft delete, env var). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter deletion tool with no output schema, the description covers the key behavioral trait (soft delete) and the prerequisite. It could mention return type or error conditions, but the low complexity makes the current description nearly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'id'. The description adds no extra meaning beyond the schema's 'Product ID to delete'. Baseline 3 is appropriate since the schema already documents the parameter.
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 'Delete' and the resource 'a product from your Karrito catalog', and specifies 'soft delete'. This distinguishes it from sibling tools like create_product, update_product, and other deletion tools for different resources.
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 only mentions a prerequisite (environment variable) but provides no guidance on when to use this tool versus alternatives like update_product or delete_category. There is no mention of when not to use it or what context is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a product review. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Review ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It states the action is permanent and requires an API key, which are useful but minimal. Lacks details on irreversible consequences, impact on related data, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with zero waste. Every word serves a purpose: verb, resource, permanence, and requirement.
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 simplicity (1 param, no output schema), the description covers the core action, permanence, and auth requirement. No explanation of return value is needed for a delete operation, but it could mention success confirmation or result.
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?
Single 'id' parameter with schema description 'Review ID to delete'. Description does not add meaning beyond the schema; coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it permanently deletes a product review. The verb 'delete' and resource 'review' are specific. Siblings include list_reviews and moderate_review, which handle non-destructive actions, so this tool is well-distinguished.
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 on when to use this tool versus alternatives like moderate_review. Does not mention that deletion is irreversible or provide any context for when deletion is appropriate. The only guideline is the environment variable requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a shipping option from your Karrito store. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Shipping option ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It only conveys 'delete' (destructive) but lacks details on reversibility, cascading effects, or permissions beyond the API key.
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: first states purpose, second states requirement. No fluff, efficient for the tool's simplicity.
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?
Adequately covers purpose and a prerequisite for a simple tool. Lacks mention of dependencies like existence checks or constraints on deletion.
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 covers 100% of parameters, so baseline is 3. Description adds no meaning beyond the schema's own description for the 'id' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), resource (shipping option), and context (from your Karrito store). It effectively distinguishes from siblings like create_shipping_option and update_shipping_option.
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 notes the required environment variable but does not specify when to use this tool vs alternatives (e.g., list_shipping_options) or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get store analytics: total orders, revenue, products, customers, average order value, and popular products. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the authentication requirement (env var) and the data returned, but does not mention read-only nature, rate limits, or data freshness. Adequate for a simple read tool but not rich.
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 concise sentences, no fluff. First sentence lists the specific analytics returned; second states the prerequisite. Front-loaded with the action and key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0 parameters, description is somewhat complete but lacks time scope (e.g., all-time vs. last 30 days) and response format. Could be improved with caveats about data aggregation.
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?
Input schema has 0 parameters, so description does not need to explain parameters. Baseline for 0 params is 4. The description adds the environment variable requirement, which is not parameter-related but adds context.
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 retrieves store analytics with specific metrics (total orders, revenue, etc.), using verb 'Get' and resource 'store analytics'. It distinguishes from siblings like list_my_orders (detailed orders) and get_my_store (settings), but does not explicitly contrast them.
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 on when to use this tool versus alternatives (e.g., for detailed order data use list_my_orders). The only guideline is a prerequisite (KARRITO_API_KEY), but no context on when to choose this over other analytics or reporting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific customer including their order history. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Customer ID to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It reveals the tool is read-only (retrieves info) and requires an API key, but omits details like rate limits, response structure, or any data freshness guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences convey the purpose and a key requirement. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval with one parameter and no output schema, the description includes the returned information (order history). Could be more specific about other customer fields, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter description ('Customer ID to retrieve'). The tool description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific customer including order history. It uses a specific verb ('Get') and resource ('customer') and distinguishes itself from siblings like list_customers and get_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions an environmental prerequisite (KARRITO_API_KEY) but provides no guidance on when to use this tool versus alternatives like list_customers for summaries or get_order for order details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about your Karrito store (name, slug, currency, stats). Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool requires an environment variable, which is a behavioral trait. However, it does not explicitly state that the tool is read-only, nor does it mention rate limits or other behavioral details.
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 of 18 words. It efficiently communicates the purpose and prerequisite without any waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially explains return values by listing fields. It could be improved by mentioning the return format (e.g., JSON object), but it is sufficient for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema description coverage is 100%. The description adds value by listing the returned fields (name, slug, currency, stats), which compensates for the lack of parameters.
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 'your Karrito store', listing specific fields (name, slug, currency, stats). This distinguishes it from sibling tools like update_store or toggle_publish.
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 a prerequisite (KARRITO_API_KEY environment variable) but does not explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about a specific Karrito niche by slug or name. Returns niche details from the 50 available niches. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | Yes | Niche slug (e.g., "reposteria") or partial name to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'No authentication required' and the data scope '50 available niches', but omits details about what 'niche details' includes, whether the operation is read-only, or potential error states. With no annotations, the description partially covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, minimal waste. Every sentence adds value.
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 tool with one parameter and no output schema, the description covers the essential purpose, input, and a key constraint. However, it could mention the return structure or notable limitations to be fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description for the 'niche' parameter. The tool description adds an example ('reposteria') and clarifies partial name search, but does not significantly surpass the schema's information. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get information' on a specific resource 'niche', specifies input method 'by slug or name', and notes a key constraint 'from the 50 available niches'. This is distinct from sibling tools like list_categories.
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 alternatives like list_categories or search_catalogs. The description only explains what the tool does, not when to prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific order including items, customer info, and status. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Order ID to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral disclosure. It indicates a read operation (get information) and notes a required environment variable. However, it does not explicitly state idempotency, safety, or potential error conditions, leaving some gaps.
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 two sentences with no extraneous words. The primary action (get detailed info) is front-loaded, followed by a required prerequisite. Every word contributes value.
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 simplicity (one parameter, no output schema), the description adequately covers what the tool does and a key prerequisite (API key). It does not detail return format or error handling, but for a basic retrieval tool this is sufficient.
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 only parameter 'id' is fully described in the schema (100% coverage). The description adds no new semantic detail beyond restating 'specific order'. With high schema coverage, 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 clearly states the tool retrieves detailed information about a specific order, listing included data (items, customer info, status). This distinguishes it from siblings like list_my_orders which returns a list, and update_order_status which modifies order state.
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 a single order ID is available and full details are needed, but does not explicitly state when to use this tool versus siblings. The mention of an API key requirement provides a usage condition but no guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List categories in your Karrito store. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max categories to return (1-100) | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the authentication requirement but lacks other behavioral details such as read-only nature or pagination behavior (though limit/offset are in schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one for purpose and one for a key requirement. No unnecessary words, front-loaded with the core action.
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 simplicity, no output schema, and well-documented parameters in the schema, the description is adequately complete. It could optionally mention return format but is not essential for a straightforward list 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 coverage is 100%, and the schema already provides descriptions for the parameters (limit and offset). The description adds no parameter information beyond what the schema offers, so 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 clearly states the verb 'list' and the resource 'categories', scoped to 'your Karrito store'. It is unambiguous and distinct from sibling tools that create, update, or delete categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the required KARRITO_API_KEY environment variable, a key usage prerequisite. It does not explicitly state when not to use the tool or compare to alternatives, but the purpose is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List customers who have placed orders in your Karrito store. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max customers to return (1-100) | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It states the action and a requirement, but omits important behavioral details such as whether the operation is read-only, any rate limits, pagination behavior, or response structure. The environment variable note adds some transparency, but overall insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the primary action. While it lacks depth, it wastes no words and is well-structured for immediate understanding.
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 absence of an output schema and annotations, the description should cover return format, pagination, and filtering behavior. It only states the purpose and an environment variable, leaving the agent to infer most runtime context from the parameter schema alone. With many sibling tools, no guidance on differentiation further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (limit, offset) fully described via their schema properties. The description adds no additional meaning beyond the schema, meeting the baseline expectation but providing no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'List' and identifies the resource as 'customers who have placed orders in your Karrito store', which clearly distinguishes it from sibling tools like list_shipping_options or get_customer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions a prerequisite (KARRITO_API_KEY) but provides no guidance on when to use this tool versus alternatives like get_customer, nor any scenario exclusions. The usage context is implied as basic listing, but not explicitly clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List discount codes in your Karrito store. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max discounts to return (1-100) | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only mentions the API key requirement, but omits details about read-only nature, return format, pagination behavior, or error handling. The tool is likely read-only, but this is not explicitly stated, and there is no disclosure of side effects or limitations.
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 extremely concise, consisting of two sentences: one for purpose and one for the prerequisite. Every sentence is necessary and directly useful, with no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with 2 parameters and no output schema, the description covers the basic purpose and a key prerequisite. However, it lacks context on return structure (e.g., array of discount objects), pagination behavior, and error conditions. Given the absence of annotations and output schema, additional completeness would be beneficial.
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 fully describes both parameters (limit, offset) with descriptions, achieving 100% schema coverage. The description adds no additional meaning beyond the schema, so 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 clearly states the tool lists discount codes in the Karrito store. The verb 'list' and resource 'discount codes' are specific, and it distinguishes from mutation siblings like create_discount and delete_discount. However, it does not differentiate from other list tools such as list_my_products or list_categories, keeping the score from being a 5.
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 only usage guideline is the requirement of the KARRITO_API_KEY environment variable. There is no guidance on when to use this tool versus alternatives like search_catalogs or list_my_products, and no mention of when not to use it. The absence of contextual usage advice limits the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List orders from your Karrito store. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max orders to return (1-100) | |
| offset | No | Pagination offset | |
| status | No | Filter by order status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'List orders', indicating a read operation, but fails to disclose any other behavioral traits such as pagination behavior beyond schema, rate limits, or whether results are sorted. The description does not explain what happens if the API key is missing.
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 consists of two sentences, both front-loaded and concise. Every word serves a purpose, with no redundancy or irrelevant detail.
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 3 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return value structure, error handling, or default ordering. A list tool typically needs to describe the format of returned orders (e.g., fields included, sort order).
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 baseline is 3. The tool description adds no additional meaning beyond the schema for the parameters. It does not elaborate on how 'limit', 'offset', or 'status' affect the return data beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'orders' with scope 'from your Karrito store'. It effectively distinguishes from siblings like 'get_order' (single order) and 'update_order_status' (mutation).
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 a prerequisite (KARRITO_API_KEY environment variable) which provides context, but it does not specify when to use this tool over alternatives like 'list_my_products' or 'list_customers'. No explicit when-not-to-use or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List products in your Karrito catalog. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max products to return (1-100) | |
| offset | No | Pagination offset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only mentions the purpose and a prerequisite. It does not state that the operation is read-only, whether it paginates, or any potential side effects. This is insufficient for a tool with no annotation support.
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 extremely concise—two sentences with no wasted words. It front-loads the core purpose and adds one essential prerequisite. Every sentence 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?
Given the tool's simplicity (2 parameters, no output schema), the description is largely adequate. It covers the purpose and a key requirement. However, it could briefly mention that the operation is read-only and that pagination is supported via the parameters, which are already in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with limit and offset already documented. The description adds no further parameter semantics beyond the schema, so 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 clearly states the verb 'List' and the resource 'products in your Karrito catalog', making the purpose unambiguous. It naturally distinguishes from sibling tools like list_shipping_options or list_categories that operate on different resources.
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 only mentions a required environment variable but provides no guidance on when to use this tool over alternatives like search_catalogs. No when-to-use or when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List product reviews in your Karrito store. Can filter by moderation status. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max reviews to return (1-100) | |
| offset | No | Pagination offset | |
| status | No | Filter by moderation status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It states a read-only operation ('List') but does not disclose any behavioral traits such as rate limits, idempotency, or potential side effects. The description adds minimal transparency beyond the obvious.
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 consists of two concise sentences, front-loading the purpose and adding a key requirement. Every sentence earns its place with no wasted verbiage.
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 complexity (3 optional parameters, no output schema), the description covers the core use case and a prerequisite. However, it omits pagination details (limit/offset behavior) and what the response format looks like, leaving some gaps for an agent.
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 all parameters. The description adds the fact that filtering by 'status' is possible, which aligns with the schema. However, it does not add new meaning beyond what the schema already provides for 'limit' and 'offset'. Baseline 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 clearly states the verb 'List' and the resource 'product reviews in your Karrito store', distinguishing it from sibling tools like 'list_my_products' and 'list_my_orders'. It also mentions filtering by moderation status, adding specificity.
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 includes a prerequisite (KARRITO_API_KEY) but provides no guidance on when to use this tool versus alternatives like 'moderate_review' or 'delete_review'. Usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List shipping options configured for your Karrito store. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behaviors. It only mentions the required environment variable but not side effects, rate limits, or return structure. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence plus a requirement line. No redundant information. Well front-loaded with the action and resource.
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 operation with no parameters and no output schema, the description is adequate but could benefit from describing the return format or any default filtering. It tells what it does and the requirement, but lacks richer context.
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?
Input schema has zero parameters, so description adds value by specifying the required environment variable, which is not a parameter in the schema. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'list' and resource 'shipping options' for the Karrito store. It distinguishes from sibling tools that create, update, or delete individual shipping options.
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 explicit guidance on when to use this tool versus alternative listing tools like search_catalogs or list_my_products. The description does not mention use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Approve or reject a product review. Approved reviews are visible on the public catalog. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Review ID to moderate | |
| status | Yes | Moderation decision: approved (visible) or rejected (hidden) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the requirement for an environment variable and the visibility change upon approval/rejection. However, it does not specify if the action is reversible, what happens to rejected reviews (e.g., hidden permanently), or any error conditions.
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 two sentences, direct and without unnecessary words. It immediately conveys the action, consequence, and a prerequisite, which is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema. The description explains the primary effect (visibility) but does not describe the return value or any side effects (e.g., if a rejected review is still stored). For a moderate action, indicating whether the operation is synchronous or what response to expect would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's explicit definition of the 'status' enum and the 'id' field. It reiterates the same mapping (approved=visible, rejected=hidden) already present in the schema property 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 clearly states the verb 'Approve or reject' and the resource 'product review', and it distinguishes from sibling tools like list_reviews (listing) and delete_review (deletion). It also explains the consequence of approval on visibility.
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 a prerequisite ('Requires KARRITO_API_KEY environment variable') but does not explicitly instruct when to use this tool versus alternatives (e.g., delete_review). However, the action is clear and the sibling list provides implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public Karrito catalogs by keyword. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query — store name, product, or niche |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It mentions 'no authentication required', which is helpful. However, does not explicitly state it is read-only or describe rate limits. Given simplicity, adequate but could be more 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?
Two sentences with no redundant information. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description omits the output format. The agent does not know what the search returns (e.g., list of catalog names, IDs, details). Given no output schema, this information would be valuable for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description's mention of 'by keyword' and the schema description of 'store name, product, or niche' overlap. The description adds no new parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'search', resource 'public Karrito catalogs', and method 'by keyword'. Distinguishes from sibling tools which are for listing, creating, or managing specific entities.
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?
Does not provide explicit when-to-use or when-not-to-use guidance. No mention of alternatives or context for choosing this over other search-like tools (e.g., get_niche_info).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quickly publish or unpublish your Karrito store. Shortcut for update_store with isPublished. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| published | Yes | true to publish the store, false to unpublish |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It indicates the tool mutates store state (publish/unpublish). However, it doesn't disclose side effects, reversibility, or what happens to the store upon publish (e.g., visibility changes). Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The most critical information (purpose, shortcut relation, prerequisite) is front-loaded. Every sentence adds value.
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 1-param tool with no output schema, the description covers the essential purpose, relationship to sibling update_store, and a prerequisite. It could mention expected outcomes or response, but it's sufficient for a quick toggle.
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 covers 100% of parameters with good descriptions. The description adds no new information about the 'published' parameter beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: 'publish or unpublish your Karrito store'. It also distinguishes itself as a shortcut for update_store with isPublished, making the purpose 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?
Explicitly says 'Quickly publish or unpublish' and 'Shortcut for update_store with isPublished', implying use when you only need to toggle publish state. It also mentions the required environment variable. However, it doesn't explicitly state when not to use (e.g., for comprehensive store updates).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing category in your Karrito store. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Category ID to update | |
| name | No | New category name | |
| isActive | No | Whether the category is active | |
| position | No | New sort order (lower = first) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the write operation but omits side effects, error behavior (e.g., if category not found), idempotency, or response format. Inadequate 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?
Two sentences efficiently convey purpose and a key prerequisite with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 4 parameters and no output schema, the description does not explain success/failure behavior, return value, or error handling. Missing critical context for an update 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 coverage is 100% with descriptions for all 4 parameters. The tool description adds no extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Update an existing category in your Karrito store', specifying verb and resource. It distinguishes from sibling tools like create_category and delete_category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions required KARRITO_API_KEY environment variable, providing a prerequisite. However, it lacks explicit guidance on when to use this tool over alternatives (e.g., when modifications are needed vs creation or deletion).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing discount code in your Karrito store. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Discount ID to update | |
| code | No | New discount code | |
| type | No | New discount type | |
| value | No | New discount value | |
| maxUses | No | New maximum uses | |
| expiresAt | No | New expiration date in ISO 8601 format | |
| minOrderAmount | No | New minimum order amount |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'Update' and a requirement, but does not explain whether partial updates are supported, success/failure outcomes, or any side effects beyond mutation.
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 unnecessary words. The purpose and a key requirement are front-loaded, making it efficient for an agent to quickly understand the essentials.
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 7 parameters and no output schema, the description is too minimal. It lacks context on update semantics (e.g., partial updates), expected return values, and error handling, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. It adds no additional semantic value beyond what the input schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing discount code' with a specific verb and resource. Among sibling tools (create_discount, delete_discount, list_discounts), it uniquely identifies the update operation.
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 only mentions a prerequisite (KARRITO_API_KEY) but provides no guidance on when to use this tool versus alternatives like create_discount or delete_discount, nor any context on when updates are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the status of an order (e.g., confirm, ship, deliver, or cancel). Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Order ID to update | |
| status | Yes | New order status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the API key requirement but does not detail side effects, idempotency, or return behavior. The status update process is not explained beyond the action.
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 plus a requirement note, both essential. It is efficiently structured with the core action first.
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 two-parameter mutation, the description covers the API key requirement but omits information about return value, error conditions, and prerequisites. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters with descriptions and enum values. The description adds example statuses, which partially overlaps with the schema. Since schema coverage is 100%, the description provides minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool updates order status and lists example statuses (confirm, ship, deliver, cancel), clearly distinguishing it from other order-related tools like get_order or list_my_orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the required environment variable but does not provide guidance on when to use this tool versus alternatives (e.g., using create_product for new orders). Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing product in your Karrito catalog. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Product ID to update | |
| name | No | New product name | |
| price | No | New price in store currency | |
| isActive | No | Whether the product is active | |
| categoryId | No | New category ID | |
| description | No | New product description | |
| comparePrice | No | Compare-at price (must be > price) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only mentions the API key requirement but does no disclose what happens on success, idempotency, partial update behavior, or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences without fluff. It efficiently states purpose and a key requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 7 parameters, the description should provide more context about return values, side effects, and usage notes. Currently it is too minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what is in the schema, resulting in baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update), the resource (product), and the context (Karrito catalog). It distinguishes from siblings like create_product and delete_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only mentions an environment variable requirement. No guidance on when to use this tool vs alternatives like create_product or update_order_status, nor any prerequisites besides the API key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing shipping option in your Karrito store. Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Shipping option ID to update | |
| name | No | New shipping option name | |
| price | No | New shipping price | |
| isActive | No | Whether this shipping option is active | |
| description | No | New description | |
| estimatedDays | No | New estimated delivery time in days |
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 not specify whether updates are partial or full, what happens to omitted fields, or any error conditions. The requirement for an API key is mentioned, but authorization details beyond that are missing.
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 useful sentence with a second short sentence about the API key. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no output schema, and no annotations, the description lacks details on return values, error handling, and update semantics (e.g., partial vs full update). It is insufficient for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it only repeats the concept of updating and adds the API key requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it updates an existing shipping option in a specific store (Karrito), distinguishing it from sibling tools like create_shipping_option and delete_shipping_option.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions the required KARRITO_API_KEY environment variable, which is a necessary precondition, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., create_shipping_option for creation, list_shipping_options for reading).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update your Karrito store settings (name, WhatsApp number, currency, description, etc.). Requires KARRITO_API_KEY environment variable.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Store name | |
| currency | No | Store currency | |
| description | No | Store description | |
| isPublished | No | Whether the store is publicly visible | |
| isMaintenance | No | Whether the store is in maintenance mode | |
| whatsappNumber | No | WhatsApp number in E.164 format (e.g., +18091234567) | |
| whatsappTemplate | No | WhatsApp message template with shortcodes: {tienda}, {productos}, {total}, {nombre} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavioral traits. It only states 'Update ... settings' implying mutation, but omits side effects (e.g., whether changes are immediate), error conditions, or any other behavioral context beyond the env var requirement.
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 extremely concise at two sentences, front-loading the purpose and adding a key prerequisite in the second sentence. Every word serves a purpose with no 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 7 optional parameters and no output schema, the description is too minimal. It does not explain what the tool returns or any success/failure behavior. Given the complexity, additional context about the update process or result is needed.
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 each parameter is documented in the schema. The description adds no additional meaning beyond listing a subset of parameters in parentheses. The baseline of 3 is appropriate as no extra semantic value is 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 clearly states 'Update your Karrito store settings' with explicit verb 'update' and resource 'store settings'. It lists example fields (name, WhatsApp number, currency, description, etc.), distinguishing it from sibling tools that operate on products, orders, categories, etc.
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 a prerequisite ('Requires KARRITO_API_KEY environment variable') but does not provide guidance on when to use this tool versus alternatives like toggle_publish or other update tools. No exclusions or conditional usage advice is given.
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. Dates show when Glama detected each change.
v2.0.3create_categorycreate_discountcreate_productcreate_shipping_optiondelete_categorydelete_discountdelete_productdelete_reviewdelete_shipping_optionget_analyticsget_customerget_my_storeget_niche_infoget_orderlist_categorieslist_customerslist_discountslist_my_orderslist_my_productslist_reviewslist_shipping_optionsmoderate_reviewsearch_catalogstoggle_publishupdate_categoryupdate_discountupdate_order_statusupdate_productupdate_shipping_optionupdate_storeEach tool targets a distinct resource and action (e.g., products, orders, categories, discounts, reviews, customers, shipping options, store settings, analytics, catalogs, niches). There is no overlap; even similar-sounding tools like list_shipping_options and create_shipping_option have clearly different purposes.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., list_shipping_options, create_product, update_order_status). The naming is predictable and makes it easy for an agent to infer functionality from the name alone.
With 30 tools, the server covers a broad e-commerce domain including products, orders, categories, discounts, reviews, customers, analytics, and shipping. While slightly above the typical sweet spot, each tool serves a clear purpose and the count is justified by the scope.
The tool surface provides comprehensive CRUD and lifecycle management for most resources (products, categories, discounts, shipping options, orders, reviews, customers). Minor gaps exist (no create_order or create_review), but these actions are likely customer-facing and not expected from a store management API. Overall, the set covers the essential administrative operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Unified MCP server for 70+ eCommerce platforms: products, orders, customers, and more.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Brand audits, visual catalogs, AI proposals & checkout for LATAM SMBs. Full funnel via MCP.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/curetcore/karrito-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
