Skip to main content
Glama
Sign In

CrunchJunkie

by io.crunchjunkie.app
OverviewDiscussionsAdmin

create_share_link

Destructive

Create, change or revoke a report's share link. create makes the link or keeps the existing one and applies the settings given; update changes it; revoke deletes it so its URL stops working for good (a later create gives a new URL). Settings: enabled (false keeps the link, viewers see "not available"), password (at least 8 characters; sets or replaces; null removes; stored hashed, never returned), allowDateChange (true lets viewers pick other periods and see data beyond the report's own range). Anyone with the link can open the report with every widget, its live numbers and the saved AI summaries, after the password if one is set. A report in Deleted cannot be shared. Returns the share URL. It does not e-mail the link (send_report does). Requires MCP write actions; without confirm:true it returns a preview of what becomes public.

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>",
      "action": "<action>"
    },
    "name": "create_share_link"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYescreate (or keep) the link, update its settings, or revoke it.
confirmNoSet true to apply. Omit for a preview. With confirm:true, also pass the preview's previewToken.
enabledNoWhether the link opens the report.
passwordNoSet a password viewers enter (at least 8 characters); null removes it. Not echoed back.
reportIdYesReport id (from list_reports).
previewTokenNoWith confirm:true: the previewToken from this tool's preview (valid 15 minutes, once, for exactly the previewed arguments).
allowDateChangeNoLet viewers switch the report's period.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / password / anyOf
      Previous value: -[
-  {
-    "maxLength": 200,
-    "minLength": 1,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 200,
+    "minLength": 8,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / password / description
      Previous value: -"Set a password viewers enter; null removes it. Not echoed back."New value: +"Set a password viewers enter (at least 8 characters); null removes it. Not echoed back."
  2. Changed2 schema fields changed
    • 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
  3. Changed1 schema field changed
    • changedInput schema / properties / password / description
      Previous value: -"Set a password viewers must enter; null removes it. Never echoed back."New value: +"Set a password viewers enter; null removes it. Not echoed back."
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Although annotations already declare destructiveHint=true, the description adds substantial context beyond them: revoke kills the URL 'for good' and a later create yields a new URL, passwords are stored hashed and never returned, enabled=false keeps the link but viewers see 'not available,' and without confirm:true the call only returns a preview of what becomes public. It also discloses the security implication that anyone with the link sees every widget, live numbers, and saved AI summaries.

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?

It is front-loaded with the action model and then the settings, and nearly every clause carries behavioral information that would otherwise be guessed wrong. It is dense to the point of being a single long block, so a bulleted or line-per-setting layout would read faster, but no sentence is filler.

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 destructive, multi-action mutation tool with no output schema, the description covers preconditions, side effects, return value ('Returns the share URL'), credential handling, the preview/confirm safety flow, and the sibling it is not. Nothing an agent needs to call it safely and correctly is missing.

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 real meaning beyond the schema for several parameters: the consequence of enabled=false, that allowDateChange exposes data beyond the report's own range, and that password null removes rather than blanks the credential. It does not, however, explain confirm/previewToken lifecycle beyond what the schema's own descriptions already say.

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?

The description opens with a specific verb set and resource: 'Create, change or revoke a report's share link,' and immediately decomposes the three actions (create/update/revoke) so the agent knows exactly which operation maps to which enum value. It also distinguishes itself from the sibling that handles distribution by stating 'It does not e-mail the link (send_report does).'

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?

It gives explicit when-to-use guidance per action, names the alternative tool for emailing (send_report), states a hard precondition ('A report in Deleted cannot be shared'), and explains the preview-then-confirm workflow. There is no meaningful ambiguity about which action or which tool to pick.

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

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