Breww MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BREWW_API_KEY | Yes | Your Breww API key, sent as a Bearer token. A value pasted with its `Bearer ` prefix is accepted. Required. | |
| BREWW_BASE_URL | No | Defaults to `https://breww.com/api`. Used by the tests. Must not contain a username or password; the server refuses to start if it does. | https://breww.com/api |
| BREWW_ALLOW_WRITES | No | Set to `true` to register the `create_order` tool. Off by default. | false |
| BREWW_TOOL_BUDGET_S | No | Time budget per tool call in seconds, above 0 and at most 55. Defaults to 45. | 45 |
| BREWW_REQUESTS_PER_MINUTE | No | How many requests this server allows itself per minute, 1 to 600. Defaults to 60, Breww's documented limit; lower it if other integrations use the same account. | 60 |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_productsA | The brewery's sellable products (casks, kegs, smallpack, multi-packs, stock items, services) with code, type, price and the drink(s) each contains. Obsolete products are left out unless asked for. Uses GET /products/. |
| get_productA | One product in full: code, type, price, barcode, volumes, duty, the drinks and stock items it is made of, tags and custom fields. Uses GET /products/{id}/. |
| stock_levelsA | Current stock. Two sources: (1) stock items (ingredients, packaging, chemicals, guest beer, merchandise) currently in stock, per stock item and location, from GET /stock-received/ with is_empty=False (quantities in kg, litres or units depending on the item's tracking type); (2) finished products, from GET /products/ with include_fields=quantity_in_stock_in_format, a conditionally included field that Breww's API guide names but its spec does not define, so the value is passed through exactly as returned. The API has no location filter on stock received, so location_id is applied here after fetching. |
| list_batchesB | Drink batches (brews) with drink, status (planned, in progress, complete), planned and actual dates, volumes and current vessel. Uses GET /drink-batches/. |
| get_batchB | One drink batch in full: drink, status, brew type, dates, planned and actual volumes, ABV, starting and final gravity, current vessel and fill, recipe version. Uses GET /drink-batches/{id}/. |
| list_customersA | Trade customers, leads and suppliers (Breww keeps them in one list) with last order date, predicted next order, ordering cadence, average order value and Breww's nightly churn and overdue probabilities. Good for 'who is overdue to reorder?' (next_expected_order_before today) and 'who have we lost?' (min_prob_churned). Contact details only with include_contact_details. Uses GET /customers-suppliers/. |
| get_customerA | One customer in full: type, sales person, price book, credit limit, payment terms, ordering cadence and predictions, trade store access, comments, number of contacts, and their most recent orders. Contacts (names, emails, phones), addresses, tax number and custom fields only with include_contact_details. Uses GET /customers-suppliers/{id}/ and GET /orders/?customer={id}&ordering=-issue_date. |
| list_ordersA | Sales orders, which in Breww are also the invoices: number, customer, issue and due dates, order and payment status, value, total and amount due. Filter by customer, status, payment status, dates, amount due, number, PO number or source. Good for 'what is unpaid and overdue?' (payment_status unpaid/part_paid, due_before today). Uses GET /orders/. |
| get_orderA | One order/invoice in full: lines (product, quantity, dispatched, returned, unit price, discount, value, tax, total), adjustment lines (delivery, deposits), totals, statuses, delivery, notes. Billing and delivery addresses, the contact email and the invoice PDF and customer links only with include_contact_details; payment records are never returned. Uses GET /orders/{id}/. |
| list_deliveriesA | Deliveries, collections, courier shipments and uplifts (Breww calls them fulfillments) with scheduled date, customer, order, dispatch and completion status, drop window and what is on board. The town is returned by default; the full address, phone number, coordinates and delivery-note links only with include_contact_details. Uses GET /fulfillments/. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool targets a distinct resource or action: list/get pairs for products, batches, customers, and orders, plus dedicated stock_levels and list_deliveries. There is no meaningful overlap that would cause an agent to misselect, and descriptions clarify boundaries.
Nine of ten tools follow a consistent list_/get_ verb_noun snake_case pattern. stock_levels breaks the pattern with a noun-only name, and there is no get_delivery counterpart, but overall naming remains predictable.
Ten tools is well-scoped for a brewery data access server, giving read coverage of products, stock, batches, customers, orders, and deliveries without bloat. Each tool earns its place.
The set covers read access to core brewery entities but lacks any create, update, or delete operations, which are notable gaps for a management domain. There is also no get_delivery tool and payment records are explicitly unavailable, leaving some lifecycle dead ends.