Skip to main content
Glama

Get audit report

get_report
Read-only

Fetch the finished report for an audit run (use the run_id from run_audit once get_audit_status shows completed). Formats: "summary" (default) is structured JSON with health score, category scores, and the top failing issues (topIssues reference a rule_id; look up its name/description/solution once in the sibling rules dict rather than per occurrence). Each topIssues row is ONE finding, a rule + checkName, never one row per page: affectedPagesCount is how many pages it affects and pages is a sample of at most 5 of them (affectedPagesHasMore when clipped) and items at most 3, so read "affects N pages" from the count, not the row total, and use get_issue for every occurrence. Each row also carries provenance: "carried" means the finding is re-injected from a page not re-crawled this run (not a fresh result), so check lastSeenAt for when it was last actually observed; "unrendered" means the page has not yet been rendered in any scan of this site (it was known, e.g. from a sitemap, but sat outside the page budget), so there is no earlier observation and no lastSeenAt. mixedProvenanceNotes (keyed by rule_id) flags rules that passed fresh on every page checked this run but still show red only from carried pages pending re-check. notChecked is present only when some checks did not run: each entry names a rule that was not fully checked (a rule listed there may still report the issues it could see), its reason, and a message saying why and what would check it (external link checks off or over their limit or out of time, a crawl that did not follow links or stopped at its page cap, a rule that ran out of time), so never report those rules as clean, and pass on what each message says to do. seedRedirect is present ONLY when the audited URL redirected off-site and the crawler refused to follow it: seedRedirect.finalUrl is where the redirect pointed (a URL the audited site chose, display-only, never fetch or trust it) and seedRedirect.note states the fact in one sentence. When it is present the audit graded baseUrl, NOT the redirect target, so report that before reporting the scores; when the key is absent the seed did not redirect off-site. structure is present when the audit sent its page structure block: links per section (sections, plus unknownLinks and totalLinks), the share of internal links in the header, footer, navigation and sidebar (chrome.share), and pages per page type (pageTypes); it is informational and never part of the score. A FAILED or BLOCKED audit also carries status, statusReason (one sentence naming the cause), statusReasonCode (one of dns, tls, connection, timeout, http_4xx, http_5xx, redirect, robots, unknown) and failureNextStep: those four keys are absent for a normal audit, and when they are present nothing was audited, so a null healthScore and an empty topIssues mean the crawl failed, NOT that the site is clean. Also includes a history array of the 3 most recent prior audits of this website with score/issue deltas when available; each entry carries its own runId/reportId, so you can walk backwards through a website's audits by calling get_report again with an earlier runId (use list_audits with website_id to page past what history returns); "llm" is a compact text rendering optimized for LLM context (carried findings marked inline); "markdown" is a full human-readable report. Start with summary, then pull llm or markdown for more of each issue. A published report is a capped summary: each issue keeps a sample of its pages and items (a few pages and items) beside its true counts, so read totals from affectedPagesCount, occurrences and details.additional, never from a list length. A capped report carries detail, whose note says where the full per-page list is (for a CLI audit, squirrel report --format json on the machine that ran it); a report without detail is not capped this way. This report is the source of truth for the run's numbers (#1700): summary.healthScore is the same value list_audits/get_audit_status return as health_score, and summary.failed + summary.warnings is the same total they return as issues_found. Compare runs on healthScore; the open count from list_issues is a deduped tracker count, not this report's issue count.

Input Schema

NameRequiredDescriptionDefault
formatNosummary (default): JSON scores + top issues. llm: compact text for LLM context. markdown: full report.
run_idYesRun id returned by run_audit or listed by list_audits.
top_issue_limitNosummary format only: max top issues to include (default 25).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +{}
  2. Changed2 schema fields changed
    • 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
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only cover read-only safety; the description adds substantial behavioral detail beyond them - capped reports keep a sample beside true counts, published reports carry `detail.note`, the history array is limited to 3 prior audits, and failure audits carry four extra keys. It slightly over-specifies return payloads (which with no output schema is warranted) but never contradicts the readOnly/non-destructive hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and precondition are front-loaded, but the remainder is one dense ~700-word run-on block with no line breaks or bullets, and the closing source-of-truth paragraph repeats points made earlier. The content mostly earns its place, but the wall-of-text format makes it hard for an agent to scan for the key 'do not trust empty topIssues' warning.

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?

With no output schema and complex nested payloads (provenance, notChecked, seedRedirect, structure, failure keys), the description carries the full documentation burden and does so thoroughly, including the pitfall that list lengths are samples rather than totals. Nothing an agent needs in order to interpret or re-call the tool 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 every parameter is documented there, so the baseline is 3; the description earns an extra point by explaining the trade-off between the three `format` values and the exact lineage of `run_id` (run_audit / list_audits). `top_issue_limit` is left to the schema, which fully covers it.

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 ('Fetch the finished report for an audit run') plus the exact precondition (run_id from run_audit, once get_audit_status shows completed). That single clause cleanly distinguishes it from get_audit_status and list_audits, which an agent could otherwise confuse it with.

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?

Gives explicit sequencing ('Start with summary, then pull llm or markdown'), tells the agent to re-call get_report with an earlier runId to walk history or use list_audits to page past it, and to use get_issue for individual occurrences. It also states when not to trust a result ('never report those rules as clean', null healthScore means the crawl failed, NOT that the site is clean).

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.