Skip to main content
Glama
deenesjakoruzh
MarkovianProtocol

markovian-mcp

Official
by MarkovianProtocol
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

markovian-mcp

비트코인에 앵커링된, 독립적으로 검증 가능한 AI 출력의 출처 증명으로, MCP 도구로 제공됩니다.

Emitter를 신뢰하시나요? 아닙니다. Emitter를 증명하세요. 출력이 생성되는 즉시 Markovian 체인에 커밋하면, 누구든 나중에 그 출력이 그 시점에 존재했으며 이후 변경되지 않았음을 확인할 수 있습니다. 여러분, 우리, 또는 어떤 운영자도 신뢰할 필요가 없습니다.

스탬프는 출처를 증명할 뿐, 진실을 증명하지 않습니다. 데이터가 특정 시간에 커밋되었음을 증명할 뿐, 데이터가 정확하다고 주장하지 않습니다.

두 개의 문, 하나의 서버

이 패키지는 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 체인에 커밋하고 검증 가능하고 변조 방지된 스탬프(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>

스탬프된 데이터의 한 바이트를 변경하면 루트가 더 이상 일치하지 않습니다. 이것이 전체 보장이며, 우리가 거짓말하고 있다고 생각하는 사람도 확인할 수 있습니다.

자세한 내용은 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