Skip to main content
Glama

squirrelscan

by com.squirrelscan

Run a cloud audit

run_audit

Run a cloud audit of a website (crawl + 260+ rule analysis + report). Credits are spent as the audit runs (pay-as-you-go). The dry run is optional: pass confirm: true on the first call to start straight away. Without confirm, an audit whose estimate is over the org's auto-run threshold comes back as status "confirmation_required" with the estimate to show the user, and you call again with confirm: true; one at or under the threshold just starts. Use max_pages to size the crawl (max_pages: 1 audits just the entry URL, the cheapest run). Audits are asynchronous and take minutes: poll get_audit_status with the returned run_id, then fetch results with get_report. The website is registered automatically on first audit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesWebsite URL to audit, e.g. https://example.com (scheme optional).
kindNoClassify the site: 'owned' for something the user runs and monitors, 'prospect' for a lead or competitor audited once. Filterable in list_websites so a prospect cleanup can never sweep up a live site. Unclassified sites read as 'owned'. Ignored when ephemeral is true (an ephemeral site never joins the list).
renderNoRender pages in a headless browser (default true). Catches JavaScript-dependent issues; costs extra credits per page.
confirmNoApprove the credit spend. Set true to start immediately. Omitting it returns an estimate first for anything over the auto-run threshold, and starts the audit anyway for anything at or under it.
coverageNoCrawl coverage profile (default fast, 10 pages). Deeper coverage crawls more pages and costs more credits.
ephemeralNoOne-shot check: run the audit and return the report without adding the site to the organization's website list, and without consuming a slot against the plan's website limit. Use for any 'just check this URL' audit the user is not going to monitor. The site is removed automatically once the audit finishes; get_audit_status and get_report keep working on the run_id. Ignored if the domain is already registered, in which case the audit runs against the existing tracked site (nothing is ever deleted) and the response reports ephemeral: false.
max_pagesNoCap the crawl at this many pages for this run. Overrides the coverage profile's page count, so max_pages: 1 audits just the entry URL for the cheapest possible run. A value above the plan's per-audit page ceiling is clamped to the ceiling and reported back in a notice, not rejected.
max_creditsNoSpend guard: refuse to start if the upper-bound estimate exceeds this many credits.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only signal readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds crucial behavioral context: pay-as-you-go credit spend, the dry-run/confirmation flow, asynchronous execution, auto-registration of the website, and the existence of an auto-run threshold. This goes far beyond annotations and gives the agent a clear model of side effects.

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 a single dense paragraph, front-loaded with the core purpose and then explaining the confirmation flow, sizing, async behavior, and auto-registration. Every sentence adds value, though it could be broken into bullets for readability. It earns a 4 rather than a 5 due to moderate length.

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?

Given the tool's complexity (8 params, async, credits, confirmation, auto-registration), the description covers all key operational aspects: cost, confirmation threshold, polling workflow, max_pages sizing, and auto-registration. It also correctly points to sibling tools for follow-up. The lack of an output schema is offset by pointing to get_audit_status and get_report.

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 description coverage is 100%, so the baseline is 3. The description adds workflow-level meaning for confirm (dry-run behavior) and max_pages (cheapest run), which helps the agent understand how parameters interact in practice. It does not add detail for every parameter, but the schema already handles those, and the added semantics justify a 4.

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 clearly states the tool's function: 'Run a cloud audit of a website (crawl + 260+ rule analysis + report).' It uses a specific verb and resource, and distinguishes itself from sibling tools like get_audit_status and get_report by explaining the asynchronous hand-off.

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?

Provides explicit guidance on when to use the tool: how to start immediately with confirm: true, how the confirmation_required flow works, when to poll get_audit_status, and when to use max_pages for sizing. It also implies when not to use it (e.g., for checking progress or results) by naming the appropriate sibling tools.

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