Prospairrow Websites MCP
PassAudited by ClawScan on May 10, 2026.
Overview
This skill appears purpose-aligned for Prospairrow prospecting, but it needs an API key and can run opt-in write actions through a local MCP server.
This skill looks reasonable for connecting an agent to Prospairrow, but install it only if you are comfortable running a local MCP server with your Prospairrow API key. Start in read-only mode unless you intentionally need writes, keep the API key scoped and private, and remember that installation fetches npm/Playwright components despite one document overstating the supply-chain safety.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If write mode is enabled, the agent can add or enrich prospects and generate Prospairrow-side outputs without a separate confirmation shown in these artifacts.
The skill exposes account-mutating Prospairrow tasks, but labels them as WRITE and requires a separate write-enabled runtime mode.
- `apollo_enrich` (WRITE) - `add_prospects` (WRITE) - `enrich_prospects` (WRITE) ... - WRITE tasks require write-enabled runtime mode.
Run the read-only mode by default and enable `npm run mcp:writes` only for sessions where you intentionally want the agent to modify Prospairrow data.
Anyone or anything that can invoke the local MCP server while it has access to the API key may be able to run authorized Prospairrow tasks.
The runtime can use a Prospairrow credential from headers, environment, or optional OpenClaw config; this is expected for the service but grants account authority.
API key resolution order 1. Request headers (`Authorization` / `X-API-Key`) 2. Process env fallback: `PROSPAIRROW_API_KEY` 3. Optional OpenClaw skill config (disabled by default; set `WEBSITES_ALLOW_OPENCLAW_CONFIG_API_KEY=1`)
Use the least-privileged API key available, avoid leaving write mode running unattended, and keep `WEBSITES_ALLOW_OPENCLAW_CONFIG_API_KEY` off unless you need config-file credential fallback.
Saved browser storage state may contain session cookies or tokens for supported sites.
Browser login state can be persisted locally as a sensitive auth artifact, with restrictive file permissions and a documented disable flag.
const STORAGE_MODE = 0o600; ... await fs.writeFile(filePath, JSON.stringify(storageState, null, 2), "utf-8"); await fs.chmod(filePath, STORAGE_MODE);
Only use `websites.bootstrap_login` when needed, delete stored auth files when no longer needed, and set `WEBSITES_DISABLE_STORAGE_STATE_WRITE=1` if you do not want session state saved.
Installing the runtime can fetch third-party code and browser binaries from outside the skill package.
The install path is disclosed and user-directed, but it still depends on external package/browser downloads.
Install copies repository source locally and runs `npm install --ignore-scripts` to fetch npm dependencies (including Playwright, which downloads browser binaries on first use).
Install only in a trusted environment, review dependency versions, and consider pinning/locking npm installs if your workflow requires stricter supply-chain control.
A user could underestimate the dependency-fetching risk if they rely on the stronger marketing claim instead of the install details.
The document overstates the supply-chain safety posture by saying there is 'no supply chain risk' despite also acknowledging external dependency and browser-binary downloads.
npm deps fetched from registry at install time; Playwright downloads browser binaries on first browser-mode use ... - no supply chain risk: all code ships with the skill, nothing fetched at runtime
Treat the runtime as having normal npm/Playwright supply-chain exposure and rely on the concrete install documentation rather than the 'no supply chain risk' wording.