LexProof — Ask Lexi (simulated Alexa+ over MCP)

Ask your contracts by voice and get answers you can prove: a simulated Alexa+ assistant on a self-hosted MCP server, with signed two-step approvals and on-chain proof checks.

Comment

Inspiration

Legal and procurement teams don't need another dashboard. They need to ask three things quickly — what's safe, what's due, what's waiting on me — and trust the answer. Voice assistants are great at the asking and bad at the trusting: they paraphrase, they can't show evidence, and letting one approve something is scary. LexProof already proves what happened to a contract (AI findings, human review, a SHA-256 "Legal Passport" anchored on Ethereum Sepolia). We wanted Alexa+ to be able to use that proof safely.

What it does

Ask Lexi is a voice workspace inside LexProof that behaves like an Alexa+ skill backed by our own MCP server:

  • "What contracts do I have?" → list_contracts (counts anchored proof passports)
  • "Is the master services agreement verified?" → verify_contract_proof recomputes the passport fingerprint and checks it against the Sepolia anchor. "Verified" is never a stored flag.
  • "What payments are due this month?" → upcoming_obligations, overdue first
  • "What's waiting for my approval?" → pending_approvals, filtered to what your roles allow and excluding items you created (separation of duties)
  • "Approve the legal review" → prepare_decision reads the action back with a signed six-character code and a five-minute countdown. Nothing changes until you say "confirm" on the very next turn → confirm_decision.
  • ask_contracts answers free-form questions only when it can cite findings.

The MCP trace panel shows every tool call, its arguments and latency live, so you can see exactly what the assistant did.

How we built it

  • MCP server: MCP Python SDK 2.3 (MCPServer), Streamable HTTP, stateless JSON responses, protocol 2025-11-25, mounted at /mcp in our FastAPI backend on Cloud Run.
  • Thin adapter: the 7 tools never re-implement business logic. They call our existing REST routes in-process, forwarding the user's Firebase bearer token and org, so RBAC, tenant isolation, read-only judge accounts and the audit log all apply unchanged.
  • Auth: a Firebase TokenVerifier plus protected-resource metadata, so standard MCP clients (MCP Inspector) get a spec-compliant 401 and connect with a bearer token.
  • Safe actions: HMAC-SHA256-signed confirmation tokens bound to the user, the item and its state; single use; five-minute expiry; a fresh prepare is required. A deterministic guard in the agent's before_tool_callback blocks confirm_decision unless the previous turn prepared that exact code and the user actually said "confirm".
  • Alexa+ simulation: a Google ADK agent (Gemini via Vertex AI) connects to our own /mcp as an MCP client over Streamable HTTP, exactly as Alexa+ would. The browser uses the Web Speech API for push-to-talk or hands-free input and natural neural voices for replies.
  • Proof: passport roots anchored on Ethereum Sepolia; verification recomputes the hash and compares it with the on-chain record.

Challenges we ran into

  • The MCP Python SDK 2.x renamed FastMCP and moved auth imports; most examples online are still v1.
  • MCP Inspector falls into OAuth Dynamic Client Registration when there's no bearer header, with an error that hides the real cause.
  • Approvals over voice: we rejected elicitation (it depends on the client and on session state) in favour of an explicit, client-agnostic prepare → confirm flow.
  • Short voice codes don't survive Cloud Run autoscaling, so tokens are HMAC-signed and portable.
  • Seeded demo data tripped our own separation-of-duties rule, which hid every approval from the judge. Good to know the rule works.

Accomplishments that we're proud of

Every answer runs as the user through the same rules as the app, and an AI can never approve something without a human confirming on the next turn. The same server works in MCP Inspector, in the Google ADK agent, and is ready for Alexa+.

What we learned

MCP makes the "assistant layer" cheap to add if your API already enforces the rules. The hard part of voice is safety and speech-friendly answers (spoken names, plurals, overdue-first), not the plumbing.

What's next for LexProof

OAuth authorization-server support (CIMD/DCR) so a real Alexa+ account can link without a pasted token; more actions (redline accept/reject); multilingual voice.

Try it

Simulated Alexa+ experience; no Amazon affiliation implied. Not legal advice.

Built With

Share this project:

Updates

Submission history