shipsafe-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SHIPSAFE_PROBE_ALLOWLIST | No | Comma-separated list of hosts that are allowed for live probes without confirmation. Used by the MCP server for the probe_live tool. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_projectA | Scan a web or mobile app project for security issues and return a launch-readiness score. Detects leaked secrets (public env vars, keys in client bundles), Supabase tables without RLS, open Firebase rules, API routes/server actions without auth, IDOR, SQL/NoSQL/command injection, SSRF, unverified Stripe webhooks, client-controlled prices, AI endpoints without auth or rate limits, insecure mobile config, and hallucinated/typosquatted/vulnerable dependencies. Args: path: Absolute path to the project root. Defaults to the client's workspace root. check_dependencies: Look up dependencies on npm/PyPI and OSV.dev. offline: Never touch the network (skips registry and vulnerability lookups). |
| list_findingsA | List findings from the latest scan, optionally filtered. Args: severity: Only this severity (critical, high, medium, low, info). category: e.g. secrets, access-control, injection, backend-config, payments, ai, mobile, supply-chain. file: Substring of the file path. offset: Pagination offset. limit: Page size (max 100). path: Project root; defaults to the most recently scanned project. |
| get_findingA | Full details for one finding: impact, fix guidance, code context and references. Args: finding_id: The id from scan_project / list_findings (e.g. "SS-3F9A2C1"). |
| verify_fixesA | Re-scan the project after edits and report what was fixed, what remains and the score change. Args: path: Project root; defaults to the most recently scanned project. |
| scan_snippetA | Check a piece of code before writing it to disk (no project needed). Use it for auth, payment, database, file/URL handling and AI-calling code. Args: code: Source code to check. filename: Realistic path; it drives language and context detection (e.g. app/api/users/route.ts, components/Form.tsx, supabase/migrations/001.sql, app.py). runtime: Where the code runs. "client" = shipped to browsers/apps; "auto" guesses from filename/directives. |
| check_dependenciesA | Check direct npm/PyPI dependencies for hallucinated (non-existent) packages, typosquats, suspiciously new packages and known vulnerabilities (OSV.dev). Args: path: Project root. Defaults to the client's workspace root. |
| probe_liveA | Passively check a running deployment: exposed .env/.git, secrets in JS bundles, Supabase tables readable with the public anon key, open Firebase Realtime Database, CORS, cookies, security headers. Only plain GET requests are made. localhost is always allowed. For any other host the user must confirm ownership (ShipSafe asks them directly when the client supports it). Set authorized=true ONLY after the user has explicitly said they own the site. Args: url: Site to check, e.g. http://localhost:3000 or https://myapp.vercel.app authorized: The user explicitly confirmed they own / may test this site. |
| generate_reportA | Write a shareable report for the latest scan. The HTML report has a score ring, severity filters and a "copy fix prompt" button per finding. By default it is written to /.shipsafe/ (which is git-ignored automatically). Args: format: html, md (Markdown), sarif (GitHub code scanning) or json. path: Project root; defaults to the most recently scanned project. output: Explicit output file path. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| pre-launch-audit | Full security audit before shipping: scan, explain, fix, verify. |
| secure-feature | Implement a feature and check it with ShipSafe before presenting it. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| rules | Every rule ShipSafe checks, with severity and impact. |
| latest-report | Markdown report of the most recent scan in this session. |
TDQS
Scored across 8 tools
Each tool has a clear primary purpose: scanning project/snippet/live, listing/getting findings, verifying fixes, checking dependencies, and generating reports. Minor overlap exists between scan_project and check_dependencies (and verify_fixes re-scans), but descriptions are specific enough to avoid serious misselection.
All tool names follow a consistent verb_noun pattern in lowercase snake_case: scan_project, list_findings, get_finding, verify_fixes, scan_snippet, check_dependencies, probe_live, generate_report. There are no mixed conventions or vague verbs.
Eight tools is well-scoped for a security scanning server. Each tool covers a distinct stage of the workflow: scanning, inspecting findings, verifying fixes, live probing, dependency checks, and reporting, with no redundant or unnecessary additions.
Core coverage is solid: scanning (project, snippet, live, dependencies), finding inspection (list, get), verification, and reporting. Minor gaps include the inability to dismiss/mark findings as false positives or view scan history, but these are not critical to the primary launch-readiness workflow.