frame-check-mcp
Frame Check
看看任何文档没有向你展示的内容。
Frame Check 是一个结构化框架分析工具。它能指出文档采取了哪些视角、忽略了哪些视角,以及它是如何定位读者的。在有覆盖范围的情况下,它还会对照权威来源对数值声明进行交叉核对。
快速入门 (MCP 服务器)
PyPI 软件包 frame-check-mcp 是模型上下文协议 (MCP) 服务器。它在本地运行,并为任何兼容 MCP 的 AI 客户端(Claude Desktop、Cursor、Cline、Continue.dev 等)提供确定性的结构化框架分析工具。
pip install frame-check-mcp然后将你的 MCP 客户端指向已安装的入口点。对于 Claude Desktop,请添加到 claude_desktop_config.json:
{
"mcpServers": {
"frame-check": {
"command": "frame-check-mcp"
}
}
}重启客户端。然后在任何对话中输入:“你能对这份文档进行框架检查吗?”完整的安装和验证详情请参阅 MCP_SERVER.md。
Related MCP server: Kluster.ai Verify MCP
功能介绍
传入一份文档,Frame Check 将返回:
结构化框架概况:文档涵盖了五种分析视角(原因、风险、利益相关者、趋势、不确定性)中的哪几种,忽略了哪些,以及每种视角的密度。
语调和认知姿态:文档如何定位读者,以及有多少比例的声明归因于来源。
时间取向:文档是将结论建立在历史数据、现状还是预测之上。
框架词汇标准 (Frame Vocabulary Standard) 候选匹配:命名框架模式,其基于规则的信号会在文本上触发,每个模式都带有识别线索和工作示例。匹配属于候选级别;针对多源标注的精确度是一个正在研究的课题。
来源网络验证:针对 SEC EDGAR、FRED、世界银行、REST Countries、Alpha Vantage 和 Wolfram Alpha 等提供商有覆盖范围的数值声明进行核对。
可选的 AI 叙述,在散文层面解释框架。标注清晰,以便读者不会将语言模型的解释与确定性测量混为一谈。
方法
结构化测量是基础。工具做出的每一项框架声明都是通过确定性模式匹配器计算得出的,并且对于相同的输入总是返回相同的结果。如果配置了 API 密钥,AI 辅助解释可作为增强功能提供,但会进行相应标注,绝不会隐藏在结构层之后。
验证是有边界的。该工具仅针对对声明类型具有真实覆盖范围的提供商验证数值声明,并且它会展示其自身的校准结果(每个提供商的精确率、召回率、F1 值),而不是在没有证据的情况下断言结论。
命名模式检测是独立于结构概况的可靠性层。在预注册验证中,检测器对专家标注者的 F1 = 0.36,低于 0.4 的有用阈值。在 v0 版本中,重点转向构建诚实度呈现(欠检测标记、密度警告、置信状态)而非自信的标签,这是支撑性的主张;一项读者辅助研究(Track B,预注册)正在测试这种呈现方式是否真的能帮助读者看到他们原本会错过的框架。
诚实的局限性和预期的对抗性解读已在 ANTICIPATED_CRITIQUES.md 中编目。
文档
METHODOLOGY.md— 完整方法论论文 (v0.2 草案)MCP_SERVER.md— MCP 服务器参考(工具、资源、提示词)MCP_CLIENT_CONFORMANCE_v1.md— 针对已安装 wheel 的 32/32 一致性往返测试FRAME_DIVERGENCE_v1.md和FRAME_DIVERGENCE_v2.md— 差异架构data/frame_library/— 包含 20 个条目的 FVS 目录及工作示例ANTICIPATED_CRITIQUES.md— 自行枚举的对抗性解读VALIDATION_PROGRAM.md— 观察性 + 正式验证计划
运行测试
pip install -r requirements.txt
python3 run_tests.py49 个测试套件,约 3 分钟。包括 test_mcp_adversarial.py 中的 63 个对抗性调度程序测试,以及 V4.2 引擎 + 分类器覆盖范围。
许可证
代码采用 Apache-2.0;FVS 库和工作示例采用 CC-BY-4.0(请参阅 NOTICE 获取各目录的枚举)。
引用
如果 Frame Check 对你的工作有帮助,请参阅 CITATION.cff 获取可引用格式。Frame Check 由 Lovro Lucic 创作;根据构建诚实度原则,署名是该项目的主要信誉资产。
贡献
根据 CONTRIBUTING.md 要求签署 DCO。治理遵循 GOVERNANCE.md(BDFL 模型,具有用于规范推广决策的命名强制函数)。外部评审员参与遵循 REVIEWERS.md。
问题
Available Tools
2 toolsframe_checkA
Deterministic structural framing analysis. Returns analysis (measurements) + agent_guidance (composition discipline, scope-regime guidance, faithfulness rules) + provenance (versions, license, citation). When source_text is provided, also runs Layer 4 source_fidelity and Layer 11 grounding_decomposition with a Monte-Carlo-verified scope regime. When include_divergence=true (default at 0.8.0), the response carries a top-level divergence block sorted by signal_strength. The agent's role is to compose ONE insight grounded in the cited measurements (a reading the user could not see by reading their own document), not to walk the measurements one by one. The measurements are Frame Check's; the reading is the agent's. Cite measurements as Frame Check's; frame the reading as a reading ('the pattern reads as X'), never as a verdict ('the document is X'). Repeated calls with identical inputs return identical measurements; the agent's insight is a composition over them.
| Name | Required | Description | Default |
|---|---|---|---|
| document_text | Yes | The document to analyse. English. 300-10,000 words. Markdown accepted. This is the text whose framing you want named. | |
| source_text | No | Optional. The source material the document is supposed to ground in (research report, filing, primary source). Unlocks Layer 4 source_fidelity (digit-level match) and Layer 11 grounding_decomposition (sentence-level G/F/P) with a scope regime telling you which layer to trust on number-dense sources. Without this, only structural framing analysis runs. | |
| prefer_contract_version | No | Optional. Coverage contract version the client prefers. 1 (default): emit both v1 coverage and v2 coverage_v2 (Phase 1 compatibility window). 2: emit only coverage_v2 and omit v1 (for clients that have migrated and want to avoid payload duplication). See MCP_CONTRACT_V2_PROPOSAL.md and MCP_SERVER.md 'Contract versions' section. When Phase 3 activates, v1 will stop emitting regardless of this parameter. | |
| include_divergence | No | Optional. Frame divergence output per FRAME_DIVERGENCE_CONTRACT_v1 Part 2. When true (default at 0.8.0; was opt-in at 0.7.x), the response carries a top-level `divergence` block (absent_frames array sorted by signal_strength tier, FaithfulnessEnvelope with divergence_summary prose) and two `agent_guidance` additions (how_to_render_divergence, absence_is_not_prescription). MCP surface does not invoke any LLM for divergence; the caller's agent model completes the composition using the guidance + library resources. Set explicitly to false to receive the v0.7.x-shape response with no divergence block. Default: true. | |
| domain_hint | No | Optional. Hint about the document's domain used to filter absent frames for domain relevance. Only meaningful when include_divergence=true. If omitted, the envelope reports domain_inferred='unfiltered' and all absent frames are returned. Domain-metadata-based filtering is a future contract minor version; the current implementation echoes the hint to the envelope without field-level filtering (documented in envelope.limitations). | |
| divergence_rendering | No | Optional. How the caller wants absent-frame records decorated. Only affects AbsentFrameRecord decoration (teaching_question field present in 'teaching_questions' mode); all other modes return the same data. The caller's agent model renders per this preference with faithfulness guarantees from agent_guidance.how_to_render_divergence. Default: 'list'. | |
| catalog_version_pin | No | Optional. Pin the FVS catalog version used for absent-frame set difference. If omitted, the latest stable catalog version is used (currently library_v3 per commit 9abeb3d). Unsupported pins are coerced to library_v3 with a limitation note in envelope.limitations. | |
| user_context | No | Optional. The user's situation, role, or decision context in plain prose (e.g., 'I'm a startup founder making a hire decision in healthcare AI', 'reviewing a research paper on language model alignment', 'drafting a Substack post on agent safety'). When provided, agent_guidance.how_to_render_divergence is extended to instruct the caller's model to filter divergence relevance for this context. The MCP does NOT echo the value back into the response (privacy posture); the caller's agent has it from the call args. Discipline: the context personalizes RELEVANCE FILTERING; never PRESCRIPTION. The absence_is_not_prescription guarantee extends to contextual surfacing. Default: omitted (no contextual filtering). Maximum length 2000 chars. | |
| include_frame_opportunities | No | Optional. Opt-in flag for LLM-augmented frame-opportunity composition (Item 12 of the substrate-side composition roadmap). When true, divergence.frame_opportunities carries up to 3 document-specific questions composed by the LLM from absent-frame teaching questions plus the document's content. Each opportunity carries model_provenance with model name, cost_usd, and is_deterministic=false. The deterministic substrate (clusters, patterns, absences) is unchanged. Cost is bounded at ~0.001 USD per invocation (3 Gemini Flash calls max). Falls back to empty opportunities list with available=false if GEMINI_API_KEY is not set or the google.genai library is unavailable. Default: false (deterministic substrate only). | |
| user_goal | No | Optional. The user's stated goal for invoking Frame Check. One of 'decide', 'brainstorm', 'persuade', 'learn', 'audit'. When provided, absent_frames carry a goal_relevance dict for frames load-bearing for the chosen goal, and the absent_frames sort promotes goal-relevant entries within their signal_strength tier (goal precedes genre in the within-tier ranking). 'audit' is the default-equivalent posture: no goal-specific override is applied; the existing catalog/coverage/genre ranking stands. When omitted, behavior matches 'audit'. Substrate-side composition Item 11. | |
| compose_budget | No | Optional. Bound the substrate's output volume so an agent in a tight working-memory budget can request a compact reading without losing structural shape. 'minimal' = top-3 absent_frames, top-1 absence_cluster, top-1 frame_pattern. 'standard' = top-5 absent_frames, all clusters, all patterns. 'full' (default) = unfiltered. The envelope.tier_counts always reflects PRE-slice counts so the agent sees the truncation honestly; divergence.compose_budget_applied carries per-layer returned/total counts. Substrate-side composition L5 interface UX. Backwards-compatible: omit to preserve current behavior. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it declares determinism, output structure, agent's role, and limitations (e.g., 'The measurements are Frame Check's; the reading is the agent's'). No contradictions.
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 front-loaded with purpose but becomes verbose with detailed instructions and repeated guidance. While well-structured, it could be trimmed by ~30% without losing meaning.
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 complexity (11 params, no output schema), the description covers response components and behavioral nuances well. Missing explicit field-level structure of divergence block, but agent_guidance hints at rendering instructions.
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%, so baseline is 3. The description adds value by explaining defaults, version behavior, and interaction between parameters (e.g., domain_hint only meaningful when include_divergence=true). This exceeds 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 'Deterministic structural framing analysis' and lists output components (measurements, agent_guidance, provenance). It explicitly distinguishes from sibling 'frame_compare' by focusing on single-document analysis.
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 guidance on when to use source_text (for layers 4 & 11), when include_divergence is default, and agent role. However, it does not explicitly exclude use cases or contrast with frame_compare, so it lacks explicit when-not advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
frame_compareA
Deterministic structural comparison of two documents on the same subject. Returns analysis (per-document summaries plus the cross-document comparison: shared blind spots, unique coverage gaps, voice / temporal / epistemic deltas, and a structured framing-differences narrative with per-dimension reader implications) + agent_guidance (what comparison tells and does not tell you, how to cite without implying a ranking) + provenance. Repeated calls with identical inputs return identical results. No LLM is invoked.
| Name | Required | Description | Default |
|---|---|---|---|
| document_a_text | Yes | The first document to compare. English. 300-10,000 words. | |
| document_b_text | Yes | The second document to compare. English. 300-10,000 words. Should be on the same subject as document_a_text for the comparison to be meaningful. | |
| document_a_label | No | Optional short label for document A (e.g. 'Industry view' or 'Gemini response'). Used in the comparison narrative. Defaults to 'Document A'. | |
| document_b_label | No | Optional short label for document B. Defaults to 'Document B'. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is deterministic, returns identical results for identical inputs, and does not invoke an LLM. It also explains what the output includes (analysis, agent_guidance, provenance), providing transparency beyond basic behavior.
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 well-structured, starting with the core purpose, then listing outputs, and finally additional traits (deterministic, no LLM). It is slightly long but each sentence adds value, and it front-loads the most important information.
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 no output schema, the description thoroughly explains what the tool returns (analysis, agent_guidance, provenance). It covers parameter constraints (word count, language, same subject) and behavioral traits. The context is complete for an agent to understand when and how to use 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?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context: documents must be English, 300-10000 words, and on the same subject. It also clarifies that labels are optional and used in the narrative, which goes beyond the schema descriptions.
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 does 'deterministic structural comparison of two documents on the same subject' and lists specific outputs (per-document summaries, cross-document comparison, etc.). It uses a specific verb ('compare') and resource ('two documents'), distinguishing it from the sibling tool 'frame_check'.
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 implies when to use (documents on same subject, deterministic comparison) but does not explicitly state when not to use or compare with alternatives. It notes that repeated calls return identical results and that no LLM is invoked, but lacks direct guidance on choosing this over the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
frame_check - First observed
frame_compare
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one analyzes a single document, the other compares two documents. There is no ambiguity.
Both tools follow the consistent 'frame_<verb>' pattern (frame_check, frame_compare). The naming is predictable and uniform.
With only two tools, the server feels minimal. While the tools are well-scoped, a server for structural analysis might benefit from additional tools for tasks like batch comparison or result export.
The server covers the two core operations (single analysis and pairwise comparison). Minor gaps exist, such as lacking a tool for multi-document analysis or aggregation, but the main use cases are addressed.
Maintenance
Related MCP Connectors
Verify claims with verdict, confidence & cited sources; batch verify, source checks, daily brief.
Verify AI outputs against real sources. Returns a trust signal and permanent doc number.
Fact-checks generated content against your sources of truth showing what to trust, change, & verify.
AI document intelligence: extract, summarize, claim-check, notarize, and signed action receipts.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables analysis of claims, validation of sources, and detection of manipulation using multiple epistemological frameworks to ensure credible and ethical information.323MIT

Kluster.ai Verify MCPofficial
AlicenseNot gradedqualityNot gradedmaintenanceEnables fact-checking of AI responses against reliable sources and validation of responses against document content to ensure accuracy and reliability.-- AlicenseBqualityDmaintenanceEnables working with large documents of any size by intelligently segmenting them and using TF-IDF search to retrieve only relevant fragments, preventing context window saturation. Provides 31 domain-agnostic tools for document ingestion, semantic analysis, epistemological validation, and extraction verification across formats like PDF, EPUB, and HTML.31MIT
- AlicenseBqualityCmaintenanceEnables revision-bound source audits with exact article fingerprinting, claim-to-source mapping, quotation verification, and immutable JSON evidence reports for prepublication review.9MIT