Skip to main content
Glama

check_content_grounding

Destructive

Runs Marcora's content grounding on a piece of content: extracts its factual claims, checks each against the team's context library, and returns which are supported, which conflict with the library, and which are gaps the library can't back up. It checks against the TEAM'S library only, never the open web.

When to use: after drafting or revising marketing content, when the user asks to fact-check, verify or ground a document against their own context ("check this against our context", "is this accurate?"), or as the check step in a draft → ground → revise → re-ground loop.

Three entry modes (supplying neither field is an error):

  • content_id alone: scan an existing content item. Use this to check part of an existing document.

  • content alone: SAVES the markdown as a NEW content item, then scans it. The new content_id comes back. title is optional and only applies here.

  • content_id + content: ⚠️ REPLACES THAT DOCUMENT'S ENTIRE BODY with the markdown you pass (identical to update_content), then re-scans. Send the FULL revised document, NEVER a fragment: the rest of the document would be destroyed.

Timing: a fresh scan typically takes 120-150 seconds. This call waits up to about 20 seconds; if the scan is still running it returns status="running" with a content_id and scan_id. Then POLL get_grounding_result with the scan_id (polling with content_id returns the PREVIOUS completed scan). Do NOT call this tool again for the same scan: it queues redundant work and spends more credits. Re-scanning an unchanged document is fast.

Gating: requires the Command plan with an active subscription and available Studio Credits, and an editor role. Full findings go to the content's creator; others get summary counts only (details_visible=false).

Present link_url exactly as returned.

When title is omitted with content, the name is derived from the first line. Re-scanning an UNCHANGED document takes a few seconds because unchanged claims are reused. The library freshness sweep that runs first is free.

Errors:

  • Provide either 'content_id' or 'content' (400): neither was supplied.

  • Not a valid UUID (400): malformed content_id.

  • Context Intelligence requires the Command plan (403): plan/credits gate failed.

  • You are not authorized to perform this action (403): the token's user lacks an editor role on the team.

Links: copy link_url character for character. Never retype, shorten, or rebuild a link or the IDs inside it.

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": "check_content_grounding"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleNoOptional. Only meaningful alongside content. When omitted the name is derived from the first line of the markdown.
contentNoOptional. Markdown to ground. On its own, it is stored as a NEW document and scanned. ⚠️ DANGER — combined with `content_id`, this REPLACES THE ENTIRE BODY of that document, exactly like update_content. It is a whole-document overwrite, never a fragment check. If you want to check one paragraph or section of an existing document, do NOT pass that fragment here with a content_id — you would destroy the rest of the document. Either pass the FULL revised document, or omit `content` entirely and scan the existing item by content_id alone.
content_idNoOptional. An existing document to scan. Pass it ALONE to scan that document as it currently stands — that is the safe default. Combining it with `content` REPLACES the document's entire body first (see the `content` warning).

Output Schema

NameRequiredDescriptionDefault
claimsNoEvery factual claim extracted from the document, with its verdict. Creator-only.
statusYesrunning = poll get_grounding_result with this scan_id, do not re-scan. none = no scan has been run for this content yet.
messageNoPresent when the scan is still running, or when details are withheld.
scan_idNoThe scan run. Null only if no scan has ever run for this content.
summaryYesClaim counts. Present even when details_visible is false.
findingsNoActionable conflicts and gaps. Creator-only.
link_urlYesOpens the document in Marcora with the grounding panel showing.
content_idYesThe content item that was scanned. In content-submission mode this is the newly created item — keep it for polling and for follow-up calls.
corpus_itemsNoThe context items this scan was actually grounded against, recorded at scan time. Creator-only.
excluded_itemsNoContext items this check did not read. Present only when at least one was skipped. Each entry has id, reason and source. reason is sync_lock (the item was being edited during the check) or library_token_budget (the reference library was larger than one check can read). source is context_item or project_brief. name is included only for the person who ran the check; everyone else, including the content's creator, gets ids only.
coverage_reasonNoWhy the check was incomplete; null when coverage_complete is true. library_catch_up = some context items were still being prepared, so re-run the check shortly. library_extraction_failed = some context items could not be prepared. library_token_budget = the reference library is larger than one check can read.
details_visibleNoFalse when the caller is not the content's creator — findings, claims and corpus_items are then omitted.
coverage_completeNoFalse means some context items were not read, so a claim marked unsupported may still have support in an unread item. True does not by itself mean every context item was read: excluded_items lists any item the check left out, and it can be present even when coverage_complete is true. Before acting on gaps, check coverage_complete, coverage_reason and excluded_items.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / claims / items / properties / support_only_calls
      Added value: +{
      +  "description": "Present only on a supported claim whose every supporting source is a call: the calls it rests on, one entry per call. Absent when any support is not a call, and absent for calls you cannot see. Tell the user such a claim rests only on calls, which are one conversation's word rather than a written source.",
      +  "items": {
      +    "properties": {
      +      "company": {
      +        "description": "The other company on the call, or null.",
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "date": {
      +        "description": "When the call happened (ISO 8601), or null.",
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "kind": {
      +        "description": "Kind of call, or null.",
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      }
      +    },
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description justifies that severity by spelling out exactly what is destroyed (the document's ENTIRE body is replaced, identical to update_content) and which unsafe pattern to avoid (passing a fragment with a content_id). It adds non-annotation context an agent cannot infer elsewhere: 120-150s scan time vs. ~20s wait, polling semantics, credit consumption, redundant-queue cost, plan/credits/editor-role gating, and that non-creators see only summary counts (details_visible=false).

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?

Well front-loaded with headed sections (When to use, Timing, Gating, Errors, Links) and bolded warnings that survive skimming. There is minor duplication: the re-scan-of-unchanged-document speed point appears twice, and link_url handling is stated in both the Gating paragraph and a trailing Links section.

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?

An output schema exists, so return values need not be enumerated, and the description still covers the operational gaps that matter: async polling path, timing expectations, error-to-status-code mapping, and auth/plan prerequisites. For a destructive, gated, long-running mutation tool, nothing an agent needs before calling 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 genuine meaning at the combination level rather than per-field: it lays out three entry modes and states that supplying neither field is an error. It also clarifies that `title` only applies in the create mode and how the name is derived when omitted, which the individual schema properties do not frame as a mode matrix.

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 ('Runs Marcora's content grounding on a piece of content') and then defines the operation concretely: extract claims, check against the team's context library, return supported/conflicting/gaps. It also draws a hard boundary ('TEAM'S library only, never the open web') that separates it from any open-web verification sibling.

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?

Provides an explicit 'When to use' block with trigger phrases ('check this against our context', 'is this accurate?') and positions itself inside a draft → ground → revise → re-ground loop. It also names the required follow-up tool (get_grounding_result) and warns against re-calling this tool for the same scan, which is exactly the alternative routing an agent needs.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources