Disclaimers

Last updated Jun 14, 2026

After reading this page you'll know which response shapes carry a disclaimer envelope, what a DisclosurePacket looks like, how SDKs are expected to surface disclaimers in logs, and how MCP tool output makes the packet readable to agent runtimes.

Why disclaimers exist

Matter is a software platform, not a law firm. Every binding action it takes — every certificate issued, every grant booked, every dissolution filed — has legal and tax consequences for the customer that Matter neither advises on nor underwrites.

The disclaimer envelope is the platform's standing statement of that fact, attached to every artifact that carries legal weight. It is machine-readable so SDKs and agent runtimes can surface it consistently; it is short enough that humans can read it.

The default floor text

Every disclaimer envelope carries this default text unless the customer account has negotiated a custom variant via their MSA:

Matter is a software platform, not a law firm. Matter does not provide legal, tax, or securities advice. The customer is solely responsible for the legal and tax consequences of this action and should consult qualified professionals before proceeding.

The text is the floor. Custom MSA variants may extend it (e.g. a venture studio adding portfolio-specific language) but cannot weaken it. The text is rendered in text/plain (no markdown) for maximal SDK and log-pipeline portability.

Where disclaimers appear

The envelope is attached to every response that carries a binding artifact. There are five canonical carriers:

Other resources (Entity, Stakeholder, Grant, Valuation, etc.) carry disclaimers transitively via the Document or Filing they generate. A bare Entity retrieve does not include a disclaimer envelope; the underlying IncorporatorReceipt retrieve does.

Envelope shape

{
  "id": "doc_PwQ7MmLk",
  "object": "document",
  "type": "action_of_incorporator",
  "entity_id": "ent_Nq3KcAbc",
  "...": "...",
  "disclaimer": {
    "version": "2026-01-01",
    "text": "Matter is a software platform, not a law firm. Matter does not provide legal, tax, or securities advice. The customer is solely responsible for the legal and tax consequences of this action and should consult qualified professionals before proceeding.",
    "text_url": "https://mattermode.com/legal/disclaimer/2026-01-01",
    "applies_to": "this_response",
    "supersedes": ["2025-04-01"]
  }
}

SDK guidance — _meta.disclaimers[]

The official SDKs (@mattermode/node, mattermode Python) surface disclaimers at the top of every response under _meta.disclaimers[], deduplicated across nested artifacts. SDK consumers are expected to log them on first observation and at the boundary of any user-facing surface.

import { MatterClient } from "@mattermode/node";

const matter = new MatterClient({
  apiKey: process.env.MATTER_KEY!,
  apiVersion: "2026-05-01",
  onDisclaimer: (d) => {
    // Always log to stderr/stdout. Don't silence.
    console.warn(`[matter] ${d.version}: ${d.text}`);
  },
});

const filing = await matter.filings.retrieve("flg_2x7Vc3Mn");
// onDisclaimer fires once per unique disclaimer version observed
// across the response tree.

The default onDisclaimer handler in every official SDK writes to stderr. Suppressing it requires explicitly passing onDisclaimer: () => {} — the SDK does not silently drop disclaimers.

The Python SDK exposes the same hook via MatterClient(on_disclaimer=…) and emits to logging.getLogger("matter.disclaimer") at WARNING level by default.

DisclosurePacket on dry-run

?dry_run=true on any binding mutation returns the DisclosurePacket inline with the would-be artifact. The packet is designed to be readable by both humans (for review) and agent runtimes (for relaying to the principal before requesting authorisation).

curl -X POST "https://api.mattermode.com/v1/entities/ent_Nq3KcAbc/dissolve?dry_run=true" \
  -H "Authorization: Bearer $MATTER_KEY" \
  -H "Matter-Version: 2026-05-01" \
  -H "Idempotency-Key: $(uuidgen)"

{
  "id": null,
  "object": "filing",
  "preview": true,
  "type": "dissolution",
  "entity_id": "ent_Nq3KcAbc",
  "would_emit_events": [
    "filing.submitted",
    "entity.state_changed",
    "tax_profile.dissolution_initiated"
  ],
  "fee_estimate": { "currency": "usd", "total": 22400 },
  "disclosure_packet": {
    "packet_hash": "sha256-d8f4c2a1b3e5…",
    "version": "2026-04-01",
    "issued_at": 1745539200,
    "expires_at": 1745625600,
    "consequences": [
      "The corporation will cease to exist as a legal entity in Delaware once the certificate of dissolution is accepted.",
      "All assets must be distributed to creditors and stakeholders before dissolution completes.",
      "The corporation must file IRS Form 966 within 30 days of the resolution authorising dissolution.",
      "Final state and federal tax returns marked 'final' must be filed for the year of dissolution."
    ],
    "irreversible_effects": [
      "Dissolution cannot be undone via API. Reviving a dissolved Delaware corporation requires a separate state proceeding (Certificate of Revival) and is not supported by Matter.",
      "The corporation's name will be released to the Delaware namespace 3 years after dissolution and may be claimed by another filer."
    ],
    "ongoing_obligations": [
      "Maintain records of dissolution and final tax filings for 7 years per IRS recordkeeping requirements.",
      "If the corporation has stockholders, distribute the dissolution notice within 60 days."
    ],
    "who_bears_risk": "customer",
    "professional_advice_recommendation": "Consult a Delaware corporate attorney and a CPA familiar with C-corp dissolution before authorising this action. Matter is a software platform, not a law firm.",
    "required_acknowledgements": [
      "dissolution_is_irreversible",
      "not_legal_advice",
      "not_tax_advice"
    ]
  }
}

Field semantics

packet_hash binding

When the customer (or their agent) creates a signing_session for the action previewed in the dry-run, the session must include the packet_hash from the packet. The signing rail then enforces:

• The action being signed exactly matches the action that was previewed.
• The DisclosurePacket the human (or agent) reviewed is the one that binds the session.
• Modifying the payload after dry-run produces a deterministically different packet_hash and invalidates the session.

This closes the loop: the disclosure the customer reviewed is the disclosure that authorises the action.

MCP tool output

Matter's MCP server (apps/mcp/) exposes the API as Model Context Protocol tools. Every tool whose underlying operation is binding returns the DisclosurePacket as part of the tool result, structured so the agent runtime can read it back to the principal verbatim before requesting authorisation.

{
  "tool_name": "matter_dissolve_entity",
  "arguments": { "entity_id": "ent_Nq3KcAbc", "dry_run": true },
  "result": {
    "preview": { "...": "..." },
    "disclosure_packet": { "...": "..." }
  }
}

A well-behaved tier-3 agent uses this pattern:

1. Call the tool with dry_run: true.
2. Read the DisclosurePacket back to the principal in plain English, highlighting irreversible_effects and who_bears_risk.
3. Capture the principal's per-action acknowledgements.
4. Call the tool with dry_run: false, the captured acknowledgements, and the packet_hash from step 1.

Tier-4 agents with standing acknowledgements still receive the DisclosurePacket on dry-run and are expected to surface it in their own audit trail; they bypass step 3 because their token already carries the standing ack on file.

Versioning

The disclaimer text version and the DisclosurePacket schema version are independent.

• Disclaimer text changes when the floor language changes — typically in response to MSA updates or regulatory clarifications. Existing artifacts retain the version they were stamped with at issuance.
• DisclosurePacket schema changes when fields are added or semantics change. Each operation's packet contract is pinned to the request's Matter-Version. Tokens pinned to a prior api_version receive packets in the prior schema; the SDK normalises to the current shape transparently.

Both follow the standard versioning cadence — monthly releases with a 24-month deprecation window.

Related

• Legal basis — the two signing rails the disclaimer envelope and DisclosurePacket support.
• Acknowledgements — the per-action acks referenced by required_acknowledgements on the packet.
• Dry run — how ?dry_run=true works across the API generally.
• Errors — the RFC 7807 envelope used by every Matter error.