LaxFinder

AI agents can search 1,331 college lacrosse programs through LaxFinder’s WebMCP tools—while the same map stays visible, synchronized, and under the student’s control.

Comment

Inspiration

College lacrosse opportunities are scattered across NCAA, NAIA, NJCAA, MCLA, WCLA, and other pathways. I built LaxFinder to bring those opportunities together in a map-first experience where student-athletes and families can explore more than 1,300 programs.

But finding the data is only part of the problem. Students increasingly use AI to help them think through decisions. I wanted to explore a different model: instead of building another chatbot that tries to know everything about college lacrosse, what if a student's AI assistant could work directly with the specialized application that already has the data, filters, map, and school details?

WebMCP made that possible.

What LaxFinder does with WebMCP

LaxFinder exposes two deliberately narrow, read-only WebMCP tools:

  • search_lacrosse_programs searches LaxFinder's structured program data and synchronizes the same filters, result count, markers, and map the student sees.
  • get_program_details retrieves a specific program by stable program ID and opens LaxFinder's existing visible program-details interface.

A student can ask a compatible AI assistant in everyday language:

Show me women's lacrosse programs in Colorado with Health Sciences. Keep all divisions open.

The agent interprets the request. LaxFinder performs the authoritative search. In the judge-accessible full hosted dataset, that request returns 7 programs, and the visible LaxFinder filters, count, and map update to match.

The student can then continue exploring the live application, click map markers, inspect school details, or refine the search conversationally.

The agent interprets. LaxFinder searches. The student decides.

Why WebMCP is a strong fit

Traditional browser automation forces an agent to infer how a site's UI works, manipulate controls, and reconstruct state from what it can see. That is especially fragile in a map-first application with interdependent filters, clusters, result counts, and program-detail views.

WebMCP lets LaxFinder explicitly expose the actions an agent is allowed to take and connect those actions to the same application state the human sees.

That creates a better division of responsibility:

  • the AI assistant handles natural-language interpretation;
  • LaxFinder remains the source of truth for program data and search behavior;
  • the human remains inside the visible map experience and retains control of the decision.

The result is not an invisible agent-only answer. It is a shared human + agent interaction with one synchronized application state.

What people and agents can now do together

Before this WebMCP extension, a student could either use LaxFinder manually or ask a general-purpose AI about college options separately. Those were disconnected experiences.

With WebMCP, the student can express a search conversationally and have the agent call LaxFinder's specialized tools directly. The resulting filters, count, markers, map position, and program details become visible in LaxFinder, where the student can continue exploring manually.

That makes AI useful without asking it to replace the application or make the decision.

What was added during the WebMCP Challenge

LaxFinder existed before the challenge as a map-first college lacrosse discovery application. The challenge work began after the Submission Period opened on August 25, 2026 and meaningfully extended the existing product with WebMCP.

The challenge extension added:

  • imperative WebMCP registration with document.modelContext.registerTool;
  • search_lacrosse_programs;
  • get_program_details;
  • a narrow bridge from tool calls into LaxFinder's existing visible filter/map/detail state;
  • feature detection for browsers without WebMCP;
  • strict schemas and runtime validation;
  • bounded search results and stable program IDs;
  • unsupported-criteria handling rather than guessing;
  • read-only behavior and output sanitization;
  • deterministic contract tests for registration, search, detail lookup, invalid inputs, zero/multiple results, sanitization, and visible UI synchronization;
  • a separate frozen judge-accessible WebMCP deployment and public open-source reference repository.

The repository's CHALLENGE_BUILD.md explicitly separates pre-existing LaxFinder functionality from work added for this challenge and records the validated challenge build.

How it was implemented

The WebMCP layer is implemented in the browser using document.modelContext.registerTool.

Tool calls operate on data already loaded by LaxFinder and invoke the application's existing search and UI behavior. A successful search_lacrosse_programs call updates the visible filters, matching-program count, map markers, and map view before returning a structured response. get_program_details accepts an exact stable program ID, opens the corresponding visible detail panel, and returns sanitized program and available admissions fields.

Neither tool follows external links or performs a mutation.

The public repository contains the complete WebMCP/application implementation plus a small representative fixture dataset for local development and deterministic testing. The judge-accessible hosted challenge deployment uses LaxFinder's separately maintained full 1,331-program runtime dataset.

No OpenAI API key is required for the WebMCP interaction. The compatible AI assistant provides conversational reasoning; LaxFinder provides the specialized tools and authoritative application state.

Validation

The end-to-end consumer workflow was validated through ChatGPT Work / Cloud Browser.

ChatGPT discovered both LaxFinder WebMCP tools, invoked search_lacrosse_programs for women + Colorado + Health Sciences, received 7 structured matches from the full hosted dataset, and the visible LaxFinder filters, result count, and map synchronized to those results.

ChatGPT then used get_program_details for Colorado Mesa University and LaxFinder opened the existing visible school details interface.

That demonstrated the complete interaction:

AI conversation → WebMCP tool discovery → authoritative LaxFinder search → structured response → synchronized visible human interface.

Challenges and design decisions

One of the most important decisions was defining what the AI should not do.

If a student asks for a criterion LaxFinder does not authoritatively expose, the system should not silently substitute a proxy or invent an answer. Unsupported criteria are surfaced as limitations instead.

Another challenge was preserving human visibility. Returning structured data only to the agent would have been simpler, but it would split the AI interaction from the trusted Finder experience. The WebMCP bridge instead keeps the existing map, filters, counts, and details synchronized with agent actions.

What I learned

WebMCP changed how I think about AI integration.

LaxFinder does not need to recreate a general-purpose AI assistant. It can concentrate on what it uniquely provides: structured college lacrosse opportunity information and reliable, bounded tools for interacting with that information.

Compatible AI assistants can provide the conversation and reasoning.

That separation creates a more trustworthy pattern for agent-native applications: specialized sites expose authoritative capabilities, agents interpret user intent, and people stay in control of the visible experience.

What's next

The next direction is not to give agents broader control for its own sake. It is to expose additional useful LaxFinder capabilities only when they can remain authoritative, bounded, and visible to the student.

Longer term, the same pattern could support richer opportunity information supplied and maintained by college programs themselves, allowing compatible agents to help student-athletes discover opportunities without requiring the AI to infer them from the open web.

The goal remains simple: make better opportunity information easier for students and families to discover, understand, and act on.

Built With

Share this project:

Updates