Skip to main content
Glama
deenesjakoruzh
MarkovianProtocol

markovian-mcp

Official
by MarkovianProtocol
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

markovian-mcp

Биткоин-закреплённое, независимо проверяемое происхождение для выходных данных ИИ, представленное как инструменты MCP.

Доверять эмитенту? Нет. Докажите эмитента. Фиксируйте выходные данные в цепочке Маркова в момент их создания, и любой сможет позже подтвердить, что они существовали тогда и не были изменены с тех пор, не доверяя вам, нам или любому оператору.

Штамп доказывает происхождение, а не истину. Он доказывает, что данные были зафиксированы в определённое время. Он не утверждает, что данные верны.

Две двери, один сервер

Этот пакет — stdio дверь. Хостируемая HTTP дверь — это тот же сервер, с теми же именами инструментов, теми же параметрами и теми же возвращаемыми объектами:

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

Код, написанный для одной, работает без изменений для другой. Выбирайте транспорт, а не семантику. (Завершающий слеш важен: /mcp возвращает перенаправление, которое некоторые клиенты не будут следовать.)

Related MCP server: Mark Reynolds

Инструменты

  • markovian_notarize(path? | sha256?) — нотариально заверьте любой файл или хэш в публичный журнал прозрачности (7 независимых подписей свидетелей, ежечасное закрепление в Биткоине). Только хэш: path хэшируется локально и никогда не загружается; только 32 байта достигают журнала. Квитанция содержит индекс листа, URL доказательства включения, URL офлайн-пакета c2sp.org/tlog-proof и политику доверия свидетелей. Ограничение скорости (10/час).

  • markovian_stamp(data, wallet?, label?, derived_from?) — зафиксируйте data в цепочке Маркова и получите проверяемый, защищённый от подделки штамп (markovian-provenance/v1). Отправляется только SHA-256 ваших данных; исходные данные никогда не сохраняются. Ни кошелёк, ни аккаунт не нужны, первый штамп работает сразу. Возвращаемый merkle_root является идентификатором.

  • markovian_verify(merkle_root) — проверьте штамп через публичный верификатор. Ни ключа, ни аккаунта. Неизвестный или изменённый корень возвращает verified: false. Любой может запустить, включая сторону, не доверяющую штамповщику.

  • markovian_trace(merkle_root) — пройдите по родословной derived_from штампа. Возвращает карту графа, а не вердикт: каждый узел содержит hash_binds и anchored, каждое ребро содержит edge_verified, и valid истинно только если все они проверены.

Ссылки родословной связаны внутри зафиксированных байтов, поэтому ребро не может быть добавлено или удалено после факта без изменения корня.

Установка

pip install markovian-mcp

Настройка (Claude Desktop / Cursor / Claude Code)

Локально, через stdio:

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

Или укажите на хостируемый сервер вместо этого, без установки:

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

Проверка без доверия к нам

Проверка — это простой публичный GET-запрос. Ничто в нём не зависит от этого пакета, этого сервера или нашего хорошего поведения:

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

Измените один байт заштампованных данных, и корень больше не совпадёт. Это вся гарантия, и она проверяема тем, кто считает, что мы лжём.

Подробнее на markovianprotocol.com.

Журнал изменений

0.2.0 — ломающее изменение. Инструменты теперь общаются с живой цепочкой и точно соответствуют хостируемому серверу. Ранее этот пакет поставлял локальные хэш-помощники, чьи имена совпадали с хостируемым сервером, но чьи сигнатуры и семантика отличались (markovian_stamp(content) возвращал локально вычисленный дайджест, в отличие от markovian_stamp(data), возвращающего привязку к цепочке). Агент не мог переключаться между ними. Теперь есть один набор инструментов с одним значением. Старое поле canonicalization также заявляло RFC 8785 (JCS), но реализовывало сортировку ключей через json.dumps, что не является JCS; это заявление удалено, а не переформулировано.

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