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, Cursor, GitHub Copilot, 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. Nothing leaves your machine: no file, no file name, no file content.
pip install jidoseal-mcp
claude mcp add jidoseal -- jidoseal-mcp # Claude Code; other hosts 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 independent and is not affiliated with or endorsed by Google. Nor is it affiliated with ISO; the ISO mapping below is JidoSeal's own reading of those standards.
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) | Basis |
Bronze |
| OKF v0.2 — |
Silver | Bronze + | ISO 9001 §7.5.2 (documented information: identification and description) |
Gold | Silver + | ISO 30401 (knowledge-management lifecycle: status and review) |
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 |
| 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 |
| Only on your explicit go-ahead: asks jidoseal.com to create a Stripe Checkout session and returns the link for you to open. Takes no payment. | jidoseal.com only |
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) 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.
claude mcp add jidoseal -- jidoseal-mcpor commit a project-scoped .mcp.json:
{ "mcpServers": { "jidoseal": { "command": "jidoseal-mcp" } } }~/.cursor/mcp.json (or .cursor/mcp.json in a project):
{ "mcpServers": { "jidoseal": { "command": "jidoseal-mcp" } } }.vscode/mcp.json:
{ "servers": { "jidoseal": { "type": "stdio", "command": "jidoseal-mcp" } } }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: nothing. Not the files, not their names, not their contents. That is a property of the import graph, not a promise about which branches run: jidoseal_mcp.py, scan_result.py and offer.py import no socket, no urllib, no HTTP client, and neither does anything they pull in. 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: 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. No file contents, no file names, no per-file hashes, no paths. 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.
Scanning is free and unlimited. If you want a signed certificate 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. Certification is point-in-time and based on a score and a corpus hash, never on 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. Issues are welcome; there is no test suite in this repository, so 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.
Search, read, and safely update Markdown notes in your connected Phasoric knowledge vaults.
