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., "@campus-guardrails scan my ./miniapp project for leaked secrets and inline rpx styles before release"
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.
MCP server + 独立 CLI · 43 条从线上事故沉淀的 uni-app / 微信小程序开发约束
版权所有 (c) 2026 北京煜澜文化（beijingyulanwenhua）· 鸥吧（hiouba）
AI 编程助手帮你写小程序代码，往往"能跑，但处处是坑"：行内样式写 rpx 真机尺寸归零、defineProps 泛型写法产物丢 type、分包开关没开真机资源 404、提审被诱导分享红线驳回……
这个护栏把 43 条踩过血的坑变成 AI 可查询、项目可扫描的结构化规则。让 Claude / Cursor / 任意 MCP 客户端在写代码前拿到约束、发版前扫出违规。
市面上的小程序 MCP（封装微信开发者工具 CLI）解决的是"手"的问题——怎么编译、截图、点元素。本护栏解决的是"脑"的问题——怎么写不踩坑。两者互补，不重复。
Related MCP server: VibeGuard MCP Server
工具 | 说明 |
| 六大类：platform / packaging / compliance / performance / interaction / engineering |
| 规则索引，按分类与严重级过滤 |
| 规则详情：症状、成因、修复方案 |
| 静态扫描你的项目：rpx 行内样式、WXSS 通配/伪类、defineProps 泛型、分包开关、动画 fill-mode，外加密钥/内网 IP/服务器路径泄露红线 |
| 提审/上线检查清单（可选 first-release 场景） |
每条规则含 severity（error / warn / info）——给 AI 的硬约束，error 级必须遵守。
Claude Code / Cursor / 任意 MCP 客户端：
{
"mcpServers": {
"campus-guardrails": {
"command": "npx",
"args": ["-y", "campus-dev-guardrails"]
}
}
}本地开发（零依赖，Node ≥ 18）：
git clone https://github.com/hiouba/campus-dev-guardrails.git
cd campus-dev-guardrails
node server/index.jsnpm 包
campus-dev-guardrails发布后，上面一段可简化为npx -y campus-dev-guardrails。
建议工作流（写进你的系统提示词或直接对 AI 说）：
动手前按任务场景调
get_rules(category)；涉及布局/组件/动画先查对应规则；发版前跑lint_project；提审前调submit_checklist。
npx -y -p campus-dev-guardrails campus-guardrails-lint <项目路径>
# clone 本地：node bin/lint-cli.js <项目路径> [--json]退出码 0 通过 / 1 有警告 / 2 有 error 或敏感信息——可直接进 CI：
- run: npx -y -p campus-dev-guardrails campus-guardrails-lint ./miniapp
# 非零退出码自动让 CI 失败lint_project 对开源/发布前的包特别有用：它会揪出内网 IP、云密钥格式、真实 AppID、硬编码 token、服务器绝对路径——我们自己的项目被它逮到过真实的行内 rpx 隐患。
规则是纯 JSON，与 server 解耦，可独立消费：
做自己的 lint 工具、文档站、团队 wiki，直接读 rules/rules.json
提 Issue 增补规则；lintable: true 的规则欢迎附带扫描用例
字段：id / cat / sev / title / symptom / rule / fix / lintable
规则不是凭空写的最佳实践清单——每一条都对应一次真实线上事故（症状栏就是当时的现场）。
├── rules/rules.json # 43 条护栏规则（核心资产）
├── server/index.js # MCP server（stdio JSON-RPC，零依赖）
├── bin/lint-cli.js # 独立 CLI（可接 CI）
└── LICENSE.md # 鸥吧社区许可证Q：规则是怎么来的？ A：多校区校园小程序运营平台的历史事故沉淀——真机才暴露的编译坑、被微信驳回的合规项、包体积红线、资金链路的发布纪律。已剔除一切业务敏感信息。
Q：能商用吗？ A：学习/研究/社团工具免费；商业用途（收费服务、嵌入商业产品）需书面授权：hiouba@126.com。
Q：支持非校园项目吗？ A：platform / packaging / performance 三类规则对任何 uni-app 项目通用；compliance 中的类目与备案建议以校园场景为例，规则本身适用于微信生态。
Q：为什么不是一份文档？
A：文档 AI 读不全、读了不遵守优先级；MCP 让约束进入 AI 的工具调用链路，severity 提供强制语义，lint_project 提供事后验证。文档版也在规划中。
Issues 提规则、报误报；商用与定制联系 hiouba@126.com；系列项目见 github.com/hiouba（校园集市论坛 / 校园代丢垃圾跑腿）。
获取规则详情（含症状、成因、修复方案）。传 ids 精确取，或传 category 取整类，都不传取全量。写代码前先按任务场景取对应类规则遵守。
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose the important default (no args returns the entire rule set) and the shape of returned content, but says nothing about result size, ordering, or whether the full-set call is expensive — a real risk given the unbounded default.
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?
Three short sentences, front-loaded with what is returned, then the three calling modes, then the workflow advice. No filler and nothing buried.
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 2-parameter read tool with no output schema and no annotations, the description covers return contents, both parameters, and the no-argument default. The remaining gap is that valid category values are neither enumerated in the schema nor pointed to via list_categories.
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 0%, so the description must compensate, and it does: ids is defined as precise lookup by identifier and category as whole-class retrieval, including the combination semantics of omitting both. It still doesn't clarify mutual exclusivity of ids vs category or the accepted category values (no enum in 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?
States a specific verb (获取) and resource (规则), and adds that the payload includes 症状、成因、修复方案, which distinguishes it from the sibling list_rules/list_categories by depth of content. It stops short of naming those siblings explicitly, so the differentiation is inferred rather than stated.
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?
Gives explicit selection rules for all three modes: ids for a precise fetch, category for a whole class, neither for the full set. It also supplies a workflow trigger — fetch the matching rule category before writing code — which tells the agent when in a task this tool should fire.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
对指定 uni-app/微信小程序项目目录做静态护栏扫描：rpx 行内样式、WXSS 通配/伪类、defineProps 泛型、分包开关与资源位置、动画 fill-mode、以及密钥/内网信息泄露红线。返回违规清单（含修复建议）。发版/开源前必跑。
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | 项目根目录绝对路径 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: '静态' scanning plus '返回违规清单（含修复建议）' makes clear the operation is a non-mutating analysis that returns a violation list with fix suggestions. It omits whether the scan is recursive, whether it requires dependency installation or a build step, and roughly how costly it is, which are the remaining gaps for an unannotated tool.
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 verb and resource, then the checklist. The check enumeration is long but each item conveys what will be reported, so it earns its place; the phrasing is dense rather than padded.
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?
No output schema exists, and the description compensates by stating the return is a violation list including remediation advice. Combined with a fully documented single parameter, an agent has enough to invoke it correctly; missing are scan scope/depth and expected runtime or failure modes.
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% and the single parameter is well documented as an absolute project root path. The description adds only a light qualifier — that the directory must be a uni-app/WeChat mini-program project — which meaningfully constrains what path is valid beyond the schema's generic 'project root absolute path'.
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 gives a specific verb (静态护栏扫描 / static guardrail scan) and resource (uni-app/微信小程序 project directory), then enumerates exactly what classes of violations are checked (rpx inline styles, WXSS universal/pseudo-class selectors, defineProps generics, subpackage flags, animation fill-mode, secret/intranet leakage). It is unmistakably distinct from siblings like list_rules or get_rules, which are rule-catalog tools rather than scanners.
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?
"发版/开源前必跑" gives a concrete trigger condition for invoking the tool, which is the key routing signal an agent needs. It doesn't name exclusions or alternatives, but the sibling tools are unrelated catalog/submission utilities, so no disambiguation is really required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出护栏规则分类（platform/packaging/compliance/performance/interaction/engineering）。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden; it does disclose the important behavior that the result is a fixed, closed set of six category names rather than a dynamic query. It says nothing about ordering, identifiers vs display names, or that a read has no side effects.
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?
A single front-loaded sentence that names the resource and immediately delivers the enumerated values. Nothing is redundant.
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?
With no parameters, no output schema, and no annotations, the description supplies almost everything needed by spelling out the return set inline. A small gap remains: it does not say whether these strings are the exact values accepted by sibling tools such as list_rules for filtering.
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?
Zero parameters, so there is no parameter semantics to explain; the schema is empty and complete. Baseline 4 applies.
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 names a specific verb and resource ("列出护栏规则分类") and enumerates the six categories, so an agent knows exactly what comes back. It implicitly separates itself from list_rules by returning categories rather than rules, but never states that contrast explicitly.
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?
No guidance on when to call this instead of list_rules or get_rules; the agent must infer that this is a discovery/lookup step preceding rule filtering. No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出规则索引，可按 category / severity(error|warn|info) 过滤。返回 id+title，供后续 get_rules 取详情。
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| severity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full disclosure burden. It does disclose the return shape (id+title only, not full rule bodies), which is genuinely useful, and '列出' implies a read-only operation. It says nothing about permissions, pagination, or result size limits, which leaves real gaps for an unannotated tool.
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?
A single tight sentence group with no filler: purpose, filters, return shape, and follow-up tool, in that order. Nothing is wasted and the most important information leads.
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?
With no output schema, the description usefully covers return fields, and no annotations means the read-only nature is adequately implied by '列出'. The main shortfall is the unexplained source of valid category values, which the agent needs before filtering.
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 0%, so the description must compensate. It restates the two filters and spells out the severity enum values, which helps, but it never explains what values 'category' accepts – presumably the categories from list_categories – nor whether filters combine. Partial compensation only.
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?
States a specific verb and resource ('列出规则索引' – list the rules index) and explicitly positions the output as an index feeding get_rules for details, which cleanly separates it from that sibling. The scope is unambiguous enough that an agent can pick it without opening the schema.
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 phrase '供后续 get_rules 取详情' tells the agent this is the lightweight entry point and names the follow-up tool, and the filter options give concrete use contexts. There is no explicit when-not guidance, but the two-step workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成微信小程序提审/上线前的护栏检查清单。scenario 可选 first-release（首版上线，附加常见卡点）。
| Name | Required | Description | Default |
|---|---|---|---|
| scenario | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It doesn't say whether the checklist is static knowledge or derived from project state, whether any read/permission is involved, or what the response looks like – notable gaps for an agent deciding how to consume the result.
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 compact sentences, both of which earn their place. The core purpose is stated first and the parameter hint follows, with no filler.
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?
The low complexity and the absence of an output schema mean heavy documentation isn't required, but the description never indicates the shape of the result (a flat list of items? grouped by rule category?) or how it composes with lint_project and get_rules.
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 single parameter has an enum with 0% schema description coverage. The description explains only 'first-release' (adds common blockers) and says nothing about 'general', including that omitting the optional parameter falls back to it, so half the enum semantics remain undocumented.
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?
States a specific verb and resource in concrete terms: generating a guardrail checklist before WeChat mini-program submission/release. Clear enough that an agent can distinguish it from list_rules/lint_project, though it never names those siblings explicitly to draw the boundary.
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 phrase '提审/上线前' gives implied timing (before you submit or go live), which is real usage context. However, there is no explicit when-to-use instruction relative to lint_project or get_rules, and no guidance on prerequisites such as running lint first.
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.0get_ruleslint_projectlist_categorieslist_rulessubmit_checklistScored across 5 tools
Each tool occupies a distinct layer of the workflow: browse categories, list a rule index, fetch full rule details, statically scan a project, and generate a submission checklist. The index-vs-detail split between list_rules and get_rules is explicitly described (id+title vs full symptom/cause/fix), and lint_project (code scanning) is clearly separated from submit_checklist (pre-release checklist generation). No two tools appear to do the same thing.
All five names follow a strict snake_case verb_noun pattern (list_categories, list_rules, get_rules, lint_project, submit_checklist), with verb choice matching semantics (list for collections, get for detail, lint/submit for actions). No mixed conventions or vague standalone verbs.
Five tools is right-sized: two discovery tools, one detail tool, one enforcement tool, one release-workflow tool. Each earns its place with no filler or redundant wrappers.
The rule-reference → lint → pre-release checklist lifecycle is covered end to end, with category/severity filtering and id/category/full-detail fetch modes. Minor gaps: no keyword/symptom-based rule search (only category/severity/id), and lint_project has no scope options (e.g., single file, changed files) or severity-threshold configuration.
Checks AI-written code against your rules as it is written, and keeps a record of what it found.
Lints + auto-fixes how AI coding agents discover any new product. 24 rules, 6 tools, score 0-100.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Compliance & security scan for your app: secrets, exposed files, headers, privacy, AI-disclosure.
