Skip to main content
Glama
deenesjakoruzh
Cherridsaid

multidim-mcp

by Cherridsaid
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

multidim-mcp

Структурированные сетки мышления для ИИ-агентов — автономный 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 как io.github.Cherridsaid/multidim-mcp.

Инструменты

Инструмент

Роль

multidim_analyze

Построить сетку для темы (depth: core / deep / full; format: текст или детерминированный JSON-фрейм v2)

multidim_contexts

Перечислить все известные контексты с их осями и под-линзами

multidim_validate

Детерминированная проверка без состояния заполненного анализа по его v2-фрейму — ACCEPT / WARNING / REJECT для каждого раздела

multidim_learn

Создать или обогатить контекст (ключевые слова, оси, ловушки) — единственная дверь для записи

Как это работает

  1. multidim_analyze определяет наилучший контекст для вашей темы (сопоставление ключевых слов по границам слов, с учётом акцентов) и возвращает v2-фрейм: обязательные разделы, схемы разделов, правила валидации, обязательные вопросы — включая каждую изученную ловушку, чьи триггеры соответствуют теме.

  2. Ваша LLM заполняет фрейм, раздел за разделом.

  3. multidim_validate пересобирает фрейм из хранилища, отклоняет изменённый или устаревший (frame_hash), затем проверяет анализ: структурную полноту, тесты на опровержение гипотез, альтернативы, которые действительно отличаются от основной, эффекты второго порядка, отличные от первого порядка, пре-мортем, который не копирует список рисков, синтез, который ссылается на реальные идентификаторы, и ограничение плотности фраз-заполнителей. Переделываются только отклонённые разделы, в пределах max_validation_rounds фрейма.

Четыре исходных контекста нейтральны и детерминированы: generic (8 общих линз), code_review, technical_writing, decision.

Хранилище

Хранилище находится в специальном пути данных для каждого пользователя (MULTIDIM_MCP_HOME переопределяет его) и создаётся при первом запуске из нейтральных исходников. Записи атомарны и сериализованы между процессами с помощью нативной файловой блокировки ОС; повреждённое хранилище перед сбросом резервируется, никогда не отбрасывается молча. Ловушка отказывает в любом чтении или записи, которые могут разрешиться в чужое личное хранилище ~/.multidim.

Поддерживающие форки могут расширить защиту нейтральности своими приватными маркерами через MULTIDIM_MCP_EXTRA_FORBIDDEN (через запятую), не встраивая их в публичный исходный код.

Прозрачность

  • Не является ИИ-системой. multidim-mcp не содержит модели и не выполняет выводов: это детерминированное программное обеспечение, основанное на правилах. В соответствии с Законом ЕС об ИИ (Рег. 2024/1689) он не является ИИ-системой в смысле ст. 3(1), и как свободное и открытое программное обеспечение подпадает под исключение ст. 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 запускается как на Ubuntu, так и на Windows для Python 3.9 / 3.11 / 3.13.

Лицензия

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