Scan a local folder of Markdown notes for OKF/ISO certification tiers, identify missing fields, get a certification offer, and optionally start a paid checkout.
Run a free local self-check (jidoseal_scan): scan every *.md file under a folder and return the corpus tier (Bronze/Silver/Gold), coverage per tier, a 0–100 score, and per-file missing fields for the next tier, each marked AUTO or NEEDS-CLIENT.
Get a certification offer (jidoseal_certification_offer): scan locally and see the paid-certification tier, price, what the certificate includes, and exactly which facts a purchase would send—all without contacting the network.
Start a Stripe checkout (jidoseal_start_checkout): with explicit confirm: true, ask jidoseal.com to create a Stripe Checkout session for certifying the corpus, returning a payment link; sends only eight specified fields (company, name, email, tier, score, Merkle root, scan ID, Bronze price flag).
Work offline for scans and offers: the scan and offer tools send nothing over the network; writes only <root>/.jidoseal/manifest.json and progress.ndjson, never modifying your notes.
Use across MCP clients: install via pip install jidoseal-mcp and wire into Claude Code, Claude Desktop, Cursor, GitHub Copilot, OpenAI Codex, Gemini CLI, Zed, Cline, Continue, JetBrains AI Assistant, or any local MCP client.
Run from the command line: use jidoseal --root ~/notes for the same scan without an AI tool.
Allows starting a Stripe Checkout session for the optional certification purchase and returns a payment link to open.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jidoseal-mcp Scan ~/notes and tell me what's missing for Silver."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Check a folder of markdown notes against Open Knowledge Format (OKF) v0.2 — from inside Claude Code, Claude Desktop, Cursor, GitHub Copilot, OpenAI Codex, Gemini CLI, Zed, Cline, Continue, JetBrains AI Assistant or a local model, on your own machine.
Pick a folder, scan it. jidoseal-mcp is a local Model Context Protocol server that reads the YAML frontmatter of every *.md file under a folder, reports which tier the knowledge base reaches (Bronze / Silver / Gold), and lists — per file — the exact frontmatter fields missing for the next tier. The scan sends nothing over the network: no file, no file name, no file content. That is JidoSeal's own claim about its engine; below is how to check it.
pip install jidoseal-mcp
claude mcp add jidoseal -- jidoseal-mcp # Claude Code; every other tool is belowThen ask your assistant: "Scan ~/notes with JidoSeal and tell me what's missing for Silver."
Independent. OKF is an open specification from Google Cloud. JidoSeal is not affiliated with, sponsored by, or endorsed by Google or ISO. ISO names no fields: the Bronze/Silver/Gold tiers and their fields are defined by JidoSeal, as one way of evidencing selected ISO clauses. A JidoSeal tier or certificate is not an ISO certification.
Reads: the *.md files under the folder you give it (hidden files and folders are skipped), plus <folder>/.jidoseal/config.yaml if present. The server refuses a folder that contains a symlink to a directory or to a file outside the folder.
Writes: <folder>/.jidoseal/manifest.json (replaced on each scan) and <folder>/.jidoseal/progress.ndjson (appended to). Nothing else; your notes are not modified.
Network, scan and offer: none, by JidoSeal's own claim about its proprietary engine, not independently audited. The tests below check it on every change.
Network, checkout (optional, paid): jidoseal_start_checkout runs only with confirm: true. It sends eight fields to jidoseal.com: company, name and email as typed, the tier, a 0–100 score, the corpus's Merkle root, the local scan's id, and one flag saying which Bronze price applies. jidoseal.com copies them into the Stripe Checkout session it creates (the email as the session's customer email, all eight as session metadata), when the session is created, before any payment. No file contents, file names, per-file hashes or paths. No card data passes through this server.
Engine: the scan engine is the separate jidoseal package, under a proprietary licence. It ships as plain Python source and is pinned here to one version (0.1.4), with its sha256 in ENGINE-SHA256SUMS and an SBOM in sbom.cdx.json. So "nothing leaves your machine" is JidoSeal's own claim: you can check it with the commands under What leaves your machine and the tests in tests/, but it has not been independently audited.
The scan is deterministic — presence of populated frontmatter fields, no model calls, no scoring by opinion. A field counts only if it has real content (title: with nothing after it earns nothing).
Tier | A file must have (populated) | What it evidences |
Bronze |
| OKF v0.2 as written — |
Silver | Bronze + | ISO 9001 §7.5.2, which asks for appropriate identification and description of a document and gives examples ("a title, date, author, or reference number"). These four fields are one reasonable way to evidence it. |
Gold | Silver + | ISO 30401's kept-current knowledge governance. The standard sets no review interval; a stated review policy with real review dates is how you evidence it, and the cadence is yours to choose. |
A corpus's tier is the tier of its weakest file. Coverage is the share of files that reach each tier. The full field reference — accepted aliases, what counts as "populated", what is excluded — is in docs/tiers.md.
A minimal Gold-tier file:
---
type: policy
title: Leave policy
description: How leave accrues and how to request it.
timestamp: 2026-09-01
owner: dept:people-ops
status: stable
review_policy: yearly
reviewed_at: 2026-09-01
next_review_at: 2027-09-01
---Worked examples for each tier, and a mixed folder, are in examples/tiers/.
Related MCP server: Security & GRC MCP Server
Tool | What it does | Network |
| The free Self-Check over a folder on this machine: corpus tier, per-file missing fields for the next tier (each marked | none (JidoSeal's claim; see below) |
| What optional certification would cost for this corpus, why, what it includes, and exactly which facts a purchase would send. Computes locally; starts nothing. | none (same claim) |
| Only on your explicit go-ahead, passed as | jidoseal.com, which passes the fields to Stripe |
Example jidoseal_scan result for examples/tiers/mixed (three files, one Gold, one Bronze, one with no frontmatter):
{
"corpus": { "file_count": 3, "tier": "none",
"coverage": { "bronze": 66.7, "silver": 33.3, "gold": 33.3 } },
"score": 44,
"certified_eligible": false,
"files": [
{ "name": "expenses.md", "tier": "bronze",
"missing": { "silver": [ { "field": "description", "fix": "AUTO" },
{ "field": "timestamp", "fix": "AUTO" },
{ "field": "owner", "fix": "NEEDS-CLIENT" } ] } }
// …
]
}frontmatter_ok: false on a file means its frontmatter block exists but does not parse; no field write can close its gaps until it is fixed by hand.
Requires Python 3.9+. pip install jidoseal-mcp also installs jidoseal (the scan engine and CLI, pinned to the tested version) and puts a jidoseal-mcp command on your PATH. No account and no API key. The scan itself needs no network — it runs the same offline.
Every tool below launches the same local command, jidoseal-mcp, over stdio. Only the place you write it down differs.
claude mcp add jidoseal -- jidoseal-mcpor commit a project-scoped .mcp.json:
{ "mcpServers": { "jidoseal": { "command": "jidoseal-mcp" } } }Settings → Developer → Edit Config opens claude_desktop_config.json. Add:
{ "mcpServers": { "jidoseal": { "command": "jidoseal-mcp", "args": [] } } }Restart Claude Desktop afterwards.
~/.cursor/mcp.json (or .cursor/mcp.json in a project):
{ "mcpServers": { "jidoseal": { "type": "stdio", "command": "jidoseal-mcp", "args": [] } } }Copilot Chat uses MCP tools in Agent mode. In VS Code, add .vscode/mcp.json to the project (or run MCP: Open User Configuration for every project):
{ "servers": { "jidoseal": { "type": "stdio", "command": "jidoseal-mcp" } } }Copilot in Visual Studio, JetBrains IDEs, Eclipse and Xcode takes the same servers entry in its own MCP settings. On a Copilot Business or Enterprise seat, your organization must have the "MCP servers in Copilot" policy turned on; it is off by default.
codex mcp add jidoseal -- jidoseal-mcpor in ~/.codex/config.toml:
[mcp_servers.jidoseal]
command = "jidoseal-mcp"gemini mcp add -s user jidoseal jidoseal-mcpor in ~/.gemini/settings.json (or .gemini/settings.json in a project):
{ "mcpServers": { "jidoseal": { "command": "jidoseal-mcp" } } }In Zed's settings.json (or Settings → AI → MCP Servers → Add Local Server):
{ "context_servers": { "jidoseal": { "command": "jidoseal-mcp", "args": [], "env": {} } } }MCP Servers → Configure → Configure MCP Servers, then add:
{ "mcpServers": { "jidoseal": { "type": "stdio", "command": "jidoseal-mcp", "args": [], "disabled": false } } }.continue/mcpServers/jidoseal.yaml in your workspace (MCP tools run in Continue's agent mode):
name: JidoSeal
version: 0.0.1
schema: v1
mcpServers:
- name: jidoseal
type: stdio
command: jidoseal-mcpSettings → Tools → AI Assistant → Model Context Protocol (MCP) → Add → STDIO, and paste:
{ "mcpServers": { "jidoseal": { "command": "jidoseal-mcp", "args": [] } } }Any MCP client that can launch a stdio server and sits in front of a local model takes the same two facts — a name and a command:
{ "mcpServers": { "jidoseal": { "command": "jidoseal-mcp", "args": [], "env": {} } } }pipx install jidoseal && jidoseal --root ~/notesSame scan, same verdict, from a terminal. See the jidoseal CLI on PyPI.
If your host uses a different Python than the one you installed into, point it at the module: "command": "/path/to/python", "args": ["-m", "jidoseal_mcp"].
Check the wiring by hand, without any host:
printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"x","version":"0"}}}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
| jidoseal-mcpYou should see an initialize result naming jidoseal, then the three tools.
The CLI writes .jidoseal/manifest.json; a few lines turn it into a gate. See docs/ci.md for a GitHub Actions workflow that fails the build when any file falls below Silver.
A scan: JidoSeal's claim is that it sends nothing: not the files, not their names, not their contents. The engine that does the scan is proprietary, and nobody independent has audited this claim. It is built to be checkable: jidoseal_mcp.py, scan_result.py and offer.py import no socket, no urllib, no HTTP client, and neither does anything they pull in, including the ten engine modules the pinned jidoseal wheel contains. checkout_client.py is the one module that can reach the network, and it is imported only inside the checkout handler.
A purchase, only if you choose one and the call carries confirm: true: the company, name and email you typed, the tier, a 0–100 score, the corpus's Merkle root, the local scan's id, and which Bronze price applies, sent to jidoseal.com. jidoseal.com copies them into the Stripe Checkout session it creates: the email as the session's customer email, and all eight as session metadata. That happens when the session is created, before any payment. No file contents, no file names, no per-file hashes, no paths, and no card data through this server (Stripe hosts the payment page). The Merkle root is a one-way digest.
Verify it yourself:
strace -f -o /tmp/trace.txt -e trace=network jidoseal-mcp < your-jsonrpc-input # no network syscalls during a scan
bwrap --unshare-net --dev-bind / / jidoseal-mcp < your-jsonrpc-input # the scan works with no network at allThe scan writes its own records — manifest.json and an appended progress.ndjson — under <folder>/.jidoseal/ and nowhere else. It never modifies your notes.
The test suite checks the same things on every change, against the pinned engine wheel after verifying its sha256 (see .github/workflows/tests.yml):
File | What it holds |
The scan opens and lists nothing outside the folder; folders with symlinks that lead out of it, or to directories, or that redirect | |
The only files created or changed are the two under | |
No socket, DNS lookup or child process during a scan — in-process with sockets blocked, and end to end over stdio in a process that exits on any socket event. | |
Checkout makes no request without | |
Static check of every module on the scan path, the engine's included. | |
The engine pin, |
The jidoseal command-line tool refuses such folders too, from engine 0.1.4 (the version pinned here): a symlink to a file or directory outside the folder, or a symlinked .jidoseal/, stops the run before anything is read or written, and the command exits with status 2. It does not follow a symlinked directory inside the folder either, so each file is read once. This server is a little stricter: it refuses a symlinked directory even when it stays inside. The CLI's own no-network line is worded as JidoSeal's claim, like this server's. Engine 0.1.3 and earlier followed symlinks and printed an unqualified line, so use 0.1.4 or later.
Scanning is free and unlimited, and so are the fixes. If you want a dated certificate for the grade your folder reached, bound to the Merkle root of your corpus, with a public verification page and a listing in the public registry, that is a paid step on jidoseal.com; current prices are published there, one flat price per grade however many files. A person at JidoSeal signs it off from the grade, the score and that fingerprint only, never from your file contents.
Website: https://jidoseal.com
Public registry of certified knowledge bases: https://jidoseal.com/registry
PyPI: jidoseal-mcp · jidoseal
MCP Registry: com.jidoseal/jidoseal-mcp
OKF specification (Google Cloud, Apache-2.0): https://github.com/GoogleCloudPlatform/open-knowledge-format
Contact: support@jidoseal.com
This repository holds the source of the jidoseal-mcp package: an MCP server implemented on the Python standard library alone (no MCP SDK), speaking JSON-RPC 2.0 over stdio. It depends on the separately published jidoseal package for the scan engine, which is not part of this repository and is pinned to one tested version. Run the tests with pip install -e ".[test]" && pytest. Issues are welcome; please include the jidoseal-mcp and jidoseal versions and the smallest folder that reproduces a problem.
Apache-2.0 for the code in this repository — see LICENSE. The jidoseal engine it depends on is distributed separately under its own terms.
Scan a folder locally and return the paid-certification offer for it: the tier it qualifies for, the real price for that tier and why that price applies, what the certificate includes (a signed certificate bound to a Merkle root of the corpus, a verifiable badge, a public verification page, a registry listing), and the exact list of facts a purchase would send to jidoseal.com. Charges nothing, starts nothing, and sends nothing — it is a local computation about a purchase the customer has not made. Exactly what leaves your machine: nothing — 100% local, zero content egress. Your files, their names, and their contents never leave your device.
| Name | Required | Description | Default |
|---|---|---|---|
| root | Yes | Absolute path of the folder. | |
| include_machine | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations are sparse, so the description carries the behavioral burden and does so strongly: it explicitly says the tool charges nothing, starts nothing, sends nothing, is 100% local, has zero content egress, and that files, names, and contents never leave the device. This is far more useful than the bare annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is dense and front-loaded, and the no-side-effect information is valuable. But 'Exactly what leaves your machine: nothing', '100% local, zero content egress', and 'Your files... never leave your device' repeat the same point, so not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool without an output schema, the description covers the return content well and gives strong privacy context. It is incomplete around the include_machine parameter and does not clarify how this tool relates to jidoseal_scan or jidoseal_start_checkout.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: root is described as an absolute path and the tool text reinforces it by saying 'Scan a folder'. The description never explains include_machine, whose meaning and effect on the returned offer or transmitted facts are essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Scan a folder locally and return the paid-certification offer for it.' It enumerates the exact output fields, which clearly distinguishes it from jidoseal_scan and jidoseal_start_checkout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a pre-purchase local quote ('a purchase the customer has not made') and emphasizes no side effects. However, it never names the sibling tools or states when to use them instead, so the routing to alternatives is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run JidoSeal's free Self-Check over a folder of Markdown documents on THIS machine and return its OKF/ISO certification tier — Bronze, Silver or Gold — plus, for every file, which fields are missing for the next tier, and the corpus's coverage against each tier. Same rubric, and the same tier, coverage and per-file gap list as the Self-Check at jidoseal.com/app/run for the same folder. Bronze = OKF v0.2 as written (a populated type); Silver = Bronze + ISO 9001 §7.5.2 fields (title, description, timestamp, owner); Gold = Silver + ISO 30401 (status, review_policy, reviewed_at, next_review_at). Each gap is marked AUTO (JidoSeal can propose the value) or NEEDS-CLIENT (only the owner can answer it), so the caller can close them for free before paying for anything. Free and unlimited. Exactly what leaves your machine: nothing — 100% local, zero content egress. Your files, their names, and their contents never leave your device. Writes the scan's own records to /.jidoseal/ (manifest.json and an appended progress.ndjson) and nowhere else.
| Name | Required | Description | Default |
|---|---|---|---|
| root | Yes | Absolute path of the folder to scan. Every *.md file under it is scanned, recursively. | |
| include_machine | No | Scan every Markdown file, ignoring this corpus's own machine/transient excludes from .jidoseal/config.yaml. Leave false: the certified path scans without it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Going beyond the annotations, the description discloses the tool's side effects precisely: it writes manifest.json and progress.ndjson to <root>/.jidoseal/ and nowhere else. It also clarifies a critical behavioral trait—100% local execution with zero content egress—which is not visible from annotations or schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but front-loaded with the core purpose and packed with essential operational details. Some repetition around 'free' and 'local/no egress' exists, but it serves to emphasize the privacy guarantees, so it does not feel wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description enumerates the expected return contents: certification tier, per-file missing fields, coverage per tier, and AUTO/NEEDS-CLIENT gap labels. With schema covering parameters and the description covering outputs, side effects, and privacy, no critical operational information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already fully documented in structured form. The description adds no new parameter-level semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Run JidoSeal's free Self-Check over a folder of Markdown documents') and the exact resource being scanned, with clearly named outputs: tier, per-file missing fields, and corpus coverage. It also distinguishes itself from the paid/checkout siblings by emphasizing that it is free, local, and pre-payment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context clear: use this to get a free local self-check before paying, with the same rubric as the web app. It does not explicitly name the sibling tools as alternatives or state when not to use them, but the 'before paying for anything' phrasing gives strong practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask jidoseal.com to create a Stripe Checkout session for certifying this corpus, and return the checkout URL for the customer to open and pay. Call it only with the customer's explicit go-ahead: it is the purchase step. It does NOT take a payment — this server never sees a card, Stripe hosts the checkout, and nothing is charged or issued unless the customer completes it themselves. This is the one JidoSeal tool that contacts the network, and it sends only: company, name and email as typed by the customer, the tier, a 0-100 score, the corpus's Merkle root, the local scan's id, and which Bronze price applies. No file contents, no file names, no per-file hashes, no paths. The tier, score and Merkle root are taken from a fresh local scan run here — never from the caller.
| Name | Required | Description | Default |
|---|---|---|---|
| root | Yes | Absolute path of the folder to certify. | |
| company | Yes | The customer's company name, as it should appear on the certificate. | |
| submitter_name | Yes | The person submitting, as typed by them. | |
| include_machine | No | ||
| submitter_email | Yes | Where the certificate and receipt go. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the annotations. It clarifies that the tool does not take a payment (Stripe hosts checkout), nothing is charged unless the customer completes it, and it enumerates exactly what data is sent (company, name, email, tier, score, Merkle root, local scan id, Bronze price) and what is not sent (file contents, names, hashes, paths). This goes well beyond the annotations and provides crucial safety/privacy context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long, but every sentence carries important safety, privacy, or usage information. It is front-loaded with the primary purpose and then follows with essential caveats. The length is justified given the monetary and privacy implications, but it could be slightly tightened without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a purchase-initiation tool with no output schema, the description is remarkably complete. It states what is returned (checkout URL), explains side effects (network contact, no payment taken), and covers data sent, prerequisites, and the go-ahead condition. Combined with the sibling tools and annotations, an agent has all necessary information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 80% (4/5 parameters described). The description adds context that the tier, score, and Merkle root are taken from a fresh local scan, not from the caller, which clarifies that the 'root' parameter is the path to scan and that these other values are not caller-provided. However, it does not elaborate on 'include_machine', which remains minimally documented in the schema. The description adds meaningful context but doesn't fully cover all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core function: 'Ask jidoseal.com to create a Stripe Checkout session for certifying this corpus, and return the checkout URL.' It uses a specific verb and resource, and distinguishes itself from siblings by emphasizing it is the purchase step and the only network-contacting tool. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs when to call: 'Call it only with the customer's explicit go-ahead: it is the purchase step.' It also implies a prerequisite by stating that the tier, score, and Merkle root come from a fresh local scan, and it differentiates from siblings by noting it is the only network-contacting tool. This gives clear context on when to use it versus the scan and offer tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1jidoseal_certification_offerjidoseal_scanjidoseal_start_checkoutScored across 3 tools
jidoseal_scan and jidoseal_certification_offer both scan locally and return a tier, so they could be confused in principle, but their descriptions clearly separate free self-check results from paid-offer pricing and deliverables. jidoseal_start_checkout is unmistakably distinct as the only network-touching purchase step.
All tools share the jidoseal_ prefix and snake_case style, which gives a cohesive feel. The inconsistency is that jidoseal_scan and jidoseal_certification_offer are noun-like while jidoseal_start_checkout is a verb phrase, breaking a strict verb_noun pattern.
Three tools is well-scoped for a focused certification funnel: assess locally, get the paid offer, and start checkout. Each tool has a clear purpose and none feels redundant.
The core JidoSeal workflow is covered end-to-end: free scan, certification offer, and checkout initiation. A minor gap is the absence of any post-purchase verification or certificate-status tool, but that may live outside the MCP surface.
Scan configs, files, or text for leaked secrets and obvious misconfigurations. Nothing stored.
Scan code for quantum-vulnerable cryptography and get NIST post-quantum migration guidance.
Lint a SKILL.md for frontmatter, structure, secrets and size. All 6 tools free.
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
