Is squirrelscan MCP server safe?

Findings (2)

• highWrite-action tools reachable without authenticationauth.open-write
• lowUnusually long tool description (over 2,000 characters)poison.long-description

  tool get_report: …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 them (`affectedPagesHasMore` when clipped), so read "affects N pages" from the count, not the row total. Each row also 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.…