CrunchJunkie

suggest_prompts

Read-only

Suggest new AI-visibility tracking prompts for a project, in two steps. Without count it returns plan — how many prompts to add to this project and why, from its active prompts, engines, runs per prompt and trial allowance — and spends nothing; the user picks the number. With count it drafts that many buyer questions grounded in the brand, its competitors, product type, its own scan data (topics where competitors out-rank it) and, with Search Console connected, real Google queries of the last 90 days (sourceQuery, sourceImpressions). approach method (default) follows the CrunchJunkie prompt method: one open question per buyer intent across the buying stages, naming no brand, each with stage, intent and tags; broad is the older mix with competitor and brand questions. Deduped against the tracked prompts. Read-only: add_tracking_prompt adds chosen ones. Not measured AI prompt volume. It spends AI only when it drafts — with count, or with approach broad (one model call on the workspace's own key or Managed AI), counts toward 20 assistant-started scans, briefs and suggestions per workspace per day, and runs without a preview on a paid plan because it changes nothing.

Input Schema

Name	Required	Description
`count`	No	How many prompts to draft (1–20), as the user chose after seeing plan. Omit to get plan only (spends nothing).
`approach`	No	method (default): the CrunchJunkie prompt method. broad: the older mix incl. competitor and brand questions — only when the user asks for it.
`clientId`	No	Client id — uses the AI-Visibility project its Overview opens in the app (the newest).
`keywords`	No	Optional keywords/topics to base suggestions on (comma or newline separated).
`projectId`	No	AI-Visibility project id.

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
```

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / approach

Added value: +{
+  "description": "method (default): the CrunchJunkie prompt method. broad: the older mix incl. competitor and brand questions — only when the user asks for it.",
+  "enum": [
+    "method",
+    "broad"
+  ],
+  "type": "string"
+}

addedInput schema / properties / count

Added value: +{
+  "description": "How many prompts to draft (1–20), as the user chose after seeing plan. Omit to get plan only (spends nothing).",
+  "maximum": 20,
+  "minimum": 1,
+  "type": "integer"
+}

First observedOct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly/destructive annotations: it discloses that no AI is spent without count, that drafting consumes the workspace's own key or Managed AI, that it counts toward a 20/day assistant-started quota, and that it runs without preview on paid plans because it mutates nothing. These are exactly the hidden costs an agent needs before invoking.

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 two-step model and mode selection, then spends on spend/side-effects last. It is long and drifts into a dense run-on near the end, and the fragment 'Not measured AI prompt volume' is unclear, but almost every clause carries decision-relevant information.

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 two-mode, 5-param tool with no output schema and real billing side effects, the description covers mode selection, data sources used for grounding (scan topics, Search Console 90-day queries), dedup behavior, quota impact, and the follow-up tool. Nothing critical to correct invocation 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, and the description adds real meaning: it explains why count is omitted (plan stage), what approach method implies (one open question per buyer intent, no brand naming, stage/intent/tags), and clarifies clientId resolves to the newest project. It doesn't fully restate keywords or the sourceQuery/sourceImpressions fields' format, but covers enough.

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 ('Suggest new AI-visibility tracking prompts for a project') and immediately names the two-step mode split. It is clearly separable from the sibling add_tracking_prompt, which it explicitly delegates the write to.

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 states when to omit count (plan only, spends nothing, user picks the number) versus supply it (draft that many), and when to use approach broad ('only when the user asks for it'). It also names the alternative tool for committing results and notes dedup against tracked prompts.

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?