Skip to main content
Glama
deenesjakoruzh
Cherridsaid

multidim-mcp

by Cherridsaid
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

multidim-mcp

面向 AI 智能体的结构化思维网格——一个独立的 MCP 服务器，纯标准库实现。

Multidim 将一个主题路由到一组分析透镜（一个上下文），并返回一个 层级化网格——轴、子透镜、强制问题——供调用方 LLM 填写。思考始终留在调用方： 服务器只提供结构，绝不提供认知。它不调用任何 LLM，不发起任何网络请求， 相同的输入永远产出相同的框架。

  • 零依赖 —— Python 3.9 以上，仅用标准库。

  • 确定性 v2 契约 —— 每个框架都携带可自校验的 frame_hash； 已填写的分析会逐节校验，并返回可操作的错误码。

  • 习得陷阱 —— 你记录一次的教训会变成强制问题， 注入到之后所有主题匹配的未来框架中。

  • 加固的存储 —— 原子写入、原生跨进程锁、增量迁移、 带备份的重置，以及一道拒绝触碰任何外来 ~/.multidim 存储的防线。

看看区别在哪里

一个智能体分析*"我们是否应该把计费服务从 MySQL 迁移到 PostgreSQL？"*。 每个部分都填满了，每句话读起来都没问题。以下是 multidim_validate 在第一次检查时返回的内容：

overall verdict: REJECT

REJECT  alternatives        NOT_ENOUGH_ALTERNATIVES, ALTERNATIVE_DUPLICATES_PRIMARY
REJECT  hypotheses          HYPOTHESIS_NOT_FALSIFIABLE
REJECT  second_order_risks  SECOND_ORDER_REPEATS_FIRST
REJECT  cross_talk          GENERIC_DENSITY_HIGH
REJECT  synthesis           SYNTHESIS_WITHOUT_REFERENCES
WARNING premortem           PREMORTEM_SIMILAR_TO_RISKS

唯一一个备选方案只是复述了假设本身，假设没有携带任何能够证伪它的检验， 二阶效应逐字重复了一阶效应，结论没有引用上面任何一部分工作。这些缺陷 在你阅读答案时都不可见；而这里全部按名称一一指了出来。

重做被拒绝的部分后，同一个检查器返回 ACCEPT。若编辑框架删除你觉得碍事的 规则，它会拒绝整个提交——因为框架携带了自身内容的哈希。

完整记录，包括修正后的部分长什么样，以及这个检查器有意不检查什么： DEMO.md。一条命令即可复现：python demo.py。

Related MCP server: CRASH - Cascaded Reasoning with Adaptive Step Handling

快速开始

pip install multidim-mcp        # from PyPI
pip install .                   # or from a source checkout

用任何 MCP 客户端注册该服务器（stdio 传输）：

{
  "mcpServers": {
    "multidim": {
      "command": "multidim-mcp"
    }
  }
}

或者直接运行：python -m multidim_mcp，无需安装：uvx multidim-mcp。

该服务器已列入官方 MCP Registry，名为 io.github.Cherridsaid/multidim-mcp。

工具

工具

职责

multidim_analyze

为某个主题构建网格（depth：core / deep / full；format：文本或确定性的 v2 JSON 框架）

multidim_contexts

列出所有已知上下文及其轴与子透镜

multidim_validate

对已填写的分析与对应 v2 框架进行确定性、无状态的校验——逐节返回 ACCEPT / WARNING / REJECT

multidim_learn

创建或丰富一个上下文（关键词、轴、教训）——唯一的写入入口

工作原理

  1. multidim_analyze 为你的主题检测最合适的上下文（基于词边界的 关键词匹配，已做变音折叠），返回一个 v2 框架：必需章节、 章节模式、校验规则，以及所有触发条件匹配的习得陷阱。

  2. 你的 LLM 逐节填写该框架。

  3. multidim_validate 从存储中重建框架，拒绝被篡改或过期的框架 （通过 frame_hash），随后对分析进行校验：结构完整性、 假设的证伪检验、与主方案真正不同的备选方案、与一阶效应 有别的二阶效应、不照抄风险清单的事后复盘、引用了真实标识符的综合结论， 以及措辞填充密度上限。只有被判定为 REJECT 的节需要重做， 且必须在框架的 max_validation_rounds 范围内完成。

四个种子上下文是中性的、确定性的：generic（8 个通用透镜）、 code_review、technical_writing、decision。

存储

存储位于一个专有的每用户数据路径上（可用 MULTIDIM_MCP_HOME 覆盖）， 首次运行时由中性种子创建。写入操作是原子的，并使用操作系统原生文件锁 跨进程串行化；任何重置之前，损坏的存储都会被备份，绝不静默丢弃。 一道绊线会拒绝一切解析到外来个人 ~/.multidim 存储的读写操作。

发布分支的维护者可以通过 MULTIDIM_MCP_EXTRA_FORBIDDEN（逗号分隔）扩展 中性守卫，加入自己的私有标记，而无需将标记硬编码进公开源码。

透明性

  • 不是 AI 系统 —— multidim-mcp 不包含任何模型，也不执行任何推理： 它是确定性的、基于规则的软件。根据欧盟《人工智能法案》（EU Reg. 2024/1689）， 它不属于该法案第 1 条第 (1) 款意义上的 AI 系统；作为自由开源软件， 它落入第 2 条第 (12) 款的豁免范围。它不收集数据，也不发起任何网络调用。

  • 本文档中的插图由 GPT 生成，并保留其 C2PA 来源信息不变。

开发

python run_tests.py      # full suite, stdlib only
python smoke_install.py  # packaging smoke test (wheel + venv + entry point)
python demo.py           # the analyse -> validate -> fix -> accept cycle of DEMO.md

CI 在 Ubuntu 与 Windows 上分别针对 Python 3.9 / 3.11 / 3.13 运行。

许可证

Apache-2.0 —— 参见 LICENSE。

Available Tools

4 tools
multidim_analyzeA

Build a hierarchical multidimensional grid (axes -> sub-lenses) adapted to the subject's context. Returns the grid to fill, not the analysis.

ParametersJSON Schema
NameRequiredDescriptionDefault
depthNoOptional, default deep. core=axes+short cross-talk; deep=+sub-lenses; full=+one targeted recursion.
formatNoOptional, default text (v1 grid). v2 = deterministic JSON frame of the v2 contract: frame_hash, mandatory questions, learned traps, required_sections, validation_rules, max_validation_rounds, optional host_hints. The calling LLM fills this frame section by section.
contextNoOptional. Force a context; otherwise auto-detected.
subjectYesThe subject to analyse.

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the key behavioral trait that the tool returns an unfilled grid rather than a final analysis. It does not mention side effects, error behavior, or state changes, though as a grid-builder this seems likely to be a read-only operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two economical sentences front-load the core action and outcome. Every sentence earns its place, and the clarifying 'not the analysis' is high-value contrast without extra fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with four parameters, two well-described enums, and no output schema, the description conveys the essential context: build a tailored grid and return it as a scaffold. It could say more about how the grid should be consumed or validated, but the schema and the explicit 'grid to fill' message make it sufficiently complete for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter, including depth and format enums. The description adds the contextual phrase 'adapted to the subject's context' and the notion of returning a fillable grid, but it does not need to repeat parameter details. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (Build) and a concrete resource (hierarchical multidimensional grid with axes and sub-lenses), and clarifies the deliverable by contrasting it with analysis. This distinguishes the tool's purpose even without explicitly naming sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'adapted to the subject's context' implies when the tool is appropriate, and 'Returns the grid to fill, not the analysis' suggests its output is a scaffold for further work. However, the description does not explicitly say when to prefer this tool over multidim_contexts, multidim_validate, or multidim_learn.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

multidim_contextsA

List every known context with its axes and sub-lenses.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It conveys that this is a read-only listing operation and describes the output contents, but it does not mention pagination, ordering, size, or whether the result is a snapshot of the current state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler or redundancy. Every word contributes to the agent's understanding of what the tool returns.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, no annotations, and no output schema, the description is nearly complete: it states that the tool takes no inputs and returns all contexts with their axes and sub-lenses. The only minor omission is detail on output formatting or return boundary, but for a simple list tool this is a modest gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so the schema already fully describes the input surface. The description correctly avoids inventing parameters and needs to communicate nothing further about parameter behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('List') and resource ('every known context'), and specifies what the result includes ('axes and sub-lenses'). This clearly separates it from the sibling operations analyze, validate, and learn.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not say when a caller should choose this tool over multidim_analyze, multidim_validate, or multidim_learn. There is no mention of when enumeration is useful, such as before analyzing or validating, and no exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

multidim_learnA

Create or enrich a context. Use only to promote a lens reusable beyond the current subject: deliberate promotion, never automatic. Persists to the dedicated store (the only write door).

ParametersJSON Schema
NameRequiredDescriptionDefault
axesNo
trapsNoOptional. Learned traps (paid lessons): each becomes a mandatory question injected into future v2 frames when a trigger matches the subject. Deduplicated by trap_id or statement; active:false disables a lesson without deleting it.
contextYes
keywordsNo
descriptionNo

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden and does disclose persistence to a dedicated store and the write-only nature of the tool. However, it does not explain whether 'enrich' overwrites or merges an existing context, whether calls are idempotent, or what failure behavior looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each earning its place: the action, the condition for use, and the persistence side effect. The most decision-relevant information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter write tool with no annotations and no output schema, this description is too thin. It defines the tool's role but leaves the meaning of multiple parameters unexplained and says nothing about return values, so an agent cannot confidently construct a correct call beyond the required context field.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20%, so the description needed to compensate by explaining parameters like axes, keywords, and description, but it does not. It only names 'context' without giving semantics for that required parameter or any of the other top-level fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-resource pair ('Create or enrich a context') and clearly delimits the tool's purpose: promoting a reusable lens rather than analyzing or validating. The phrase 'the only write door' distinguishes it from the sibling tools without needing their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit use condition: only promote a lens reusable beyond the current subject, and only through deliberate promotion, never automatic. It does not name the sibling alternatives for when to use them instead, but the 'only write door' phrasing clearly separates this from the other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

multidim_validateA

Deterministic, STATELESS check of a filled analysis against its v2 frame (multidim_analyze format v2). Returns an ACCEPT / WARNING / REJECT verdict per section with actionable error codes. Never modifies the store, calls no LLM, never judges the truth of the content: structure, internal consistency and checkable requirements only. The calling LLM redoes ONLY the rejected sections, within the frame's max_validation_rounds (tracked by the caller).

ParametersJSON Schema
NameRequiredDescriptionDefault
frameYesThe exact JSON frame returned by multidim_analyze format v2.
analysisYesThe analysis filled by the calling LLM, section by section.

TDQS

A4.4/5.0
Behavior5/5

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 explicitly states determinism, statelessness, no store modification, no LLM calls, no judgment of content truth, and actionable error codes per section. This is thorough and leaves little ambiguity about side effects and scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph, but it is front-loaded with the core purpose and every sentence contributes key information: how it works, what it returns, what side effects it avoids, and how the caller should react. It could be structurally broken into bullets, but it is concise and free of filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (two nested objects, no output schema, no annotations), the description is complete: it covers purpose, behavior, output shape (verdicts per section), non-modification, non-truth-judging nature, and explicit caller responsibility. An agent has all needed information to decide when and how to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes both parameters adequately (frame as v2 frame, analysis as filled analysis), so the baseline is 3. The description adds context about the frame format and the caller's responsibility, but it does not provide field-level semantics beyond what the schema provides. No extra detail about required or optional properties is added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('check') and resource ('filled analysis against its v2 frame'), and clearly defines the output as ACCEPT/WARNING/REJECT per section. It distinguishes itself from multidim_analyze by referencing its format v2 and from content-judging tools by explicitly saying it never judges truth.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context on when to use the tool: as a check of a filled analysis against its frame, returning verdicts per section. It also explains the usage loop—only rejected sections are redone, within max_validation_rounds. It does not explicitly name alternatives or exclusion conditions, but the contrast with LLM-based analysis and store-modifying operations implies when not to use it.

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.

  1. 4 tool updatesv0.1.0
    • First observedmultidim_analyze
    • First observedmultidim_contexts
    • First observedmultidim_learn
    • First observedmultidim_validate
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.9/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a unique, clearly defined purpose: analyze creates a grid, contexts lists them, validate checks structure, and learn writes. No overlapping responsibilities.

Naming Consistency4/5

All tools share the 'multidim_' prefix, but 'multidim_contexts' uses a noun instead of a verb_noun pattern while others use verbs (analyze, validate, learn). Minor inconsistency.

Tool Count4/5

With only 4 tools, the server is tightly scoped for its domain. The count is low but appropriate for a focused multidimensional analysis framework, not over- or under-inclusive.

Completeness4/5

The tools cover the core lifecycle: creating/analyzing, listing, validating, and learning. There is no explicit delete, but 'learn' can enrich or create, and the set appears sufficient for the stated purpose.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers