io.jikida/mcp

PRO TIER + DESTRUCTIVE-ADJACENT: create a custom WAF rule on the user's account. The rule joins the policy every Jikida SDK enforces, live within ~5 minutes. ALWAYS show the user the exact pattern, target and action and get an explicit yes before calling. WHEN TO USE: the user asks to block a specific attack pattern, path or payload across their sites ("block anything hitting /wp-admin", "block requests containing this payload"). WHEN NOT TO USE: for blocking a single IP — use block_ip. For per-endpoint rate limits — those are endpoint rules in the dashboard.

PRO TIER + DESTRUCTIVE-ADJACENT: block an IPv4/IPv6 address or CIDR range across the user's sites (or one site via site_id). Enforced by every SDK within ~5 minutes. ALWAYS confirm the exact IP/range with the user before calling — a wrong CIDR can block real users. WHEN TO USE: the user says "block this IP", typically after seeing it in list_recent_attacks. WHEN NOT TO USE: ASN-wide blocks (not supported yet — block the specific ranges), or attack patterns — use add_waf_rule for those.

Fetch a URL and return the response security-header set (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy) plus server banner. Deterministic, ~1 second. WORKS WITHOUT A TOKEN: this is a public probe (anything curl can do), so it runs keyless — 20 checks/day per IP without a JIKIDA_TOKEN, 200/day with one. WHEN TO USE: user asks about the *current* security header state of a specific site. Faster and lighter than scan_domain. WHEN NOT TO USE: to explain what a header does — answer that from your own knowledge.

Probe a public AWS S3 bucket for open ACLs. HEAD + anonymous ListBucket only — no AWS credentials required, no writes. Flags AllUsers / AuthenticatedUsers grants and whether the bucket allows anonymous listing. WORKS WITHOUT A TOKEN: keyless (15 probes/day per IP without a JIKIDA_TOKEN, 60/day with one). WHEN TO USE: user says "is my S3 bucket public", "check this bucket", or pastes a bucket URL. Also part of the vibe-audit runbook. WHEN NOT TO USE: for private buckets that require authentication — this endpoint has no AWS creds so it will just report "not reachable".

Given a Jikida attack-log verdict ID or rule ID, return the pattern, target, action, plan tier, and one-paragraph explanation with reproduction and mitigation. WHEN TO USE: user asks "why did rule XSS-1 fire", "explain this block", or references a specific verdict/rule ID. Preferred over guessing. WHEN NOT TO USE: for generic "what is XSS" answers — use your own knowledge.

Return the user's account-scoped security preferences. These are instructions the user wants YOU (the AI) to remember and honor every session — e.g. "never scan a production site without asking", "always block .env probes". WHEN TO USE: at the START of a new coding session, or before doing anything destructive/scan-related on a Jikida-protected site. Read once, apply throughout the session. WHEN NOT TO USE: for per-file or per-project settings — those live in the user's own repo config.

Run a fast pattern check on a code snippet the user just wrote (or is about to write) and return security findings: server secrets on the client, hardcoded API keys, SQL concatenation, unbounded queries, missing input validation, unrate-limited auth routes, dynamic eval. WORKS WITHOUT A TOKEN: this is pure static analysis on code the caller already has — nothing leaves as account data — so it runs keyless (30 checks/day per IP without a JIKIDA_TOKEN, 500/day with one). Great for a first-touch security pass with zero signup. WHEN TO USE: after writing anything that touches auth, DB, env vars, request bodies, or is in a client-side file. Also whenever the user pastes a chunk of code and asks "is this safe?". WHEN NOT TO USE: as a substitute for a full pentest — this is heuristic, not exhaustive. Use scan_domain for the running app.

Look up known CVEs affecting a package via osv.dev (Open Source Vulnerabilities). Returns the 30 most-recent vulnerabilities with severity, affected version ranges, and advisory URLs. WHEN TO USE: user asks "any CVEs in X", "is package Y safe", or you spot a dependency in code they just wrote. Also useful before recommending a package. WHEN NOT TO USE: for private/internal packages — osv.dev only knows about public ecosystems (npm, PyPI, Packagist, Go, RubyGems, crates.io, Maven, NuGet).

List every uptime monitor the calling account owns, with current status (up/down), last checked timestamp, and 24h uptime %. WHEN TO USE: user asks "are my sites up", "any monitors down", or wants current uptime state.

Return the most recent WAF and honeypot events from the last N hours, with rule, IP, path, action. WHEN TO USE: user asks "any attacks recently", "who's hitting my site", or is investigating an incident. Live data — the assistant cannot know this without calling us.

Return the user's recent pentest and repo/vibe scans from the last N days, with target, grade, and pass/warn/fail counts. WHEN TO USE: user asks "what did I scan recently", "show my last pentest", "history of my scans", or wants to compare a new scan against past results. Live account data.

List every site registered under the authenticated Jikida account, with plan, connection method, and CNAME status. WHEN TO USE: user asks "what sites do I have on jikida", "which sites are protected", or wants a summary of coverage. Requires a valid JIKIDA_TOKEN.

Look up the status of a pentest run on the user's account. Without run_id, returns the most-recent scan across all sites. With run_id, returns that specific scan's state — useful for polling while a long scan runs. WHEN TO USE: user just kicked off a pentest and wants to know when it's done, or wants to see the last pentest verdict for their site. WHEN NOT TO USE: for the vibe scan history — use list_recent_scans with kind:"vibe" instead.

Run the DEEP pentest pass on a URL you own: everything in run_pentest plus surface discovery, tech fingerprint, a safe error-based SQL-injection probe, admin/login-panel discovery and extra secret patterns. Returns the full graded report saved to history. REQUIRES A TOKEN + a plan that allows deep scans (the free/anonymous path returns the surface pentest instead). The server enforces the plan and per-account limits. WHEN TO USE: user asks for a "deep pentest", "full pentest", "thorough audit" of a site they own and has connected an account. WHEN NOT TO USE: for a quick free look — use run_pentest.

Run a live pentest against a URL: TLS/HSTS/CSP, cookie flags, exposed .env/.git/backup files, leaked Supabase/Firebase/S3 keys, source-map leaks and security headers. Returns a graded A-F report with a fix for each finding. WORKS WITHOUT A TOKEN: with no JIKIDA_TOKEN it returns a free once-a-day preview (grade + top findings) for any public URL. With a token + the site onboarded, it returns the full report saved to history. WHEN TO USE: user asks to "pentest", "audit", "scan", or "check the security of" a running site or app. This tool actually reaches the target. WHEN NOT TO USE: for a GitHub repo (use scan_repo). For AI-editor code before deploy (use run_vibe_scan / guard_code).

Run a vibe-coder scan against a LIVE URL: exposed secrets in the served bundle, open S3 buckets, wide-open Supabase RLS / Firebase rules, and other misconfigurations vibe-coded apps ship by default. Pro-tier — plan-gated per site. WHEN TO USE: user asks "is my deployed app leaking anything", "scan my live site for exposed keys / open buckets", right after a deploy. WHEN NOT TO USE: for a GitHub repo (use scan_repo). For a general header/TLS grade (use scan_domain). Requires a token on a plan that includes vibe scans.

Alias of run_pentest — a live pentest of a URL (TLS, headers, exposed files, leaked keys), graded A-F. Prefer run_pentest / run_deep_pentest by name.

Scan a public GitHub repo for committed secrets, exposed .env / firebase-adminsdk / serviceAccountKey files, and other SAST-style leaks. Reads the default branch via GitHub raw-content endpoints — no clone, no auth needed. WHEN TO USE: user asks "is my repo leaking anything", "did we commit an .env", or is pointing at a specific repo URL on github.com, gitlab.com, or bitbucket.org. Also great before a public repo goes public. WHEN NOT TO USE: for the user's running website — use scan_domain instead. For a private repo — this endpoint has no token so it will get a 404. AFTER SCANNING: the response includes a `verify` block. Do NOT just report the raw findings. Open the referenced code for each finding, confirm whether it is a genuine issue in THIS repo, and call verify_finding with your verdict — so the report shows CONFIRMED issues, not just potential ones.

Save a single security preference on the user's account so it persists across sessions and devices. Use short snake_case keys (e.g. never_scan_production_without_ask). Value is stored verbatim as JSON. WHEN TO USE: user says "remember that I never want you to X" or "always do Y before Z" in a security context. Confirm the key and value with the user before saving. WHEN NOT TO USE: for ephemeral session state — keep that in your own memory.

Record your verdict on a single finding from a scan_repo / scan_code / pentest scan, AFTER you have checked it against the real code. This is the agentic triage loop: turn "here are N potential issues" into "here are the ones I confirmed". WHEN TO USE: right after scan_repo or scan_code, once per finding — open the referenced file/code, decide if the finding is a genuine, exploitable issue in THIS codebase (not a library, test fixture, comment, or already-mitigated case), then call this with confirmed or false_positive plus a one-line evidence proof. EFFECT: a confirmed finding is emphasised in the report; a false positive is demoted and will not alert. Only affects the scan report — it never changes live-site monitoring alerts.