Skip to main content
Glama
Sign In

Fastero

by com.fastero
OverviewDiscussionsAdmin

Schedule dashboard email

fastero_schedule_dashboard_email
Destructive

Email a dashboard on a timetable to members of this organisation. Each run runs every query widget's query fresh (a widget pinned from a notebook cell shows its notebook's latest run, so schedule the notebook before the email) and emails each recipient the dashboard itself (its number cards, up to twelve charts as pictures, and each table's first ten rows) and a short summary, with a PDF of the whole dashboard attached and a button that opens the dashboard in Fastero after signing in. No public link is made; fastero_share_dashboard is the tool that publishes one. Recipients must be members of the organisation, up to 20, and an address outside it is refused: only a person can add one, in the Fastero app. Each recipient can stop this one report from a link in the email (only they can start it again); with no emails it goes to you. The cadence is at most once an hour, in the timezone given. Asking again for the same dashboard updates the timetable and recipients rather than adding a second schedule. If a run fails, only you are told. Given slackChannel, each run also posts the dashboard's name, a link to it and its charts as pictures to that channel of the organisation's Slack (no PDF), and it posts even when no recipient gets the email. Returns scheduleId, cadence, timezone, nextRunAt, recipients, slackChannel (the channel's id, when it posts to Slack) and created (false when it updated your existing schedule). fastero_set_schedule_enabled switches it off. Owners, admins and editors of the project can schedule one.

Input Schema

NameRequiredDescriptionDefault
emailsNoUp to 20 addresses, each belonging to a member of the organisation.
cadenceYesFive-field cron (minute hour day-of-month month day-of-week), at most once an hour, read in `timezone`. '0 9 * * 1' is 09:00 every Monday; '0 8 1 * *' is 08:00 on the 1st of each month.
timezoneYesIANA timezone the cadence is read in, e.g. 'Europe/Berlin' or 'America/New_York'.
projectIdYesThe project’s id, from fastero_list_projects.
dashboardIdYesA dashboard’s id, from fastero_list_dashboards.
slackChannelNoA Slack channel to post the dashboard's charts as pictures to as well, by name ('#metrics') or id. Slack must be connected to the organisation and Fastero in the channel: if it is not, the call is refused and says so, and someone types /invite @Fastero in the channel. Left out, the schedule keeps the channel it has; an empty string stops posting to Slack.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / slackChannel
      Added value: +{
+  "description": "A Slack channel to post the dashboard's charts as pictures to as well, by name ('#metrics') or id. Slack must be connected to the organisation and Fastero in the channel: if it is not, the call is refused and says so, and someone types /invite @Fastero in the channel. Left out, the schedule keeps the channel it has; an empty string stops posting to Slack.",
+  "type": "string"
+}
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

Discloses far beyond annotations: fresh query widget runs, notebook pinning caveat, exactly what the email contains (number cards, up to 12 charts, first 10 table rows, PDF, sign-in button), recipient unsubscribe behavior, failure notification routing ('only you are told'), hourly rate limit, Slack posting behavior including posting even with no email recipients, and the idempotent update-instead-of-duplicate behavior which is consistent with destructiveHint=true. No contradictions.

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 core action in the first sentence, and every sentence carries distinct information. It is dense and run-on, with several behavioral clauses stacked into long sentences, which costs it a point but no sentence is truly wasted.

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?

For a mutation/upsert scheduling tool with no output schema, the description enumerates returned fields (scheduleId, cadence, timezone, nextRunAt, recipients, slackChannel, created) and covers permissions, failure modes, Slack connection prerequisite, and rate limits. Nothing an agent needs 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.

Parameters5/5

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

Schema coverage is already 100%, but the description adds real semantics: 'at most once an hour, in the timezone given', 'with no emails it goes to you', and the slackChannel empty-string-vs-omitted distinction ('Left out, the schedule keeps the channel it has; an empty string stops posting to Slack'). That is genuine meaning beyond 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?

States a specific verb (email/schedule) and resource (dashboard) with exact scope, and explicitly contrasts itself with fastero_share_dashboard ('No public link is made; fastero_share_dashboard is the tool that publishes one') and fastero_set_schedule_enabled. An agent can distinguish it from all siblings without opening schemas.

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?

Explicitly names alternatives (share_dashboard for public links, set_schedule_enabled to disable), states prerequisites (recipients must be org members, max 20, owners/admins/editors can schedule), and explains the upsert semantics of re-calling for the same dashboard. When-to-use and when-not-to-use are both covered.

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