Skip to main content
Glama

squirrelscan

by com.squirrelscan

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 carries provenance: "carried" means the finding is re-injected from a page not re-crawled this run (not a fresh result) — 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. 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. 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 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 when you need every issue and page detail. 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

TableJSON 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. Dates show when Glama detected each change.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and non-destructive behavior, so the description carries the burden of explaining operational nuance. It does so extensively: failure audits carry status keys where null healthScore means crawl failure not a clean site, seedRedirect is display-only and must not be fetched, provenance values distinguish fresh vs carried vs unrendered findings, and the report is the source of truth for run numbers. This far exceeds what annotations alone provide.

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?

Although long, the description front-loads the core purpose in the first sentence and then systematically covers formats, failure modes, provenance, seedRedirect, history, and numeric source-of-truth mappings. Every sentence adds operational value; the length is proportional to the tool's genuine complexity and there is no filler or tautology.

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?

There is no output schema, so the description must fully describe return semantics, and it does: report formats, healthScore/topIssues structure, provenance and lastSeenAt behavior, seedRedirect edge case, failure status keys, history walking, and the relationship to list_audits and list_issues. An agent has everything needed to correctly invoke the tool and interpret its results across normal and exceptional audit outcomes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds meaning well beyond the schema by explaining format semantics ('summary' returns structured JSON with health scores and topIssues, 'llm' is compact and marks carried findings inline, 'markdown' is full human-readable), clarifies that run_id comes from run_audit or list_audits, and explains failure-related fields absent from the schema. The top_issue_limit parameter is already fully described by the schema, so the description appropriately focuses where the schema is thin.

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 description opens with a specific verb and resource: 'Fetch the finished report for an audit run', and immediately disambiguates from siblings by tying it to run_audit and get_audit_status. It clearly distinguishes the report's role from list_audits, get_audit_status, and list_issues, so an agent knows exactly what this tool is for.

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?

The description gives explicit when-to-use guidance: wait until get_audit_status shows completed, use the run_id from run_audit, start with summary then escalate to llm/markdown when more detail is needed, and use list_audits with website_id to page past the history array. It also states which values to compare across runs and warns against using list_issues' open count as the report's issue count, providing clear alternatives and exclusions.

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

All squirrelscan toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool maps to a distinct resource-action pair: websites, audits, issues, rules, credits, notifications, and account info are cleanly separated. Even the close pairs (delete_website vs delete_websites, get_rule vs list_rules) are clear singular/bulk or fetch-all vs fetch-one distinctions.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: add_, delete_, get_, list_, run_, comment_, send_, create_. The only outlier, whoami, is a conventional standalone command and does not break the overall predictability.

Tool Count4/5

At 20 tools, the surface is slightly heavy, but the count is justified by the wide domain coverage: audit lifecycle, issue tracking, rule catalog, billing/credits, notifications, and account management. Each tool appears to earn its place, and none feel redundant.

Completeness4/5

The core workflow is well covered: run an audit, poll it, fetch a report, compare audits, list and comment on issues, browse rules, and manage websites. Minor gaps exist—no cancel-audit tool, no update_website, and issues cannot be status-changed—but agents can work around these using the existing tools.

Resources