datamancy — the grimoire

A cryptographically verifiable static MCP. Latin-named defensive spells — each a SKILL.md an LLM subagent casts against a target, SHA-256 verified against an ECDSA P-256-signed manifest by the datamancy npm adapter, which pins the public key, before it reaches a model.

Use it

Add to any MCP client (Claude Code, Cursor, …):

{ "mcpServers": { "datamancy": { "command": "npx", "args": ["-y", "datamancy@^1.1.0"] } } }

Use ^1.1.0, not @1. The tool surface arrived in 1.1.0, and npx reuses a cached tree that still satisfies the range you asked for — so @1 can keep serving a cached 1.0.0, which advertises no tools, forever. The caret floors you at the tool surface and still takes fixes within major 1. A bare datamancy is worse again: it re-resolves every launch, so a release can change what your client runs.

Served through two surfaces over one pipeline the datamancy npm adapter verifies: MCP resources, and the tools list_spells / fetch_spell for hosts that only wire tools through to the model. Same manifest, same verification, same bytes.

Read it

Content integrity, not access control: the manifest is signed by a key held non-exportably in AWS KMS; the public key (fingerprint 09db7668…) is pinned in the npm package and cross-published at datamancer.dev. Tampered content is refused by the adapter, never delivered.

Elsewhere