Marcora

trigger_health_audit_scan

Destructive

Start a Context Intelligence health audit — a library-wide AI sweep of the team's context/reference items that produces findings (stale content, contradictions, gaps) reviewable via list_ci_findings.

When to use: the user explicitly asks to check/audit their context health ("run a health check on our context", "scan the library"). Do NOT trigger one unprompted — always confirm first.

⚠️ Cost + gating: the scan consumes team Studio Credits and is gated — it requires the Command plan (active subscription) with at least 50 credits remaining, only one health audit can run at a time, and a cooldown applies after each completed run (the error message tells you when it can run again). Starting a new audit CLEARS the previous health-audit findings.

The scan runs in the background; the response returns immediately with a scan_run_id. Findings land as the scan progresses — check list_ci_findings afterwards.

Errors:
- ci_not_eligible (403) — plan/subscription/credits gate failed (JSON error body with reason + credit numbers).
- A health check is already running. Please wait for it to finish.
- Health check ran recently. You can run it again in about {time}.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "trigger_health_audit_scan"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`status`	No	running
`message`	No
`scan_run_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses credit consumption, a plan/credit gating threshold (Command plan, 50 credits), single-concurrency lock, post-run cooldown, and that starting a new audit clears prior findings. It also documents async semantics (returns immediately with scan_run_id) and the specific error codes (ci_not_eligible 403, already-running, cooldown). Nothing material about behavior is left implicit.

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?

Front-loaded with what the tool does, then labeled sections for when-to-use, cost/gating, async behavior, and errors. The length is justified by the destructive, credit-consuming nature of the call; no sentence is filler or repetitive.

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, gated, asynchronous tool, the description covers eligibility, cost, exclusivity, cooldown, side effects on prior findings, and the hand-off to list_ci_findings. An output schema exists, so return-value detail is correctly omitted beyond noting the immediate scan_run_id.

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?

The tool takes zero parameters, so the baseline applies and there is no parameter meaning to add. The description correctly implies a parameterless invocation rather than inventing inputs, but adds no schema-adjacent detail because none exists.

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 ('Start a Context Intelligence health audit'), defines the scope ('library-wide AI sweep of the team's context/reference items'), and names both the output type (stale content, contradictions, gaps) and the sibling that surfaces results (list_ci_findings). This distinguishes it from list_ci_findings and check_content_grounding 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 Guidelines5/5

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

Explicit when-to-use trigger phrases, an explicit prohibition ('Do NOT trigger one unprompted — always confirm first'), and a pointer to the follow-up tool. Both the include and exclude conditions are stated, which is the highest bar.

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

All Marcora 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?