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

유일한 대안은 가설을 되풀이했을 뿐이고, 가설에는 틀렸음을 증명할 테스트가 없었으며, 2차 효과는 1차 효과를 글자 그대로 반복했고, 결론은 앞선 작업 중 어떤 것도 참조하지 않았다. 이런 문제는 답변을 읽을 때 전혀 드러나지 않는다. 하지만 여기서는 항목별로 전부 보고한다.

거부된 섹션을 다시 작업하면 같은 검사기가 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)은 거부된다. 그런 다음 분석을 검사한다: 구조적 완전성, 가설에 대한 반증 테스트, 기본안과 실제로 다른 대안, 1차 효과와 구별되는 2차 효과, 위험 목록을 복사하지 않는 프리모템, 실제 식별자를 참조하는 종합, 그리고 채우기 문구 밀도 상한. 거부된 섹션만 프레임의 max_validation_rounds 이내에서 다시 수행된다.

네 개의 시드 컨텍스트는 중립적이고 결정적이다: generic (8개 일반 렌즈), code_review, technical_writing, decision.

저장소

저장소는 전용화자별 데이터 경로에 위치하며(MULTIDIM_MCP_HOME으로 재정의 가능) 처음 실행 시 중립 시드로부터 생성된다. 쓰기는 원자적이며 OS의 네이티브 파일 잠금으로 프로세스 간 직렬화된다. 손상된 저장소는 리셋 전에 항상 백업되며 절대 조용히 폐기하지 않는다. 트립와이어는 외부 개인 ~/.multidim 저장소로 이어지는 모든 읽기/쓰기를 거부한다.

포크를 배포하는 유지관리자는 개인적인 비공개 표시를 공개 소스에 하드코딩하지 않고 MULTIDIM_MCP_EXTRA_FORBIDDEN(쉼표로 구분)을 통해 이 중립성 보호막을 확장할 수 있다.

투명성

  • AI 시스템이 아니다. multidim-mcp는 모델을 포함하지 않으며 어떤 추론도 수행하지 않는다. 결정적이고 규칙 기반의 소프트웨어다. EU AI Act(Reg. 2024/1689)에 따라 Art. 3(1)에 정의된 AI 시스템이 아니며, 무료·오픈소스 소프트웨어로서 Art. 2(12) 면제 조항에 해당한다. 어떠한 데이터도 수집하지 않고 네트워크 호출도 하지 않는다.

  • 이 README의 일러스트레이션은 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는 Python 3.9 / 3.11 / 3.13에 걸쳐 Ubuntu와 Windows 둘 다에서 실행된다.

라이선스

Apache-2.0 — LICENSE 및 NOTICE 참조.

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