Skip to main content
Glama
deenesjakoruzh
MarkovianProtocol

markovian-mcp

Official
by MarkovianProtocol
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

markovian-mcp

Bitcoin-verankerte, unabhängig überprüfbare Herkunft von KI-Ausgaben, bereitgestellt als MCP-Werkzeuge.

Dem Aussteller vertrauen? Nein. Den Aussteller beweisen. Verankern Sie eine Ausgabe im Moment ihrer Erstellung in der Markov-Kette, und jeder kann später bestätigen, dass sie zu diesem Zeitpunkt existierte und seitdem nicht verändert wurde, ohne Ihnen, uns oder einem Betreiber vertrauen zu müssen.

Ein Stempel beweist Herkunft, nicht Wahrheit. Er beweist, dass die Daten zu einem bestimmten Zeitpunkt verankert wurden. Er behauptet nicht, dass die Daten korrekt sind.

Zwei Türen, ein Server

Dieses Paket ist die stdio-Tür. Die gehostete HTTP-Tür ist derselbe Server, mit denselben Werkzeugnamen, denselben Parametern und denselben zurückgegebenen Objekten:

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

Code, der für eine geschrieben wurde, funktioniert unverändert mit der anderen. Wählen Sie einen Transport, nicht eine Semantik. (Der nachgestellte Schrägstrich ist wichtig: /mcp gibt eine Weiterleitung zurück, die einige Clients nicht verfolgen werden.)

Related MCP server: Mark Reynolds

Werkzeuge

  • markovian_notarize(path? | sha256?) — notarisiert jede Datei oder jeden Hash im öffentlichen Transparenz-Log (7 unabhängige Zeugen-Kosignaturen, stündliche Bitcoin-Verankerung). Nur Hash: Ein path wird lokal gehasht und niemals hochgeladen; nur 32 Bytes erreichen das Log. Die Quittung enthält den Blattindex, die URL für den Inklusionsbeweis, eine Offline-URL für das c2sp.org/tlog-proof-Bündel und die Vertrauensrichtlinie der Zeugen. Ratenbegrenzung (10/Stunde).

  • markovian_stamp(data, wallet?, label?, derived_from?) — verankert data in der Markov-Kette und gibt einen überprüfbaren, manipulationssicheren Stempel zurück (markovian-provenance/v1). Nur der SHA-256-Hash Ihrer Daten wird gesendet; die Rohdaten werden niemals gespeichert. Keine Wallet oder Konto erforderlich, der erste Stempel funktioniert einfach. Der zurückgegebene merkle_root ist der Handle.

  • markovian_verify(merkle_root) — überprüft einen Stempel gegen den öffentlichen Verifizierer. Kein Schlüssel, kein Konto. Eine unbekannte oder bearbeitete Wurzel gibt verified: false zurück. Jeder kann es ausführen, auch eine Partei, die dem Stempler nicht vertraut.

  • markovian_trace(merkle_root) — durchläuft die derived_from-Abstammung eines Stempels. Gibt eine Karte des Graphen zurück, kein Urteil: jeder Knoten trägt hash_binds und anchored, jede Kante trägt edge_verified, und valid ist nur wahr, wenn alles stimmt.

Abstammungsverknüpfungen sind innerhalb der verankerten Bytes gebunden, sodass eine Kante nicht nachträglich hinzugefügt oder entfernt werden kann, ohne die Wurzel zu ändern.

Installieren

pip install markovian-mcp

Konfigurieren (Claude Desktop / Cursor / Claude Code)

Lokal, über stdio:

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

Oder zeigen Sie stattdessen auf den gehosteten Server, ohne Installation:

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

Überprüfen, ohne uns zu vertrauen

Die Überprüfung ist ein einfacher öffentlicher GET-Aufruf. Nichts darin hängt von diesem Paket, diesem Server oder unserem guten Verhalten ab:

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

Ändern Sie ein Byte der gestempelten Daten und die Wurzel stimmt nicht mehr. Das ist die gesamte Garantie, und sie ist von jemandem überprüfbar, der denkt, dass wir lügen.

Mehr unter markovianprotocol.com.

Änderungsprotokoll

0.2.0 — bahnbrechend. Die Werkzeuge kommunizieren jetzt mit der Live-Kette und entsprechen genau dem gehosteten Server. Zuvor enthielt dieses Paket nur lokale Hash-Helfer, deren Namen mit denen des gehosteten Servers kollidierten, deren Signaturen und Semantiken jedoch nicht (markovian_stamp(content) gibt einen lokal berechneten Digest zurück, während markovian_stamp(data) eine Kettenverankerung zurückgibt). Ein Agent konnte nicht zwischen beiden wechseln. Es gibt jetzt einen Satz von Werkzeugen mit einer Bedeutung. Das alte Feld canonicalization beanspruchte auch RFC 8785 (JCS), während es sortiertes json.dumps implementierte, was nicht JCS ist; dieser Anspruch ist verschwunden, anstatt neu formuliert zu werden.

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