Skip to main content
Glama
deenesjakoruzh
MarkovianProtocol

markovian-mcp

Official
by MarkovianProtocol
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

markovian-mcp

基于比特币锚定、可独立验证的AI输出溯源，以MCP工具形式提供。

信任发出者？不。证明发出者。 在输出产生的瞬间将其提交到马尔可夫链，任何人都可以在之后确认它当时存在且未被篡改，无需信任你、我们或任何操作者。

一个戳记证明的是溯源，而非真实性。它证明数据在某个时间点被提交，并不断言数据是正确的。

两扇门，同一台服务器

本包是 stdio 门。托管HTTP 门是同一台服务器，具有相同的工具名称、相同的参数和相同的返回对象：

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

针对其中一个编写的代码无需修改即可用于另一个。选择传输方式，而非语义。（尾部斜杠很重要：/mcp 返回一个重定向，某些客户端不会跟随。）

Related MCP server: Mark Reynolds

工具

  • markovian_notarize(path? | sha256?) — 将任何文件或哈希公证到公共透明度日志中（7个独立见证人联合签名，每小时比特币锚定）。仅哈希：path 在本地哈希且永不上传；只有32字节到达日志。收据包含叶子索引、包含证明URL、离线 c2sp.org/tlog-proof 捆绑包URL以及见证人信任策略。有速率限制（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