Project Tango
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
Each tool has a clearly distinct purpose: aggregate analytics (analyze_sales_metrics) vs. per-order drill-down (find_orders), inventory alerting (get_low_stock_alerts) vs. restock recommendation (smart_restock_predictor), plus catalog browse, copy generation, order simulation, and demo reset. The descriptions explicitly cross-reference each other to delineate boundaries, leaving little room for misselection.
Most names follow a verb_noun pattern (analyze_sales_metrics, list_all_products, find_orders, reset_demo_state, simulate_order_placement, draft_product_copy). Two deviate mildly: 'get_low_stock_alerts' inserts an adjective and 'smart_restock_predictor' uses an adjective_noun form with no verb. Still readable and largely predictable.
Eight tools is well within the sweet spot and each earns its place across the read/write lifecycle. No redundant or filler tools; the set is tightly scoped to a simulated commerce domain.
The surface covers catalog browse, order placement/lookup, analytics, inventory alerts, restock planning, copy generation, and state reset—core workflows are all present. Minor gaps exist around product CRUD (no create/update/delete of catalog items) and order mutation, though the demo/simulated framing makes these reasonable omissions.