Every vibe coding session generates massive insights — deviations, patterns, quality signals. But you close the terminal, and all of it vanishes. Next session, you start blind again. AIDA captures structured data at every development checkpoint, visualizes it in a live dashboard, and distills deviation patterns into rules that make your AI write better code — every single run.
One line to integrate. Zero workflow changes.
{ "mcpServers": { "aida": { "command": "npx", "args": ["-y", "ai-dev-analytics", "mcp"] } } }
One-Line Setup · Data-Driven Loop · Dashboard · SOP Workflow · Data for Reports · 中文文档
Vibe coding is powerful. But it's a black box.
You tell Claude to build a feature. It writes code. You ship it. But you have zero visibility into what actually happened:
How many tasks did AI complete? How long did each take?
Where did AI deviate from your project conventions? Why?
Which deviations keep recurring? What rules would prevent them?
What's the bug rate? Which phases produce the most bugs?
Without data, you can't improve. You're just vibing — over and over, with the same blind spots.
AIDA makes the invisible visible. It collects structured data from every vibe coding session, renders it in a real-time dashboard, and turns deviation patterns into project rules. Your AI doesn't just code — it learns your project.
Related MCP server: ctxray
This is the core of AIDA — data in, rules out, better code next time.
Vibe Coding Session
↓
AIDA silently collects structured data
(tasks, deviations, bugs, reviews, files, timeline)
↓
Dashboard visualizes patterns
"9 deviations → 56% hallucination, 44% rule-missing"
↓
Deviation patterns identified → AI suggests rules → user confirms → sedimented
.aidevos/rules/ ← your AI's growing knowledge base
↓
AI reads rules next session → same mistakes eliminated
↓
Repeat — each cycle, AI output gets closer to your expectationsReal data from a production project:
Run | Deviations | What happened | Rules sedimented |
#1 | 23 deviations across 47 tasks | AI misused components, wrong layouts, incorrect API patterns | 6 project-specific rules |
#2 | 0 repeat deviations | AI read the rules. Same patterns — zero errors. | — |
Step 1: See why AI deviates — Root cause breakdown reveals whether issues stem from hallucination, missing rules, or insufficient context.
Step 2: See where AI deviates — Category distribution pinpoints the exact areas: UI spacing, layout, component usage, API patterns.
Step 3: Watch rules compound — As rules accumulate (green line), the same deviation patterns stop recurring.
The .aidevos/rules/ directory is your project-specific AI knowledge base. It grows with every run. The more you use AI, the smarter it gets at your project.
Your entire vibe coding process — structured, visualized, actionable.
Live Demo → Real anonymized project data. No install needed.
AIDA captures every dimension of AI-assisted development and turns it into interactive charts:
What you see | Why it matters |
Deviation root cause breakdown | Know why AI fails — rule-missing? hallucination? context gap? |
Deviation category distribution | Know where AI fails — layout? components? API? |
Deviation & rule trend over time | Watch deviations drop as rules accumulate |
Bug severity distribution | Track quality — which phases produce critical bugs? |
Self-review pass rate trend | Is AI code getting better or worse over time? |
Task completion by phase | See progress across the full development lifecycle |
File modification hotspots | Which files keep getting changed? Where are the pain points? |
Rules table with source mapping | Every rule links back to the deviation that created it |
Full development timeline | Every task, bug, review, deviation — chronologically |
Project overview (team view) | Cross-branch stats, developer comparison, requirement status |
Every KPI card is clickable — drill down into task details, deviation root causes, review reports, and file changes.
Run npx ai-dev-analytics dashboard to see your own project's data in seconds.
AIDA writes JSON files to .aidevos/ in your project directory. The codebase contains zero HTTP calls to external services — no telemetry, no cloud sync, no analytics, no tracking. Zero runtime dependencies. Your code and data never leave your machine. Period.
.mcp.json — that's the entire integration.{ "mcpServers": { "aida": { "command": "npx", "args": ["-y", "ai-dev-analytics", "mcp"] } } }No SDK. No wrapper. No code changes. Add this to your project root .mcp.json, and AIDA starts collecting data the next time your AI writes code. It works silently — zero workflow changes.
Tip: If
npxis slow, install globally first:npm install -g ai-dev-analytics, then change the command to"aida". Global install also gives you theaidaCLI command (e.g.aida dashboard,aida init).
Cursor .cursor/mcp.json:
{
"mcpServers": {
"aida": {
"command": "npx",
"args": ["-y", "ai-dev-analytics", "mcp"]
}
}
}VS Code Copilot .vscode/mcp.json:
{
"servers": {
"aida": {
"command": "npx",
"args": ["-y", "ai-dev-analytics", "mcp"]
}
}
}Windsurf ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"aida": {
"command": "npx",
"args": ["-y", "ai-dev-analytics", "mcp"]
}
}
}Lingma (通义灵码) .lingma/mcp.json:
{
"mcpServers": {
"aida": {
"command": "npx",
"args": ["-y", "ai-dev-analytics", "mcp"]
}
}
}npx ai-dev-analytics dashboardOpen http://localhost:2375 — real-time updates via SSE, Chinese/English toggle built in.
Without data, every vibe coding session starts from zero. With data, each one builds on the last.
Vibing blind | Vibing with data |
"AI keeps getting layouts wrong" | Dashboard shows: 9 layout deviations, root cause 56% hallucination + 44% rule-missing. 4 rules sedimented → zero repeats next run |
"I corrected this three times already" | AIDA recorded the deviation pattern. AI detected |
"That feature had a lot of bugs" | 5 bugs, 3 critical — all concentrated in one phase. Now you know where to add guardrails |
"What did I even do this quarter?" | 47 tasks, 23 deviations fixed, 6 rules sedimented, 4064 lines. Export → H1 performance review done |
Vibe coding without data is just vibing. Add data, and it becomes a compounding system.
Vibe Coder — "I want my AI to actually learn my project"
You've been using Claude Code for a week. AIDA's dashboard shows: 23 deviations, concentrated in
component-usageandlayoutcategories, root cause mostlyrule-missing. AI detects the patterns and suggests rules — you confirm, 6 project rules sedimented. Next week, those categories show zero deviations. Your AI now knows your project conventions.
Tech Lead — "I need to see what AI is actually doing across the team"
Team of 4 uses Claude Code daily. Open the project overview: Developer A has 2 deviations + 5 sedimented rules (AI is learning). Developer B has 15 deviations + 0 rules (AI is not learning). The data tells you exactly where to intervene.
Senior Engineer — "Show me the data for my performance review"
End of H1. Open the dashboard: 150 tasks across 3 features, 89% first-pass review rate, 12 rules sedimented that now benefit the entire team. All structured data — export it, attach it to your review doc. Data beats "I think I did a lot."
Team adopting vibe coding — "How do we go from chaotic to systematic?"
Start collecting data. After 2 weeks, the dashboard shows clear patterns: which types of tasks AI handles well, where it consistently deviates, what rules are needed. You go from "AI sometimes works" to "AI works predictably because we've taught it our conventions."
AIDA doesn't just visualize — it sediments. Every run accumulates structured data that compounds over time.
Week 1: 47 tasks, 23 deviations, 5 bugs, 6 rules, 4064 lines
Week 4: 180+ tasks, deviation rate dropping, 15 rules, full quality history
Quarter: Complete development record — exportable, analyzable, presentableWhat you can do with sedimented data:
Scenario | What you get |
H1 / H2 Performance Review | Tasks completed, quality metrics (pass rate, bug rate), code volume, rules contributed — all with numbers, not feelings |
Annual Summary | Cross-project trends, deviation patterns over time, rule growth curve, total output |
Sprint Retrospective | What went wrong, what rules were added, which phases improved, measurable quality delta |
Team Leader Report | Per-developer stats, deviation hotspots, which modules need better rules, team-wide AI maturity |
Project Handover | Full development history — someone new can see exactly what happened, what rules exist, and why |
All data is structured JSON in .aidevos/. No vendor lock-in. Export it, query it, pipe it into any reporting tool. Run aida report to generate a summary at any time.
flowchart LR
A["Your AI Tool\nClaude Code / Cursor"] -->|Vibe Coding| B{"AIDA MCP Server\n10 Tools"}
B -->|Silent Data Collection| C[".aidevos/run.json"]
C -->|Visualization| D["Dashboard\nlocalhost:2375"]
C -->|Pattern Analysis| E[".aidevos/rules/"]
E -->|AI Reads Rules| AYour AI tool calls AIDA's MCP tools automatically as it works. You don't invoke them manually. No prompts to write, no scripts to run — just vibe code as usual.
Tool | What it captures |
| Task begins — ID, title, stage, PRD phase |
| Task completed — duration auto-calculated |
| Bug found — severity, title, related files |
| Bug fixed — links fix to original bug |
| Code self-review — pass/fail, issue list |
| AI output ≠ expectation — root cause, category |
| File changes — auto-scans |
| Notable achievement worth recording |
| Current run status snapshot |
| Sediment project rule — user confirms, then AI calls this tool |
All data is local JSON. No database, no cloud.
Level | File | What it contains |
Run |
| Every task, bug, deviation, review, file change |
Branch |
| Aggregated stats per requirement |
Project |
| Cross-branch overview for team leads |
Rules |
| Sedimented project rules — your AI's growing knowledge base |
All structured JSON — ready for export, analysis, or feeding into reports.
Beyond data collection, AIDA provides a complete SOP for AI-assisted development — a standardized workflow that turns chaotic vibe coding into a repeatable, measurable process.
aida init # Select "Full workflow"
aida start # Create a development runThis enables 14 AI Skills orchestrated as a full development pipeline:
PRD Ingestion → Requirement Analysis → Task Decomposition
↓
Code Generation → Self-Review → Bug Fix → Deviation Fix
↓
Data Collection → Pattern Analysis → Rule Sedimentation
↓
Next Run: AI reads rules → better output → fewer deviationsPhase | What AI does | What AIDA records |
Requirement | Parses PRD, extracts modules and phases | PRD phases, scope |
Task Split | Breaks requirements into atomic tasks | Task list, stages, estimates |
Code Gen | Generates code per task | Files changed, lines added, duration |
Self-Review | Reviews its own output against conventions | Pass/fail, issue list, quality score |
Bug Fix | Fixes bugs found during review | Bug severity, fix details, related files |
Deviation Fix | Corrects output that doesn't match expectations | Root cause, category, new rule (when root cause is rule-missing) |
Every step produces structured data. Every deviation can become a rule. The SOP ensures nothing falls through the cracks — and the data makes the whole process visible and improvable.
aida init # Interactive project setup
aida start # Create a new development run
aida status # Show current run status
aida dashboard # Launch dashboard (default port 2375)
aida dashboard --port 3000 # Custom port
aida mcp # Start MCP server (for AI tool config)
aida log <subcommand> # Write structured data (task, bug, review, etc.)
aida reindex # Rebuild project-level index
aida report # Generate performance report
aida rules build # Generate rule view files from registry
aida rules dedupe # Find and remove near-duplicate rules
aida rules merge # Merge rules from parallel branches
aida update # Update skills to latest version
aida migrate # Migrate old data to current schemaAIDA uses Model Context Protocol — the standard way for AI tools to interact with external systems. The MCP server runs over stdio with zero dependencies.
What happens when you add the config:
Your AI tool discovers AIDA's 10 tools via MCP
As the AI works, it naturally calls aida_task_start, aida_log_files, etc.
Data flows into run.json silently
Deviation patterns emerge → AI suggests rules → user confirms → sedimented
AI reads rules next session → output quality improves
No prompts to write. No scripts to run. No workflow to learn.
Rules are the compounding asset of AIDA. Here's how they work in a team setting.
.aidevos/rules.json ← source of truth, committed to git
↓
aida rules build
↓
.aidevos/rules/*.md ← auto-generated views, gitignored
↓
AI reads rules next sessionaida init automatically adds .aidevos/rules/*.md to your .gitignore. Never edit the .md files manually — they are always regenerated from rules.json.
After pulling changes that include new rules:
git pull
aida rules build # regenerate local rule views from updated rules.jsonWhen two developers add rules on separate branches and merge, rules.json may get a standard git conflict. Resolve it in one command:
# After git merge produces a conflict in rules.json:
aida rules merge # fingerprint union — no duplicates, no lost rules
aida rules build # rebuild .md views
git add .aidevos/rules.json
git commit -m "merge: resolve rules conflict"aida rules merge uses fingerprint deduplication: if two rules have identical content, only one is kept. If they differ, both are kept and the incoming rule is renumbered to avoid ID collisions.
aida rules list # list all rules grouped by category
aida rules dedupe # surface rules with >40% keyword overlap for manual reviewRules have a status field (active / deprecated). When project conventions evolve, deprecate old rules — they stop appearing in the .md files your AI reads, but remain in rules.json as an audit trail.
Export reports as PDF / HTML (H1/H2 performance reviews)
Historical trend analysis — deviation reduction curves over time
Team dashboard with multi-project aggregation
VS Code extension for inline deviation alerts
Cross-project rule sharing — team-wide AI knowledge base
Runtime | Node.js + TypeScript, zero dependencies |
Dashboard | React 19 + ECharts + Tailwind CSS 4 |
Protocol | MCP over stdio (JSON-RPC 2.0) |
Data | Local JSON files, no database |
Real-time | Server-Sent Events (SSE) |
i18n | Chinese / English, switchable in dashboard |
npm test # 82 tests across 29 suitesIssues, feature requests, and PRs are welcome.
git clone https://github.com/LWTlong/ai-dev-analytics.git
cd ai-dev-analytics
npm install
npm testVibe coding without data is just vibing. Add data, and your AI gets smarter every run.
当你修复了一个 bug 后调用。标记 bug 为已修复。
| Name | Required | Description | Default |
|---|---|---|---|
| bugId | Yes | Bug ID，如 BUG-01 | |
| fix | No | 修复方案简述 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States the marking action but fails to disclose mutation side effects, reversibility, state transitions, or whether this triggers notifications. For a state-change tool, behavioral details are insufficient.
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 zero waste. Front-loaded with the trigger condition ('当你修复了一个 bug 后调用'), followed immediately by the effect. Appropriate length for the tool's scope.
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?
Adequate for a simple 2-parameter state-update tool with no output schema. Covers the essential trigger and action, though omitting operational details (e.g., whether this archives the bug, updates timestamps, or interacts with aida_status).
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%, establishing baseline 3. The phrase 'after you have fixed a bug' adds context that the 'fix' parameter should describe the completed solution, but no additional semantic guidance (format constraints, example values) is provided 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 action (标记/mark as fixed) and resource (bug), and specifies the trigger condition ('after you have fixed a bug'). It implicitly distinguishes from sibling aida_log_bug through the post-fix timing versus logging, though it could explicitly contrast with bug creation tools.
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?
Provides clear timing guidance ('when you have fixed a bug'), indicating the workflow state for invocation. However, lacks explicit guidance on when NOT to use (e.g., vs. aida_task_done for tasks) or alternatives for unverified fixes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
记录值得关注的亮点，如性能提升、架构优化等。
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | 亮点内容描述 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While '记录' implies persistence, the description does not clarify side effects, visibility of the recorded highlights, authentication requirements, or what happens upon successful execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. Information is front-loaded with the verb and resource, followed by illustrative examples that earn their place by clarifying scope.
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 simple single-parameter tool with full schema coverage and no output schema, the description adequately covers the core use case. However, given the mutation-like nature (recording/creating entries) and lack of annotations, it omits important behavioral context that would help an agent understand the full impact of invocation.
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?
With 100% schema description coverage, the baseline is 3. The description provides examples of highlight content (performance improvements, architecture optimizations) which gives semantic context for the 'content' parameter, though this does not significantly exceed what the schema already documents.
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 records (记录) highlights/highlights (亮点) and provides concrete examples (performance improvements, architecture optimizations) that distinguish it from sibling bug-tracking and logging tools. However, it lacks explicit differentiation text comparing it to alternatives like aida_log_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 explains what the tool does but provides no guidance on when to use it versus siblings (e.g., when to use aida_highlight vs aida_task_done or aida_log_review). There are no exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
当你在开发或测试中发现 bug 时调用。记录 bug 信息。
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Bug 描述 | |
| severity | No | 严重程度：critical/high/medium/low，默认 medium | |
| source | No | 发现来源：self-review/user-feedback/testing，默认 self-review |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states '记录' (records) without disclosing persistence mechanism, visibility, notifications generated, or return value. Missing behavioral traits like idempotency or confirmation.
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 concise sentences, front-loaded with trigger condition. No redundant words. Could potentially combine into one sentence but structure is efficient and scannable.
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 and no annotations, a logging tool should ideally disclose what happens after invocation (e.g., ticket creation, notifications). Description covers minimal 'when' and 'what' but omits 'what happens next' and sibling relationships expected for a 3-param tool with side effects.
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% with complete Chinese documentation for each parameter. Description provides only generic '记录 bug 信息' without adding syntax guidance, validation rules, or usage tips beyond what schema already specifies. Baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific trigger ('在开发或测试中发现 bug 时') and action ('记录 bug 信息'). Clear verb+resource. Loses one point because it doesn't differentiate from sibling 'aida_bug_fix' (logging vs fixing) or distinguish from other 'aida_log_*' tools.
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?
Provides implied usage context ('当...发现 bug 时调用') covering when to use. However, lacks explicit guidance on when NOT to use (e.g., vs aida_log_deviation) or workflow relationship to aida_bug_fix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
当 AI 产出与用户预期不符时调用。记录偏差用于后续分析。当 rootCause 为 rule-missing 时，修复后如果属于项目级技术规范（非业务逻辑），应询问用户是否沉淀为规则。
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 偏差描述 | |
| rootCause | No | 根因分类 | |
| category | No | 偏差类别 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It mentions the persistence aspect ('记录') and a specific behavioral side effect ('应询问用户是否沉淀为规则'), which adds context. However, it omits other behavioral traits like return values, idempotency, or failure modes that agents need for mutation/logging tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The three-sentence structure is efficient and front-loaded: trigger condition first, purpose second, and conditional workflow third. Each sentence earns its place. The Chinese phrasing is professional and compact, though a slightly more structured format (e.g., bullet points for the conditional logic) could improve scanning.
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 this is a logging tool with no output schema, the description adequately covers the logging intent, categorization parameters, and the specific rule-missing workflow. However, it lacks information about return confirmation, error handling, or how logged deviations are subsequently accessed (e.g., via aida_log_review or similar), which would complete the usage context.
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?
With 100% schema description coverage, the baseline is 3. The description adds valuable semantic context for 'rootCause' by explaining the specific workflow when this value is 'rule-missing', helping agents understand how to populate this enum. It does not add significant details for 'title' or 'category' 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 trigger condition ('当 AI 产出与用户预期不符时调用'), the action ('记录偏差'), and the purpose ('用于后续分析'). It partially distinguishes from siblings by specifying the deviation scenario and referencing the rule precipitation workflow (connecting to aida_log_rule), though it could explicitly contrast with aida_log_bug.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides specific guidance for the 'rootCause' enum value ('当 rootCause 为 rule-missing 时...') and a follow-up workflow, but lacks explicit 'when-not-to-use' guidance or clear distinction from sibling logging tools like aida_log_bug. The alternative action (asking about rule creation) is described rather than alternative tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
记录文件变更。无需传参，自动扫描 git diff 获取变更文件列表和行数。在完成一轮代码修改后调用。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully explains the automatic git diff scanning mechanism and zero-parameter design, but lacks details on data persistence, output format, or whether the recording operation has side effects on the repository.
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 with zero waste: first states purpose, second explains mechanism and parameters, third specifies invocation timing. Information is front-loaded and appropriately sized for the tool's simplicity.
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 zero-parameter tool without output schema, the description adequately covers purpose, invocation context, and data source. It omits output format details, but this is acceptable given the lack of output schema and the tool's straightforward logging nature.
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?
With zero parameters, the baseline score is 4. The description appropriately confirms no arguments are required ('无需传参') and does not need to compensate for missing schema documentation.
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 uses a specific verb ('记录'/record) with a clear resource ('文件变更'/file changes) and distinguishes itself from siblings by specifying the unique mechanism ('自动扫描 git diff'/automatically scans git diff) rather than logging bugs, reviews, or rules like the other aida_log_* tools.
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?
Provides explicit temporal guidance on when to invoke: '在完成一轮代码修改后调用' (Call after completing a round of code modifications). It also clarifies the zero-parameter requirement ('无需传参'), eliminating confusion about whether arguments are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
当你完成一轮代码审查后调用。记录审查结果。
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | No | 关联的任务ID | |
| result | Yes | 审查结果：pass 或 fail | |
| issues | No | 发现的问题，逗号分隔。通过时不填。 | |
| scope | No | 审查覆盖的文件或模块范围 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无任何annotations提供，描述需承担全部行为披露责任。但仅说明是'记录审查结果'，未说明是否幂等、是否影响任务状态、有无副作用或返回确认信息。对于写操作类工具，缺乏关键行为特征披露。
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?
两句话结构紧凑，首句说明触发时机，次句说明功能，无冗余信息。但鉴于兄弟工具众多且缺乏annotations，信息量略显不足，故未给满分。
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?
虽有100% schema覆盖率，但无output schema和annotations，且面对9个兄弟工具（其中4个同为log前缀工具），两句话的描述不足以支撑AI智能体在复杂工具生态中做出准确选择，缺乏对其在审计链路中定位的完整说明。
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描述覆盖率达100%，参数含义已由schema充分定义（如issues'逗号分隔'等）。描述中的'审查结果'为参数提供了上下文语境，但未额外补充schema未涵盖的语法细节或示例，符合高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?
描述明确使用动词'记录'和资源'审查结果'，并限定触发场景为'完成一轮代码审查后'。但面对多个同类logging兄弟工具（log_bug, log_deviation等）时，未明确说明与它们的甄别标准（如是记录整体评审结论而非具体缺陷）。
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?
明确指触发时机'当你完成一轮代码审查后调用'，但未提供何时不应使用（如不应替代log_bug记录单个缺陷），也未说明与task_done或log_bug等工具的协作或互斥关系。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
沉淀项目规则。当偏差的 rootCause 为 rule-missing 且修复方案属于项目级技术规范（非业务逻辑）时，询问用户同意后调用此工具沉淀规则。仅限：公共组件使用规范、API 调用规范、参数传递规范、代码风格/架构规范。禁止沉淀业务逻辑。
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | 规则内容，简洁描述项目规范 | |
| category | Yes | 规则分类 | |
| sourceDeviation | No | 关联的偏差 ID，如 DEV-01 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the user-consent requirement and clearly defines scope boundaries (allowed categories vs prohibited business logic). It implies this is a persistent write operation but omits failure modes or idempotency details.
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?
Single complex sentence that efficiently packs purpose, condition, scope, and restrictions without redundancy. Information is front-loaded with the action (沉淀项目规则). Minor improvement possible by breaking into two sentences for readability.
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?
Appropriate for a 3-parameter logging tool with no output schema. The description sufficiently covers domain-specific logic (technical vs business rules) and prerequisites (user consent). Could mention whether rule deposition is idempotent or what confirms success.
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). The description adds semantic value by mapping the category enum values to concrete examples (公共组件使用规范→component, API调用规范→api, 代码风格/架构规范→style/architecture) and contextualizing sourceDeviation as linking to specific deviation IDs.
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 uses a specific verb (沉淀/deposit) with a specific resource (项目规则/project rules). It clearly distinguishes from sibling tools like aida_log_bug and aida_log_deviation by specifying this is specifically for rule-missing root causes and technical specifications.
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?
Provides explicit triggering conditions (当偏差的 rootCause 为 rule-missing), scope restrictions (项目级技术规范 vs 业务逻辑), and clear prohibitions (禁止沉淀业务逻辑). It also notes the consent requirement (询问用户同意后), establishing a critical workflow constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查看当前开发运行的状态：任务列表、bug 数量、进度等。在需要了解当前进度时调用。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies read-only behavior through '查看' (view) and lists retrieved data categories, but does not explicitly disclose side effects, idempotency, caching behavior, or return format structure that would help an agent understand the full behavioral contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two highly efficient sentences. The first sentence front-loads the action and scope, while the second provides usage context. There is no redundant or filler text; every word 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?
Given the tool's simplicity (no input parameters) and the lack of an output schema, the description appropriately lists the key data components (tasks, bugs, progress) that constitute 'status'. It could be improved by hinting at the return structure or format, but it adequately covers the essential information needed for tool selection.
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 tool has zero parameters, which per evaluation rules establishes a baseline of 4. The description does not need to compensate for schema gaps since there are no parameters to document.
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 uses the specific verb '查看' (view/check) and clearly identifies the resource as 'development operation status'. It enumerates specific data components returned (task list, bug count, progress), which implicitly maps to the sibling tools (task_*, bug_*) and clarifies this is a reporting tool rather than an action tool.
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 provides an explicit when-to-use condition: '在需要了解当前进度时调用' (call when needing to understand current progress). However, it lacks guidance on when NOT to use this (e.g., when to use specific query tools instead) and does not mention alternatives among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
当你完成一个任务后调用。标记任务为已完成，自动计算耗时。
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | 任务ID，如 TASK-01。如不确定，可调用 aida_status 查看。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It successfully communicates one key behavioral trait—the automatic calculation of time consumed ('自动计算耗时')—but omits other critical mutation details such as reversibility (can a task be un-marked?), side effects, error conditions, or the nature of the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two highly efficient sentences: the first establishes the trigger condition, and the second lists the dual effects (marking completion and time calculation). There is zero redundancy or filler, with critical information 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 tool's simplicity (single string parameter, no nested objects, 100% schema coverage) and the absence of an output schema, the description adequately covers the essential invocation context and primary effect. It lacks safety annotations (destructive/reversible hints) which would be expected for a state-transition mutation, but remains sufficient for agent selection given the clear lifecycle positioning.
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?
With 100% schema coverage, the input schema fully documents the taskId parameter including examples and cross-references to aida_status. The main description does not add parameter-specific semantics beyond what the schema already provides, warranting the baseline score of 3.
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 specific action (mark task completed) and trigger condition (after finishing a task), with a distinct behavioral detail (automatic time calculation). It implicitly contrasts with sibling aida_task_start through the temporal marker '完成后' (after completion), clearly positioning it in the task lifecycle.
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 provides explicit temporal guidance on when to invoke ('当你完成一个任务后调用' / call after completing a task). However, it does not explicitly reference sibling alternatives like aida_task_start for initiation or caution against using this for starting tasks, nor does it mention the aida_status reference found in the parameter schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
当你开始一个新任务或功能开发时调用。在接到用户需求、开始编码前调用。每个任务的完整数据采集流程：1) aida_task_start 2) 编码 3) aida_log_files 4) aida_log_review 5) aida_task_done。多个子任务必须每个都单独 start/done。
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 任务标题，简洁描述要做什么 | |
| stage | No | 所属模块或阶段，如 Authentication, UI, API 等 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses the workflow context ('数据采集流程' - data collection process) and lifecycle implications, but lacks explicit detail about return values, idempotency, or specific side effects (e.g., whether it creates a persistent record).
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?
Four sentences with zero waste: (1) purpose definition, (2) timing context, (3) workflow sequence, (4) subtask rule. Logical front-loaded structure moves from general use to specific sequencing constraints.
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 workflow complexity and sibling tool ecosystem, the description successfully explains the complete task lifecycle, integration with logging tools, and subtask protocols. No output schema exists, and none is required given the schema coverage.
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 both 'title' and 'stage' fully documented in the schema including examples. The description adds no parameter details, which is acceptable when the schema is self-documenting, warranting the baseline score of 3.
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 '开始一个新任务' (starts a new task) with specific verb+resource, and distinguishes from siblings by positioning it as step 1 of a 5-step workflow (contrasting with aida_task_done at step 5 and the aida_log_* middle steps).
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?
Provides explicit temporal guidance ('在接到用户需求、开始编码前调用' - call after requirements, before coding), sequences the full workflow with numbered steps, and specifies subtask handling rules ('多个子任务必须每个都单独 start/done'), clearly delineating when to use vs. alternatives.
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.
v1.0.0aida_bug_fixaida_highlightaida_log_bugaida_log_deviationaida_log_filesaida_log_reviewaida_log_ruleaida_statusaida_task_doneaida_task_startScored across 10 tools
Each tool has a clearly distinct purpose with no overlap: bug fixing, highlighting achievements, logging bugs/deviations/files/reviews/rules, checking status, and managing tasks. The descriptions explicitly define when to use each tool, eliminating any ambiguity.
All tools follow a consistent 'aida_' prefix with descriptive snake_case names (e.g., aida_log_bug, aida_task_start). The naming pattern is uniform throughout, making it easy to predict and understand tool functions.
With 10 tools, the server is well-scoped for AI development analytics, covering key aspects like bug tracking, task management, file logging, and rule documentation. Each tool serves a specific, necessary function without bloat.
The tool set provides complete coverage for the AI development lifecycle, including task initiation/completion, bug logging/fixing, file change tracking, code review logging, deviation analysis, rule documentation, status checks, and highlighting achievements. No obvious gaps exist for this domain.
AI colleagues that keep your standards, your project and their reasoning between sessions
Give your AI agent persistent, governed memory for every project. At task start it recalls the approved decisions, conventions, risks and architecture (semantic search, ranked by importance); at close it proposes what was learned as typed memories that you review and approve — governance, not a notes dump. Agents propose, humans govern: edits go back to pending and deletion is human-only by design. Connect Claude Code, Cursor, Claude Desktop or any MCP client in two minutes with just your API key — hosted (nothing to install) or locally via `uvx solucortex-mcp`. Built by SoluAI and dogfooded daily: SoluCortex is developed using its own living memory.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
