The MCP server

Connecting

• Endpoint https://estatedraftfl.com/mcp — JSON-RPC 2.0, one message per POST, one JSON answer (no stream; GET answers 405).
• Protocol 2025-06-18 or 2025-03-26; send MCP-Protocol-Version after initializing.
• Authorization: the firm’s key as a bearer token, exactly as for the REST API. A key sees only the tools its scopes allow.
• Each key has its own MCP lanes: 120 reads and 30 writes a minute.

{
  "mcpServers": {
    "estatedraftfl": {
      "type": "http",
      "url": "https://estatedraftfl.com/mcp",
      "headers": { "Authorization": "Bearer ${EDFL_FIRM_KEY}" }
    }
  }
}

Tools

• list_mattersmatters:read · reads

  List the firm's matters

  The firm's matters, newest first: id, status, stage, product and dates — never a name, a document or a person's words. Matters with a wall are never read.

• get_mattermatters:read · reads

  Read one matter

  One matter the key may read. Richer for a key whose allowlist names it (the next confirmed date, open client requests); document fingerprints only with documents:meta.

• list_deadlinesdeadlines:read · reads

  List the firm's derived deadlines

  The dates the firm derived, each with its rule, its citation and whether it was confirmed.

• list_receiptsreceipts:read · reads

  List the firm's receipts

  The tamper-evident receipts of filed and delivered work: type, hash and the previous receipt's hash.

• get_agendaagenda:read · reads

  What waits on the firm

  The firm's agenda by kind and register — ids and dates, never names. A lane that could not be read is named in the notes.

• list_capabilitiescapabilities:read · reads

  List the platform's capabilities

  The published capability catalogue: what each capability does, in which lane, and its status.

• propose_actionrecord:propose · writes (files a proposal)

  Propose an action for the firm to decide

  Files a proposal on a matter for the firm's attorneys to decide. Nothing is executed (executed: false). Anything beyond a title, a description and requested data — a status, a clearance, an approval, an override — is stripped and named on the firm's card. Three undecided proposals per matter at most.

What every result carries

Each tool result is the REST answer itself, as structured content and as text, with the verified-read triple at its top level: provenance_ids and provenance_count (what it rests on), verification_status (unknown < ungrounded < grounded < verified — the weakest of its parts) and as_of. A read that could not be completed returns data: null, a null count and the status unknown, marked as an error — never an empty list an assistant could mistake for “nothing”. A refused tool (a missing scope, an unknown matter) is an error result that names why; an unknown tool or method is a protocol error.

propose_action

Needs record:propose and an idempotency_key argument (the same proposal with the same key returns the first answer). It files the proposal awaiting the firm’s attorneys and executes nothing; anything beyond a title, a description and requested data is stripped and named on the firm’s card. Three undecided proposals per matter at most.

Prompts and resources

• matter_status_brief — Reads one matter (and its deadlines when the key may) and asks for a brief that keeps the verification status and says what could not be read.
• agenda_review — Reads the firm's agenda and asks for it grouped by register, oldest first, keeping the notes about lanes that could not be read.
• edfl://openapi.json — Every v1 operation, its scope and its answers.

The operations behind the tools, their errors and the webhooks are in the API reference.