Skip to main content
Glama

Pin notebook cell

fastero_pin_notebook_cell

Make a dashboard widget from a notebook cell's result, as the cell's Pin to Dashboard button does: a SQL cell's rows, or the table a Python cell shows last (a pandas DataFrame on its last line, or one passed to display()). The widget shows the rows of the notebook's latest run, so a notebook on a schedule (fastero_schedule_notebook) keeps it current, and dashboards, their shared links and emails, and pages show it like any widget. Run the notebook first (fastero_run_notebook) so the cell has a result. cellIndex counts from 0 over all the notebook's cells, markdown ones too, in the order fastero_read_notebook gives them. A chart needs assignments naming the columns it plots; table is the default. With dashboardId it is placed on that dashboard too. Returns the widget with its _id and url.

Input Schema

NameRequiredDescriptionDefault
nameYesThe widget’s title, shown above it.
vegaLiteNoA Vega-Lite v6 description, only for a chart chartType can't say: several panels, several kinds of mark on one chart, bands, shaded periods, labelled lines, a log or reversed axis, a colour per row, floating bars, side-by-side boxplots. A plain bar, line or pie stays chartType: it is shorter, follows the dashboard's Day/Week/Month switch, and a person can edit it by hand, which nobody can do to this. Rebuild an existing chart this way only when asked for something its type can't do; its old version stays in its history. The rows are the query's, so give no data. Give no config, background, padding, autosize or top-level title: the app decides the look, and the widget's name is the title (title.subtitle stays). About 800 wide in all, in numbers: width 720, height 320. Leave text colours to the theme. Not available: params, selections, url, href, the image and geoshape marks, and nested data. A fixed level line takes y: { datum: 80 }, and x: null under a shared x, or it draws one line per x. Formulas may call only simple functions (format, round, toDate, year and the like). Anything else, and any number people will quote, belongs in the query, so it reads the same in every view. sort: null keeps the query's order. To read well: say the finding in the name or subtitle, with its number, or, on a chart that refreshes, in a text mark worked out from the rows, since typed words go stale; a mid grey plus one accent colour, mid-tones that read on a light and a dark card, more only where they mean something; a target or limit on the chart as a labelled mark; values on the marks or an axis, not both; label only the points the finding rests on; bars start at zero. On a chart that refreshes, keep words and legends off the plot, where a later bar can land on them: a legend with orient "top", a text mark with y: -6 and baseline "bottom". Example: { "width": 720, "height": 320, "encoding": { "x": { "field": "month", "type": "temporal" } }, "layer": [ { "mark": { "type": "bar", "color": "#94a3b8" }, "encoding": { "y": { "field": "orders", "type": "quantitative" } } }, { "mark": { "type": "line", "color": "#3b82f6" }, "encoding": { "y": { "field": "avg_3m", "type": "quantitative" } } }, { "mark": { "type": "rule", "strokeDash": [4, 4] }, "encoding": { "x": null, "y": { "datum": 500 } } } ] }
cellIndexYesThe cell, counting from 0 over all the notebook's cells, markdown ones too.
chartTypeNotable (the default), number, or a chart with its assignments: bar, horizontal_bar, stacked_bar, line, time_series, pie, scatter, waterfall, combo, heatmap, treemap, bubble. line or time_series for a measure over time; bar to compare categories (horizontal_bar for long labels, stacked_bar for the parts of each); pie or treemap for shares of one whole (a pie shows the 7 largest slices and groups the rest as Other); waterfall for steps that add up to a total; combo for two measures on different scales; scatter to relate two measures, bubble for three; heatmap for one measure across two categories.
projectIdYesThe project’s id, from fastero_list_projects.
changeNoteNoFor a Vega-Lite chart: what this change does and why, in a few words. People read it in Chart history.
notebookIdYesA notebook’s id, from fastero_list_notebooks.
assignmentsNoWhich result columns a chart plots, by chart type: bar, horizontal_bar, stacked_bar {category, value_slot_1, value_slot_2...}; line {xAxis, yAxis, optional value_slot_2, value_slot_3...} (a line each); time_series {date, yAxis1, optional yAxis2}; pie {category, value}; scatter {xAxis, yAxis}; waterfall {category, value}; combo {category, bar_value, line_value}; heatmap {xAxis, yAxis, value}; treemap {name, value}; bubble {xAxis, yAxis, size, optional category}; map {latitude, longitude, optional size, category, label}. Values are column names from the query result. Write the query to return one row per point (aggregate in SQL).
dashboardIdNoA dashboard’s id, from fastero_list_dashboards.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / vegaLite / description
      Previous value: -"A Vega-Lite v6 description, only for a chart chartType can't say: several panels, several kinds of mark on one chart, bands, shaded periods, labelled lines, a log or reversed axis, a colour per row, floating bars, side-by-side boxplots. A plain bar, line or pie stays chartType: it is shorter, follows the dashboard's Day/Week/Month switch, and a person can edit it by hand, which nobody can do to this. Rebuild an existing chart this way only when asked for something its type can't do; its old version stays in its history.\nThe rows are the query's, so give no data. Give no config, background, padding, autosize or top-level title: the app decides the look, and the widget's name is the title (title.subtitle stays). About 800 wide in all, in numbers: width 720, height 320. Leave text colours to the theme. Not available: params, selections, url, href, the image and geoshape marks, and nested data. A fixed level line takes y: { datum: 80 }, and x: null under a shared x, or it draws one line per x. Formulas may call only simple functions (format, round, toDate, year and the like). Anything else, and any number people will quote, belongs in the query, so it reads the same in every view. sort: null keeps the query's order.\nTo read well: say the finding in the name or subtitle, with its number, or, on a chart that refreshes, in a text mark worked out from the rows, since typed words go stale; a mid grey plus one accent colour, mid-tones that read on a light and a dark card, more only where they mean something; a target or limit on the chart as a labelled mark; values on the marks or an axis, not both; label only the points the finding rests on; bars start at zero.\nExample: { \"width\": 720, \"height\": 320, \"encoding\": { \"x\": { \"field\": \"month\", \"type\": \"temporal\" } }, \"layer\": [ { \"mark\": { \"type\": \"bar\", \"color\": \"#94a3b8\" }, \"encoding\": { \"y\": { \"field\": \"orders\", \"type\": \"quantitative\" } } }, { \"mark\": { \"type\": \"line\", \"color\": \"#3b82f6\" }, \"encoding\": { \"y\": { \"field\": \"avg_3m\", \"type\": \"quantitative\" } } }, { \"mark\": { \"type\": \"rule\", \"strokeDash\": [4, 4] }, \"encoding\": { \"x\": null, \"y\": { \"datum\": 500 } } } ] }"New value: +"A Vega-Lite v6 description, only for a chart chartType can't say: several panels, several kinds of mark on one chart, bands, shaded periods, labelled lines, a log or reversed axis, a colour per row, floating bars, side-by-side boxplots. A plain bar, line or pie stays chartType: it is shorter, follows the dashboard's Day/Week/Month switch, and a person can edit it by hand, which nobody can do to this. Rebuild an existing chart this way only when asked for something its type can't do; its old version stays in its history.\nThe rows are the query's, so give no data. Give no config, background, padding, autosize or top-level title: the app decides the look, and the widget's name is the title (title.subtitle stays). About 800 wide in all, in numbers: width 720, height 320. Leave text colours to the theme. Not available: params, selections, url, href, the image and geoshape marks, and nested data. A fixed level line takes y: { datum: 80 }, and x: null under a shared x, or it draws one line per x. Formulas may call only simple functions (format, round, toDate, year and the like). Anything else, and any number people will quote, belongs in the query, so it reads the same in every view. sort: null keeps the query's order.\nTo read well: say the finding in the name or subtitle, with its number, or, on a chart that refreshes, in a text mark worked out from the rows, since typed words go stale; a mid grey plus one accent colour, mid-tones that read on a light and a dark card, more only where they mean something; a target or limit on the chart as a labelled mark; values on the marks or an axis, not both; label only the points the finding rests on; bars start at zero. On a chart that refreshes, keep words and legends off the plot, where a later bar can land on them: a legend with orient \"top\", a text mark with y: -6 and baseline \"bottom\".\nExample: { \"width\": 720, \"height\": 320, \"encoding\": { \"x\": { \"field\": \"month\", \"type\": \"temporal\" } }, \"layer\": [ { \"mark\": { \"type\": \"bar\", \"color\": \"#94a3b8\" }, \"encoding\": { \"y\": { \"field\": \"orders\", \"type\": \"quantitative\" } } }, { \"mark\": { \"type\": \"line\", \"color\": \"#3b82f6\" }, \"encoding\": { \"y\": { \"field\": \"avg_3m\", \"type\": \"quantitative\" } } }, { \"mark\": { \"type\": \"rule\", \"strokeDash\": [4, 4] }, \"encoding\": { \"x\": null, \"y\": { \"datum\": 500 } } } ] }"
  2. Changed2 schema fields changed
    • addedInput schema / properties / changeNote
      Added value: +{
      +  "description": "For a Vega-Lite chart: what this change does and why, in a few words. People read it in Chart history.",
      +  "maxLength": 200,
      +  "type": "string"
      +}
    • addedInput schema / properties / vegaLite
      Added value: +{
      +  "description": "A Vega-Lite v6 description, only for a chart chartType can't say: several panels, several kinds of mark on one chart, bands, shaded periods, labelled lines, a log or reversed axis, a colour per row, floating bars, side-by-side boxplots. A plain bar, line or pie stays chartType: it is shorter, follows the dashboard's Day/Week/Month switch, and a person can edit it by hand, which nobody can do to this. Rebuild an existing chart this way only when asked for something its type can't do; its old version stays in its history.\nThe rows are the query's, so give no data. Give no config, background, padding, autosize or top-level title: the app decides the look, and the widget's name is the title (title.subtitle stays). About 800 wide in all, in numbers: width 720, height 320. Leave text colours to the theme. Not available: params, selections, url, href, the image and geoshape marks, and nested data. A fixed level line takes y: { datum: 80 }, and x: null under a shared x, or it draws one line per x. Formulas may call only simple functions (format, round, toDate, year and the like). Anything else, and any number people will quote, belongs in the query, so it reads the same in every view. sort: null keeps the query's order.\nTo read well: say the finding in the name or subtitle, with its number, or, on a chart that refreshes, in a text mark worked out from the rows, since typed words go stale; a mid grey plus one accent colour, mid-tones that read on a light and a dark card, more only where they mean something; a target or limit on the chart as a labelled mark; values on the marks or an axis, not both; label only the points the finding rests on; bars start at zero.\nExample: { \"width\": 720, \"height\": 320, \"encoding\": { \"x\": { \"field\": \"month\", \"type\": \"temporal\" } }, \"layer\": [ { \"mark\": { \"type\": \"bar\", \"color\": \"#94a3b8\" }, \"encoding\": { \"y\": { \"field\": \"orders\", \"type\": \"quantitative\" } } }, { \"mark\": { \"type\": \"line\", \"color\": \"#3b82f6\" }, \"encoding\": { \"y\": { \"field\": \"avg_3m\", \"type\": \"quantitative\" } } }, { \"mark\": { \"type\": \"rule\", \"strokeDash\": [4, 4] }, \"encoding\": { \"x\": null, \"y\": { \"datum\": 500 } } } ] }",
      +  "type": "object"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / assignments / description
      Previous value: -"Which result columns a chart plots, by chart type: bar, horizontal_bar, stacked_bar {category, value_slot_1, value_slot_2...}; line {xAxis, yAxis}; time_series {date, yAxis1, optional yAxis2}; pie {category, value}; scatter {xAxis, yAxis}; waterfall {category, value}; combo {category, bar_value, line_value}; heatmap {xAxis, yAxis, value}; treemap {name, value}; bubble {xAxis, yAxis, size, optional category}; map {latitude, longitude, optional size, category, label}. Values are column names from the query result. Write the query to return one row per point (aggregate in SQL)."New value: +"Which result columns a chart plots, by chart type: bar, horizontal_bar, stacked_bar {category, value_slot_1, value_slot_2...}; line {xAxis, yAxis, optional value_slot_2, value_slot_3...} (a line each); time_series {date, yAxis1, optional yAxis2}; pie {category, value}; scatter {xAxis, yAxis}; waterfall {category, value}; combo {category, bar_value, line_value}; heatmap {xAxis, yAxis, value}; treemap {name, value}; bubble {xAxis, yAxis, size, optional category}; map {latitude, longitude, optional size, category, label}. Values are column names from the query result. Write the query to return one row per point (aggregate in SQL)."
  4. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations declare a non-read-only, non-destructive mutation, and the description adds real context beyond them: the widget tracks the notebook's latest run, so scheduled runs keep it current, and it propagates to dashboards, share links, emails, and pages. It also states the return value (_id and url). It does not say whether re-pinning the same cell creates a duplicate widget or replaces the existing one, which is the main remaining behavioral gap.

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?

Front-loaded with the action and its output, then prerequisites, then index semantics, then return value. Every sentence is relevant, though the cellIndex sentence partially duplicates the schema description and could be trimmed.

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?

For a 9-parameter tool with a nested object and no output schema, the description covers the prerequisite, result-source semantics, index convention, chart-assignment requirement, optional dashboard placement, and the return shape. Minor gaps remain around duplicate-pinning behavior and non-tabular Python cell results, but nothing essential to calling it correctly is missing.

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 coverage is 100%, so the baseline is 3. The description mostly restates schema content (cellIndex counting from 0 including markdown cells; charts need assignments naming plotted columns; table is the default). The one genuine addition is tying cell ordering to 'the order fastero_read_notebook gives them', which helps the agent derive a valid index.

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

Purpose5/5

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

States a specific verb and resource ('Make a dashboard widget from a notebook cell's result') and pins down which cell results qualify (SQL rows, or the last table a Python cell shows, whether from a DataFrame on the last line or via display()). This is clearly distinct from siblings like fastero_save_chart, fastero_show_chart, and fastero_publish_widget_api.

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

Usage Guidelines4/5

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

Gives a concrete prerequisite ('Run the notebook first (fastero_run_notebook) so the cell has a result') and names the related schedule tool. It also explains that dashboardId optionally places the widget on a dashboard too. It never explicitly says when NOT to pin (e.g., versus saving a chart from a query), so it stops just short of full routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.