The ReplenishRadar server allows AI agents to access, manage, and act upon inventory, sales, and purchase order data. Key capabilities include:
Inventory & Stock Management
Get stockout risk levels for SKUs, stock-by-location, SKU health summaries, lost sales estimates, and total inventory value breakdowns
List and search inventory items, filtering by vendor or review status
Sales & Demand Analytics
Retrieve demand forecast stats and sales history for SKUs
Identify top-selling and slow-moving SKUs
Purchase Order (PO) Management
List, search, and view POs (including line items, PDFs, and attached documents)
Create and update draft POs, add notes, request human approval, send to suppliers, and cancel POs
Get document upload URLs and record proforma invoice details
Alerts & Replenishment
Retrieve and acknowledge active alerts (filterable by SKU, severity, type, or store)
Get suggested purchase orders and replenishment actions; dismiss, prepare, or execute them (draft or autonomous mode)
Resolve or retry replenishment actions
Suppliers & Sync
List suppliers/vendors and trigger inventory syncs (Shopify or Amazon)
View sync run history, data freshness, store health, setup status, and recent activity
Knowledge & Fit Evaluation
Search the ReplenishRadar knowledge base
Run deterministic ICP and tier fit assessments without org data
Agent Context Store
Get, set, list, and delete bounded key-value memory entries scoped to namespaces (with TTL and size limits)
Permission Tiers
Standard and up: Acknowledge alerts, add notes, request approvals, manage replenishment actions, get upload URLs
Growth and up: Trigger syncs, create/update/send/cancel POs, create manual inventory locations, set stock at manual locations
Provides AI agents with access to live Amazon inventory intelligence, including stockout risk analysis, demand forecasting, and the ability to draft and manage purchase orders.
Provides AI agents with access to live Shopify inventory intelligence, including stockout risk analysis, demand forecasting, and the ability to draft and manage purchase orders.
Connect AI agents to live ReplenishRadar inventory data. Works with Claude Desktop, OpenClaw, and any MCP-compatible client.
Get your API key from ReplenishRadar > Settings > API Keys.
Add this server to your MCP client config. In Claude Desktop, open Settings > Developer > Edit Config:
{
"mcpServers": {
"replenishradar": {
"command": "npx",
"args": ["-y", "@replenishradar/mcp-server"],
"env": {
"REPLENISHRADAR_API_KEY": "rr_sk_your_key_here"
}
}
}
}Restart Claude Desktop and ask: "What are my top stockout risks?"
No ReplenishRadar account yet? Use the public agent intake endpoint to request a short-lived, read-only sandbox key before configuring the server:
POST https://api.replenishradar.com/api/public/agent-intakeRelated MCP server: cob-shopify-mcp
Standard includes limited read API access. Growth adds diagnosis/status read tools.
Tool | Description |
| Stockout risk levels for SKUs |
| Stock-by-location for an item |
| Demand forecast stats |
| Suggested POs |
| Canonical buyer replenishment actions |
| One replenishment action with event history |
| Active alerts |
| List inventory items |
| Recent sync history |
| List vendors/suppliers |
| List purchase orders |
| Single PO with line items |
| PO PDF info |
| Documents attached to a PO |
| Notes attached to a PO |
| Sales history |
| Top-selling SKUs |
| Slow-moving SKUs |
| Inventory value breakdown |
| SKU-level health summary |
| Estimated lost sales from stockouts |
| Store connection and sync health |
| Freshness status by data dimension |
| Setup milestones and next step |
| Recent alerts, POs, and sync rollup |
| ReplenishRadar product knowledge search |
| Deterministic ICP + tier fit verdict (no org data) |
Safe, low-blast-radius writes - no money or stock mutation.
Tool | Description |
| Acknowledge an alert |
| Add a note to a PO |
| Request human approval for a PO |
| Add a note to a replenishment action |
| Dismiss a replenishment action |
| Preview an action and get its current |
| Execute an action. |
| Resolve an action as no-action with a reason; idempotent, stale-state protected |
| Retry a blocked or failed action via the draft execution path; idempotent, stale-state protected |
| Get upload URL for a PO document |
| Record proforma invoice details |
Money / stock mutation.
Tool | Description |
| Trigger inventory sync |
| Create a draft PO |
| Update a draft PO |
| Send an approved PO |
| Cancel a PO |
| Create a manual inventory location |
| Set stock at a manual location |
PO creation always starts as a draft. rr_send_purchase_order only sends a PO that was already human-approved.
Action execution has two modes. rr_execute_replenishment_action with mode="draft" (the default) creates a draft PO and/or draft transfer for an action's items and never auto-sends to a supplier or commits stock. With mode="autonomous" it additionally sends the PO or commits the transfer, but only when the key has sensitive_write + the operation's tool group + an enabled per-key budget (autonomous_enabled=true) and every guardrail passes; otherwise it leaves a draft and returns an rr_request_approval hint (draft_fallback) or refuses without mutating (hard_refuse). Call rr_prepare_replenishment_action first to get the action's current updated_at, then pass it as expected_updated_at so a stale action is rejected before any write. Pass a stable idempotency_key so a retried call replays the original result instead of double-creating artifacts or double-sending.
A small, org-scoped, auditable key/value memory so an agent can remember bounded workflow state. rr_get_agent_context / rr_list_agent_context are read-capability; rr_set_agent_context / rr_delete_agent_context are basic-write. All four are in the agent_context tool group.
Tool | Description |
| Get one entry by |
| Store a bounded JSON object under |
| List live entries for ONE |
| Delete one entry by |
Rules and limits:
Namespaces are code-owned and per-key allowlisted. A human admin must grant your API key read/write/delete on each namespace in Settings > API Keys. Same-organization access alone is not sufficient.
No secrets, no raw PII. Writes that look like tokens, passwords, private keys, credentials, or raw emails/phones/addresses are rejected.
value must be a JSON object (not a scalar or array), capped at 16 KiB serialized.
ttl_seconds is optional and capped at 90 days; with no TTL the entry persists while the organization exists.
rr_list_agent_context requires namespace and never lists across namespaces.
scope_ref is descriptive metadata only and is not part of uniqueness - encode per-scope entries into the key (for example supplier_rules/sku:ABC123).
Sensitive namespaces (for example sourcing_economics) additionally require the key to hold the sensitive economics read capability + tool group.
Per-API-key spend budgets - per-PO value cap, rolling-24h daily cap, max transfer quantity delta, an autonomous_enabled flag, and vendor / destination / transfer-source (or route-pair) allowlists - constrain what an autonomous key may buy or move. They are managed only by a human admin in Settings > API Keys (a JWT-admin Settings API); there is no MCP tool to read or change a budget, and an API key cannot reach the budget routes, not even for its own caps. Budgets are consumed only by autonomous send/commit, autonomous mode is off by default, and a denied autonomous action receives only a short decision reason - never the cap amounts, the allowlists, or another key's ledger.
Standard ($99/mo): 10 calls/hour, read + basic-write tools
Growth ($199/mo): 100 calls/hour, read + basic + sensitive read/write + diagnosis/status tools
Scale ($499/mo): 1,000 calls/hour, full read + write capability set
Create a manual inventory location such as warehouse, 3PL, or inbound location.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City | |
| name | Yes | Location name | |
| type | Yes | Location type | |
| state | No | State or province | |
| country | No | Country | |
| is_default | No | Whether this should be the default manual location | |
| postal_code | No | Postal code | |
| address_line1 | No | Street address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'Create a manual inventory location' but gives no details on permissions, side effects, idempotency, or rate limits. This is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with core purpose ('Create a manual inventory location'), no unnecessary words, and appropriately sized.
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?
Adequate for a simple creation tool with well-documented schema parameters, but lacks information about return values (no output schema) and any behavioral constraints. Could be improved with a note on what the response contains.
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 descriptions cover 100% of parameters, so baseline is 3. The tool description adds no additional meaning beyond the schema's own field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (create) and resource (manual inventory location), provides examples of location types (warehouse, 3PL, inbound), and is distinct from sibling tools, none of which create locations.
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, no prerequisites, exclusions, or context about when creation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete one agent context entry by namespace and key. Records actor provenance. The namespace must be granted to this key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Entry key within the namespace | |
| namespace | Yes | Allowlisted context namespace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool deletes data (destructive) and records actor provenance. However, it lacks details on error handling, idempotency, or behavior when the entry does not exist. Without annotations, more transparency about side effects and constraints is expected.
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 at two sentences, with no extraneous information. It front-loads the purpose and adds key constraints 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 tool with two parameters and no output schema, the description covers purpose and a key constraint but omits return values, error conditions, or confirmation of success. It is adequate for a minimal viable description but could be more 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 100% coverage, so the baseline is 3. The description adds the constraint that the namespace must be granted to the key, which provides limited additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes one agent context entry by namespace and key, distinguishing it from siblings like get, set, and list. It specifies the verb 'delete' and the resource 'agent context entry', fulfilling a specific verb+resource pattern.
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 provides a prerequisite ('namespace must be granted to this key') but does not offer guidance on when to use this tool versus alternatives (e.g., rr_set_agent_context or rr_list_agent_context). No explicit when-to-use or when-not-to-use instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a replenishment action in draft mode: creates a draft purchase order and/or draft transfer order for the action's items. Idempotent by idempotency_key; rejects with conflict if the action changed since prepare (stale expected_updated_at) or if the same key is reused with a different payload or actor. Never auto-sends to suppliers and never commits stock.
| Name | Required | Description | Default |
|---|---|---|---|
| action_id | Yes | Replenishment action UUID | |
| idempotency_key | Yes | Caller-chosen idempotency key; replay with the same key + payload returns the original result | |
| expected_updated_at | Yes | The action updated_at from rr_prepare_replenishment_action; execute fails if it no longer matches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses idempotency via idempotency_key, rejection on stale expected_updated_at, and that it never auto-sends or commits stock. With no annotations, this covers essential behavioral traits comprehensively.
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 main action, then details. No 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?
Covers behavior well but lacks description of return values (e.g., what the created draft orders look like). Given no output schema, some guidance on the response 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?
Adds meaning beyond schema: explains why 'expected_updated_at' is needed (from prepare) and how idempotency_key ensures replay. Schema coverage is 100%, but description enriches understanding of causality and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool executes a replenishment action to create draft purchase/transfer orders. The verb 'execute' and resource 'replenishment action' are specific. It distinguishes from siblings like 'rr_prepare_replenishment_action' by focusing on execution in draft mode.
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 states 'Never auto-sends to suppliers and never commits stock', indicating this tool is for draft-only execution. It implies usage after 'rr_prepare_replenishment_action' via the 'expected_updated_at' parameter. Could be more explicit about when not to use (e.g., when final approval is needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one agent context entry by namespace and key. Expired entries are omitted. The namespace must be granted to this API key by a human admin.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Entry key within the namespace (max 200 chars) | |
| namespace | Yes | Allowlisted context namespace (for example supplier_rules) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses expiry omission and authorization needs, but does not mention behavior for missing keys or return format. Adequate but not exhaustive.
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 redundancy, front-loaded with the primary purpose. 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 get tool with two parameters and no output schema, the description covers purpose, expiry, and authorization. Missing details on error handling or return structure, but still 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%, so baseline is 3. The description adds context about namespace permissions, but does not elaborate on key constraints 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 the verb 'Get' and the resource 'agent context entry', and specifies the identifying fields (namespace and key). It distinguishes from sibling tools like rr_list_agent_context which retrieves multiple entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: expired entries are omitted, and the namespace must be admin-granted. However, it does not explicitly state when to use this tool over siblings like rr_list_agent_context for batch retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get demand forecast statistics (mu/sigma) for a SKU or item. Returns active forecast windows.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | No | Canonical SKU | |
| item_id | No | Item UUID | |
| store_id | No | Filter by store ID | |
| window_days | No | Filter by forecast window (e.g., 7, 14, 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool returns 'active forecast windows' but does not disclose whether it is read-only, the data freshness, or any side effects. Behavioral traits like permissions or performance are not addressed.
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 clear sentences. It is front-loaded with the core purpose and avoids any unnecessary words or repetition.
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 moderate complexity (4 optional parameters, no output schema), the description does not explain what 'active forecast windows' means in terms of structure, how parameters combine (e.g., exclusivity of sku vs item_id), or if results are paginated. The description feels incomplete for effective use.
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 all four parameters have descriptions in the schema. The tool description adds no additional meaning beyond what the schema provides (e.g., 'Filter by store ID' is already in schema). The description mentions 'active forecast windows' but does not clarify parameter interactions.
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 demand forecast statistics (mu/sigma) for a SKU or item and returns active forecast windows. It uses a specific verb ('Get') and resource ('demand forecast'), and distinguishes itself from sibling tools like rr_create_location or rr_delete_agent_context by focusing on forecast retrieval.
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. There is no mention of preconditions (e.g., at least one identifier required) or exclusions. The description lacks context for optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a document record for a purchase order (invoice, packing slip, etc.). Requires Scale tier.
| Name | Required | Description | Default |
|---|---|---|---|
| po_id | Yes | Purchase order UUID | |
| filename | Yes | Document filename | |
| description | No | Document description | |
| document_type | No | Document type (default: attachment) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Requires Scale tier' (a behavioral constraint) but does not disclose other behaviors: e.g., does it automatically upload? Can it overwrite? What triggers an error? The description falls short of adequately describing tool 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 concise sentences, but the first sentence is misleading due to verb mismatch with the tool name. Conciseness is present but at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so the description should explain return values. It does not mention what the tool returns (presumably a URL). With no annotations and no output description, the tool is incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters adequately. The description adds no additional meaning beyond noting it relates to purchase orders. Baseline 3 is appropriate since schema does the work.
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 says 'Create a document record' but the tool name is 'get_document_upload_url'. This mismatch creates confusion about whether the tool creates a record or returns a URL. The purpose is somewhat clear (creates a record for a purchase order), but the inconsistency with the name lowers clarity.
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. The sibling tools list includes various actions but no similar document upload tools, so no explicit or implicit differentiation. The 'Requires Scale tier' note is a prerequisite but not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single purchase order with full details including line items and vendor info.
| Name | Required | Description | Default |
|---|---|---|---|
| po_id | Yes | Purchase order UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It mentions returning line items and vendor info but does not state whether the operation is read-only, requires authentication, or has side effects. The read nature is implied but not explicit, leaving gaps for a mutation-unaware agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the verb and resource, and contains no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description adequately conveys the tool's purpose and expected returns. Some details (e.g., whether all fields are returned, error handling) are absent, but not critical for a simple get 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 one parameter (po_id) already described as 'Purchase order UUID'. The description repeats this without adding new semantic meaning beyond what the schema provides. Hence baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'purchase order', specifying scope as 'single' and content as 'full details including line items and vendor info'. This effectively distinguishes it from siblings like rr_list_purchase_orders and rr_list_suppliers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single purchase order but does not explicitly state when to use this tool over alternatives (e.g., rr_list_purchase_orders for multiple, or other get tools for different resources). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List live agent context entries for a single namespace. The namespace is required and the limit is bounded (max 200). This tool never lists across namespaces.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 50, max 200) | |
| namespace | Yes | Allowlisted context namespace (required) | |
| key_prefix | No | Optional key prefix filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description mentions 'live' entries and 'never lists across namespaces', but omits details on pagination, ordering, or return format.
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, zero wasted words, front-loaded with key action and scope.
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?
Adequate for a simple list tool with no output schema; covers constraints and scope, though could hint at return type.
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 description repeats schema info (namespace required, limit bounded) without adding new meaning beyond structured fields.
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 'List live agent context entries for a single namespace' with specific verb and resource, and distinguishes from siblings by noting it does not list across namespaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit constraints (namespace required, max limit 200) and clarifies scope (single namespace only), but lacks explicit when-to-use/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List purchase orders with filtering by status, vendor, and search. Supports pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 50, max 200) | |
| offset | No | Pagination offset | |
| search | No | Search by PO number | |
| status | No | Filter by status (comma-separated: draft,sent,approved,received,cancelled) | |
| vendor_id | No | Filter by vendor ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses filtering and pagination but does not mention behavioral traits like read-only nature, rate limits, error handling, or the fact that it returns a list. The description is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 12 words, front-loading the core purpose. Every word earns its place with no filler or repetition.
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 5 optional parameters, no output schema, and no annotations, the description is too sparse. It does not explain return format, default behavior (e.g., default limit, unfiltered list), or sorting. This leaves gaps for an agent invoking 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 schema already documents all parameters. The description adds no new semantic detail beyond summarizing the filtering options. Baseline 3 is appropriate; it adds marginal 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 clearly states the tool lists purchase orders and supports filtering by status, vendor, and search, as well as pagination. This is a specific verb+resource combination that distinguishes it from sibling tools like rr_get_purchase_order (single order) and other resource-specific tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing with filters but does not explicitly state when to use vs. alternatives (e.g., when to use rr_get_purchase_order). No when-not or exclusions are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all suppliers/vendors for the organization. Optionally include vendor SKU mappings.
| Name | Required | Description | Default |
|---|---|---|---|
| include_skus | No | Include vendor SKU mappings (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as authentication requirements, rate limits, or side effects. The 'list' verb implies read-only behavior, but this is implicit rather than explicit.
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 redundant words. It is front-loaded and 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?
Given the tool's simplicity (one optional boolean parameter, no output schema), the description adequately states the core function and optional parameter. However, it does not describe the output format, which could be expected, but for a list tool, the result is likely a list of suppliers.
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%; the parameter 'include_skus' is already documented in the schema. The description's mention of 'Optionally include vendor SKU mappings' adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'suppliers/vendors', making the purpose unambiguous. It effectively distinguishes from sibling tools, none of which are supplier-listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'for the organization' which implies scope but lacks explicit guidance on when to use this tool vs alternatives or when not to use it. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview a replenishment action and return its current updated_at before executing. Use the returned updated_at as expected_updated_at on execute/resolve/retry.
| Name | Required | Description | Default |
|---|---|---|---|
| action_id | Yes | Replenishment action UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description indicates read-only preview behavior but does not explicitly state it is non-destructive. Adequate but could be more explicit.
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 waste. First sentence covers purpose and output, second sentence guides usage.
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 exists, but description fully explains return value and how to use it, plus relationship to siblings.
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 the single param. Description adds context on output usage but no new param info beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool preivews a replenishment action and returns its updated_at, distinguishing it from sibling tools like execute, resolve, and retry.
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 to use before executing and how to use the output (as expected_updated_at). No when-not-to-use stated, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record proforma invoice details on a purchase order (PI number, date, total, terms).
| Name | Required | Description | Default |
|---|---|---|---|
| po_id | Yes | Purchase order UUID | |
| pi_date | No | PI date (ISO 8601) | |
| pi_terms | No | Payment terms | |
| pi_total | No | PI total amount | |
| pi_number | No | Proforma invoice number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must bear the full burden. It indicates mutation ('Record') but does not disclose idempotency, side effects (e.g., overwriting existing PI details), required permissions, or return behavior. For a write tool, this is 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 a single, well-structured sentence that front-loads the verb and resource. No unnecessary words; every word earns its place. It is as concise as possible while remaining clear.
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 5 parameters and no output schema, the description is minimal. It does not explain when or why to call this tool, what the response indicates (e.g., confirmation, error), or how it fits into the larger workflow. More detail is needed for an AI to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description lists the fields that correspond to parameters but adds no additional meaning beyond the schema descriptions. It reinforces the context but does not deepen understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Record') and resource ('proforma invoice details on a purchase order'), and lists the key fields (PI number, date, total, terms). It distinguishes itself from sibling tools like 'rr_get_purchase_order' which are read-related.
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. It does not mention prerequisites (e.g., the purchase order must exist) or when not to use it (e.g., if the PI already exists). The 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.
Resolve a replenishment action as no-action with a reason. Idempotent; requires idempotency_key and expected_updated_at and applies the same stale-state conflict contract as execute.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | Reason the action needs no procurement/transfer | |
| action_id | Yes | Replenishment action UUID | |
| idempotency_key | Yes | Caller-chosen idempotency key | |
| expected_updated_at | Yes | The action updated_at the resolution was decided against |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses idempotency, the requirement for idempotency_key and expected_updated_at, and a stale-state conflict contract. This is sufficient behavioral context for a mutation-like tool, though it omits authorization needs and return value 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 concise with two sentences, front-loading the key purpose and behavioral traits. No unnecessary information is present.
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 4 required parameters and no output schema, the description covers the essential behavioral aspects (idempotency, conflict contract) and the action's outcome. However, it assumes knowledge of the 'execute' tool's contract and does not describe return values or what 'no-action' entails fully.
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 baseline is 3. The description adds minimal value beyond the schema (e.g., 'as no-action with a reason' clarifies the reason parameter's purpose). It does not provide syntax or format details for 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 'Resolve' and the resource 'replenishment action' with a specific outcome ('as no-action with a reason'). This differentiates it from sibling tools like rr_execute_replenishment_action and rr_retry_replenishment_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?
The description implies the tool is used for resolving actions as no-action and mentions the idempotent and conflict contract, but does not explicitly state when to use it versus alternatives or when not to use it. Usage context is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retry a blocked or failed replenishment action by re-running the draft execution path. Idempotent; requires idempotency_key and expected_updated_at and applies the same stale-state conflict contract as execute.
| Name | Required | Description | Default |
|---|---|---|---|
| action_id | Yes | Replenishment action UUID | |
| idempotency_key | Yes | Caller-chosen idempotency key | |
| expected_updated_at | Yes | The action updated_at the retry was decided against |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses idempotency, required fields, and the stale-state conflict contract, providing essential behavioral context beyond just the operation type.
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, front-loaded with the core purpose immediately.
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 3 required params and no output schema, the description sufficiently covers purpose, key constraints (idempotency, conflict contract), and context for retry operations, though it could briefly mention expected outcomes.
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%; the description adds context by linking idempotency_key and expected_updated_at to the stale-state conflict contract, enhancing understanding beyond the schema alone.
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 verb "Retry" clearly indicates the action, resource "replenishment action" is specific, and the scope "blocked or failed" distinguishes it from sibling tools like rr_execute_replenishment_action and rr_prepare_replenishment_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?
The description states when to use (retry blocked or failed actions) and mentions idempotency and stale-state contract, but does not explicitly exclude other scenarios or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a bounded JSON object under a namespace and key. The value must be a JSON object (max 16 KiB), must not contain secrets or raw PII, and ttl_seconds is optional and capped at 90 days. The namespace must be granted to this key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Entry key within the namespace (max 200 chars) | |
| value | Yes | JSON object value (max 16 KiB, no secrets or PII) | |
| namespace | Yes | Allowlisted context namespace | |
| scope_ref | No | Optional descriptive scope label (max 200 chars, non-secret) | |
| ttl_seconds | No | Optional expiry in seconds (max 7776000 = 90 days) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals constraints (max 16 KiB, no secrets/PII, TTL cap, namespace grant) but does not specify overwrite behavior, atomicity, or response structure. Some important behavioral traits 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 concise with two sentences, front-loading the main purpose and key constraints. Every sentence adds value without 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?
Given the lack of output schema and the tool's complexity (5 parameters, 3 required), the description covers essential constraints and usage. It misses details like overwrite behavior and expected return value, but for a store operation, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds the context that 'namespace must be granted to this key,' which slightly enhances the schema. However, most parameter constraints are already in the schema, so the added value is minimal.
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's purpose: storing a bounded JSON object under a namespace and key. It uses specific verbs and resources ('Store a bounded JSON object'), and distinguishes from sibling tools like rr_get_agent_context and rr_delete_agent_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for storing JSON objects) but does not explicitly contrast with sibling tools or provide guidance on when not to use it. It mentions constraints but no alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set stock quantity for a SKU at a manual location.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes | Canonical SKU | |
| quantity | Yes | New on-hand quantity | |
| location_id | No | Manual location UUID | |
| location_name | No | Manual location name, used if location_id is omitted |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether the operation is idempotent, what happens if location is unspecified, or authorization requirements. For a mutation tool, this is 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 very brief (one sentence), which is efficient but lacks necessary depth. It could be improved by adding context without becoming verbose.
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 4 parameters, no output schema, and no annotations, the description should provide more context about return values, error handling, and behavioral constraints. The current description is inadequate for proper tool selection.
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?
Although schema coverage is 100%, the description adds minimal extra meaning beyond restating that the location is 'manual'. It does not explain the relationship or priority between location_id and location_name, nor the impact of omitting optional 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 action (set stock quantity), resource (SKU), and scope (at a manual location). It distinguishes from sibling tools like rr_create_location or rr_set_agent_context by focusing on stock modification.
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 vs alternatives. Sibling tools include replenishment actions that might also modify stock, but no differentiation is provided.
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.
v1.0.8rr_create_locationrr_create_purchase_orderrr_execute_replenishment_actionrr_get_agent_contextrr_get_data_freshnessrr_get_demand_forecastrr_get_document_upload_urlrr_get_lost_salesrr_get_po_documentsrr_get_purchase_orderrr_get_recent_activityrr_get_setup_statusrr_get_sku_healthrr_list_agent_contextrr_list_purchase_ordersrr_list_suppliersrr_prepare_replenishment_actionrr_record_pi_reviewrr_resolve_replenishment_actionrr_retry_replenishment_actionrr_set_agent_contextrr_set_stock_at_locationv1.0.8rr_create_purchase_orderrr_delete_agent_contextrr_execute_replenishment_actionrr_get_data_freshnessrr_get_document_upload_urlrr_get_lost_salesrr_get_po_documentsrr_get_setup_statusrr_get_sku_healthrr_list_purchase_ordersrr_prepare_replenishment_actionrr_record_pi_reviewrr_request_approvalrr_resolve_replenishment_actionrr_retry_replenishment_actionrr_update_purchase_orderv1.0.8rr_acknowledge_alertrr_add_po_noterr_cancel_purchase_orderrr_create_purchase_orderrr_execute_replenishment_actionrr_get_alertsrr_get_demand_forecastrr_get_document_upload_url4 fields changedInput schema / properties / description / descriptionAdded value: +"Document description"Input schema / properties / document_type / descriptionAdded value: +"Document type (default: attachment)"Input schema / properties / filename / descriptionAdded value: +"Document filename"Input schema / properties / po_id / descriptionAdded value: +"Purchase order UUID"rr_get_inventory_positionrr_get_inventory_valuerr_get_lost_salesrr_get_po_documentsrr_get_po_pdfrr_get_purchase_orderrr_get_recent_activityrr_get_sales_historyrr_get_sku_healthrr_get_slow_moversrr_get_stockout_riskrr_get_suggested_purchase_ordersrr_get_sync_statusrr_get_top_sellersrr_list_itemsrr_list_purchase_orders7 fields changedInput schema / properties / limit / descriptionAdded value: +"Max results (default 50, max 200)"Input schema / properties / limit / typePrevious value: -"number"New value: +"integer"Input schema / properties / offset / descriptionAdded value: +"Pagination offset"Input schema / properties / offset / typePrevious value: -"number"New value: +"integer"Input schema / properties / search / descriptionAdded value: +"Search by PO number"Input schema / properties / status / descriptionAdded value: +"Filter by status (comma-separated: draft,sent,approved,received,cancelled)"Input schema / properties / vendor_id / descriptionAdded value: +"Filter by vendor ID"rr_list_suppliersrr_prepare_replenishment_actionrr_record_pi_review5 fields changedInput schema / properties / pi_date / descriptionAdded value: +"PI date (ISO 8601)"Input schema / properties / pi_number / descriptionAdded value: +"Proforma invoice number"Input schema / properties / pi_terms / descriptionAdded value: +"Payment terms"Input schema / properties / pi_total / descriptionAdded value: +"PI total amount"Input schema / properties / po_id / descriptionAdded value: +"Purchase order UUID"rr_request_approval2 fields changedInput schema / properties / message / descriptionAdded value: +"Message for the approver"Input schema / properties / po_id / descriptionAdded value: +"Purchase order UUID"rr_resolve_replenishment_actionrr_retry_replenishment_actionrr_send_purchase_orderrr_trigger_syncrr_update_purchase_order4 fields changedInput schema / properties / expected_delivery_date / descriptionAdded value: +"Updated expected delivery date"Input schema / properties / notes / descriptionAdded value: +"Updated notes"Input schema / properties / po_id / descriptionAdded value: +"Purchase order UUID"Input schema / properties / vendor_id / descriptionAdded value: +"Updated vendor ID"v1.0.1rr_acknowledge_alertrr_add_po_noterr_cancel_purchase_orderrr_create_purchase_orderrr_get_alertsrr_get_demand_forecastrr_get_document_upload_urlrr_get_inventory_positionrr_get_inventory_valuerr_get_lost_salesrr_get_po_documentsrr_get_po_pdfrr_get_purchase_orderrr_get_sales_historyrr_get_sku_healthrr_get_slow_moversrr_get_stockout_riskrr_get_suggested_purchase_ordersrr_get_sync_statusrr_get_top_sellersrr_list_itemsrr_list_purchase_ordersrr_list_suppliersrr_record_pi_reviewrr_request_approvalrr_send_purchase_orderrr_trigger_syncrr_update_purchase_orderEach tool has a distinct purpose with clear boundaries. The replenishment action tools (prepare, execute, resolve, retry) are well-differentiated, and the agent context tools form a separate subsystem with no overlap.
Most tools follow a verb_noun pattern (e.g., rr_create_location, rr_list_purchase_orders). However, rr_get_document_upload_url is a misnomer as it creates a document record, and there is a mix of 'create' and 'set' for creation actions. Overall, still readable and mostly consistent.
With 16 tools covering inventory replenishment and agent context management, the count is well-scoped for the domain. It is neither too sparse nor overly numerous.
The agent context tools are fully CRUD-complete. However, the inventory domain lacks a tool to retrieve stock quantity (only set_stock_at_location) and lacks location update/delete operations. The replenishment action workflow is well-covered, but these gaps limit overall completeness.
Inventory, restock planning, and sales analytics for your Amazon FBA business.
Run storefronts, listings, orders, content, fulfillment, and analytics through AI.
Ask questions across Shopify, Klaviyo, GA4 and 20+ e-commerce sources in plain English.
Co-purchase intelligence and merchant ops tools for AI shopping, ecommerce, and B2B agents
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ReplenishRadar/MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
