CrunchJunkie

set_site_audit_issue_status

Mute or ignore an SEO audit issue for a client — the whole issue type, or one page of it with url — with a reason the team can read (required), or make it active again (status active). Muting hides it from lists, Fix first and the Signals, never from a score. 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": {
      "clientId": "<clientId>",
      "issueId": "<issueId>",
      "status": "<status>"
    },
    "name": "set_site_audit_issue_status"
  }
}

Input Schema

Name	Required	Description
`url`	No	Only this page of the issue (as list_site_audit_pages lists it). Omit for the whole issue type.
`reason`	No	Why (required for muted / ignored, at least 3 characters).
`status`	Yes	muted / ignored (with a reason), or active to undo a mute.
`confirm`	No	true saves. Omit to preview. With confirm:true, also pass the preview's previewToken.
`issueId`	Yes	Issue id (from list_site_audit_issues).
`clientId`	Yes	Client id (from list_clients).
`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.

AddedNov 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well past the annotations by explaining the actual effect of a mute — hidden from lists, Fix first and the Signals, but never from a score — and by spelling out the preview-then-confirm flow, including that the previewToken is valid 15 minutes, single-use, and bound to the exact previewed arguments. That is exactly the kind of write-safety context annotations cannot convey on their own.

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 action and its two scopes, then effects, then the confirm caveat — a sensible ordering with almost no filler. Some clauses are telegraphic ('never from a score'), which costs a little immediate readability.

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 7-parameter mutation with no output schema, it covers what an agent needs to call it correctly: required reason, scope selection, undo path, and the two-step preview requirement. The remaining gap is the unexplained muted-versus-ignored semantic difference.

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 already 100%, yet the description still adds meaning: the reason must be human-readable for the team, 'status active' is framed as an undo, and 'confirm' is framed as preview versus save. It does not, however, distinguish 'muted' from 'ignored', which the enum presents as separate states.

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?

Names specific verbs (mute, ignore, make active) and the resource (SEO audit issue) plus its two scopes — whole issue type or a single page via 'url'. This is clearly distinct from read siblings like list_site_audit_issues and get_site_audit_issue.

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?

States the operational conditions well: use 'active' to undo a mute, supply 'url' for a single page, omit it for the whole issue type, and expect a preview unless 'confirm:true'. It never names a sibling alternative (e.g. create_site_audit_task or resolve_signal) for the 'this isn't really a mute' case, so routing among tools is only implicit.

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?