First Key

Inspiration

Renting a first apartment is a high-stakes moment. A student or first-time renter often has to understand a dense lease quickly, while a parent wants to help without taking over. We wanted to explore a sharper question for WebMCP: what if AI safety came from the product architecture itself, not just from asking the model to behave?

What it does

First Key is a first-apartment desk for a tenant and parent. An AI clerk can read the listing, inspect the lease, flag costly clauses, and draft a landlord letter. The important part is what it cannot do: the app never exposes tools for sending email, agreeing, paying, submitting, or countersigning.

The demo follows Maya Chen and her parent through a shared rental packet. The clerk can identify costly lease terms like a non-refundable pet fee, early termination fee, automatic renewal, and rent increase. The letter can be staged, but it only becomes downloadable after two separate human seats agree in two different tabs.

How we built it

We built First Key with React, TypeScript, and WebMCP page tools. The app registers different tools depending on the current stage: listing, lease, application, or outbound. This makes tool availability part of the UI state.

For example, the clerk can use tools like pull_listing_terms, run_playbook, pin_finding, and stage_outbound. But tools like send, agree, and countersign are intentionally never registered. The interface shows this directly with active tools and withheld tools side by side.

We also built a deterministic clerk playbook evaluation. The app reports costly-clause recall, precision, and boilerplate silence across development, held-out, and adversarial lease fixtures.

Challenges we ran into

The hardest part was resisting the temptation to make the AI do everything. Many rental demos would let the agent email the landlord, submit the application, or sign the document. We chose the opposite: the AI can prepare work, but irreversible actions require humans.

Another challenge was evaluation. A lease scanner can look good if it only checks one hand-written example. We added held-out fixtures, adversarial decoys, and a regression probe so the project has a measurable claim instead of just a nice demo.

Accomplishments that we're proud of

We are proud that First Key demonstrates WebMCP as a product boundary, not just an integration layer. The app can say: these tools are available now, these tools are withheld forever, and this action requires human agreement.

We are also proud of the evaluation page. It shows 1.00 costly-clause recall, 1.00 precision, and 1.00 boilerplate silence on development, held-out, and adversarial extractive labels. It also openly shows the 0.00 paraphrase robustness result as a deliberate boundary: the clerk prefers silence over speculative guesses.

What we learned

We learned that WebMCP is most powerful when the site is opinionated about capability. Instead of giving an agent a broad instruction and hoping it follows policy, the application can expose a small, stateful set of tools that match the current workflow.

We also learned that restraint can be a feature. The best demo is not an agent doing everything. It is an agent helping at the right moments while the app protects the actions that should stay human.

What's next

Next, First Key could support more lease templates, clearer state sync for families, and richer jurisdiction-specific playbooks. The same architecture could also apply to other high-stakes workflows: medical forms, insurance claims, school financial aid, or any process where AI should assist but not act alone.

Built With

• agent
• ai
• react
• typescript
• vite
• webmcp