writ-mcp
OfficialRelated Servers
Alternatives to writ-mcp
No user-submitted related servers found.
Related Servers
- AlicenseAqualityBmaintenanceCryptographic accountability for AI agents. Ed25519-signed receipts for every MCP tool call. Constraints, chains, AI judgment, invoicing, and local dashboard included.244 npm1MIT
- AlicenseAqualityBmaintenanceLeast-privilege compiler and MCP gateway for AI agents: run your agent in record-only mode, compile the smallest policy it actually needs from its real tool calls, enforce it at the gateway (deny > approve > allow), and keep a SHA-256 hash-chained audit of every call that verifies offline.14132 npm1Apache 2.0
- AlicenseBqualityBmaintenanceA governance proxy for AI tools — every MCP/agent tool call is policy-gated, secret-redacted, and written to a hash-chained, offline-verifiable audit trail.13MIT
- AlicenseAqualityCmaintenanceAI agent identity, permissions, trust scores, and tamper-evident audit trails. 17 MCP tools: register agents (Ed25519 keypairs), check permissions (sub-5ms), emit audit events, verify trust scores (0-100), delegate credentials, ephemeral agents. IETF Internet-Draft filed. Works with LangChain, OpenAI, CrewAI, Stripe ACP. npx @vorim/mcp-server1783 npm66MIT
- AlicenseAqualityAmaintenanceGates every AI agent tool call against your policy before it runs, then writes a hash-chained, tamper-evident record of what was decided and what happened. Anyone can verify that record offline, without your software, your systems or any key you hold.4147 PyPI15AGPL 3.0
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to call backend tools under per-agent policy, deciding which tools each agent can see, what arguments it may pass, how often it may call, and which writes wait for human approval. It also redacts secrets and PII from tool results, fences untrusted output against injection, and records every call in a hash-chained audit log.19 npmMIT
TDQS
Scored across 19 tools
The core governance pipeline (writ_check → writ_lease → writ_execute → writ_verify_token) is well differentiated by explicit ordering cues and mutually exclusive arguments, and the GitHub/admin tools each target a distinct resource. Minor overlap remains: writ_lease and writ_execute both accept an authToken and near-identical method/path/body arguments, and writ_receipts vs writ_explain_receipt could be momentarily confused (list vs. explain one).
All 19 tools share a consistent writ_ prefix and snake_case, and most read as verb_noun (writ_check, writ_revoke, writ_github_set_threshold). The deviation is a cluster of noun-only names for list operations (writ_receipts, writ_policy, writ_manifests, writ_principals, writ_verbs, writ_keys), which is readable but breaks the verb-first pattern.
19 tools is slightly above the ideal band but each maps to a real step in the authorize/lease/execute/audit lifecycle or a concrete GitHub/admin operation. It tips toward heavy because of five-plus read-only listing tools (principals, verbs, keys, manifests, receipts) that could arguably be consolidated.
The authorization lifecycle is complete: check, lease, execute, point-of-action verify, step-up grant, revoke/reinstate, plus audit receipts and a sandbox demo path. Gaps: policy and API keys are read-only (no policy write or key create/rotate tools), and GitHub PR-comment/threshold settings are covered while broader installation administration is not.