writ-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| writ_checkA | Ask Writ whether an action may proceed. CALL THIS BEFORE any consequential write. A consequential write is anything hard to undo: sending money or messages, changing access or identity records, deleting data, calling an external API that acts in the world. Args: sponsor_id: The human sponsor accountable for this action (e.g. a user id or email). agent_id: The agent or workflow performing the action. verb: What is being done (e.g. "verify_human", "send_payment"). target: What it acts on (e.g. "benefit-case-123"). purpose: Why, in plain words. Be specific — the approval is bound to this purpose. Returns a decision: ALLOW — proceed. You get an authToken valid 90 seconds, bound to this exact sponsor/agent/verb/target/purpose. Call writ_verify_token against the intended write immediately before executing it. DENY — do NOT perform the action. Explain the receipt reason to the user. STEP_UP — a human sponsor must approve first. Tell the user what needs approval; they can approve via writ_grant (or the dashboard), then call writ_check again. Every outcome creates an audit receipt with a receiptId. |
| writ_verify_tokenA | Verify a Writ auth token against the write you are about to execute. Call this IMMEDIATELY before executing an ALLOWed write, with the exact verb/target/purpose you intend. If valid is false — expired, tampered, or bound to a different purpose — do NOT execute the write; call writ_check again. This is the commit-time enforcement: the check authorizes, the token proves the authorization still matches what you are actually doing. |
| writ_grantA | SPONSOR ONLY. Mint a one-time grant approving a specific action. Use this when writ_check returned STEP_UP and the human sponsor approves. The grant is single-use: the next writ_check consumes it and returns ALLOW. The grant is scoped to your tenant. Requires WRIT_SPONSOR_TOKEN. |
| writ_revokeA | SPONSOR ONLY. Kill switch: immediately deny all future checks for this principal. Revocation overrides live grants and tenant policy. Use when a principal is compromised, misbehaving, or its task is done. Scoped to your tenant. Requires WRIT_SPONSOR_TOKEN. |
| writ_reinstateA | SPONSOR ONLY. Undo writ_revoke: the principal is evaluated by policy again. Scoped to your tenant. Requires WRIT_SPONSOR_TOKEN. |
| writ_receiptsB | List recent decision receipts (audit trail). Newest first. |
| writ_policyA | Read the tenant's verb policy: which verbs allow, deny, require a grant, or step up. |
| writ_sandboxB | Get a free 90-second sandbox grant for a demo write. No API key needed. Issues a live grant for verb "demo_write" on a target starting with "demo-", then runs writ_check so you get back an ALLOW decision plus auth token to practice the verify-before-write flow end to end. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool has a distinct role in the authorization lifecycle: check, verify token, grant, revoke, reinstate, receipts, policy, and sandbox. Descriptions clearly separate the stages, especially writ_check vs writ_verify_token and writ_grant vs writ_sandbox.
All tools use the writ_ prefix with snake_case and descriptive verb or noun suffixes, forming a predictable and consistent pattern across the entire set.
8 tools is well-scoped for an authorization and audit server, covering the core actions without redundancy or bloat.
The set covers the core check-grant-verify-revoke lifecycle plus audit receipts and policy read. A minor gap is the absence of a tool to update policy or manage tenant settings via MCP, but covered workflows can proceed.