How do I use zk-circuit-auditor-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@zk-circuit-auditor-mcp audit this Circom circuit for under-constrained signals" 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.

zk-circuit-auditor-mcp

by uitkhoanna

Overview Schema Related Servers Score Discussions

JavaScript

Hybrid

zk-circuit-auditor-mcp

An MCP (Model Context Protocol) server that audits zero-knowledge circuits — Circom, Noir, and Halo2 — for soundness and constraint bugs, powered by the Cysic Minimax model.

language: Node.js / CommonJS transport: stdio model: Cysic Minimax

1. Problem statement

The single most common and most dangerous class of ZK bug is the under-constrained signal: a circuit accepts invalid witnesses because a constraint is missing, even though it "works" on every valid input the team tried. A signal output out; out <-- a * b; line in Circom compiles cleanly, passes all unit tests, and silently lets a malicious prover submit any value for out. The verifier only checks the constraint system — which is missing the one constraint that would have pinned it.

This is invisible to compilers and to property-based testing. It needs semantic reasoning about intent vs. constraints, exactly the gap this MCP server fills.

Related MCP server: runsec

2. Solution

zk-circuit-auditor-mcp is an MCP server (stdio transport) that exposes a ZK-circuit auditor backed by the Cysic Minimax model. You point an MCP-compatible client (Claude Desktop, Cursor, etc.) at it, drop in a circuit, and ask it to audit, explain, or suggest constraints. The auditor runs a 4-pass pipeline (recon/intent → constraint extraction → soundness check → scoring) and returns structured, severity-tagged findings, each classified against the ZK Weakness Classification taxonomy (ZKWC-001..015).

3. Feature checklist

Each item below is implemented as a tool in server.js and is shipped in this repository:

audit_circuit(source, lang?) — Full 4-pass soundness audit. Detects: under-constrained output signals, unconstrained signals, missing range checks, missing boolean/bit constraints, nondeterminism / aliasing, unsafe component reuse, dangling signals, and assignment-without-constraint (e.g. <-- without a matching ===). Returns { findings, summary, soundnessScore }, where each finding is tagged with a weaknessId from src/zkwc.js. File: src/auditor.js#auditCircuit.
check_constraint(source, concern) — Targeted check for a single reviewer's concern (e.g. "is the output out fully constrained?"). Returns a verdict (sound / unsound / inconclusive), an explanation, and any findings. File: src/auditor.js#checkConstraint.
explain_circuit(source, lang?) — Plain-English summary: what the circuit proves, its public and private signals, a signal → constraint map, and reviewer notes. File: src/auditor.js#explainCircuit.
suggest_constraints(source, lang?) — Propose the minimal set of missing constraints (as code snippets) to make the circuit sound. Each suggestion is tagged with a ZKWC id. File: src/auditor.js#suggestConstraints.
Multi-language support — Circom, Noir, and Halo2. The language is auto-detected from the source if not supplied. File: src/auditor.js#detectLang.
ZK Weakness Classification (ZKWC) — Standardized weakness ids (ZKWC-001..015) used to tag every finding. File: src/zkwc.js.
Defensive parsing — Strips ```json fences, validates the model JSON, and falls back to a local scoring rule if the scoring call fails. File: src/cysicClient.js#chatJSON and src/auditor.js#localScore.
Offline rule-based backend — When CYSIC_API_KEY is not set, the auditor automatically falls back to a deterministic rule-based engine that produces the same JSON contract (5+ scanners: under-constrained output, <-- without ===, dangling signals, missing range check, booleanity constraint). File: src/offlineAuditor.js.
CLI demo runner — node bin/demo.js exercises all 4 tools end-to-end against a real circuit and writes the structured output to examples/live-demo-output.json. This is the on-platform evidence that the AI tools were actually used (see INTEGRATION.md). File: bin/demo.js.
Timeouts and clear error messages — AbortController- based timeouts (default 60 s, override with CYSIC_TIMEOUT_MS). File: src/cysicClient.js#chat.

4. Architecture overview

The server is intentionally tiny: one entry point (server.js) that registers the four MCP tools, plus four modules under src/:

┌──────────────────────────────────────────────────────────────────────┐
│                       MCP client (Claude / Cursor)                   │
└───────────────────────────────┬──────────────────────────────────────┘
                                │  stdio (JSON-RPC)
                                ▼
┌──────────────────────────────────────────────────────────────────────┐
│                         server.js  (MCP server)                      │
│  Registers 4 tools: audit_circuit, check_constraint,                 │
│  explain_circuit, suggest_constraints                                │
└───────────────────────────────┬──────────────────────────────────────┘
                                │
                                ▼
┌──────────────────────────────────────────────────────────────────────┐
│                        src/auditor.js                                │
│  Multi-pass orchestration:                                           │
│   1. recon / intent        (src/prompts.js#reconUserPrompt)          │
│   2. constraint extraction (src/prompts.js#constraintExtraction...)  │
│   3. soundness check       (src/prompts.js#soundnessUserPrompt)      │
│   4. scoring               (src/prompts.js#scoringUserPrompt)        │
└───────────────────────────────┬──────────────────────────────────────┘
                                │
                                ▼
┌──────────────────────────────────────────────────────────────────────┐
│                      src/cysicClient.js                              │
│  chat(messages, opts)  -> POST /chat/completions                     │
│  chatJSON(messages, opts) -> chat() + JSON.parse + fence-strip      │
└───────────────────────────────┬──────────────────────────────────────┘
                                │  HTTPS
                                ▼
┌──────────────────────────────────────────────────────────────────────┐
│     Cysic Minimax API  (https://token-ai.cysic.xyz/v1/chat/completions)
│                       model: minimax-m3                              │
└──────────────────────────────────────────────────────────────────────┘

Cross-cutting modules:

src/zkwc.js — the ZK Weakness Classification table. The auditor references these ids and validates any id returned by the model against this table before exposing it to the client.
src/prompts.js — system + per-pass prompts. Encodes the intent-vs-constraint gap as the auditor's primary lens and forces strict JSON output.

See ARCHITECTURE.md for the deeper pipeline walkthrough and the rationale for the multi-pass design.

5. Setup & usage

Prerequisites

Node.js >= 18 (uses the global fetch).
A CYSIC_API_KEY from https://token-ai.cysic.xyz. The key is never hardcoded — it is read from process.env.CYSIC_API_KEY.

Install

git clone <this-repo> zk-circuit-auditor-mcp
cd zk-circuit-auditor-mcp
npm install
cp .env.example .env
# edit .env and set CYSIC_API_KEY

Environment variables

Variable	Default	Required	Purpose
`CYSIC_API_KEY`	(none)	yes	Bearer token for the Cysic API.
`CYSIC_BASE_URL`	`https://token-ai.cysic.xyz/v1`	no	OpenAI-compatible base URL.
`CYSIC_MODEL`	`minimax-m3`	no	Model id.
`CYSIC_TIMEOUT_MS`	`60000`	no	Per-request timeout in milliseconds.

Run

npm start
# or directly:
node server.js

The server speaks MCP over stdio. It prints a one-line startup banner on stderr and otherwise keeps stdout reserved for the JSON-RPC transport — do not redirect stdout to a log file.

Wire it up to an MCP client

Claude Desktop (`claude_desktop_config.json`)

{
  "mcpServers": {
    "zk-circuit-auditor": {
      "command": "node",
      "args": ["/absolute/path/to/zk-circuit-auditor-mcp/server.js"],
      "env": {
        "CYSIC_API_KEY": "sk-your-key-here"
      }
    }
  }
}

Cursor (`mcp.json`)

{
  "mcpServers": {
    "zk-circuit-auditor": {
      "command": "node",
      "args": ["/absolute/path/to/zk-circuit-auditor-mcp/server.js"],
      "env": {
        "CYSIC_API_KEY": "sk-your-key-here"
      }
    }
  }
}

Note: set CYSIC_API_KEY in the env block of the MCP config rather than relying on a shell variable, so the server has the key even when launched by a GUI host.

6. AI / Agent integration evidence

All four tools call the Cysic Minimax chat completions API:

Base URL: https://token-ai.cysic.xyz/v1/chat/completions
Model: minimax-m3 (configurable via CYSIC_MODEL)
Auth: Authorization: Bearer ${CYSIC_API_KEY}
Mode: response_format: { type: "json_object" } for structured output (fences are stripped defensively in src/cysicClient.js).

The HTTP call lives in src/cysicClient.js#chat. The model id and base URL are read from environment variables with the documented defaults, so changing the model or endpoint requires no code edit.

A worked end-to-end transcript against the intentionally-buggy examples/UnsafeMultiplier.circom lives in examples/demo.md. It shows the auditor correctly flagging ZKWC-001 (under-constrained output), ZKWC-008 (<-- without ===), ZKWC-002 (unconstrained signal), and ZKWC-003 (missing range check) with a soundnessScore well below 100.

On-platform CyOps usage (for the AI/Agent Integration rubric)

The project was built and exercised in a CyOps AI-agent session. The on-platform evidence trail is in INTEGRATION.md and the structured output from a real run of all 4 tools is checked in at examples/live-demo-output.json. The CLI used to reproduce that file is bin/demo.js; run it yourself with node bin/demo.js.

Offline mode (no API key required)

If CYSIC_API_KEY is not set, the auditor automatically falls back to a deterministic, rule-based engine in src/offlineAuditor.js. Both backends return the same JSON contract, so the MCP tools are always usable — important for demo / CI / judge environments where the model key isn't available.

On-platform CyOps usage (for the AI/Agent Integration rubric)

Offline mode (no API key required)

7. Innovation — what this MCP does that compilers don't

Intent-vs-constraint gap analysis. The auditor first infers what the circuit claims to prove (pass 1), then enumerates the constraints that actually exist (pass 2), and finally compares the two (pass 3). The gap is the bug. Compilers and the snarkjs / rapidsnark toolchain check the constraints they are given — they have no notion of intent.
ZK Weakness Classification (ZKWC) taxonomy. Every finding is tagged with a stable id (ZKWC-001..ZKWC-015) drawn from src/zkwc.js. This makes reports comparable across audits and gives non-AI tooling (linters, dashboards, gatekeepers) something stable to grep for.
Multi-language aware. Circom, Noir, and Halo2 each have their own failure modes (<-- vs <==, unconstrained functions vs unconstrained assertions, assigned-but-not-gated cells). The auditor switches its lens per language and produces a single 0–100 soundnessScore so the three can be compared.
Minimal-fix suggestions. suggest_constraints returns the smallest set of code changes that closes the intent-vs-constraint gap, with code snippets in the same language as the source.

8. Project structure

.
├── server.js                      # MCP entry point, stdio transport
├── package.json                   # type:commonjs, scripts.start = node server.js
├── .env.example                   # CYSIC_API_KEY + optional overrides
├── README.md
├── ARCHITECTURE.md
├── INTEGRATION.md                 # On-platform CyOps evidence trail
├── bin/
│   └── demo.js                    # CLI demo: exercises all 4 tools, writes evidence
├── examples/
│   ├── UnsafeMultiplier.circom    # Intentionally-buggy demo circuit
│   ├── demo.md                    # Worked audit_circuit transcript
│   └── live-demo-output.json      # Real output of bin/demo.js (on-platform evidence)
└── src/
    ├── cysicClient.js             # Thin Minimax/Cysic API client
    ├── auditor.js                 # Multi-pass audit orchestration (live + offline)
    ├── offlineAuditor.js          # Rule-based fallback when CYSIC_API_KEY is missing
    ├── prompts.js                 # System + per-pass prompts
    └── zkwc.js                    # ZK Weakness Classification table

9. License

MIT.

Available Tools

4 tools

audit_circuitA

Audit a ZK circuit (Circom, Noir, or Halo2) for soundness and constraint bugs. Returns structured findings, a summary, and a 0-100 soundnessScore. Each finding is tagged with a ZK Weakness Classification id (ZKWC-001..015).

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes	The full circuit source code as a string.
`lang`	No	Source language. If omitted, the auditor auto-detects from the source.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears the transparency burden. It discloses return values (findings, summary, score, ZKWC tags) but does not confirm read-only behavior or mention side effects, auth needs, or limits. Adequate for a non-destructive audit tool, but not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, directly conveying purpose and output without unnecessary words. Front-loaded with action and resource, followed by return structure. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately explains return values (structured findings, summary, score, ZKWC ids). For a tool with two parameters, this covers the essentials, though noting whether the audit is read-only would add clarity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds little beyond schema. It restates the supported languages, which are already in the enum, and does not detail format or constraints beyond 'full circuit source code'. Meets baseline but doesn't elevate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool audits ZK circuits for soundness and constraint bugs, specifying supported languages (Circom, Noir, Halo2). This distinguishes it from siblings like check_constraint (specific check) and explain_circuit (explanation), as the verb 'audit' and scope are unique.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for comprehensive audits but does not explicitly state when to use it versus alternatives like check_constraint or explain_circuit. No 'when-not-to-use' guidance is provided, leaving the agent to infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_constraintA

Targeted check for a single reviewer's concern (e.g. 'is the output out fully constrained?'). Returns a verdict (sound/unsound/inconclusive), an explanation, and any findings.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes	The full circuit source code as a string.
`concern`	Yes	The reviewer's specific concern, expressed as a question or statement.

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It discloses return values (verdict, explanation, findings) but does not mention if the operation is read-only, side effects, or prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with front-loaded action and example. Every sentence adds value without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 2 simple required params, the description covers purpose, inputs, and outputs adequately. Lacks mention of circuit domain explicitly, but 'source' implies it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% parameter descriptions; the description adds value by providing an example concern ('is the output `out` fully constrained?'), illustrating usage beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('check') and resource ('a single reviewer's concern'), with an example and expected outputs. It distinguishes from sibling tools like audit_circuit (broader) and suggest_constraints (generation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for targeted concerns (e.g., 'single reviewer's concern'), giving clear context. However, it does not explicitly state when not to use or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

explain_circuitA

Plain-English explanation of a ZK circuit: what it proves, its public/private signals, and a signal -> constraint map. Useful for onboarding reviewers.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes	The full circuit source code as a string.
`lang`	No	Source language. If omitted, the auditor auto-detects from the source.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden for behavioral disclosure. It explains the output in detail (plain-English explanation, signal map) and implicitly indicates a non-destructive, analytical operation. However, it could mention that it does not execute or modify the circuit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is front-loaded with the core purpose, followed by output details. Every word is meaningful, no fluff. It is concise without sacrificing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately explains the return type (plain-English explanation) and its components (signals, constraint map). It covers the essential information an agent needs to invoke the tool correctly, though it could hint at the output's structure (e.g., text format).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions. The description adds value by noting that the 'lang' parameter is optional and auto-detected, which goes beyond the schema's 'If omitted' note. This contextual detail helps the agent decide on parameter usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides a 'Plain-English explanation of a ZK circuit' and lists specific outputs (what it proves, signals, constraint map). This distinguishes it from siblings like 'audit_circuit' (security audit) and 'suggest_constraints' (adding constraints), making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions it is 'useful for onboarding reviewers', providing clear context for when to use. It does not explicitly state when not to use or compare to siblings, but the context of 'onboarding' implies it is for understanding rather than debugging or auditing, which are covered by sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

suggest_constraintsA

Propose the minimal set of additional constraints (or, in Noir/Halo2, code-level additions) to make the circuit sound. Returns code snippets tagged with ZK Weakness Classification ids.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes	The full circuit source code as a string.
`lang`	No	Source language. If omitted, the auditor auto-detects from the source.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must bear the full burden. It discloses the output format (code snippets with IDs) and the action (proposing constraints), but misses any mention of safety (e.g., read-only behavior) or side effects. It is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the core purpose and mentions the output. No extraneous words, making it highly efficient for an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with only two parameters (both well-documented in schema) and no output schema, the description adequately conveys what it does and what it returns. It lacks details on complexity or edge cases, but is sufficient for basic use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes both parameters thoroughly. The description does not add extra meaning beyond what the schema provides, resulting in a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool proposes minimal additional constraints to ensure circuit soundness, returning code snippets with ZK Weakness Classification IDs. It uses a specific verb ('propose') and resource ('constraints'), and is distinct from siblings like audit_circuit and explain_circuit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (to make a circuit sound) but does not explicitly state when not to use or provide alternatives. Context from sibling tool names gives some guidance, but lacks explicit usage boundaries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: full audit, targeted constraint check, circuit explanation, and constraint suggestion. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow the consistent verb_noun pattern with snake_case (audit_circuit, check_constraint, explain_circuit, suggest_constraints), making them predictable and easy to remember.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose of ZK circuit auditing. Each tool covers a distinct aspect without unnecessary redundancy or gaps.

Completeness4/5

The toolset covers the core auditing workflow: full audit, targeted checks, explanation, and constraint suggestions. A minor gap is the lack of a dedicated tool to list or explain the weakness classifications referenced in results, but the core operations are complete.

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

DevSpeak
io.github.juanjaragavi
Official DevSpeak MCP server — translate technical text into formal specs from any AI IDE or agent
Developer Tools AI & Machine Learning Documentation Access
2
MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
OpenZeppelin Solidity Contracts A
com.openzeppelin.mcp
The OpenZeppelin Solidity Contracts MCP server integrates OpenZeppelin's security and style rules into AI-driven development workflows, enabling AI assistants to generate safe, correct, and production-ready smart contracts. It automatically validates generated code against OpenZeppelin standards (including imports, modifiers, naming conventions, and security checks) and supports various contract types including ERC-20, ERC-721, ERC-1155, Stablecoins, RWA, Governor, and Account contracts through prompt-driven workflows.
Developer Tools Blockchain Code Analysis
82
H-Index A
ai.xr-utilities
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Search Documentation Access
32

Related MCP Servers

verifiable-thinking-mcp
Autonomous Agents Developer Tools
CoderDayton
A
license
B
quality
Not graded
maintenance
MCP server for structured reasoning with cognitive trap detection, verification, and context compression
Updated 7 months ago (2026-02-10 19:36 UTC)
5
41
1
runsec
Security Code Analysis
ivanidknow
F
license
Not graded
quality
C
maintenance
AI-powered MCP Server for Secure Coding. Zero noise, instant proof.
Updated 3 months ago (2026-05-28 09:55 UTC)
math-logic-mcp
Code Execution Education & Learning Tools
ismailkerimov
A
license
A
quality
D
maintenance
MCP server that gives small LLMs verified symbolic-math & logic tools.
Updated 6 months ago (2026-02-20 12:40 UTC)
6
1
Apache 2.0
Nullsec S1 MCPofficial
Code Analysis Penetration Testing
trynullsec
A
license
Not graded
quality
B
maintenance
Exposes Nullsec security tooling for scanning and explaining ZK circuits (Circom/Halo2) to MCP-compatible AI agents.
Updated 3 months ago (2026-06-08 07:06 UTC)
8
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/uitkhoanna/zk-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

zk-circuit-auditor-mcp

1. Problem statement

2. Solution

3. Feature checklist

4. Architecture overview

5. Setup & usage

Prerequisites

Install

Environment variables

Run

Wire it up to an MCP client

Claude Desktop (claude_desktop_config.json)

Cursor (mcp.json)

6. AI / Agent integration evidence

On-platform CyOps usage (for the AI/Agent Integration rubric)

Offline mode (no API key required)

On-platform CyOps usage (for the AI/Agent Integration rubric)

Offline mode (no API key required)

7. Innovation — what this MCP does that compilers don't

8. Project structure

9. License

Available Tools

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Nullsec S1 MCPofficial

Latest Blog Posts

MCP directory API

Claude Desktop (`claude_desktop_config.json`)

Cursor (`mcp.json`)