fidacy-mcp

Anchor Artifact (Bitcoin-anchored integrity proof)

anchor_artifact

Prove a file existed unchanged at a specific time by registering its SHA-256 hash on a tamper-evident audit chain anchored to Bitcoin. Receive a signed receipt verifiable offline.

Instructions

Prove an artifact existed exactly as-is at this moment, and make any later tampering detectable. Give a file path (hashed locally with SHA-256 — the file itself is NEVER uploaded) or a precomputed sha256. The hash is registered on Fidacy's tamper-evident audit chain, which is checkpointed to the Bitcoin blockchain, and you get a signed receipt (JWS) verifiable offline against the engine JWKS. Use it for contracts, invoices, medical prescriptions, insurance claims, images, audio, video. kind defaults to document; optional label is a short reference (an invoice number, a case id — no PII).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "anchor_artifact"
  }
}

Input Schema

Name	Required	Description	Default
`kind`	No
`path`	No
`label`	No
`sha256`	No
`subject`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 4, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses side effects beyond annotations: file is never uploaded (hashed locally), hash is registered on a blockchain-checkpointed audit chain, and a JWS receipt is returned. This adds privacy and verification details that complement the openWorldHint=true and idempotentHint=false 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?

Three well-structured sentences: purpose, mechanism, and use cases. Every sentence provides necessary information with no repetition or filler.

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?

Covers the anchoring workflow, output (JWS receipt), and offline verification, which is substantial given no output schema. Lacks error conditions or receipt contents, but this is acceptable when a sibling tool (check_artifact) may handle verification.

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?

With 0% schema coverage, the description explains most parameters: path (hashed locally, not uploaded), sha256 (precomputed), kind (defaults to document), and label (short reference, no PII). It fails to mention `subject` and does not explicitly state mutual exclusivity of path/sha256, leaving a partial gap.

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 opens with a clear action: 'Prove an artifact existed exactly as-is at this moment' — a specific verb and resource. It also distinguishes itself from siblings like check_artifact (verification) and get_audit_proof (retrieval) by focusing on the anchoring/creation act.

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?

Explicitly lists use cases (contracts, invoices, prescriptions, etc.) and gives the path/sha256 alternative. However, it does not contrast with sibling tools or state when not to use it, so no exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server