writ-mcp

Official

Overview Schema Source Related Servers Discussions Admin

writ_lease

Convert an ALLOW token from writ_check into a single-use execution lease bound to the exact method, path, and body you will pass to writ_execute, ensuring the approved upstream write is gated.

Instructions

Convert an ALLOW token into a single-use gated-execution lease.

Call this AFTER writ_check returns ALLOW, passing that ALLOW's authToken. The lease is bound to the exact upstream request you intend to run: the same method, path, and body bytes you will later pass to writ_execute. A lease is single-use; once executed (or expired) it is spent.

Args: auth_token: The authToken from a writ_check ALLOW decision. system_id: The registered upstream system: "stripe", "github", or "salesforce". A vaulted credential must be active for this system or the gate answers ok:false. method: HTTP method of the upstream request (e.g. "POST"). path: Upstream path (e.g. "/v1/refunds"). Must match the system's allowed path patterns. body: Optional JSON object (at most 1 MB). Sent only when provided; if you lease a body you must execute the identical body. ttl_seconds: Optional lease TTL in seconds. The gate caps it at 90 and at the token's remaining life.

On success the gate answers 201 with leaseId, expiresAt, ttlSeconds, verb, target, purpose, and systemId. On failure it answers {"ok": false, "reason": ...} (token invalid or expired, or no active vaulted credential for the system). On ok:false do NOT execute.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "auth_token": "<auth_token>",
      "system_id": "<system_id>",
      "method": "<method>",
      "path": "<path>"
    },
    "name": "writ_lease"
  }
}

Input Schema

Name	Required	Description	Default
`body`	No
`path`	Yes
`method`	Yes
`system_id`	Yes
`auth_token`	Yes
`ttl_seconds`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.15Nov 12, 2026

TDQS

A4.9/5.0

Behavior5/5

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

No annotations are supplied, so the description carries the whole burden and does so: single-use semantics, expiry, TTL capped at 90 seconds and at token remaining life, prerequisite of an active vaulted credential per system, and the 201 success payload field list. Failure behavior is also disclosed ({"ok": false, "reason": ...} for invalid/expired token or missing credential), which is exactly the kind of stateful detail an agent needs before mutating anything.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, then prerequisites, then per-argument detail, then response shapes — a sensible order with no filler. Slight redundancy between the "bound to the exact upstream request ... same method, path, and body bytes" sentence and the later "if you lease a body you must execute the identical body," which repeats the binding rule.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter mutation-gating tool with no annotations, everything an agent needs is present: sequencing, prerequisites, argument meanings and caps, success payload, and failure handling. The output schema exists so return values needn't be enumerated, yet the description still summarizes them usefully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate and it does for all six parameters: auth_token's provenance, system_id's allowed values (stripe/github/salesforce), method and path examples plus the path-pattern constraint, body's 1 MB limit and identity requirement, and ttl_seconds' 90-second cap. This adds substantially more meaning than the bare typed schema.

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?

States a concrete verb and resource — "Convert an ALLOW token into a single-use gated-execution lease" — and positions itself precisely against siblings by naming writ_check (upstream) and writ_execute (downstream). The agent can tell what this does and where it sits in the sequence without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit precondition ("Call this AFTER writ_check returns ALLOW, passing that ALLOW's authToken") and an explicit negative rule ("On ok:false do NOT execute"). The relationship to writ_execute is spelled out, including the binding requirement that the leased method/path/body must match what is later executed.

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