Project Tango
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PROJECT_TANGO_STORE | No | Set to `json` to use the older whole-snapshot JSON file instead of SQLite. Works on a runtime without `node:sqlite`, with a narrower guarantee. | |
| PROJECT_TANGO_PERSIST | No | Set to `0` to disable persistence entirely — the original in-memory behaviour, for throwaway or CI runs. | |
| PROJECT_TANGO_DATABASE_DIR | No | Directory holding the state database. Defaults to `~/.project-tango`. |
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": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_all_productsA | Returns the product catalog, optionally filtered by category, a min/max price range, or a free-text search. Use this to browse inventory or to find a specific product by name, SKU, description or tag before recommending, restocking, or drafting copy for products. |
| get_low_stock_alertsA | Scans inventory and returns InventoryAlert objects for every product at or below a stock threshold. Products under 3 units are flagged 'critical'; everything else at or under the threshold is flagged 'low'. Results are sorted by current stock ascending (most urgent first). An optional category restricts the scan to one category; the echoed 'filters' block reports the category actually applied. |
| analyze_sales_metricsA | Calculates gross revenue, average order value (AOV), the top-selling products by units sold, and a breakdown of orders by fulfillment status (pending / shipped / delivered), based on current order history. Figures cover all recorded orders; the 'period' field reports the actual date span so a stale dataset is visible. An optional category scopes every figure to products in that category: revenue, units and the trend count only lines of those products, an order counts toward the breakdown and AOV when it contains at least one such line, and the echoed 'filters' block reports the category actually applied. |
| find_ordersA | Looks up orders by exact order id or by customer name (case-insensitive substring match, so 'maya' finds 'Maya Chen') and returns each order's line items enriched with product name, unit price and line total. This is the drill-down behind the aggregates: analyze_sales_metrics reports what sold in total, this reports what a single order or customer actually bought. Results are newest first. Line prices come from the current catalog; a line whose product is no longer catalogued reports null rather than an invented price. Supplying both filters requires an order to satisfy both; the echoed 'filters' block reports the values actually matched on. A filter that matches nothing is a successful lookup with count 0 and an empty 'orders' array — the same answer list_all_products gives — not a tool error. Results are deliberately uncapped by default and there is no pagination: 'customer_name' is a substring match, so a broad query returns every matching order in the dataset (a one-letter name matches most of it). Pass 'limit' to bound a broad query — 'totalMatches' always reports how many matched in full, so a capped answer cannot be mistaken for a complete one. Narrow the filter rather than expecting a page, and prefer 'order_id' when you want a single order. |
| smart_restock_predictorA | Evaluates every low-stock item and recommends an exact reorder quantity. The recommendation is derived from each product's demand velocity (units sold per day over recent order history), projected demand across an assumed 14-day supplier lead time plus a 7-day safety buffer, minus current stock on hand. Items with no recent sales history fall back to a conservative flat restock quantity. Results are ordered by days of cover (stock remaining / daily velocity), so the first recommendation is the item that runs out first; items with no measurable demand report a null daysOfCover and sort last. An optional category restricts the plan to one category; the echoed 'filters' block reports the category actually applied. |
| draft_product_copyA | Looks up a product by SKU and generates structured, high-conversion marketing copy (headline, short and long description, key bullet points) plus SEO tags tailored to that product's category and tags. |
| simulate_order_placementA | Write-action tool: places a new simulated order, validating stock availability for every line item, decrementing inventory counts, computing the order total from current catalog prices, and returning a success receipt with the updated stock levels. Rejects the entire order (no partial writes) if any item is unavailable or under-stocked. The whole read-validate-write runs inside the provider's transaction, so a concurrent order cannot both pass a stock check and oversell. This permanently changes the dataset until reset_demo_state is called. |
| reset_demo_stateA | Write-action tool: discards every simulated order and inventory change made during this or any earlier session, restoring the original seed catalog. Use it to undo exploratory ordering before reporting results, so the numbers you hand back reflect the real dataset rather than your own test orders. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| weekly_inventory_review | Runs the full inventory review: low-stock alerts, restock plan ordered by days of cover, and the sales trend behind them, then writes up what to reorder first. An optional category narrows every step to one category. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| catalog | The current product catalog as JSON — the same rows list_all_products returns, readable without a tool call. |
TDQS
Scored across 8 tools
Most tools have clearly distinct purposes, and the descriptions explicitly draw boundaries (e.g. find_orders as drill-down vs analyze_sales_metrics as aggregates, get_low_stock_alerts as flagging vs smart_restock_predictor as reorder quantities). The closest overlaps are get_low_stock_alerts/smart_restock_predictor (both scan low stock) and list_all_products/draft_product_copy (both resolve a product), but the output differences make selection reasonably clear.
Nearly all names are snake_case verb_noun: find_orders, draft_product_copy, list_all_products, get_low_stock_alerts, analyze_sales_metrics, simulate_order_placement, reset_demo_state. The single deviation is smart_restock_predictor, which uses a noun/adjective form with no leading verb, breaking the otherwise predictable pattern.
Eight tools is well-scoped for a simulated retail analytics/ops server, with each tool covering a distinct workflow (browse, search orders, analyze, alert, predict, write, reset). Nothing feels redundant or missing at the count level.
Read and analytics coverage is strong, and there is a write path (simulate_order_placement) plus recovery (reset_demo_state). However the order lifecycle is a dead end: fulfillment status is reported by analyze_sales_metrics but no tool can advance or update an order's status, cancel it, or adjust inventory outside of placing a new order; product management is also read-only.