@bicharts/chart-mcp 0.6.87 → 0.6.89

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@bicharts/chart-mcp",
3
- "version": "0.6.87",
3
+ "version": "0.6.89",
4
4
  "description": "MCP (Model Context Protocol) stdio server for BIC AI charts: profile a dataset locally, then generate chart code that has passed the BIC backend's render gates. Works with any MCP-capable client (Claude Code, Claude Desktop, Cursor, Copilot Studio). An account pays to author charts; the code it writes is yours and runs with no licence.",
5
5
  "keywords": [
6
6
  "mcp",
@@ -47,8 +47,8 @@
47
47
  },
48
48
  "// 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.",
49
49
  "devDependencies": {
50
- "@bicharts/chart-host": "^0.6.87",
51
- "@bicharts/shape-core": "^0.6.87",
50
+ "@bicharts/chart-host": "^0.6.89",
51
+ "@bicharts/shape-core": "^0.6.89",
52
52
  "@modelcontextprotocol/sdk": "^1.0.0",
53
53
  "@types/node": "^20.0.0",
54
54
  "@types/papaparse": "^5.3.14",
@@ -180,11 +180,29 @@ disqualifies it; leave it unset when they only asked for a chart, and the engine
180
180
  `@bicharts/chart-host` draws), `width`/`height`, and
181
181
  `reasoning_mode: "1P"` when you want the cheapest, fastest pass.
182
182
 
183
- **Two parameters are the user's to answer, not yours to guess.** `level_of_detail` (how much of
183
+ **Settings are the user's to answer, not yours to guess.** Every `generate_chart` result carries a
184
+ `structuredContent.settings` block: `applied` lists each setting that took effect and whose choice it
185
+ was (`user`, `app`, `default`, `server-roll`, `from-prompt`), `askable` names the ones still open to
186
+ the user and how to set each, and `conflicts` lists arguments that were not sent, each with its
187
+ reason. The reply's text carries the same news in one `Settings:` line (what the user set, what the
188
+ engine picked, what was dropped), for a client that shows only the text. `engineChoices` says whether
189
+ the server reported what it picked; when it is `unavailable` the engine may have picked where a row
190
+ reads `default`, so never tell the user it picked nothing. Most settings are
191
+ passed only when the user has said them in their own words: a title, data labels, a legend position,
192
+ a limit, a date grain, an overlay, a font. A few are worth one question when they matter and the user
193
+ hasn't said: `chart_style` (which family of charts to consider: the familiar forms or the other types), `level_of_detail` (how much of
184
194
  the data they want to see: every observation, a distribution, or one mark per category) and
185
- `font_family` (a font or house style they've named) are preferences, not properties of the data.
186
- When one matters to the request and the user hasn't said, ask them in one short question;
187
- otherwise leave it unset, which changes nothing.
195
+ `culture` (their language and region), and, once the chart is drawn, the live options
196
+ `settings.askable` marks as `offer` (whether an animated chart plays by itself, where a card deck's
197
+ flip controls sit). `font_family` is a font or house style they've named, never one read off the
198
+ data. Put at most ONE consolidated question to them before the first `generate_chart` and one after
199
+ it, giving each row's options (the second uses only the `askable` rows whose `phase` is
200
+ `after-generate`); never ask again what the conversation already answered, and never ask
201
+ about theme, size, selection or cross-filtering, which the host app owns. An answer is an argument on
202
+ the next `generate_chart`, or, for a live setting, an option in the emitted component
203
+ (`<EnrollmentChart ... options={{ animAutoPlay: true }} />`). When you can't ask (a sub-agent, an
204
+ unattended run), ask nothing, use the defaults, and tell the user which settings were assumed from
205
+ `settings.applied`. `get_guide` with topic `settings` lists every row with its options.
188
206
 
189
207
  **Generation takes minutes.** Fire the calls for independent charts **in parallel** rather
190
208
  than in sequence — it is the difference between ~4 minutes and ~12.