Vayl MCP server

Read from the package source without running it. The installed server may list more.

• attest

  Issue a signed, third-party-verifiable attestation of what memory currently holds for `subject` — 'as of now, the active value is X', anchored to the tamper-evident audit-log head. Use it to prove what was known at a point in time. Verify later with verify_receipt, or independently with export_public_key.

• audit_log

  The accountability trail (GDPR Art. 5(2)) — recent data operations: who / what / when. Optionally filter by user_id. Not affected by memory erasure.

• check_before_act

  Ask whether it's SAFE to take an autonomous action based on what memory knows about `subject`. Returns SAFE, or BLOCKED with explicit reasons — an unresolved conflict, confidence below the bar, a value that's gone stale, or one that just changed. Call this before any irreversible action (a payment, an email, a config change) so the agent never silently acts on bad memory. Tune the policy via the p

• confirm_change

  Approve a proposed change to a confirm-required slot, applying it. Needs the `approve` capability (admin and member roles; agents lack it, so an agent can't approve its own proposal). The approver recorded is the authenticated caller; `decided_by` is an optional note.

• create_principalwrite action

  Admin only. Create a principal (a human user, agent, or service) and issue its API key. Roles: admin, member, agent, viewer, auditor. The key is shown ONCE — store it securely; it can't be recovered (reissue by creating a new principal).

• deletewrite action

  PERMANENTLY erase every record of a subject — including history and tombstones — for a user. Unlike `forget` (which retires but retains for audit), this is a hard delete for right-to-be-forgotten / GDPR erasure. The `subject` is the key shown by `list_memories`.

• delete_allwrite action

  PERMANENTLY erase memory (history included). With no agent_id/run_id, erases ALL of the user's memory across every space (account deletion / GDPR); pass them to erase just one space. Irreversible — not the same as `forget`, which retains history for audit.

• explain_decision

  Reconstruct why an agent acted: the recorded action and the exact beliefs it held at that moment — even if those facts have since been superseded, retracted, or erased. Also verifies the decision's signed receipt so you know the record itself wasn't altered.

• export_memory

  Export everything held about a user/space as machine-readable JSON — data-subject access & portability (GDPR Art. 15/20). A complete DSAR answer: statements (active + full history), PLUS what the append-only records hold about them — decision snapshots, audit entries, and receipts.

• export_public_key

  Return Vayl's Ed25519 public key (hex). Anyone can use it to verify erasure receipts, attestations, and the signed audit chain WITHOUT the secret key or access to the database.

• forget

  Retract a fact — a removal with no replacement. Unlike additive stores, this actually retires it so it stops being returned as current (kept in history for audit). Examples: 'We dropped Sentry', 'Alice left the Platform team', 'we no longer support IE11'.

• get_memory

  Fetch one memory by its id (the `#id` shown by `list_memories`) — its value, status, scope, confidence, what it supersedes, and any metadata.

• get_reconcile_policy

  Show the source-aware reconciliation policy configured for a space (default RECENCY if unset).

• health

  Check that Vayl is configured and its dependencies are reachable — database, embedder, LLM, and graph (if enabled). Run this to diagnose setup before relying on memory; it makes one small LLM/embed call, so it costs a few tokens.

• history

  The change-log for a subject — every value it has held, oldest → newest, with status. The 'what did we use first vs now' view that additive stores can't give you. The `subject` is the key shown by `list_memories`.

• license_status

  Show the deployment's edition and entitlements — Community or a licensed edition, seats used vs allowed, expiry, and unlocked features. If a license was rejected (tampered/expired/wrong key), this says so and reports the Community fallback it's running under.

• list_memories

  List the current active facts (the reconciled current beliefs) for a user, plus a history block of what was superseded / retracted / archived. Active rows show the `#id` for get/update.

• list_principals

  Admin only. List your tenant's principals — id, name, roles, and whether disabled (the deployment operator sees every tenant's). Never shows API keys (only their hashes are stored).

• pending_changes

  List proposed changes to confirm-required slots that have NOT been applied.

• purge_expired

  Retention / storage-limitation (GDPR Art. 5(1)(e)): permanently delete records written more than `older_than_days` ago. Statements are scoped to the user/space. The optional flags extend the same window to the append-only tables — NOTE these are not per-user: `include_decisions` and `include_receipts` purge those tables for your whole tenant, and `include_audit` purges the audit log from the head

• recall

  Answer a question from CURRENT memory — the active value ('what state library do we use?') or a multi-hop question over current facts. Returns 'I don't know' rather than guessing, and NEVER answers from a retired/retracted fact. For the timeline of a subject, use `history`.

• recall_related

  Answer a DEEP / RELATIONAL / multi-hop question using the entity graph ('who owns the company Bob works for?', 'which services depend on the auth module?'). Uses the Neo4j graph projection when configured; otherwise falls back to slot recall.

• record_decision

  Log a decision an agent is about to take, bound to the EXACT facts it consulted. Atomically recalls `question` with provenance and snapshots those beliefs (value, source, confidence, what they superseded) alongside `action_summary`. The snapshot is immutable and signed, so 'why did the agent do X?' stays answerable even after the facts later change. Returns the decision id and a verifiable receipt

• reject_change

  Discard a proposed change. The current value stands. The proposal is kept as history — that someone proposed it is itself worth being able to audit. Needs `approve`, like confirm_change: an agent quietly discarding proposals would empty the review queue just as surely as approving them. `decided_by` is an optional note beside the authenticated caller.

• remember

  Store fact(s) from a statement. Reconciles automatically: a new value SUPERSEDES the old one (not appended), removals are RETRACTED, and multiple facts in one message are all captured. Optional `metadata` tags the facts stored in this call. `source` records WHO/WHAT asserted the fact (an agent id, a person, a connector) — belief provenance, and the basis for source-aware reconciliation in a shared

• revoke_principal

  Admin only. Disable a principal — its API key stops working immediately. Irreversible (create a new principal to restore access). With `erase=True`, the principal row is HARD-deleted (Art. 17 for team members) instead of retained as disabled. A tenant admin can only revoke its own tenant's principals; another tenant's id reads as unknown.

• safe_recall

  Like `recall`, but for when the agent will ACT on the answer. It answers only if every current fact behind the answer passes the safety policy; otherwise it withholds the answer and returns the reasons (disputed value, low confidence, stale, or nothing current). Use this instead of `recall` on the path to an irreversible action.

• set_reconcile_policy

  Configure how a SHARED space resolves conflicts between DIFFERENT contributors (sources). A shared space is any space (e.g. user_id='org:acme') that multiple agents/people write to with a `source` on each remember. Modes: • RECENCY — newer assertion wins (default; contributors equally trusted). • AUTHORITY — a higher-ranked source wins; a lower-ranked source contradicting it is FLAGGED, not overwr

• stats

  Operational KPIs for this Vayl instance — on-device, nothing leaves the machine: per-tool call counts, average latency and error counts, plus the distribution of reconciliation actions the engine has taken (SUPERSEDE / RETRACT / FLAG / SKIP / ADD / …).

• update_memorywrite action

  Correct a memory by id (the `#id` from `list_memories`). Audit-preserving: the old value is retired to history and the new value becomes active — so the change still shows up in `history`.

• verify_audit

  Verify the tamper-evident audit chain end-to-end. Recomputes every row's hash and (if signed) signature; reports INTACT, or the exact row where the chain breaks — so you can prove the accountability log wasn't edited, reordered, or truncated.

• verify_receipt

  Verify a persisted erasure receipt or knowledge attestation: recompute its canonical body and check the Ed25519 signature. Confirms the artifact is authentic and unaltered — the same check a third party can run with only the public key.

• Code scan52 source files scanned25/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitystatic API keys via environment variables6/15
• Maintenancelast push 3 days ago15/15
• Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Safety score

83/100

higher than 65% of 48,255 servers

Tools

32

the typical server has 7

Tools that change things

13%

typical: 0%. Fewer write tools means less an agent can break

GitHub stars

2

more than 75% of 28,688 servers

Downloads a week

475

more than 87% of 12,191 servers with a package

Vayl: common questions

Is Vayl MCP server safe?

Mostly: it is graded B (83/100). Read the Vayl safety report

How do I install Vayl?

It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.

Does Vayl need an API key?

Yes. The registry entry asks for OPENAI_API_KEY.

Is Vayl maintained?

The last commit was 13 days ago (2026-10-22). The latest release is v0.10.0.

What can I use instead of Vayl?

Servers from other publishers that do the same job: Knowl MCP server.

How does Vayl compare with other MCP servers?

safety score 83/100 (higher than 65% of 48,255 servers); tools 32 (the typical server has 7); tools that change things 13% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.