The klaws server scans codebases for Korean legal compliance risks and maps findings to specific Korean legal provisions.
scan_directory: Recursively scan all matching files in a directory tree for compliance risks across PIPA, the Network Act, the Credit Information Act, and the E-Commerce Act. Returns a JSON report with each finding's detector ID, risk level (HIGH/MEDIUM), file path, line number, code snippet, message, and related law provision IDs.
scan_file: Scan a single source file for the same compliance risks, returning the same JSON report format — useful for checking the file currently being edited.
list_detectors: List all available compliance risk detectors with their ID, name, description of the code pattern they look for, and the related Korean law provisions they map to.
get_law_reference: Look up a specific Korean law provision by ID (e.g. PIPA-15, NIA-50, CIA-19, ECA-6) to get its Korean and English names, a plain-language summary, the source URL on law.go.kr, a risk level, and optionally the full Korean article text — either from the bundled database or fetched live from law.go.kr.
Korean law compliance risk scanner for codebases. Scans source code for patterns that may indicate compliance risks under Korean law and maps findings to specific legal provisions. Runs as an MCP server (so AI coding assistants can scan on request) and as a standalone CLI.
Currently covers PIPA (Personal Information Protection Act), the Network Act (정보통신망법), the Credit Information Act (신용정보법), and the E-Commerce Act (전자상거래법).
Disclaimer: klaws identifies possible compliance risks for review. It does not constitute legal advice. Consult qualified legal counsel for definitive guidance.
Privacy: klaws analyzes code locally and transmits nothing. The only outbound network call is the optional
--livelaw lookup to law.go.kr; without that flag it is fully offline. See Privacy & Security.
# Scan the current directory with Docker — no install needed
docker run --rm -v "$PWD":/src:ro ghcr.io/rostradamus/klaws scan /src
# ...or, if you installed the binary:
klaws scan ./my-project # scan a directory
klaws scan ./MyService.java # scan a single fileRelated MCP server: Meridian
No toolchain required — the image is published to GitHub Container Registry and works identically on macOS, Linux, and Windows:
# Scan the current directory (mount it read-only at /src)
docker run --rm -v "$PWD":/src:ro ghcr.io/rostradamus/klaws scan /src
# Pin a version instead of the floating latest tag
docker run --rm -v "$PWD":/src:ro ghcr.io/rostradamus/klaws:0.1.6 scan /srcDownload the archive for your platform from the latest release, extract it, and move klaws onto your PATH.
go install github.com/rostradamus/klaws/cmd/klaws@latestRequirements: Go 1.23+
git clone https://github.com/rostradamus/klaws.git
cd klaws
go build -o klaws ./cmd/klaws/Verify the install:
klaws --version# Scan a directory (default: *.java files)
klaws scan ./src
# Scan specific file types
klaws scan ./src --pattern "*.kt"
# Text output (default is JSON)
klaws scan ./src --format text
# SARIF output (for GitHub code scanning / other tools)
klaws scan ./src --format sarif > klaws.sarif
# Fail the command (exit 1) if any finding is at or above a severity
klaws scan ./src --fail-on HIGH
# Use a custom laws file
klaws scan ./src --laws ./my-laws.yamlklaws scan report
Target: ./testdata
Files: 4
Findings: 7
--- Finding 1 ---
Detector: PIPA-CST-001
Risk: HIGH
Location: testdata/MemberController.java:10
Snippet: @PostMapping("/register")
Message: Endpoint accepts possible personal data without apparent consent
mechanism — may require review under PIPA Article 15
Laws: PIPA-15
--- Finding 2 ---
Detector: PIPA-ENC-001
Risk: HIGH
Location: testdata/MemberEntity.java:11
Snippet: private String residentNumber;
Message: Possible unencrypted personal identifier (residentNumber) — may
require review under PIPA Article 24-2
Laws: PIPA-24-2, PIPA-29
--- Finding 3 ---
Detector: PIPA-LOG-001
Risk: MEDIUM
Location: testdata/UserService.java:11
Snippet: log.info("User registered: " + email);
Message: Possible personal data (email) in log output — may require review
under PIPA Article 29
Laws: PIPA-29# Look up from bundled database
klaws law PIPA-15
# Fetch live text from law.go.kr
klaws law PIPA-15 --liveklaws detectors[
{
"id": "PIPA-LOG-001",
"name": "Personal Data Logging Risk",
"description": "Detects log statements that may contain personal data fields",
"related_laws": ["PIPA-29"]
},
{
"id": "PIPA-ENC-001",
"name": "Unencrypted Personal Data Risk",
"description": "Detects personal identifier fields stored without apparent encryption",
"related_laws": ["PIPA-24-2", "PIPA-29"]
},
{
"id": "PIPA-CST-001",
"name": "Missing Consent Check Risk",
"description": "Detects endpoints accepting personal data without apparent consent verification",
"related_laws": ["PIPA-15"]
}
]ID | Name | What it looks for | Risk | Related Law |
| Personal Data Logging |
| MEDIUM | PIPA Art. 29 |
| Unencrypted Personal Data | Sensitive identifier fields (resident number, SSN) without encryption annotations or calls | HIGH | PIPA Art. 24-2, 29 |
| Missing Consent Check |
| HIGH | PIPA Art. 15 |
| Marketing Message Consent | Advertising/marketing message dispatch ( | MEDIUM | Network Act Art. 50 |
| Unprotected Credit Information | Credit/financial identifier fields (card number, account number, credit score) without encryption or masking | HIGH | Credit Information Act Art. 19 |
| Transaction Record Retention | Transaction record fields (order/payment IDs) stored without apparent retention or preservation handling | MEDIUM | E-Commerce Act Art. 6 |
| Personal Data Retention | Personal data fields (email, phone, resident number) stored without apparent destruction or retention-limit handling | MEDIUM | PIPA Art. 21 |
| Third-Party Data Transfer | Personal data sent to a third-party or external endpoint (outbound call to an external URL/partner) without an apparent consent check | HIGH | PIPA Art. 17 |
Detectors use regex-based pattern matching. They support both English and Korean field names (e.g., email/이메일, residentNumber/주민번호, consent/동의).
klaws can run as an MCP server, making its scanning capabilities available to AI coding assistants.
klaws serveTool | Description |
| Scan a directory for compliance risks |
| Scan a single file |
| List all available detectors |
| Look up a Korean law provision by ID |
All clients use the same launch command: klaws serve over stdio. Use the absolute path to the binary (run which klaws, or where klaws on Windows, to find it), or just klaws if it is on your PATH. Prefer not to install anything? Use the Docker variant below — it works in any client that supports stdio MCP servers.
Claude Code — ~/.claude/settings.json:
{
"mcpServers": {
"klaws": {
"command": "klaws",
"args": ["serve"]
}
}
}Or add it in one command:
claude mcp add klaws -- klaws serveClaude Desktop — claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"klaws": {
"command": "klaws",
"args": ["serve"]
}
}
}Cursor — ~/.cursor/mcp.json (or .cursor/mcp.json in a project):
{
"mcpServers": {
"klaws": {
"command": "klaws",
"args": ["serve"]
}
}
}VS Code — .vscode/mcp.json:
{
"servers": {
"klaws": {
"command": "klaws",
"args": ["serve"]
}
}
}Once connected, ask your assistant something like "scan this directory for Korean compliance risks with klaws."
No binary install needed — swap the command/args for a docker run that mounts the code you want scannable. The -i flag keeps stdin open for the stdio transport; --scan-root /src confines scans to the mounted directory:
{
"mcpServers": {
"klaws": {
"command": "docker",
"args": [
"run", "--rm", "-i",
"-v", "/absolute/path/to/your/project:/src:ro",
"ghcr.io/rostradamus/klaws:latest",
"serve", "--scan-root", "/src"
]
}
}
}Point the assistant at paths under /src (the container-side mount), e.g. "scan /src for Korean compliance risks."
By default klaws serve uses stdio (local). To run it as a remote MCP server over HTTP, pass --http:
klaws serve --http :8080
# or via the published container image:
docker run --rm -p 8080:8080 ghcr.io/rostradamus/klaws serve --http :8080The MCP endpoint is then available at http://<host>:8080/mcp (Streamable HTTP transport). Point an HTTP-capable MCP client at that URL.
klaws serve --http :8080 \
--auth-token "$(openssl rand -hex 32)" \
--scan-root /workspace--auth-token <token> — requires Authorization: Bearer <token> on every HTTP request; unauthenticated requests get 401. Can also be supplied via the KLAWS_AUTH_TOKEN environment variable. Applies to --http only.
--scan-root <dir> — restricts scan_directory / scan_file to paths within <dir>; requests for paths outside it are rejected. (Also honored in stdio mode.)
Notes:
--auth-tokenprovides bearer auth but not TLS. For untrusted networks, still terminate TLS at a reverse proxy / gateway in front of klaws.The
scan_directoryandscan_filetools read the server's filesystem (the paths you pass resolve on the host running klaws). For remote scanning, run klaws where the code lives (e.g. a CI runner with the repo checked out) and set--scan-rootto that checkout. Theget_law_referenceandlist_detectorstools have no filesystem dependency.
klaws ships with 40 articles across 4 Korean laws embedded in the binary (no external files needed):
ID | Article | Topic |
| Art. 15 | Collection and use of personal information |
| Art. 17 | Provision to third parties |
| Art. 18 | Restriction on use beyond purpose |
| Art. 21 | Destruction of personal information |
| Art. 23 | Restriction on sensitive information |
| Art. 24 | Restriction on unique identification info |
| Art. 24-2 | Restrictions on resident registration numbers |
| Art. 29 | Duty of safety measures |
| Art. 30 | Privacy policy |
| Art. 34 | Notification of data breach |
ID | Article | Topic |
| Art. 22 | Consent for collection/use of personal info |
| Art. 23 | Restriction on collection |
| Art. 23-2 | Restriction on resident registration numbers |
| Art. 24 | Restriction on use |
| Art. 24-2 | Provision to third parties |
| Art. 27 | Safety measures |
| Art. 28 | Entrustment of personal info |
| Art. 28-2 | Notification of data breach |
| Art. 44 | User protection |
| Art. 44-7 | Prohibition of illegal information |
| Art. 50 | Restriction on transmission of advertising info |
ID | Article | Topic |
| Art. 15 | Principles of collection |
| Art. 17 | Prohibition of disclosure beyond purpose |
| Art. 19 | Safety of credit info systems |
| Art. 20 | Accuracy and currency of credit info |
| Art. 32 | Consent for provision/use |
| Art. 33 | Use of personal credit info |
| Art. 34 | Provision/use of personal credit info |
| Art. 38 | Protection of credit info |
| Art. 39 | Notification of data breach |
| Art. 40 | Rights of credit info subjects |
ID | Article | Topic |
| Art. 6 | Preservation of transaction records |
| Art. 7 | Prevention of operational errors |
| Art. 11 | Reliability of electronic payment |
| Art. 13 | Provision of identity and transaction info |
| Art. 14 | Confirmation of orders |
| Art. 17 | Right of withdrawal |
| Art. 21 | Use of consumer information |
| Art. 24 | Cybermall security |
| Art. 26 | Protection of consumer information |
Full Korean article text is included. Use --live to fetch the latest version from law.go.kr.
klaws is designed to be safe to point at private code:
Local-only analysis. Scanning is pure static pattern-matching on files you pass in. Source code never leaves your machine — nothing is uploaded, logged remotely, or sent to any service.
One optional outbound call. The only network request klaws ever makes is the --live law lookup (CLI) / get_law_reference with live fetch (MCP), which fetches public statute text from law.go.kr. It sends only the statute's name (e.g. 개인정보보호법, resolved from the provision you looked up) as the search query — never your code. Omit --live to stay fully offline.
Read-only by design. klaws only reads the files it scans; it never modifies your code. Its MCP tools are annotated read-only.
Confine the reachable filesystem. When exposing the MCP server, pass --scan-root <dir> to restrict scan_directory/scan_file to a single tree, and --auth-token when serving over --http. See Securing a remote server.
To report a vulnerability, see SECURITY.md.
klaws scan ./src
│
▼
FileWalker ──► walks directory, matches glob pattern
│
▼
ScannerService ──► reads each file
│
▼
DetectorRegistry ──► runs all detectors on source code
│
▼
Findings ──► mapped to law provisions
│
▼
Report ──► JSON or text outputMore detectors: marketing-message consent (NIA-MKT-001) (done), unprotected credit information (CIA-ENC-001) (done), transaction-record retention (ECA-RET-001) (done), personal-data retention (PIPA-RET-001) (done), third-party/cross-border transfer (PIPA-XBR-001) (done)
Multi-language: Python, JavaScript/TypeScript detection patterns
More Korean laws: E-Commerce Act (전자상거래법) consumer protection rules (done), Network Act (정보통신망법) (done), Credit Information Act (신용정보법) (done)
CI/CD: GitHub Action, SARIF output, severity thresholds (done)
Configuration: custom pattern rules via config file
klaws ships a composite action that scans your code and produces a SARIF report, which you can upload to GitHub code scanning so findings appear inline on pull requests and in the Security tab.
# .github/workflows/klaws.yml
name: klaws compliance scan
on: [pull_request]
permissions:
contents: read
security-events: write # required to upload SARIF
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- id: klaws
uses: rostradamus/klaws@v0 # moving major tag; add `version: vX.Y.Z` below to pin the klaws binary
with:
path: ./src
pattern: "*.java"
fail-on: none # or MEDIUM / HIGH to gate the PR
- name: Upload SARIF
if: always() # upload even if fail-on tripped the step
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: ${{ steps.klaws.outputs.sarif }}Set fail-on: HIGH (or MEDIUM) to make the check fail the PR when findings at that severity or above are present. The if: always() on the upload step ensures the SARIF is still published when the gate fails.
Maintainers: see RELEASE.md for how to cut a release and publish to the MCP registry.
MIT
Look up a bundled Korean law provision by ID and return its Korean and English names, a plain-language summary, the source URL on law.go.kr, a risk level, and (when available) the full Korean article text. Typically used to expand a related_laws ID returned by a scan. This is reference material, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| live | No | If true, fetch the latest full text from law.go.kr (requires network access). If false (default), use the text bundled in the binary. | |
| law_id | Yes | Bundled provision ID. Examples by law: PIPA-15, PIPA-29 (개인정보 보호법); NIA-22, NIA-50 (정보통신망법); CIA-19 (신용정보법); ECA-6 (전자상거래법). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a safe read operation, but annotation destructiveHint: true contradicts this. The description does not disclose any destructive behavior, and the conflict undermines transparency. Score 1 due to contradiction.
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?
Two sentences with no fluff. Front-loaded with purpose, followed by usage hint and disclaimer. 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?
Without output schema, description adequately lists return fields (names, summary, URL, risk level, full text when available). Mentions typical use case. Could briefly note network requirements for live=true, but overall complete.
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 100%, but description adds valuable examples for law_id and explains live parameter behavior (fetch latest vs. bundled). Provides additional context beyond schema.
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?
Clearly states the tool looks up a bundled Korean law provision by ID and returns specific fields. Also mentions typical use case of expanding a related_laws ID from a scan. No need to differentiate from siblings as they are unrelated.
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?
Describes typical usage: 'expand a related_laws ID returned by a scan.' Also clarifies it's reference material, not legal advice. Lacks explicit when-not-to-use or alternatives, but sufficient given narrow scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every available compliance risk detector with its id, name, description (the code pattern it looks for), and the related_laws it maps to. Use this to explain what klaws checks for, or to see which risks to expect before scanning. Takes no arguments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description accurately portrays a read-only list operation, but annotations contain destructiveHint=true which contradicts this. The description does not address the contradiction or provide additional behavioral 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?
Two sentences, front-loaded with the action and results. No extraneous information.
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?
Completely describes what the tool returns and its use case. No output schema needed for such a simple list.
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?
No parameters in schema; description confirms 'Takes no arguments.' This is sufficient given 0 parameters and 100% schema coverage.
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 lists all compliance risk detectors with specific fields (id, name, description, related_laws). It is distinct from sibling tools like scan_directory and get_law_reference.
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?
Explicitly says use it to explain what klaws checks for or to see risks before scanning. No explicit exclusion of alternatives, but implied differentiation from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan all matching files in a directory tree for possible Korean compliance risks across PIPA, the Network Act, the Credit Information Act, and the E-Commerce Act. Returns a JSON report where each finding has a detector_id, risk_level (HIGH or MEDIUM), file_path, line_number, snippet, a hedged message, and related_laws (provision IDs you can pass to get_law_reference). Findings are possible risks for review, not legal conclusions. Use this for a whole project or folder; use scan_file for a single file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the directory to scan (e.g. /Users/me/project/src). | |
| file_pattern | No | Glob pattern selecting which files to scan. Defaults to *.java. Examples: "*.java", "*.kt". Detectors target Java/Kotlin-style source. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description presents a read-only scanning operation, but annotations include destructiveHint=true, creating a contradiction. The description does not address or explain this destructive annotation, which could mislead an agent.
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?
Description is concise (5 sentences) with front-loaded purpose. Every sentence adds value: purpose, output format, clarification of findings, usage guidelines, and sibling reference. No wasted words.
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 with 2 parameters and no output schema, the description provides comprehensive context: purpose, return structure, legal caveats, related tool (get_law_reference), and usage guidance. Covers all necessary aspects.
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 100% with parameter descriptions. The description adds context: default pattern '*.java', examples, and mentions detectors target Java/Kotlin-style source, enhancing understanding beyond the schema.
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 function: scanning a directory tree for Korean compliance risks across specific acts. It specifies the output format and distinguishes from sibling tool scan_file for single files.
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?
Explicitly tells when to use this tool ('for a whole project or folder') and when to use the alternative ('use scan_file for a single file'). No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a single source file for possible Korean compliance risks and return the same JSON report shape as scan_directory. Use this to check one file (for example, the file currently being edited); use scan_directory to review a whole project. Findings are possible risks for review, not legal conclusions.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the file to scan (e.g. /Users/me/project/src/UserService.java). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description does not address the contradiction in annotations: readOnlyHint true but destructiveHint true. The description implies a read-only scan, but annotations suggest possible destructiveness. No explanation provided.
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?
Two sentences, front-loaded with purpose and usage, no redundancy. Every sentence adds 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?
Covers purpose, usage, and output shape (same as scan_directory). Missing discussion of permissions or error handling, but adequate for a simple tool. Slightly incomplete due to not addressing annotation contradiction.
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 already fully describes the path parameter with 100% coverage. Description adds only an example path, not substantial new meaning beyond schema.
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?
Clearly states it scans a single file for Korean compliance risks and returns JSON report. Distinguishes from sibling scan_directory by specifying single file vs whole project.
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?
Explicitly says use this for checking one file (e.g., current editor) and scan_directory for whole project. Also notes findings are not legal conclusions.
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. Dates show when Glama detected each change.
v0.1.0get_law_referencelist_detectorsscan_directoryscan_fileEach tool has a distinct purpose: get_law_reference looks up laws by ID, list_detectors lists available detectors, scan_directory scans entire directories, and scan_file scans single files. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case: get_law_reference, list_detectors, scan_directory, scan_file. The naming is predictable and uniform.
With 4 tools, the set is concise yet complete for its domain. It covers the necessary operations: listing detectors, scanning, and law reference lookup. No excess or deficiency.
The tool surface covers the full workflow: discover detectors (list_detectors), scan files (scan_directory/scan_file), and retrieve legal references (get_law_reference). There are no obvious gaps for the intended use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Scan any public GitHub MCP-server repo for security issues. 37 MCP-specific L1 rules, 8 languages.
Compliance lint for AI, scraping, and privacy law. Cited findings in 200 or more jurisdictions.
Generate, audit, and maintain legal policies that match what your code actually does.
US federal and state cybersecurity/privacy law MCP server with cross-state comparison
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rostradamus/klaws'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
