# io.jikida/mcp (npm · @jikida/mcp)

Security tools for your AI: scan, pentest, check headers, guard code and scan repos for secrets.

- Trust score: 69/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-25

## Components

- npm · `@jikida/mcp`: 69/100 (this document), [markdown](https://verifymcp.io/servers/io-jikida-mcp/jikida-mcp.md), [page](https://verifymcp.io/servers/io-jikida-mcp/jikida-mcp)

## Channel facts

- Registry: `npm`
- Package: `@jikida/mcp`
- Version: `0.3.6`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-25.

- **Supply Chain Security**: 98/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 31 of 95 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 1 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 72/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 3736 tokens (~186/item across 20 items; 20 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 99/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 97% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 20 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 21 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### How do I install the io.jikida/mcp server?

io.jikida/mcp runs locally as an npm package, launched with npx -y @jikida/mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add io-jikida-mcp -- npx -y @jikida/mcp
```

### Cursor

```json
{
  "mcpServers": {
    "io-jikida-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@jikida/mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "io-jikida-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@jikida/mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add io-jikida-mcp -- npx -y @jikida/mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "io-jikida-mcp": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@jikida/mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add io-jikida-mcp --command npx --arg -y --arg @jikida/mcp
```

### Hermes

```yaml
mcp_servers:
  io-jikida-mcp:
    command: "npx"
    args: ["-y", "@jikida/mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "io-jikida-mcp": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "@jikida/mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add io-jikida-mcp -t stdio -c npx -a -y @jikida/mcp
```

### Other

```json
{
  "mcpServers": {
    "io-jikida-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@jikida/mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-25 (score 69, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-09-22 (score 69)

First indexed and scored.

## MCP tools (20)

### `run_pentest` (~201 tokens)

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).

Input parameters:

- `url` (string, required): Full URL including scheme, e.g. https://example.com

### `run_deep_pentest` (~168 tokens)

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.

Input parameters:

- `url` (string, required): Full URL including scheme, e.g. https://example.com

### `scan_domain` (~68 tokens)

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.

Input parameters:

- `url` (string, required): Full URL including scheme, e.g. https://example.com

### `check_headers` (~152 tokens)

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.

Input parameters:

- `url` (string, required)

### `list_sites` (~68 tokens)

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.

### `list_monitors` (~59 tokens)

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.

### `list_recent_attacks` (~109 tokens)

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.

Input parameters:

- `hours` (integer): How far back to look (default 24, max 168)
- `limit` (integer): Max rows (default 20, max 100)

### `list_recent_scans` (~112 tokens)

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.

Input parameters:

- `days` (integer): How far back to look (default 7, max 90)
- `kind` (string): Filter by scan kind

### `explain_verdict` (~131 tokens)

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.

Input parameters:

- `verdict_id` (string, required): Attack log row ID or WAF rule ID (e.g. XSS-1, SQLi-3, HONEY)

### `scan_repo` (~229 tokens)

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.

Input parameters:

- `repo_url` (string, required): Public repo URL on github.com, gitlab.com, or bitbucket.org

### `verify_finding` (~268 tokens)

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.

Input parameters:

- `evidence` (string): One-line proof, e.g. "src/db.js:12 concatenates req.query into SQL"
- `finding_id` (string, required): The finding.id to verify
- `finding_title` (string): The finding title (for the audit record)
- `scan_id` (string, required): The scan_id returned by scan_repo / scan_code
- `verdict` (string, required): confirmed = a genuine issue you proved; false_positive = could not reproduce / not applicable

### `run_vibe_scan` (~154 tokens)

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.

Input parameters:

- `url` (string, required): The live URL to scan (e.g. https://myapp.com)

### `guard_code` (~275 tokens)

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.

Input parameters:

- `code` (string, required): The code snippet to check (max 60000 chars)
- `file_path` (string): Relative path of the file so we can tell client vs server (e.g. app/api/route.ts, src/pages/index.tsx)
- `language` (string): Language hint (js, ts, py, php, go, rb, java)

### `get_security_preferences` (~115 tokens)

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.

### `set_security_preference` (~150 tokens)

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.

Input parameters:

- `key` (string, required): Snake-case slug, e.g. never_scan_production_without_ask
- `value`: Any JSON value (boolean, string, number, object, array, null)

### `check_s3_bucket` (~179 tokens)

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".

Input parameters:

- `bucket` (string, required): Bucket name (3-63 chars, lowercase, hyphens allowed)
- `region` (string): AWS region (default us-east-1)

### `list_cves` (~167 tokens)

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).

Input parameters:

- `ecosystem` (string): Package ecosystem (default npm)
- `package` (string, required): Package name, e.g. "lodash" or "django"
- `version` (string): Optional exact version to filter to

### `add_waf_rule` (~230 tokens)

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.

Input parameters:

- `action` (string, required): What happens on match
- `category` (string): Optional short category slug, e.g. "custom" or "scanner"
- `description` (string): Optional human note stored with the rule
- `pattern` (string, required): Regular expression the rule matches (case-insensitive), e.g. "/wp-admin" or "union\\s+select"
- `target` (string, required): Which part of the request the pattern runs against

### `block_ip` (~210 tokens)

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.

Input parameters:

- `ip_or_asn` (string, required): IPv4/IPv6 address or CIDR, e.g. "203.0.113.9" or "203.0.113.0/24"
- `note` (string): Optional note about why this was blocked
- `site_id` (string): Optional site nano ID to scope the block to one site; omit for all sites

### `pentest_status` (~135 tokens)

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.

Input parameters:

- `run_id` (integer): Optional pentest run ID. If omitted, returns the most recent scan.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/io-jikida-mcp/jikida-mcp#diagnostics

## Score history

- 2026-09-25: 69
- 2026-09-24: 69
- 2026-09-23: 69
- 2026-09-22: 69

## Common questions

### What is the io.jikida/mcp server?

io.jikida/mcp is listed in the public MCP registry as io.jikida/mcp. Security tools for your AI: scan, pentest, check headers, guard code and scan repos for secrets. This page covers its npm package (@jikida/mcp).

### Is the io.jikida/mcp server safe to use?

io.jikida/mcp scores 69 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 25 September 2026. It declares no install or post-install scripts. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the io.jikida/mcp server expose?

io.jikida/mcp exposes 20 tools: run_pentest, run_deep_pentest, scan_domain, check_headers, list_sites, and 15 more. Their descriptions and schemas cost roughly 3,180 tokens of context every time the server is loaded.

### Is the io.jikida/mcp server still maintained?

io.jikida/mcp is still listed as active in the MCP registry. We last reached this channel on 25 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the io.jikida/mcp server under?

io.jikida/mcp declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/@jikida/mcp
- Socket report: https://socket.dev/npm/package/@jikida/mcp
- Repository: https://github.com/unesLam/jikida
- Changelog RSS feed: https://verifymcp.io/servers/io-jikida-mcp/jikida-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/io-jikida-mcp/jikida-mcp.json
- HTML version of this page: https://verifymcp.io/servers/io-jikida-mcp/jikida-mcp