storelink-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STORELINK_MODE | No | mock = in-process fixtures; http = call the real API | mock |
| STORELINK_API_KEY | No | Optional Bearer for non-store endpoints | |
| KORRAL_GCP_PROJECT | No | GCP project where Korral stores weekly-rotated store keys (required in http mode) | |
| STORELINK_BASE_URL | No | Base URL used in http mode | https://storelink.com |
| STORELINK_BUYER_MD | No | Category-buyer activity (readable markdown) | logs/buyer-activity.md |
| STORELINK_AUDIT_LOG | No | NDJSON audit log file path | logs/storelink-audit.ndjson |
| STORELINK_BUYER_LOG | No | Category-buyer activity (JSON lines) | logs/buyer-activity.ndjson |
| STORELINK_THREAD_ID | No | Optional agent/thread id for correlating a chat | |
| KORRAL_SECRET_PREFIX | No | Secret id = {prefix}{store_id} (e.g. korral-store-47) | korral-store- |
| GOOGLE_APPLICATION_CREDENTIALS | No | Path to service account key file for GCP Secret Manager (Application Default Credentials) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_storesA | List all StoreLink stores (id, name, city, country code, active flag). Args: reason: Why you are listing stores (required for audit). |
| get_storeA | Get details for a single store by store_id (e.g. 47 or store-001). Args: store_id: Store identifier. reason: Why you need this store's details (required for audit). |
| get_on_hand_vs_posA | Current on-hand plus POS sales for a SKU at a store (category buyer view). Returns inventory, last-24h POS (by default), delta = units_sold − available, and a product block (name, case_pack, supplier lead_time_days) for order sizing. If delta >= 6, call create_replenishment (prefer multiples of case_pack). Args: store_id: Store identifier (e.g. 47 or 102). sku: Product SKU (e.g. 8847291 for Madeta butter 250g). reason: Why you are checking on-hand vs POS (required for audit). since: Optional ISO-8601 start of the POS window. If omitted, defaults to 24 hours ago (UTC). |
| create_replenishmentA | Raise a replenishment order when get_on_hand_vs_pos delta >= 6. Call after get_on_hand_vs_pos when units_sold − available is at least 6. Prefer ordering in multiples of product.case_pack from that response. Args: store_id: Store identifier (e.g. 47). sku: Product SKU to replenish (e.g. 8847291). quantity: Units to order (must be > 0; prefer case_pack multiples). reason: Why you are raising this order (required for audit). order_reason: Optional note stored on the replenishment order record. priority: One of low, normal, high, urgent (default normal). |
| get_replenishmentB | Get status of a replenishment order by store_id and order_id. Args: store_id: Store identifier. order_id: Replenishment order id. reason: Why you are checking order status (required for audit). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| buyer_activity_feed | Plain-language activity feed for category buyers (what the agent did and why). |
TDQS
Scored across 5 tools
Each tool targets a distinct action and resource: listing stores, getting store details, checking inventory/POS, creating a replenishment, and retrieving a replenishment. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern (list_stores, get_store, get_on_hand_vs_pos, create_replenishment, get_replenishment). The naming is predictable and clear, with the compound 'get_on_hand_vs_pos' still fitting the convention.
The server has 5 tools, which is well-scoped for its purpose of store and replenishment management. Each tool serves a necessary function without redundancy, making the set neither too thin nor too heavy.
The main workflow is covered: list/get stores, check inventory vs POS, create a replenishment, and check its status. A minor gap is the lack of a 'list_replenishments' tool or update/cancel capabilities, but the core lifecycle is functional.