Skip to main content
Glama
deenesjakoruzh
MarkovianProtocol

markovian-mcp

Official
by MarkovianProtocol
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

markovian-mcp

Procedencia anclada a Bitcoin y verificable de forma independiente para salidas de IA, expuesta como herramientas MCP.

¿Confías en el emisor? No. Demuestra al emisor. Compromete una salida en la cadena de Markovian en el momento en que se produce, y cualquiera puede confirmar posteriormente que existió en ese momento y no ha sido alterada desde entonces, sin confiar en ti, en nosotros ni en ningún operador.

Un sello demuestra procedencia, no veracidad. Demuestra que los datos fueron comprometidos en un momento determinado. No afirma que los datos sean correctos.

Dos puertas, un servidor

Este paquete es la puerta stdio. La puerta HTTP alojada es el mismo servidor, con los mismos nombres de herramientas, los mismos parámetros y los mismos objetos devueltos:

https://api.markovianprotocol.com/mcp/

El código escrito para una funciona sin cambios en la otra. Elige un transporte, no una semántica. (La barra inclinada final importa: /mcp devuelve una redirección que algunos clientes no seguirán).

Related MCP server: Mark Reynolds

Herramientas

  • markovian_notarize(ruta? | sha256?) — notariza cualquier archivo o hash en el registro de transparencia público (7 firmas concurrentes de testigos independientes, anclaje horario a Bitcoin). Solo hash: una ruta se hashea localmente y nunca se sube; solo 32 bytes llegan al registro. El recibo incluye el índice de la hoja, la URL de prueba de inclusión, una URL de paquete c2sp.org/tlog-proof fuera de línea y la política de confianza de los testigos. Limitado de velocidad (10/hora).

  • markovian_stamp(datos, cartera?, etiqueta?, derivado_de?) — compromete datos en la cadena de Markovian y obtén un sello verificable y a prueba de manipulaciones (markovian-provenance/v1). Solo se envía el SHA-256 de tus datos; los datos brutos nunca se almacenan. No se necesita cartera ni cuenta, el primer sello funciona directamente. El merkle_root devuelto es el identificador.

  • markovian_verify(raíz_merkle) — verifica un sello contra el verificador público. Sin clave, sin cuenta. Una raíz desconocida o editada devuelve verified: false. Cualquiera puede ejecutarlo, incluyendo una parte que no confíe en el sellador.

  • markovian_trace(raíz_merkle) — recorre el linaje derivado_de de un sello. Devuelve un mapa del grafo, no un veredicto: cada nodo lleva hash_binds y anchored, cada arista lleva edge_verified, y valid es verdadero solo si todos son correctos.

Los enlaces de linaje están vinculados dentro de los bytes comprometidos, por lo que no se puede agregar ni eliminar una arista después del hecho sin cambiar la raíz.

Instalar

pip install markovian-mcp

Configurar (Claude Desktop / Cursor / Claude Code)

Local, a través de stdio:

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

O apunta al servidor alojado en su lugar, sin instalación:

{
  "mcpServers": {
    "markovian": {
      "url": "https://api.markovianprotocol.com/mcp/"
    }
  }
}

Verificar sin confiar en nosotros

La verificación es una simple GET pública. Nada en ella depende de este paquete, este servidor o nuestro buen comportamiento:

curl https://api.markovianprotocol.com/verify/<merkle_root>

Cambia un byte de los datos sellados y la raíz ya no coincide. Esa es toda la garantía, y es verificable por alguien que piense que estamos mintiendo.

Más en markovianprotocol.com.

Registro de cambios

0.2.0 — cambio radical. Las herramientas ahora se comunican con la cadena en vivo y coinciden exactamente con el servidor alojado. Anteriormente, este paquete enviaba ayudantes de hash solo locales cuyos nombres colisionaban con los del servidor alojado pero cuyas firmas y semántica no coincidían (markovian_stamp(contenido) devolviendo un resumen calculado localmente, versus markovian_stamp(datos) devolviendo un compromiso de cadena). Un agente no podía moverse entre los dos. Ahora hay un conjunto de herramientas con un solo significado. El antiguo campo canonicalization también afirmaba ser RFC 8785 (JCS) mientras implementaba json.dumps con clave ordenada, que no es JCS; esa afirmación ha desaparecido en lugar de ser reformulada.

Apache-2.0.

Available Tools

3 tools
markovian_stampA

Compute the canonical commitment root for any output.

JSON is canonicalized with RFC 8785 (JCS); other text is used verbatim, then SHA-256 hashed. The returned root is exactly what Markovian anchors to Bitcoin, so anyone can later verify the output was unaltered and existed when claimed, without trusting the source or any operator.

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYes

TDQS

A4.5/5.0
Behavior5/5

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

No annotations provided, but the description fully discloses behavioral traits: JSON canonicalization via RFC 8785, SHA-256 hashing, and Bitcoin anchoring. There is no contradiction with annotations.

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 sentences with no wasteful text. The first sentence states the purpose, the second details the process and value proposition.

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 a single string parameter and no output schema, the description covers the input processing, hashing, and the significance for verification, making it complete for the tool's simplicity.

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?

Schema description coverage is 0%, but the description explains how the 'content' parameter is processed (canonicalized if JSON, otherwise verbatim) and the resulting hash, adding meaning beyond the schema's type definition.

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 clearly states the action ('Compute') and the resource ('canonical commitment root'). It distinguishes the tool from siblings (markovian_trace, markovian_verify) by focusing on commitment creation.

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 description implies usage for creating verifiable commitments, but lacks explicit guidance on when to use versus alternatives (markovian_trace, markovian_verify) or when not to use this tool.

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

markovian_traceA

Walk a lineage of stamps back to its origin.

Pass a JSON array of receipts, each an object with a "root" and an optional "derived_from" (the parent root). Returns the ordered chain from the given head to the origin, so an output can be traced to the data and model it came from.

ParametersJSON Schema
NameRequiredDescriptionDefault
receipts_jsonYes

TDQS

A4.5/5.0
Behavior4/5

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

No annotations provided, so description carries the burden. It discloses the input format (JSON array of receipts) and output (ordered chain). It doesn't mention side effects, but the tool appears to be read-only, which is acceptable.

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 paragraphs, first sentence is a clear header, then details. No wasted words. Well-structured and efficient.

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 simple tool with one parameter, the description covers input format and output behavior. It lacks explanation of error cases or edge cases, but is otherwise complete.

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

Parameters5/5

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

The description adds significant meaning beyond the schema, explaining that 'receipts_json' must be a JSON array of objects with 'root' and optional 'derived_from'. Schema coverage is 0%, so description compensates fully.

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 clearly states the tool walks a lineage of stamps back to its origin, specifying the input format and output. It distinguishes itself from siblings 'markovian_stamp' and 'markovian_verify' by focusing on tracing, not creation or verification.

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 implies when to use (tracing origin) but does not explicitly state when not to use or mention alternatives. However, given sibling names, the context is clear enough.

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

markovian_verifyA

Verify content against a previously stamped canonical_root by recomputing it.

Tampering with a single byte changes the root and fails the check. Trust nobody: the check is pure recomputation, needing nothing from the operator.

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYes
canonical_rootYes

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: the tool is a pure recomputation with no external dependencies, fails on any byte change, and requires nothing from the operator. This provides clear expectations.

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?

The description is concise (two paragraphs, about 40 words) and front-loaded with the purpose. Every sentence adds value without redundancy.

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

Completeness3/5

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

The tool has no output schema, so the description should explain return behavior. It implies failure ('fails the check') but does not state whether it returns a boolean, raises an error, or what happens on success. This is a notable gap given the lack of annotations and schema.

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 0%, so the description must compensate. It mentions 'content' and 'previously stamped canonical_root' but does not specify formats, constraints, or how they relate to each other. The schema titles only provide basic hints.

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 clearly states that the tool verifies content by recomputing a canonical root, using specific verbs ('Verify') and resources ('content', 'canonical_root'). It also distinguishes from siblings by focusing on verification, while sibling tools are 'stamp' and 'trace'.

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 context about when to use (after stamping, to detect tampering) and emphasizes that the check is pure and trustless. However, it does not explicitly mention alternatives or when not to use it, leaving some ambiguity.

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. 3 tool updatesv0.1.0
    • First observedmarkovian_stamp
    • First observedmarkovian_trace
    • First observedmarkovian_verify
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: stamp computes a canonical root, trace walks lineage, and verify checks content against a root. No overlap.

Naming Consistency5/5

All tools follow a consistent pattern: prefix 'markovian_' plus a verb (stamp, trace, verify). No mixing of styles.

Tool Count5/5

Three tools is well-scoped for the niche domain of Markovian anchoring. Each tool earns its place without duplication.

Completeness4/5

The set covers core operations (stamp, trace, verify). Minor gaps exist, such as no tool to list or search stamps, but the main workflow is complete.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • otskit-mcp

    OTSkit
    A
    license
    A
    quality
    A
    maintenance
    Stamp, upgrade, and verify Bitcoin timestamps via AI agents using the OpenTimestamps protocol. No API keys required.
    9
    95 npm
    3
    MIT

  • Mark Reynolds

    m-reynaldo35
    A
    license
    Not graded
    quality
    C
    maintenance
    Post-quantum document anchoring for AI agents. Anchor any SHA-256 hash to Algorand mainnet with ML-DSA-65 (NIST FIPS-204) signatures and receive a self-contained proof bundle verifiable offline — decades from now, without trusting any vendor.
    20 npm
    1
    MIT

Appeared in Searches