• 

  Praxa-thumbnail

• 

  Landing-Page

• 

  Cited-Answer

• 

  Semantic-Search

Inspiration

Theatre information is scattered across articles, PDFs, venue announcements, and historical lists. Finding a reliable answer often means opening several documents, searching manually, and checking whether every detail is supported.

I built Praxa to explore a better model: a shared research workspace where a person can ask naturally and a browser agent can use purpose-built tools to retrieve evidence, compare productions, and present a concise answer with page-level citations.

What it does

Praxa is a WebMCP-native research assistant focused on Broadway and West End theatre. It exposes three typed browser tools:

• ask_theatre answers factual theatre questions using indexed source documents.
• search_theatre_archive performs semantic search and returns the strongest page-level passages without requiring an LLM response.
• compare_productions compares two productions using a user-selected focus, such as venue, opening date, or run length.

Every agent action updates the same visible workspace used by the person. This keeps the human in the loop: the user can see the request, answer, latency, sources, page numbers, and supporting excerpts.

Why WebMCP

A conventional assistant must scrape page text, infer controls, or imitate clicks. Praxa instead publishes explicit tools through document.modelContext.registerTool.

The tools have JSON input schemas, bounded inputs, read-only annotations, untrusted-content annotations, cancellation support, and structured results. This gives agents a reliable interface while preserving the normal human-facing website as progressive enhancement.

Before WebMCP, a person could ask Praxa questions manually, but an agent could not reliably discover its research capabilities or invoke them directly. Now people and agents can work in the same interface: an agent can search the archive, inspect evidence, ask a grounded question, compare productions, and leave the result visible for the person to review.

How I built it

The production application uses:

• FastAPI and Uvicorn for the web service and research APIs
• the WebMCP imperative API for browser-native tool registration
• LangChain for retrieval-augmented generation
• Chroma for persistent vector search
• Hugging Face sentence-transformer embeddings
• OpenRouter for grounded answer generation
• Railway for containerized production hosting
• GitHub Actions for linting, tests, coverage enforcement, and Docker builds

The retrieval system downloads theatre PDFs, divides them into overlapping chunks, embeds them, and stores the index on a persistent Railway volume. Answers are restricted to retrieved excerpts and include citation labels matching the page-level source records shown in the interface.

The production pipeline also rejects provider metadata and uncited generated claims, retries invalid responses once, and safely abstains if a grounded answer cannot be produced.

Challenges I faced

The first major challenge was converting a human-only Streamlit prototype into a genuine WebMCP product. I replaced the original entry point with a same-origin FastAPI application and created tool-specific APIs that both return structured results and update the visible interface.

Cold-start behavior was another challenge because the embedding model must be loaded before retrieval. Persistent Chroma storage prevents the source index from being rebuilt after each deployment.

Live testing also exposed an intermittent model-provider response that returned safety metadata instead of a theatre answer. I added a tested output-quality gate that rejects metadata and uncited claims before they can reach users.

Challenge-period work

Praxa existed before the hackathon as a theatre RAG prototype. During the submission period, I meaningfully extended it with:

• three working WebMCP tools;
• a new shared human–agent interface;
• FastAPI research and semantic-search endpoints;
• structured tool schemas and annotations;
• visible agent-driven UI updates;
• citation-alignment and output-quality safeguards;
• Railway deployment, CI checks, and WebMCP regression tests.

The dated GitHub pull requests and commit history clearly separate this work from the earlier prototype.

What I learned

This project taught me that WebMCP is more than browser automation. It creates a stable contract between websites and agents while preserving the website as the place where people understand and supervise the work.

I also learned that agent-ready applications need more than tool registration. They need careful schemas, visible state, deterministic evidence retrieval, cancellation handling, security boundaries, production monitoring, and graceful failure behavior.

What’s next

Next, I would expand Praxa into a broader performing-arts research network with licensed data sources, venue and ticket integrations, saved research collections, multilingual retrieval, evaluation datasets, and tools that help audiences, journalists, students, and theatre professionals collaborate with agents.

Built With

• actions
• api
• chroma
• docker
• face
• fastapi
• github
• html
• hugging
• javascript
• langchain
• openrouter
• python
• rag
• railway
• rest
• search
• semantic
• webmcp