CrunchJunkie

send_report

E-mail a report once to up to 10 recipients, the same e-mail as "One-time email" on the report's Share panel: a localized subject naming the period, an optional message, a button to the report's share link, sent in the name of the report's creator, with the PDF attached unless attachPdf is false, and logged in the report's send history. An invalid address is refused; none is dropped silently. AI summaries go out as last saved and are never rewritten, so the send spends no AI. Recurring sends are schedule_report. At most 20 assistant-started sends per workspace a day; an identical send repeated the same day is not sent twice. A report in Deleted cannot be sent. Requires MCP write actions; without confirm:true it returns a preview and sends nothing.

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": {
      "reportId": "<reportId>",
      "recipients": "<recipients>"
    },
    "name": "send_report"
  }
}

Input Schema

Name	Required	Description
`confirm`	No	Set true to send. Omit for a preview. With confirm:true, also pass the preview's previewToken.
`message`	No	Optional message shown above the button.
`reportId`	Yes	Report id (from list_reports).
`attachPdf`	No	Attach the PDF (default true). Rendering can take up to two minutes.
`recipients`	Yes	E-mail addresses, 1–10.
`previewToken`	No	With confirm:true: the previewToken from this tool's preview (valid 15 minutes, once, for exactly the previewed arguments).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 24, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

First observedOct 19, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations only say readOnly=false, destructive=false, openWorld=true; the description adds far more: invalid addresses are refused rather than dropped, AI summaries are sent as last saved and never rewritten (no AI spend), a 20-sends-per-day workspace cap, identical same-day sends suppressed, and the Deleted-report block. It does not detail the send-history entry's contents or error codes, which keeps it just short of 5.

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 and the recipient cap, and every sentence carries operational information with no filler. It is, however, a single dense run-on paragraph mixing layout, side effects, quotas, and the confirm gate, which slightly hurts scannability.

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 write-side-effect tool with no output schema, the description covers the preview-token two-step, recipient limits, error refusal behavior, rate limits, dedupe, and the Deleted-state restriction — everything an agent needs to invoke it safely on the first try.

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 schema already documents confirm, previewToken, attachPdf, recipients, and message. The description reinforces meaning in prose ("with the PDF attached unless attachPdf is false," the preview/confirmToken flow) but adds no syntax or format detail beyond the schema, so the 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: "E-mail a report once to up to 10 recipients," and grounds it in a concrete UI equivalent ("the same e-mail as 'One-time email' on the report's Share panel"). It explicitly distinguishes itself from the sibling schedule_report ("Recurring sends are schedule_report").

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 the alternative (schedule_report) for recurring sends, and states the preview/confirm gate: "without confirm:true it returns a preview and sends nothing." It also gives when-not conditions (report in Deleted cannot be sent, daily per-workspace quota, duplicate suppression).

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

All CrunchJunkie tools Inspect

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

Need Help?