类案检索与分析工作流(北大法宝 MCP × Claude Code)—— Word 渲染依赖
Critical gaps across all dimensions. Tool descriptions are present but written in Chinese with domain-specific jargon that LLMs struggle to parse for intent. No visible input schemas in the source code, parameter types and constraints are undocumented. Tool names lack clear action verbs (e.g., 'apply_coding' vs 'apply_case_coding'; 'build_demo_fixture' vs 'generate_demo_fixture'). Output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages. The server appears designed for human researchers, not LLM agents. Example: apply_coding accepts 'research_dir' and 'coding_json' but no schema shows types, validation rules, or what the output structure is.
判断性编码落盘标准化(收编"每次研究手写脚本"的手工环节)。按 CaseFlag(或 Gid)在 04(core 优先)/03 中找到原始记录;把编码字段**追加**到原始记录上(字段保全铁律:原始 MCP 字段只增不改);与已有 05 按 Gid 合并(同案编码字段覆盖更新),写回 05_enriched_cases.json。
生成「脱敏演示数据」(可复现)。为什么需要它:北大法宝是订阅制,拿不到 Token 的访客无法跑通工作流、也看不到产出。本脚本合成一份**结构与 MCP get_case_list 返回完全一致**的小样本(6 件普通案例 + 2 件经典/指导案例),让任何人无需 Token 即可一键跑通 normalize → run_analytics(出图) → generate_excel → 渲染 docx → verify_report 从而看到工作流的真实产出形态。
生成「集团诉讼·证券虚假陈述」脱敏演示数据(可复现)。为两大研究模式提供同一套**证券虚假陈述合成数据**:实案示范(类案检索报告·四顺位深挖)与学理示范(裁判规则研究报告·全景范式)共用本数据,让无 Token 访客看清两模式的结构差异。
裁判观点分歧检测(数据层,散案/集团案两类管道共用)。把"同一争点、对立立场并存"从统计副产品升级为一等产出。对每个出现 ≥2 个实质立场的争点,输出 立场分布 / 各立场代表案号 / 地域观察 / 地域闸门判定。
报告 Markdown → Word(薄包装)。解析 output/<report_md> 的 Markdown 为干净 JSON 块模型(封面元信息、分级标题、正文/要点、`[案名(案号·法院)](裸链接)` 转脚注、`[^id]`+定义 转脚注、`![chart:key]` 按图表清单插图、Markdown 表格),交由共用渲染器 render_report.mjs(docx-js)产出 .docx。
检索覆盖率自检(把"完整性不可保证"变成量化缺口表)。读 03_raw_cases.json(含 _query 命中词)与 04_screened_cases.json(含 _track),可选读 <research_dir>/名录.json(典型案例名录),输出分节量化结果:关键词覆盖 / 案件等级分布 / 法院层级分布 / 年份跨度 / 时效结构 / track分布 / 名录核对 / 去重审计 / 顺位覆盖。
No input schemas visible in source code. All 7 tools lack JSON Schema definitions with type constraints, required fields, and validation rules. Parameter descriptions exist in docstrings but are not machine-parseable.
Descriptions are in Chinese with domain-specific legal terminology (e.g., '判断性编码落盘标准化', '四顺位法院解析'). LLMs trained primarily on English struggle to parse intent from non-English descriptions, reducing tool discoverability and selection accuracy.
No output schemas documented. Tools return JSON files or structured data, but the response format is not formally specified. LLMs cannot plan downstream tool calls without knowing what fields to expect.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 23 | 2026-07-28+ | v2 |
实案模式四顺位法院解析(法发〔2020〕24号第四条)。输入核心法院(待决案件审理法院),输出四顺位检索范围的法院清单提议:顺位① 最高人民法院发布的指导性案例;顺位② 最高人民法院发布的典型案例及裁判生效的案件;顺位③ 本省(自治区、直辖市)高级人民法院发布的参考性案例及裁判生效的案件;顺位④ 上一级人民法院及本院裁判生效的案件。
Tool names lack clear action verbs. 'build_demo_fixture' and 'build_demo_secmisrep' are vague about what 'build' produces. 'apply_coding' does not clarify whether it reads, writes, or transforms. Verb-noun naming (e.g., 'generate_demo_fixture', 'merge_coding_into_cases') would improve clarity.
No error handling or recovery guidance. Tools fail silently or with generic messages (e.g., 'file not found'). No guidance on retryability, user-fixable errors, or next steps. Example: apply_coding prints warnings but does not return structured error codes.