Skip to main content
Glama
maskchanel14-source

PO Pilot MCP

by maskchanel14-source
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Build MOQ-Compliant Supplier POs, Landed Costs, OTB & Shopify PO/Transfer CSVs

build_supplier_purchase_orders
Read-onlyIdempotent

Converts SKU demand signals into vendor-grouped purchase orders, applying MOQs, case packs, landed costs, and budget limits, then exports Shopify Draft PO CSVs and vendor emails.

Instructions

Turns SKU demand signals into ready-to-send Purchase Orders grouped by vendor. Enforces carton/case-pack multiples, per-SKU MOQs, supplier-level minimum units/USD thresholds (topping up A-class SKUs first), US import tariff + freight landed unit costs with margin-erosion alerts, and optional Open-to-Buy (max_cash_budget_usd) cashflow rationing. Outputs ready-to-import Shopify Native Draft PO CSV (SKU,Supplier SKU,Quantity,Cost,Tax %), Shopify POS Inventory Transfers CSV (SKU,Barcode,Quantity), and formatted vendor PO emails.

Input Schema

NameRequiredDescriptionDefault
skusNoStructured SKU inventory + velocity rows.
demo_modeNoGenerate full multi-vendor POs using the built-in Austin, TX merchant demo dataset.
po_prefixNoPrefix for generated Purchase Order numbers.PO-2026
inventory_csvNoRaw Shopify Products/Inventory CSV text.
service_levelNoTarget cycle service level used for Z-score safety stock calculation (85%=1.04, 90%=1.28, 95%=1.65, 97.5%=1.96, 99%=2.33).95%
supplier_rulesNoPer-vendor MOQ, minimum USD spend, import tariff %, freight USD, lead time override, payment terms, email, and ship-to location rules.
use_live_shopifyNoPull live store SKUs and barcodes from Shopify Admin GraphQL (Pro / License).
review_period_daysNoDays of forward cover to buy beyond lead time.
max_cash_budget_usdNoOptional Open-to-Buy (OTB) maximum landed cash spend ceiling in USD across all generated POs. Trims lowest-priority C/B cartons first while protecting CRITICAL A-class SKUs.
min_gross_margin_pctNoMinimum acceptable landed gross margin % before triggering `margin_erosion_warning: true` on a PO line.
default_import_duty_pctNoFallback US import tariff / customs duty % when not specified on a vendor's supplier_rules entry.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavioral detail beyond the annotations: carton rounding, MOQ enforcement, vendor minimums, landed-cost calculation, margin-erosion alerts, and OTB rationing. Safety annotations already establish it as a read-only, idempotent operation; the description complements this by explaining what rules the generated output enforces, though it could more explicitly state whether emails are actually sent or only formatted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loads the core transformation before listing enforcement rules and output formats. It is appropriately sized for a complex planning tool, though the single long sentence structure makes it slightly harder to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, 11 parameters, rich nested schema, and no output schema, the description does a good job explaining outputs, constraint handling, and optional live/demo modes. The main remaining gap is workflow positioning relative to the sibling replenishment-planning tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is already 100%, so the schema carries the parameter-documentation burden. The description highlights key semantics for max_cash_budget_usd and supplier-level rules, but most parameter meaning comes from the schema rather than the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it turns SKU demand signals into vendor-grouped purchase orders and names the exact CSV/email outputs. It is clear what the tool produces, but it does not explicitly differentiate itself from the sibling calculate_replenishment_plan, which likely handles the upstream planning step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the detailed feature list and output formats, making it evident this is for PO generation rather than reconciliation or migration. However, there is no explicit 'use this when' guidance, no exclusions, and no direct comparison to calculate_replenishment_plan or reconcile_po_three_way_match.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools