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. 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).

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark the tool as read-only and non-destructive, so the description adds rich behavioral context beyond that: provenance semantics for carried vs unrendered findings, seedRedirect safety warnings ('display-only, never fetch or trust it'), the meaning of mixedProvenanceNotes, and the fact that the open count from list_issues is a deduped tracker count rather than this report's issue count. This is substantial disclosure of behavior an agent must know.

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?

The description is long, but it covers a genuinely complex return shape and many edge cases, and each sentence contributes real operational guidance. It is front-loaded with the main purpose and report formats. It could be tightened slightly, but the density is justified by the absence of an output schema.

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, the description must explain the return values, and it does so thoroughly: summary structure, health score, top issues, provenance, seedRedirect, history, and llm/markdown variants. It also explains behavioral equivalences with sibling tools and provides the needed caveats for interpreting report numbers. Nothing critical is missing for an agent to select and invoke this tool correctly.

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 each parameter has a schema description, so the baseline is 3. The tool description adds meaningful semantic value beyond the schema by elaborating what each format returns, how run_id relates to completion state, and that top_issue_limit applies to summary only. This lifts it above baseline but it does not exhaustively redefine the parameters.

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 object: 'Fetch the finished report for an audit run,' clearly identifying what the tool does and its core resource. It also distinguishes itself from siblings like get_audit_status, list_audits, and list_issues by positioning itself as the detailed source of truth for a run's numbers.

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: call it after get_audit_status shows completed, using the run_id from run_audit. It contrasts get_report with list_audits/get_audit_status on numeric equivalence, explains when to choose summary vs llm vs markdown, and even shows how to walk backwards through history with list_audits. Alternatives and conditions are both explicit.

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