Skip to main content
Glama
deenesjakoruzh
Cherridsaid

multidim-mcp

by Cherridsaid
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

multidim-mcp

Strukturierte Denkraster für KI-Agenten – ein eigenständiger MCP-Server, reine Standardbibliothek.

Multidim leitet ein Thema an eine Reihe von Analyse-Linsen (einen Kontext) weiter und gibt ein hierarchisches Raster zurück – Achsen, Unter-Linsen, Pflichtfragen –, das die aufrufende LLM ausfüllt. Das Denken bleibt beim Aufrufer: Der Server liefert Struktur, niemals Kognition. Er ruft keine LLM auf, macht keine Netzwerkanfragen, und dieselbe Eingabe erzeugt immer denselben Rahmen.

  • Null Abhängigkeiten – Python 3.9+, nur Standardbibliothek.

  • Deterministischer v2-Vertrag – jeder Rahmen trägt einen selbstverifizierbaren frame_hash; eine ausgefüllte Analyse wird Abschnitt für Abschnitt mit umsetzbaren Fehlercodes geprüft.

  • Gelernte Fallen – Lektionen, die du einmal aufzeichnest, werden zu Pflichtfragen, die in jeden zukünftigen Rahmen eingefügt werden, dessen Thema übereinstimmt.

  • Abgesicherter Speicher – atomare Schreibvorgänge, natives prozessübergreifendes Sperren, additive Migrationen, gesicherte Zurücksetzungen und eine Wächterfunktion, die sich weigert, jemals einen fremden ~/.multidim-Speicher zu berühren.

Den Unterschied sehen

Ein Agent analysiert „Sollten wir den Abrechnungsdienst von MySQL auf PostgreSQL migrieren?". Jeder Abschnitt ist ausgefüllt, jeder Satz liest sich gut. Hier ist, was multidim_validate bei diesem ersten Durchlauf zurückgibt:

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

Die einzige Alternative wiederholte die Hypothese, die Hypothese enthielt keinen Test, der sie widerlegen könnte, der Effekt zweiter Ordnung wiederholte den ersten wortwörtlich, und die Schlussfolgerung bezog sich auf keine der obigen Arbeiten. Nichts davon ist sichtbar, wenn du die Antwort liest; alles wird hier namentlich gemeldet.

Wiederhole die abgelehnten Abschnitte und derselbe Prüfer gibt ACCEPT zurück. Bearbeite den Rahmen, um die Regel zu löschen, die dir unangenehm ist, und er verweigert die gesamte Einreichung – der Rahmen trägt einen Hash seines eigenen Inhalts.

Vollständiges Transkript, einschließlich wie die korrigierten Abschnitte aussehen und was dies bewusst nicht prüft: DEMO.md. Reproduziere es mit einem Befehl: python demo.py.

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

Schnellstart

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

Registriere den Server bei einem beliebigen MCP-Client (stdio-Transport):

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

Oder führe ihn direkt aus: python -m multidim_mcp, oder ohne Installation: uvx multidim-mcp.

Der Server ist im offiziellen MCP-Registry als io.github.Cherridsaid/multidim-mcp gelistet.

Werkzeuge

Werkzeug

Rolle

multidim_analyze

Erstellt das Raster für ein Thema (depth: core / deep / full; format: Text oder deterministischer v2-JSON-Rahmen)

multidim_contexts

Listet jeden bekannten Kontext mit seinen Achsen und Unter-Linsen auf

multidim_validate

Deterministische, zustandslose Prüfung einer ausgefüllten Analyse gegen ihren v2-Rahmen – ACCEPT / WARNING / REJECT pro Abschnitt

multidim_learn

Erstellt oder erweitert einen Kontext (Schlüsselwörter, Achsen, Fallen) – die einzige Schreibmöglichkeit

So funktioniert es

  1. multidim_analyze erkennt den besten Kontext für dein Thema (Wortgrenzen-Keyword-Matching, akzentgeglättet) und gibt einen v2-Rahmen zurück: erforderliche Abschnitte, Abschnittsschemata, Validierungsregeln, Pflichtfragen – einschließlich jeder gelernten Falle, deren Auslöser zum Thema passen.

  2. Deine LLM füllt den Rahmen Abschnitt für Abschnitt aus.

  3. multidim_validate rekonstruiert den Rahmen aus dem Speicher, lehnt einen manipulierten oder veralteten ab (frame_hash), und prüft dann die Analyse: strukturelle Vollständigkeit, Falsifikationstests für Hypothesen, Alternativen, die sich wirklich von der primären unterscheiden, Effekte zweiter Ordnung, die sich von erster Ordnung unterscheiden, eine Pre-Mortem-Analyse, die die Risikoliste nicht kopiert, eine Synthese, die echte Bezeichner referenziert, und eine Obergrenze für Füllphrasen. Nur abgelehnte Abschnitte werden wiederholt, innerhalb der max_validation_rounds des Rahmens.

Die vier Startkontexte sind neutral und deterministisch: generic (8 allgemeine Linsen), code_review, technical_writing, decision.

Speicher

Der Speicher befindet sich auf einem dedizierten benutzerspezifischen Datenpfad (MULTIDIM_MCP_HOME überschreibt ihn) und wird beim ersten Lauf aus den neutralen Startwerten erstellt. Schreibvorgänge sind atomar und werden über Prozesse hinweg mit der nativen Dateisperre des Betriebssystems serialisiert; ein beschädigter Speicher wird vor jedem Zurücksetzen gesichert, nie stillschweigend verworfen. Eine Stolperdraht-Funktion verweigert jeden Lese- oder Schreibvorgang, der in einen fremden persönlichen ~/.multidim-Speicher auflösen würde.

Wartende, die Forks veröffentlichen, können die Neutralitätswächterfunktion mit eigenen privaten Markierungen über MULTIDIM_MCP_EXTRA_FORBIDDEN (kommagetrennt) erweitern, ohne sie in den öffentlichen Quellcode zu hardcodieren.

Transparenz

  • Kein KI-System. multidim-mcp enthält kein Modell und führt keine Inferenz durch: Es ist deterministische, regelbasierte Software. Unter dem EU-KI-Gesetz (Verordnung 2024/1689) ist es kein KI-System im Sinne von Art. 3 Abs. 1 und fällt als freie und Open-Source-Software unter die Ausnahme von Art. 2 Abs. 12. Es sammelt keine Daten und führt keine Netzwerkaufrufe durch.

  • Abbildungen in dieser README wurden mit GPT generiert und behalten ihre C2PA-Herkunftsmetadaten intakt.

Entwicklung

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 läuft sowohl auf Ubuntu als auch auf Windows mit Python 3.9 / 3.11 / 3.13.

Lizenz

Apache-2.0 – siehe LICENSE und 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