The LiDAR Harness MCP is an incremental code validation middleware for AI coding agents (Claude Code, OpenCode, etc.) that reduces context overhead by only surfacing new errors each turn.
harness_init — Initialize a project by auto-detecting typecheck/lint commands (TypeScript, Go, Rust, Java), establishing error baselines, and classifying task complexity. Call once per session.
harness_classify — Classify a user's request as "simple" (Q&A, explanation) or "complex" (coding, refactor, fix) to skip unnecessary verification overhead for simple tasks.
harness_pgo — Run incremental typecheck and lint after each code change, returning only newly introduced errors since the last call — reducing context token usage by 60–80%. Includes auto-reset when an error explosion is detected (e.g., after major dependency upgrades).
harness_review — Perform multi-perspective code review covering security (hardcoded secrets in git diff), correctness (uncommitted changes), and style (lint results). Recommended every 3rd turn, with optional file scoping.
harness_reset — Manually clear PGO baselines and error history when switching tasks or after significant project changes, enabling a fresh verification cycle.
Its stable, incremental output schema is also optimized for better KV cache hit rates in LLMs.
Click on "Install 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., "@LiDAR Harness MCP initialize Lidar Harness for this project and run first typecheck"
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 中间件，用于 Claude Code、OpenCode 等代码代理。
受 SLAM 建图中 PGO（位姿图优化）启发，LiDAR Harness 提供四层验证架构，在不增加每轮上下文负担的前提下，确保 agent 输出的代码质量。
大多数代码 agent 的工作方式是：每轮修改代码后，全量运行 tsc / lint，把全部错误注入回上下文。这在 10 轮以上的任务中会浪费大量 token。
LiDAR Harness 的 PGO（Pose Graph Optimization）引擎采用 增量机制：
首次: tsc --noEmit → 发现 7 个错误 → 全部注入
第 2 轮: 修复了 3 个 → 剩余 4 个已知，0 个新增 → 不注入，agent 不被打断
第 3 轮: 引入了 1 个新错误 → 只注入这 1 个新错误
...效果：上下文占用减少 60-80%，且与 DeepSeek V4 MLA KV cache 复用机制兼容——固定的输出 schema 结构确保每轮前缀缓存命中。
Related MCP server: knowing
工具 | 用途 | 典型时机 |
| 初始化项目，自动检测 typecheck/lint 命令，建立基线 | 会话开始一次 |
| 判断任务是 "simple"（问答）还是 "complex"（编码） | 用户发消息后 |
| 增量检查 — 只返回新出现的 typecheck/lint 错误 | 每轮修改代码后 |
| 多视角代码审查（安全扫描、正确性、风格） | 每 3 轮 |
| 重置 PGO 状态 | 切换任务时 |
Model completes a turn (modifies code)
│
▼
┌──────────────────────┐
│ Layer 0: Gate │ ─── 简单任务（问答/解释）→ 跳过后续所有验证
└────────┬─────────────┘
▼
┌──────────────────────┐
│ Layer 2: PGO │ ─── typecheck + lint，增量注入（核心功能）
└────────┬─────────────┘
▼
┌──────────────────────┐
│ Layer 3: MultiReview │ ─── 安全/正确性/风格（每 3 轮）
└──────────────────────┘灵感来自 SLAM 的 kidnapped robot problem。
当单轮新增错误数超过阈值（默认 15）时，说明 PGO 状态已失效（典型场景：依赖升级、tsconfig 大幅变更）。引擎会自动重新建立基线，并在结果中标注 autoReset: true，让 agent 知道发生了状态重置。
之前的行为（手动 harness_reset）：agent 在废墟上无限迭代。
现在：自动识别失效状态，重新校准，继续收敛。
harness_pgo 的输出字段顺序固定为：
{
"converged": false,
"autoReset": false,
"newErrorCount": 2,
"totalUniqueErrors": 5,
"newErrors": ["..."],
"message": "..."
}每轮只有值变化，结构不变。配合 DeepSeek V4 MLA 的 KV cache 机制，可显著提升多轮 session 的 prefill 缓存命中率。
Node.js >= 18
一个 MCP 客户端（Claude Code、OpenCode、或任何 MCP 兼容工具）
git clone https://github.com/bernardleex526-png/lidar_harness_mcp.git
cd lidar_harness_mcp
npm install
npm run build在项目 .claude/settings.local.json 中添加：
{
"mcpServers": {
"lidar-harness": {
"command": "node",
"args": ["/path/to/lidar_harness_mcp/dist/index.js"]
}
}
}重启 Claude Code 后，5 个工具会自动可用。
{
"mcpServers": {
"lidar-harness": {
"command": "node",
"args": ["/path/to/lidar_harness_mcp/dist/index.js"]
}
}
}# 列出工具
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | node dist/index.js
# 初始化项目
echo '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"harness_init","arguments":{"cwd":"/your/project","taskMessage":"fix the build"}}}' | node dist/index.jsUser: 帮我重构这个模块
Claude: [调用 harness_init 初始化，检测到 tsc 和 lint]
Claude: [完成任务，调用 harness_pgo 检查]
Claude: → 编译通过，无新错误
Claude: 重构完成。
User: 添加一个 API 端点
Claude: [修改代码，调用 harness_pgo]
Claude: → 发现 2 个新类型错误，需要修复
Claude: [修复错误，再次调用 harness_pgo]
Claude: → 0 个新错误，autoReset: false，编译通过语言 | 检测文件 | 默认命令 |
TypeScript |
|
|
Go |
|
|
Rust |
|
|
Java (Maven) |
|
|
Java (Gradle) |
|
|
lidar-harness-mcp/
├── src/
│ ├── index.ts # MCP Server 入口，工具注册
│ └── harness/
│ ├── pgo.ts # PGO 增量验证引擎
│ ├── pgo.test.ts # 单元测试（vitest）
│ ├── review.ts # 多视角代码审查
│ └── gate.ts # 复杂度门控
├── package.json
├── tsconfig.json
└── README.md零运行时依赖（除 @modelcontextprotocol/sdk 外）。
MIT
Classify a task as "simple" (question, explanation) or "complex" (implementation, refactor, fix).
Simple tasks skip PGO and review overhead entirely. Call before starting work.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | User's task description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that simple tasks skip PGO and review, but does not detail other behavioral traits (e.g., idempotency, state changes). Adequate for a simple classification but not fully transparent.
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, examples, and usage guidance. Every sentence is purposeful with no extraneous content.
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 description covers purpose, usage, and behavioral implications. However, it does not describe the output/return value (e.g., expected format like 'simple' or 'complex'), which is missing since no output schema exists. This leaves an important gap for an AI agent invoking the tool.
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 documents one parameter 'message' with description 'User's task description'. The tool description adds meaning by defining the classification outcomes and context, significantly enriching the parameter semantics beyond the schema alone.
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: 'Classify a task as simple or complex' with explicit examples. It distinguishes from sibling tools (harness_init, etc.) by focusing on classification rather than execution or review.
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 specifies 'Call before starting work' and explains that simple tasks skip overhead, providing clear contextual guidance. However, it does not explicitly discuss when not to use or give direct comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize LiDAR Harness for a project: detect typecheck/lint commands, establish baselines, classify task complexity.
Call this ONCE at the start of a session. Provide the user's task message for complexity classification.
Returns: session info with detected commands, complexity, and PGO readiness.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory (default: cwd of MCP process) | |
| commands | No | Override auto-detected commands (e.g. ["npx tsc --noEmit", "npm run lint"]) | |
| taskMessage | No | User's task description for complexity classification |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool detects commands, establishes baselines, classifies complexity, and returns session info. However, it does not mention side effects, prerequisites, or whether it overwrites existing state.
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 sentences, each serving a distinct purpose: purpose, usage, return. No redundancy or fluff.
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?
Given the tool's role as an initializer with three parameters and no output schema, the description adequately covers what it does, when to call, what to provide, and what it returns. Could elaborate on 'baselines' and 'PGO readiness', but sufficient for typical usage.
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%, baseline 3. Description adds value by explaining the purpose of taskMessage for complexity classification and that commands can override auto-detection. Adds 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?
The description clearly states 'Initialize LiDAR Harness for a project' and lists three specific actions: detect commands, establish baselines, classify complexity. It distinguishes from siblings like harness_classify and harness_reset by being the initialization step.
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 'Call this ONCE at the start of a session' and advises to provide the user's task message. Provides clear context for usage, though no explicit when-not-to-use or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run incremental PGO (Pose Graph Optimization) typecheck/lint verification.
KEY CONCEPT: Only returns NEW errors not seen in previous calls. If you call it 10 times, each call only shows errors that appeared SINCE the last call. When it returns 0 new errors, the code compiles cleanly.
Use after each agent turn that modifies code to verify incrementally.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the incremental behavior (only new errors, reset on success) well. Lacks details on side effects or permissions, but for a verification tool, this is adequate.
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 sentences, each adding unique value: action, key concept, usage guidance. No waste, effectively front-loaded.
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?
Given the simple tool (one param, no output schema), the description provides sufficient context: what it does, its incremental nature, and when to use it.
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 a single parameter 'cwd' described as 'Working directory'. The description adds no extra meaning beyond the schema, so baseline score of 3 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 clearly states the tool runs incremental PGO verification and highlights the key concept of returning only new errors. However, it does not distinguish itself from sibling tools beyond the incremental aspect, which could be more explicit.
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 recommends use after each agent turn that modifies code for incremental verification. No when-not or alternatives provided, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset PGO baselines and shown-errors state for a fresh start.
Call when switching to a new task or after significant dependency changes.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory | |
| commands | No | Re-detect or override commands (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It states it resets state but lacks details on reversibility or 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?
Two sentences: first explains purpose, second gives usage context. No unnecessary 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?
No output schema, but tool is simple. Could elaborate on return values or error scenarios, but adequate for basic use.
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% for both parameters. Description adds no additional semantic value beyond what schema provides.
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?
Clear verb 'Reset' and specific resources 'PGO baselines and shown-errors state' distinguish it from siblings like harness_classify or harness_init.
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?
Explicit when to use: 'when switching to a new task or after significant dependency changes.' No explicit exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run multi-perspective code review: security scan (secrets in git diff), correctness (uncommitted changes), style (lint results).
Call periodically (e.g. every 3rd turn) to catch issues the agent might miss.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory | |
| files | No | Limit review to specific files (optional) | |
| scanGitDiff | No | Scan git diff for hardcoded secrets/keys (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions what is scanned but fails to indicate if the tool is read-only, has side effects, performance impacts, or output format.
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, no wasted words. First sentence packs the core purpose, second provides usage guidance. Ideal conciseness.
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?
Missing essential details: no output schema, no mention of return values, no prerequisites (e.g., git repository). For a scan tool, this is insufficient.
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%, so baseline is 3. The description adds context about the review types but does not enhance understanding of individual parameters 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 runs multi-perspective code review covering security, correctness, and style, with specific examples. It differentiates from sibling tools like harness_classify and harness_init.
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 advises periodic calling (every 3rd turn) to catch missed issues. While it doesn't list when not to use, the sibling tools have distinct purposes, making usage context clear.
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.1harness_classifyharness_initharness_pgoharness_resetharness_reviewScored across 5 tools
Tools have distinct purposes but some overlap exists: harness_classify and harness_init both classify task complexity, which could cause confusion about which to use. The descriptions help clarify, but ambiguity remains.
All tools follow a consistent 'harness_' prefix with descriptive, uniform naming (classify, init, pgo, reset, review), all in lowercase with underscores.
5 tools is well-scoped for a harness tool. Each covers a distinct phase: pre-work classification, initialization, incremental verification, reset, and periodic review.
The tool surface covers the core workflow but is missing a status/list tool to show current baselines or state, which could be useful. Still, major operations are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Context engineering for AI coding agents: product context, project missions, and 360 memory.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
Formally-verified injection/exfiltration detector for AI agents (MCP-02).
Architecture compiler for AI code. 11 tools, 92 actions, 872 Lean4 proofs, 100/100 self-cert.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bernardleex526-png/lidar_harness_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
