@bicharts/chart-mcp 0.6.121 → 0.6.123

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bicharts/chart-mcp",
-  "version": "0.6.121",
+  "version": "0.6.123",
   "description": "AI Data Components for Power BI, Excel, Fabric Apps and the web, over MCP: working what-if apps, interactive tables and bivariate maps first, plus about 90 everyday chart types, with selection and cross-filtering already wired. It profiles your table locally; the code it writes is yours and runs with no license.",
   "keywords": [
     "mcp",
@@ -51,8 +51,8 @@
   },
   "// dependencies": "NONE, deliberately. dist/ bundles every module the server uses, so a runtime dependency installs nothing it needs - it only makes npx fetch that package (and its tree) before the first start. Everything the bundle carries is a devDependency; scripts/verify-package.mjs fails the release if a dependency appears or a shipped file imports anything but Node's built-ins.",
   "devDependencies": {
-    "@bicharts/chart-host": "^0.6.121",
-    "@bicharts/shape-core": "^0.6.121",
+    "@bicharts/chart-host": "^0.6.123",
+    "@bicharts/shape-core": "^0.6.123",
     "@modelcontextprotocol/sdk": "^1.32.1",
     "@types/node": "^26.6.5",
     "@types/papaparse": "^5.3.14",

package/skills/bic-charts/SKILL.md

@@ -622,6 +622,15 @@ has passed the template's check: don't run it again with `run-dax-query`. Don't
 table and aggregate it in the browser: the Execute Queries API refuses a response over 15 MB, and a
 column repeated on every fact row (a country's population on each sale) sums to nonsense.
 
+**When the chart is about the records themselves, its grain IS the records.** A scatter of customers, a
+distribution, customer segments or a map of accounts takes one row per customer, account or order - the raw facts -
+and the engine does the shaping. For totals (revenue by region, a monthly trend) the chart's grain is the simplest
+request. Raw rows work too where the list offers grains: the types that draw totals are then listed under "Fits once the
+rows are totalled", once per grain, and the person picks one (step 4). Where a list shows no such heading, raw rows for a
+total lose the bar, card and donut charts: query the chart's grain.
+Ratio measures (a growth %, an attainment %, a share) and measures from different fact tables stay as the model
+computes them: raw rows can't rebuild them.
+
 **A "vs" measure is blank where there's nothing to compare against.** `[Goal Attainment %] - 1` is never blank:
 BLANK() - 1 is -1, so SUMMARIZECOLUMNS keeps every row, a place with no goal reads -100%, and on a symmetric diverging
 scale that one mark sets the span and every other draws near-neutral. The same goes for `1 - [Share]` and for
@@ -745,8 +754,9 @@ table and any symbols: `[Occupancy %]` becomes `Occupancy`), saves every row to
 reads each column's role, format and description from the model (`INFO.VIEW.MEASURES()` / `INFO.VIEW.COLUMNS()`),
 and profiles the result. Its reply ends with the arguments for the next two calls - `csv_path`, `measures`,
 `dimensions`, `formats`, `descriptions` - so pass them to `list_eligible_charts` and `generate_chart` as they
-are. It keeps at most 1,000 rows of a query; the tool says so when it cut a result, and the fix is a query at the
-chart's grain.
+are. It keeps up to 250,000 rows of a query by default (the setting `BIC_MCP_QUERY_ROW_CAP` raises it, up to 1,000,000;
+the older `fabric-app-data` layout only 1,000, that CLI's own limit) and says so when a result is past it; only then
+narrow the query, with a filter or the grain the chart reads.
 
 **4. Ask before choosing, then choose what answers the question.** `list_eligible_charts` on that
 data. Pass `chart_type` to `generate_chart` only for a type the person named; when they only asked for a chart, leave it
@@ -771,6 +781,13 @@ without naming:
 If the list doesn't offer what you expected, read its notes: it names a type refused on a count
 when your table is small, and it says when `name_filter` hid description matches.
 
+**A grain is the person's choice, like the chart's form.** When the rows are finer than a type draws (raw rows where
+it wants one per category), the list offers that type under "Fits once the rows are totalled", once per grain: each row
+says how the rows are totalled first and carries a `projection` key, and a type listed twice is the same chart at two
+grains. Don't pick one yourself and don't re-query to total the rows in DAX: ask which grain they want in their own
+words ("revenue per country, or per region?"), then pass that row's name as `chart_type` and its key, copied exactly,
+as `projection`. The chart is drawn at that grain and says so.
+
 The Interactive table and the Variance grid are preview types too, so either may be missing from the list. When the person asked for one and it isn't listed, say so and ask how to go on; don't build a table by hand in its place.
 
 The Selection explainer is a preview type: the server offers it only where it's switched on, so it may be missing from the