Skip to main content
Glama
Sign In

Fastero

by com.fastero
OverviewDiscussionsAdmin

Create page

fastero_create_page

Publish an HTML dashboard page to a project, where every member opens it with live numbers. A page is one HTML document that runs sealed off in a member's browser. It reads a widget's live rows with const { rows, lastUpdated, truncated } = await fastero.data("<name>"), being one of the names given in widgets, and redraws when fastero.onRefresh(fn) calls fn. It may load libraries only from https://cdnjs.cloudflare.com or https://cdn.jsdelivr.net; every other request, fetch and XHR included, is blocked. A link cannot leave the frame: fastero.open({ dashboard: "<dashboardId>" }) opens one of the dashboards of the project for the person reading. Read the numbers rather than writing them into the page, so it stays current. Lay it out to fit from about 600px wide, a card in Claude's chat, to a full screen in Fastero: let tiles wrap, and give flex items that hold charts min-width: 0. Returns the page without its HTML, with url, the page's address. fastero_show_page shows it in the conversation.

Input Schema

NameRequiredDescriptionDefault
htmlYesThe whole HTML document, at most 2 MB.
nameYesThe page’s name, as members see it; at most 200 characters.
widgetsYesThe widgets the page may read, each under the name its code asks for: widgets of this project of type query, file or notebook (fastero_list_reports lists them). One of type integration is refused; a text block, though of type file, is accepted and gives the page no rows.
projectIdYesThe project’s id, from fastero_list_projects.
noteEnabledNoFastero writes a short AI note about the page's numbers above it. false turns it off, for a page with text of its own.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / widgets / description
      Previous value: -"The widgets the page may read, each under the name its code asks for: widgets of this project of type query or file (fastero_list_reports lists them). One of type notebook or integration is refused; a text block, though of type file, is accepted and gives the page no rows."New value: +"The widgets the page may read, each under the name its code asks for: widgets of this project of type query, file or notebook (fastero_list_reports lists them). One of type integration is refused; a text block, though of type file, is accepted and gives the page no rows."
    • changedInput schema / properties / widgets / items / properties / widgetId / description
      Previous value: -"A query or spreadsheet widget of the project (fastero_list_reports lists them, as reports)."New value: +"A query, spreadsheet or notebook-cell widget of the project (fastero_list_reports lists them, as reports)."
  2. Changed2 schema fields changed
    • addedInput schema / properties / name / description
      Added value: +"The page’s name, as members see it; at most 200 characters."
    • changedInput schema / properties / widgets / description
      Previous value: -"The widgets the page may read, each under the name its code asks for. Each must be a spreadsheet or query widget of the same project (fastero_list_reports lists them)."New value: +"The widgets the page may read, each under the name its code asks for: widgets of this project of type query or file (fastero_list_reports lists them). One of type notebook or integration is refused; a text block, though of type file, is accepted and gives the page no rows."
  3. Changed2 schema fields changed
    • addedInput schema / properties / projectId / description
      Added value: +"The project’s id, from fastero_list_projects."
    • addedInput schema / properties / widgets / items / properties / widgetId / description
      Added value: +"A query or spreadsheet widget of the project (fastero_list_reports lists them, as reports)."
  4. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Goes well past the annotations (readOnlyHint=false, destructiveHint=false): it documents the sandbox contract (CDN allowlist of cdnjs.cloudflare.com and cdn.jsdelivr.net, all other fetches/XHR blocked), the in-page runtime API (fastero.data, fastero.onRefresh, fastero.open), and the return value ('the page without its HTML, with url'). That is substantial behavioral context an agent cannot get from the structured fields.

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?

Purpose and return value are front-loaded and the paragraph is dense with non-redundant detail. A few clauses (the min-width: 0 / tile-wrapping layout tip, the open({dashboard}) aside) sit closer to authoring advice than tool selection, so it is busy but not padded.

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?

No output schema exists, and the description compensates by stating what is returned (page object without HTML, plus url) and how to surface it (fastero_show_page). With 5 parameters and thin annotations, the remaining gap is edit/overwrite and failure behavior — e.g., what happens if the name already exists or when the excluded 'integration' widget type is supplied (the latter is only covered in the schema).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, and the description earns an extra point by explaining the coupling between the `widgets` parameter and page code — `<name>` in `fastero.data("<name>")` must match a name given in widgets. The layout advice ('fit from about 600px wide... give flex items that hold charts min-width: 0') also adds meaning about expected HTML content beyond the 2 MB limit in the schema.

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?

Opens with a specific verb and resource: 'Publish an HTML dashboard page to a project,' then defines what a page is ('one HTML document that runs sealed off in a member's browser'), which separates it from fastero_create_dashboard and fastero_create_streamlit_app without naming them. An agent knows exactly what artifact this produces.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: it asserts the page should 'read the numbers rather than writing them into the page' and points to fastero_show_page for displaying the result. It never says when to choose a page over a dashboard, streamlit app, or report, nor what prerequisites or naming/overwrite behavior apply, so the agent must infer tool selection.

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

All Fastero toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources