EdgeLex MCP tooling: technical capability and governance model.

EdgeLex does not treat MCP tool availability as blanket authority to act. A tool call passes through several distinct authorization layers. The backend remains authoritative for:

The model cannot grant itself access merely by supplying a tenant ID, matter ID, document ID or user ID.

Some tools can mutate EdgeLex immediately, but only when the user has already given an explicit instruction authorizing the specific action. Examples:

“Direct” does not mean ungoverned. These calls still pass through backend permission checks, validation, audit and persistence controls. Typical direct-write safeguards include explicit user-command authority, exact target identifiers, matter and tenant validation, allowed-field validation, evidence references, idempotency keys, expected object-version timestamps, stale-write rejection, special handling for legally significant records, and true execution-result reporting.

A tool result is the source of truth. The AI must not say that an email was sent, task created or document saved unless the returned result confirms it.

These are related but different concepts.

EdgeLex proposal. A durable domain artifact stored by EdgeLex. It represents a contemplated action: send this message, create this task, update this calendar event, delete this record, transition this workflow, create this standing agent. It may survive beyond the immediate model turn and can be listed, confirmed or declined later.

MCP elicitation. The interactive mechanism through which the host asks the user for required input, authorization or confirmation. It is appropriate when a required value is missing, multiple authorized targets match, the recipient is ambiguous, the operation requires affirmative user approval, authentication or reconnection is required, or the server needs structured user input it cannot safely infer.

In practice: the proposal is the durable governed object; elicitation is the user-interaction channel used to obtain the decision. An AI should never treat silence, prior general approval, approval of a different proposal, the fact that a proposal exists, or a model-generated recommendation as confirmation of the current action.

Certain legal and operational actions require supporting evidence references. The clearest example is completing a court-mandated task: ordinary bulk completion rejects court-mandated tasks, and court-mandated completion requires references to supporting filing, order or proof records. Other proposed or direct writes may also accept evidence references documenting why the operation is justified.

This establishes a provenance chain: source record → proposed conclusion/action → user approval → executed mutation → audit record. Evidence references are not decorative citations; they are part of the governed write contract.

Workflow tools do not allow the AI to force an arbitrary state change. Read tools expose current workflow status, available transitions, blocked transitions, exact blocking reasons, guard states, sibling-workflow dependencies, pending approvals, SLA or stuck-state information, and court-rule deadline lineage.

A workflow transition is proposal-first: EdgeLex dry-runs the transition and returns current guard truth and blockers; the user reviews the proposal; confirmation invokes the server-side workflow engine, which reruns guards, validators, form requirements and approvals; a stale or now-invalid transition fails closed. Neither ChatGPT nor the MCP client can bypass the workflow engine’s authority.

The DMS surface separates document discovery, reading, analysis and saving. Typical sequence: find document candidates; read metadata; retrieve complete text or bounded text slices; execute a structured search plan if corpus reasoning is required; extract facts with provenance; check scan/OCR readiness if relevant; compare document versions where necessary; evaluate court-format compliance; prepare a save proposal or governed save.

The AI should not claim that an extracted fact is present unless the document text or extraction result supports it. It should preserve document IDs, versions, page references and source spans when the tool provides them. Court-form discovery and preparation are distinct from proving that a form is legally required.

Standing agents use a separate, deliberately staged lifecycle.

Stage 1: capability consultation. edgelex_capabilities_agent is read-only. It explains what standing agents can do, matches the requested outcome to registered recipes, explains supported triggers, identifies accessible inputs, produces a validated design when given an authorized matter, and returns a signed design_reference. The design is selected from server-registered executable patterns; the model does not invent an arbitrary executable graph.

Stage 2: creation proposal. edgelex_agent_create_proposal accepts the signed design reference and creates a pending proposal. It does not create the agent immediately.

Stage 3: explicit confirmation. The lawyer confirms the exact proposal. EdgeLex then creates the agent as a disabled draft.

Stage 4: separate enablement. Creating the agent does not activate it. Enablement is intentionally separate.

Current safety properties: consultation is read-only; creation requires confirmation; created agents start disabled; enablement is a separate operation; design references are server-signed and registry-bound. This prevents a conversational suggestion from silently becoming a continuously operating background actor.