Skip to main content
Glama
deenesjakoruzh
MarkovianProtocol

markovian-mcp

Official
by MarkovianProtocol
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

markovian-mcp

ビットコインにアンカーされた、独立して検証可能なAI出力の出所情報を、MCPツールとして公開します。

発信者を信頼しますか？いいえ。**発信者を証明します。**出力が生成された瞬間にマルコビアンチェーンにコミットし、後日誰でもその時点で存在していたこと、およびそれ以降改ざんされていないことを確認できます。あなた、私たち、または任意の運営者を信頼する必要はありません。

スタンプは出所を証明するものであり、真実ではありません。データが特定の時点でコミットされたことを証明します。データが正しいことを主張するものではありません。

2つのドア、1つのサーバー

このパッケージは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はすべてが確認された場合のみtrueになります。

系統リンクはコミットされたバイト内部にバインドされているため、ルートを変更せずに後からエッジを追加または削除することはできません。

インストール

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>

スタンプされたデータの1バイトを変更すると、ルートは一致しなくなります。それが保証のすべてであり、私たちが嘘をついていると考える人でも確認可能です。

詳細はこちら：markovianprotocol.com

変更履歴

0.2.0 — 破壊的変更。ツールはライブチェーンと通信し、ホスト型サーバーと完全に一致するようになりました。以前は、このパッケージはローカルのみのハッシュヘルパーを提供していましたが、その名前はホスト型サーバーのものと衝突していましたが、シグネチャとセマンティクスは一致していませんでした（markovian_stamp(content)はローカルで計算されたダイジェストを返すのに対し、markovian_stamp(data)はチェーンコミットメントを返す）。エージェントは両者間を移動できませんでした。現在は、1つの意味を持つ1つのツールセットがあります。以前のcanonicalizationフィールドは、ソートキーjson.dumpsを実装しながらRFC 8785 (JCS)を主張していましたが、それは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