Skip to main content
Glama

get_grounding_result

Read-onlyIdempotent
Read the result of a content grounding scan started by check_content_grounding — the poll companion to it.

When to use: check_content_grounding returned status="running" (its ~20s inline wait elapsed before the scan finished). Poll this with the **scan_id** it gave you, roughly every 15-30 seconds; a fresh scan usually completes within 120-150 seconds. Do NOT call check_content_grounding again — that starts a second scan and charges again.

Which id to pass:
- `scan_id` — reads that exact scan. This is what you want when polling: it always reports the run you started, whatever its status.
- `content_id` (no scan_id) — reads the latest COMPLETED grounding for that document. Use it to ask "what is this document's grounding state right now" without starting a scan. It deliberately skips a scan that is still running, so it is NOT the right call for polling — you would get the previous result back marked complete.

It never starts a scan and never charges credits — it returns immediately with whatever the current state is.

The response envelope is identical to check_content_grounding's, so the same handling works for both.

Errors:
- Provide 'scan_id' or 'content_id' (400) — one of them is required.
- Not a valid UUID (400) — malformed scan_id or content_id.
- Scan not found (404) — no such grounding scan in your team.
- Content not found (404) — no such content in your team.
- scan_id and content_id refer to different content (400) — pass scan_id alone.

**Links:** present `link_url` to the user exactly as returned — copy it 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": "get_grounding_result"
  }
}

Input Schema

NameRequiredDescriptionDefault
scan_idNoThe scan id returned by check_content_grounding. Pass this when polling — it reads the exact run you started, whatever its status. Either scan_id or content_id is required.
content_idNoThe content id returned by check_content_grounding. Passed alone, it reads the latest COMPLETED grounding for that document and skips any scan still running — so use scan_id, not this, when polling. Either scan_id or content_id is required.

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 already declare readOnly/idempotent/non-destructive, and the description still adds substantive behavior: it never starts a scan, never charges credits, returns immediately with current state, mirrors check_content_grounding's response envelope, and enumerates four specific error conditions with status codes.

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 purpose and when-to-use, then bulleted id guidance and an error list — easy to scan. There is mild redundancy between the 'Which id to pass' bullets, the schema descriptions, and the last error line about passing scan_id alone.

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-param read tool with an output schema and full annotation coverage, the description covers selection, timing, cost implications, error cases, and a link-handling instruction; nothing material 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% and the property descriptions already carry most of the semantics, so the description is largely restating them; it does add the decision framing of when scan_id vs. content_id matters operationally (polling vs. current-state lookup) and warns that content_id can silently return a stale completed result.

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 first sentence states a specific verb and resource ('read the result of a content grounding scan') and explicitly frames the tool as 'the poll companion to' check_content_grounding, so an agent can separate it from that sibling at a glance.

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 the exact triggering condition (check_content_grounding returned status="running"), a polling cadence (~every 15-30s), an expected completion window (120-150s), and an explicit prohibition against re-calling check_content_grounding with the reason (starts a second scan and charges again).

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