Skip to main content
Glama
Sign In

Fastero

by com.fastero
OverviewDiscussionsAdmin

Publish widget as API

fastero_publish_widget_api
Destructive

Publish a widget's rows as a private web address another app or agent calls, read-only, without the database password: for a script or service that needs the numbers outside Fastero. For people to look at, fastero_share_dashboard publishes a dashboard's link instead. Only a query, spreadsheet or notebook-cell widget can be published (fastero_list_reports lists the widgets), and one already published is refused, with its address. A request to it carries the header X-Endpoint-Key: , and it answers { rows, lastUpdated, truncated }: rows at most five minutes old for a query widget; a spreadsheet widget's are its stored rows, and a notebook-cell widget's those of its notebook's last run, lastUpdated saying when. Anyone holding the key can read the rows until it is turned off (fastero_unpublish_widget_api). The organisation's owners are emailed about every publish. Returns widgetId, name, url, key, publishedAt and howToCall, a curl command; the key is in this answer only, since Fastero keeps just its hash. Owners, admins and editors of the project can publish.

Input Schema

NameRequiredDescriptionDefault
widgetIdYesA query, spreadsheet or notebook-cell widget of the project (fastero_list_reports lists them, as reports).
projectIdYesThe project’s id, from fastero_list_projects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / 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. Added

TDQS

A4.6/5.0
Behavior5/5

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

Well beyond the annotations: it discloses the response shape ({rows, lastUpdated, truncated}), the X-Endpoint-Key auth header, data-freshness semantics per widget type, that anyone holding the key can read until unpublished, that owners are emailed, and that the key is returned only once because only its hash is stored. These are exactly the non-obvious traits an agent cannot infer from destructiveHint/openWorldHint.

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 purpose and alternative, and nearly every clause carries new information (eligibility, freshness, key handling, return fields). It is a single dense paragraph with heavy clause-stacking, which slightly hurts scannability for an agent parsing it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A mutating, open-world tool with no output schema; the description compensates by covering permissions, side effects (owner email), response fields, auth mechanics, and the reversibility path via fastero_unpublish_widget_api. Nothing material needed to call 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 description coverage is 100% and both parameters are already documented, including the widget-type constraint and the fastero_list_projects pointer for projectId. The description repeats the widget-type rule but adds no new parameter-level meaning, so baseline 3 applies.

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 ('Publish a widget's rows as a private web address') plus the key scope qualifier ('read-only, without the database password'). It explicitly distinguishes itself from fastero_share_dashboard and fastero_unpublish_widget_api, so an agent can route correctly without opening either schema.

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

Usage Guidelines5/5

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

Gives the use case (a script or service needing the numbers outside Fastero), names the alternative and the condition selecting it (fastero_share_dashboard for people to look at), and states eligibility rules: only query, spreadsheet or notebook-cell widgets, and already-published ones are refused. Also names who may call it (owners, admins, editors).

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