bizdata-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BIZDATA_DB | No | Path to the SQLite database file. Default is data/harbor_pine.db in this repo. | data/harbor_pine.db |
| BIZDATA_MAX_ROWS | No | Maximum number of rows returned by run_sql. Default is 200. | 200 |
| BIZDATA_AUDIT_LOG | No | Path to the JSONL audit log file. Default is logs/audit.jsonl in this repo. | logs/audit.jsonl |
| BIZDATA_TIMEOUT_S | No | Query timeout in seconds before a query is cancelled. Default is 5. | 5 |
| BIZDATA_HIDDEN_COLUMNS | No | Comma-separated list of table.column columns to hide (read as NULL) through run_sql. Default is customers.email; set it empty to hide nothing. | customers.email |
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 |
|---|---|
| run_sqlA | Run one read-only SQLite SELECT (or WITH ... SELECT) and return columns, rows and a truncated flag. Results are capped (200 rows by default) and queries are stopped after a few seconds. Aggregate in SQL rather than pulling raw rows. Call describe_schema first if you haven't seen the tables. |
| describe_schemaA | List every table with its columns, row counts, foreign keys, and notes on how to use them. Read the conventions section before writing SQL: it defines revenue, refunds and date formats. |
| sales_summaryA | Orders, units, revenue, refunds and net revenue, grouped by time period or dimension. start/end are inclusive YYYY-MM-DD dates; leave either out for no bound. Only completed orders count. Refunds are attributed to the original order's date. Weeks start on Monday. Includes a totals row with average order value. |
| top_customersA | The n customers with the highest net revenue (after refunds) in an optional date range. n is 1-100. Returns customer id, name, state, order count, revenue, refunds, and first/last order time. |
| refund_rateA | Refunded dollars as a percentage of revenue, plus units sold and refunded, grouped by Dates filter on when the order was placed. Small groups can show extreme rates; check units_sold before drawing conclusions. |
| inventory_alertsB | Active products that are out of stock, at or below their reorder point, or running low. Days of cover = stock on hand / average daily units sold over the last 30 days, measured up to the most recent order in the data. Products with no recent sales show no cover figure. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| schema | Tables, columns and usage notes for the store database, as Markdown. |
TDQS
Scored across 6 tools
Each analytical tool targets a distinct question (sales over time, top customers, refund rate, inventory health), and describe_schema is clearly a discovery step. The only blur is run_sql, which can technically reproduce any of the specialized tools, but descriptions steer agents toward the purpose-built ones.
All names are snake_case, but the conventions are mixed: run_sql and describe_schema use verb_noun while sales_summary, top_customers, refund_rate and inventory_alerts use noun-style labels. Still readable and predictable enough to navigate.
Six tools is well-scoped for a focused business-analytics server: schema discovery, a SQL escape hatch, and four targeted analytics. Each tool earns its place with no redundancy.
The surface covers revenue, refunds, customers, and inventory, plus describe_schema and a raw SQL escape hatch that fills most gaps. Minor gaps exist for product-level performance or period-over-period comparisons, but agents can work around them via run_sql.