CrunchJunkie

create_report

Create a new report for a client. It can be pre-filled from one or more connected data sources' standard templates (e.g. "Google Ads", "Meta", "GA4"), including "All channels", a blended cross-channel section available with at least two paid ad accounts. add_widget and edit_widget refine it afterwards. Requires MCP write actions to be enabled for the workspace; without confirm:true it returns a preview and creates 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": {
      "clientId": "<clientId>",
      "name": "<name>"
    },
    "name": "create_report"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Name for the new report.
`confirm`	No	Set true to actually create it. Omit or false to preview what would be created. With confirm:true, also pass the preview's previewToken.
`clientId`	Yes	Client id (from list_clients).
`language`	No	Report language (labels, week names like KW, number and € formatting). Default: the workspace language.
`template`	No	Optional connected source to pre-fill from, e.g. "Google Ads", "Meta", "GA4", "All channels" — or a comma-separated list, e.g. "All channels, Google Ads, Reddit Ads, ChatGPT Ads" (the blend then covers exactly the paid platforms named), optionally with a date preset such as "last_month" or "custom_YYYY-MM-DD_YYYY-MM-DD". Omit for a blank report.
`templates`	No	Several templates in order, one section each, e.g. ["All channels", "Google Ads", "Meta"]. Replaces `template` for a multi-source report.
`datePreset`	No	Report date range. Default "last30days". E.g. "last_month", "this_quarter", "quarter_to_date", "last_quarter", "year_to_date", "last_7_days", "last_90_days", "last_12_months", or "custom_YYYY-MM-DD_YYYY-MM-DD".
`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
```

Changed1 schema field changedOct 22, 2026

changedInput schema / properties / templates / description

Previous value: -"Several templates in order, one section each, e.g. [\"All channels\", \"Google Ads\", \"Meta\"]. Use instead of `template` for a multi-source report."New value: +"Several templates in order, one section each, e.g. [\"All channels\", \"Google Ads\", \"Meta\"]. Replaces `template` for a multi-source report."

First observedOct 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds the high-value behavior the agent actually needs: without confirm:true it returns a preview and creates nothing, write actions must be enabled for the workspace, the blended 'All channels' section requires at least two paid ad accounts, and add_widget/edit_widget refine the result afterward. These are real operational constraints not present in 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the purpose, then capability, then the alternative/routing sentence, then the safety guardrail. Every sentence carries information an agent needs; nothing is padding.

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?

Covers the tricky part of this tool well: the preview-then-confirm lifecycle and permission prerequisite. With no output schema, it explains the preview return but says nothing about what a successful creation returns (e.g. a report id), which an agent may need to chain into get_report or add_widget.

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 the baseline is 3, but the description adds a genuine constraint absent from the schema: the blended cross-channel section is only available with at least two paid ad accounts. It also reinforces the confirm/preview contract in narrative form, though it repeats some template examples the schema already enumerates.

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+resource ('Create a new report for a client') and immediately scopes it against siblings by naming add_widget/edit_widget as the follow-up path and by explaining the template pre-fill capability. An agent can distinguish this from get_report, update_report_settings, schedule_report, and send_report without opening any schema.

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

Usage Guidelines4/5

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

Gives a clear creation context, a stated prerequisite ('Requires MCP write actions to be enabled for the workspace'), and routes post-creation edits to add_widget/edit_widget. It stops short of explicitly stating when NOT to use it (e.g. for existing reports use update_report_settings, for distribution use send_report), so it doesn't reach a full 5.

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?