CrunchJunkie

add_text_widget

Add a text widget, a free-text block written by the caller, to a report. Deterministic, no AI: the text goes in exactly as given, as HTML (p, br, strong, em, u, s, ul, ol, li, h2–h4, blockquote, a href) or plain text, at most 50,000 characters; scripts, event handlers, javascript: links, frames, images and inline styles other than text-align are removed. Styling is carried by attributes, never inline styles: (text colour), (highlight), , (a tinted box around one block) and (a divider); each is painted with the report theme's own colours in light and dark mode and in the PDF. Goes at the end of the report unless position says otherwise. An existing text block is changed with edit_widget (text). Requires MCP write actions; without confirm:true it returns a preview.

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>",
      "title": "<title>",
      "text": "<text>"
    },
    "name": "add_text_widget"
  }
}

Input Schema

Name	Required	Description
`text`	Yes	The complete body, as HTML or plain text (at most 50,000 characters).
`title`	Yes	The block's title, shown above the text (unless hideTitle).
`width`	No	quarter, third, half, two-thirds or full (default full).
`confirm`	No	Set true to add it. Omit for a preview. With confirm:true, also pass the preview's previewToken.
`anchorId`	No	With position before or after: the id of the widget it goes next to (from get_report). After a section = after everything in that section.
`position`	No	Where the block goes (default end). before and after need anchorId.
`reportId`	Yes	Report id (from list_reports).
`hideTitle`	No	Hide the title in the report (default false).
`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.

Changed1 schema field changedOct 25, 2026
- addedInput schema / properties / text / maxLength
```
Added value: +50000
```

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.7/5.0

Behavior5/5

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

With annotations only declaring readOnlyHint=false and destructiveHint=false, the description carries real weight: it discloses determinism, the 50k cap, an explicit sanitization denylist (scripts, event handlers, javascript: links, frames, images, inline styles), theme-aware rendering in light/dark/PDF, and the preview-then-confirm flow. That is exactly the sort of mutation-side-effect context annotations cannot express.

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 purpose, then rendering rules, then placement, then alternatives — a sensible order. The inline enumeration of every data-attribute and HTML tag is dense and reads like documentation reference rather than selection guidance, which bloat is the only thing keeping it from a 5.

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?

For a 9-parameter mutation tool with no output schema, the description covers sanitization, placement, permissions, preview semantics and the edit alternative — nearly everything needed to call it safely. It does not say what a successful call returns (widget id?), which is a minor residual gap given no output schema exists.

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; the description earns more by explaining the `text` value's accepted HTML vocabulary and the sanitization model, which the schema only gestures at with 'as HTML or plain text'. The preview/confirm coupling is restated rather than expanded, so it stops short of a 5.

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 ('Add a text widget... to a report') and immediately qualifies it as a caller-authored free-text block with no AI generation, which separates it from the generic add_widget sibling. An agent knows exactly what this creates without opening the 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?

Names the alternative explicitly: 'An existing text block is changed with edit_widget (`text`)', which is the key routing decision between this tool and its nearest sibling. It also states the default placement behavior ('Goes at the end of the report unless `position` says otherwise') and the write-permission requirement, leaving little to inference.

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?