Skip to main content
Glama
Sign In

Rollstack

by com.rollstack
OverviewDiscussionsAdmin

Get email settings

getReportEmailConfig
Read-onlyIdempotent

Who a report's email goes to and how it is sent, for a report of any type. Answers 404 until its email is set up, as on a burst's variant that sends no email of its own. For a burst, read listBurstVariants, which has every variant's recipients, and listBurstEmailConfigs rather than calling this on each variant. On an older report that sends to several recipient groups, to, cc, bcc and replyTo list every group's addresses together.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "params": "<params>"
    },
    "name": "getReportEmailConfig"
  }
}

Input Schema

NameRequiredDescriptionDefault
paramsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / params / properties / id / description
      Previous value: -"The report to act on, by its `id` from `listReports` or `createReport`. Only reports whose `type` is `SlideDeck` work here: another type, such as a Google Slides presentation, returns `400`. You can also copy it from the report's link in Rollstack: it's the part right after `/slides/`."New value: +"The report to act on, of any `type`, by its `id` from `listReports` or `createReport`. You can also copy it from the report's link in Rollstack (`appUrl`): it's the part right after `/slides/` or `/destinations/`."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds failure behavior — a 404 until email is configured, including the burst-variant case where nothing is sent — plus the flattening semantics on legacy multi-group reports. It stops short of describing auth requirements or the full returned payload, but the added context is substantial.

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?

Three sentences, front-loaded with the purpose, then the failure mode, then the sibling routing. Every sentence carries information, though the variant/legacy-report clauses pack several ideas together and could be split for faster scanning.

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?

With no output schema, the description does the work of naming the fields that come back (`to`, `cc`, `bcc`, `replyTo`) and how they aggregate across recipient groups, which is the main ambiguity for a config-read tool. Other possible return fields (subject, sending options) go unmentioned, leaving a modest gap.

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?

The single `id` parameter is well documented in the schema (listReports/createReport source, copy-from-appUrl trick), so the description's 'a report of any type' only reinforces that any report type is accepted. It adds little syntax or format detail beyond the schema, which is the baseline for a one-parameter tool.

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 statement of what is returned: the recipients and sending method of a report's email, scoped to 'a report of any type'. That distinguishes it immediately from the burst-scoped siblings it names, so an agent can pick the right tool 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?

Explicitly routes the agent away from this tool for bursts, naming both `listBurstVariants` (all variants' recipients) and `listBurstEmailConfigs`, and explains the reason ('rather than calling this on each variant'). It also gives the precondition — 404 until email is set up — so the agent knows when this call is the wrong one.

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

All Rollstack 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