Skip to main content
Glama
deenesjakoruzh
Cherridsaid

multidim-mcp

by Cherridsaid
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

multidim-mcp

Cuadrículas de pensamiento estructurado para agentes de IA: un servidor MCP independiente, biblioteca estándar pura.

Multidim enruta un tema hacia un conjunto de lentes de análisis (un contexto) y devuelve una cuadrícula jerárquica (ejes, sublentes, preguntas obligatorias) para que el LLM que lo invoca la complete. El pensamiento permanece en quien invoca: el servidor aporta estructura, nunca cognición. No llama a ningún LLM, no realiza peticiones de red, y la misma entrada siempre produce el mismo marco.

  • Cero dependencias: Python 3.9+, solo biblioteca estándar.

  • Contrato v2 determinista: cada marco lleva un frame_hash autoverificable; un análisis completado se comprueba sección por sección con códigos de error accionables.

  • Trampas aprendidas: las lecciones que registras una vez se convierten en preguntas obligatorias inyectadas en cada marco futuro cuyo tema coincida.

  • Almacén robusto: escrituras atómicas, bloqueo nativo entre procesos, migraciones aditivas, reinicios con copia de seguridad y un guardián que se niega a tocar cualquier almacén ~/.multidim ajeno.

Ve la diferencia

Un agente analiza "¿Deberíamos migrar el servicio de facturación de MySQL a PostgreSQL?". Cada sección está completada, cada frase se lee bien. Esto es lo que devuelve multidim_validate en esa primera pasada:

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

La única alternativa reformulaba la hipótesis, la hipótesis no incluía ninguna prueba que pudiera refutarla, el efecto de segundo orden repetía el primero palabra por palabra, y la conclusión no hacía referencia a ninguno de los trabajos anteriores. Nada de eso es visible cuando lees la respuesta; todo ello se informa aquí, por su nombre.

Vuelve a hacer las secciones rechazadas y el mismo verificador devuelve ACCEPT. Edita el marco para eliminar la regla que te resulta incómoda, y rechaza toda la entrega: el marco lleva un hash de su propio contenido.

Transcripción completa, incluido el aspecto de las secciones corregidas y lo que esto deliberadamente no comprueba: DEMO.md. Reprodúcela con un solo comando: python demo.py.

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

Inicio rápido

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

Registra el servidor con cualquier cliente MCP (transporte stdio):

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

O ejecútalo directamente: python -m multidim_mcp, o sin instalarlo: uvx multidim-mcp.

El servidor está listado en el Registro MCP oficial como io.github.Cherridsaid/multidim-mcp.

Herramientas

Herramienta

Función

multidim_analyze

Construye la cuadrícula para un tema (depth: core / deep / full; format: texto o marco JSON v2 determinista)

multidim_contexts

Enumera todos los contextos conocidos con sus ejes y sublentes

multidim_validate

Comprobación determinista y sin estado de un análisis completado contra su marco v2: ACCEPT / WARNING / REJECT por sección

multidim_learn

Crea o enriquece un contexto (palabras clave, ejes, trampas): la única puerta de escritura

Cómo funciona

  1. multidim_analyze detecta el mejor contexto para tu tema (coincidencia de palabras clave por límites de palabra, con plegado de acentos) y devuelve un marco v2: secciones obligatorias, esquemas de sección, reglas de validación, preguntas obligatorias, incluida cada trampa aprendida cuyos disparadores coincidan con el tema.

  2. Tu LLM completa el marco, sección por sección.

  3. multidim_validate reconstruye el marco desde el almacén, rechaza uno manipulado u obsoleto (frame_hash), y luego comprueba el análisis: completitud estructural, pruebas de falsación sobre hipótesis, alternativas que difieren genuinamente de la principal, efectos de segundo orden distintos de los de primer orden, un pre-mortem que no copia la lista de riesgos, una síntesis que hace referencia a identificadores reales y un límite de densidad de frases de relleno. Solo se rehacen las secciones rechazadas, dentro del max_validation_rounds del marco.

Los cuatro contextos semilla son neutros y deterministas: generic (8 lentes generales), code_review, technical_writing, decision.

Almacenamiento

El almacén reside en una ruta de datos dedicada por usuario (MULTIDIM_MCP_HOME la anula) y se crea en la primera ejecución a partir de las semillas neutras. Las escrituras son atómicas y serializadas entre procesos con el bloqueo de archivos nativo del sistema operativo; un almacén corrupto se copia como respaldo antes de cualquier reinicio, nunca se descarta en silencio. Un cable trampa rechaza toda lectura o escritura que se resuelva en un almacén personal ~/.multidim ajeno.

Los mantenedores que publiquen bifurcaciones pueden ampliar el guardián de neutralidad con sus propios marcadores privados mediante MULTIDIM_MCP_EXTRA_FORBIDDEN (separados por comas), sin codificarlos en el código fuente público.

Transparencia

  • No es un sistema de IA. multidim-mcp no contiene ningún modelo ni realiza inferencia alguna: es software determinista y basado en reglas. En virtud de la Ley de IA de la UE (Reg. 2024/1689) no es un sistema de IA en el sentido del art. 3, apdo. 1, y como software libre y de código abierto se acoge a la exención del art. 2, apdo. 12. No recopila datos ni realiza llamadas de red.

  • Las ilustraciones de este README se generaron con GPT y conservan intactos sus metadatos de procedencia C2PA.

Desarrollo

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

La CI se ejecuta tanto en Ubuntu como en Windows con Python 3.9 / 3.11 / 3.13.

Licencia

Apache-2.0: consulta LICENSE y 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