Hacklist

HackList helps builders stop missing the right opportunities by letting their AI agent search, understand, compare and recommend hackathons, jobs, grants, bounties and programs that actually fit them.

Comment

Inspiration

HackList started because finding good AI and Web3 opportunities is unnecessarily fragmented. Hackathons, jobs, grants, bounties, and builder programs are spread across dozens of platforms, and even when builders find them, the harder question remains:

Which of these opportunities actually fits me?

A directory can tell someone what exists. It cannot naturally answer:

  • Which hackathons can a React developer in Ghana realistically enter?
  • What remote AI jobs match my skills?
  • Is this bounty a better use of my weekend than this hackathon?
  • What exactly do I need to submit for this opportunity?
  • Which parts of my eligibility are confirmed, and which are still unknown?

The WebMCP Challenge gave me the opportunity to turn HackList from a discovery product into an agent-native opportunity intelligence layer.

What it does

HackList exposes its live opportunity catalog directly to browser agents through WebMCP.

Instead of an agent scraping the page or guessing from UI elements, HackList registers semantic tools using:

document.modelContext.registerTool(...)

The current WebMCP toolset is:

  • search_opportunities
  • get_opportunity
  • match_opportunities
  • compare_opportunities
  • get_opportunity_readiness

These tools work across HackList's opportunity categories:

  • Hackathons
  • Jobs
  • Grants
  • Bounties
  • Programs

A user can ask naturally:

"I am a React developer in Ghana with a few days free. What hackathons on HackList fit me?"

The agent can translate that request into structured constraints and call HackList directly.

HackList then performs the domain reasoning searching live opportunity data, evaluating known eligibility constraints, matching technologies and interests, comparing trade-offs, and surfacing readiness requirements.

How we built it

HackList already existed as a human-facing discovery platform for AI and Web3 opportunities. For the WebMCP Challenge, I extended it into an agent-native opportunity intelligence layer.

The core change was adding five semantic WebMCP tools through the canonical document.modelContext.registerTool(...) API:

search_opportunities get_opportunity match_opportunities compare_opportunities get_opportunity_readiness

These tools operate across HackList’s five opportunity categories: hackathons, jobs, grants, bounties, and programs.

The WebMCP layer sits on top of the existing Supabase-backed application. The underlying HackList data-entry workflow did not need to change. Instead, I added a unified opportunity model, category adapters, structured matching logic, and a verified intelligence layer for deeper reasoning where data is available.

The matching engine is deterministic rather than LLM-ranked. The browser agent interprets what the user means, while HackList evaluates the opportunity itself using structured constraints such as skills, technologies, location, format, deadline, and eligibility.

The system explicitly distinguishes PASS, FAIL, and UNKNOWN, and uses fit states such as STRONG_FIT, POSSIBLE_FIT, WEAK_FIT, and INSUFFICIENT_DATA. If HackList does not know something, it does not invent it.

All current WebMCP operations are read-only. They were tested locally and in production using Chrome 152 and WebMCP tooling, including chained flows such as search → inspect and match → compare → readiness.

Challenges we ran into

The hardest challenge was avoiding the obvious implementation: simply wrapping HackList search in WebMCP and calling it finished.

That would have technically exposed a tool but it would not have created a meaningful new human-agent experience.

The more difficult problem was deciding what HackList should be authoritative about. The agent is good at understanding natural language, but it should not invent opportunity eligibility, rank candidates from vague page text or pretend incomplete data is complete.

That led to a clear separation of responsibilities:

The agent understands the user. HackList understands the opportunities.

Another challenge was generalizing the system. Early work focused heavily on hackathons, but HackList is broader than that. I refactored the implementation around a unified opportunity domain so the same WebMCP interface works across jobs, grants, bounties, programs, and hackathons without exposing dozens of overlapping tools.

Data quality was another major challenge. Many existing listings contain enough information for discovery but not enough for confident personalized matching. Instead of hiding those records or hallucinating missing details, the system preserves them and returns UNKNOWN or INSUFFICIENT_DATA where appropriate.

Production validation also surfaced real browser issues, including a React hydration error and deployment-cache behavior. Those were fixed narrowly and revalidated rather than ignored.

Accomplishments that we're proud of

I am most proud that the final result is not a scripted demo path built for a single example.

HackList already serves a community of more than 10,000 developers and builders looking for AI and Web3 opportunities. That means the WebMCP layer had to work for real, varied users not just one hardcoded profile.

A builder can ask about hackathons, jobs, grants, bounties, programs, or broad opportunity discovery, and the same general WebMCP architecture handles the request.

For example, a user can ask:

“I am a React developer in Ghana with a few days free. What hackathons fit me?”

and HackList can restrict the search to hackathons, evaluate the supplied constraints and return explainable results.

Another user can ask for remote AI jobs, a weekend bounty, a grant, or a broader set of opportunities, without requiring a different application architecture.

Technically, the final implementation has five real read only WebMCP tools, production Supabase integration, deterministic matching, category-aware comparison, readiness analysis, explicit uncertainty handling, tool chaining, automated tests, visible agent activity in the UI and production browser validation.

Most importantly, HackList still works as the same product for humans who never use an agent. WebMCP adds a new interface to an existing product already serving thousands of builders, turning HackList from a directory people browse into an opportunity intelligence layer that both humans and their agents can use.

What we learned

WebMCP changes how I think about web product design.

A traditional website exposes pages and controls.

An agent native website can also expose its capabilities and domain semantics.

For HackList, that means the site no longer only answers:

"What opportunities exist?"

It can now participate in answering:

"Which opportunities make sense for me, why, and what do I need to do next?"

WebMCP also changed how I think about the relationship between a user’s agent and a web application. The agent should not replace the domain logic of the application. Instead, the agent and the website should each do what they are best at.

The agent understands intent and conversation.

HackList provides verified opportunity state and domain-specific reasoning.

WebMCP becomes the bridge between them.

What's next for Hacklist

The next step is to expand the intelligence coverage behind the same WebMCP interface.

Today, every opportunity can be discovered through the unified catalog, while deeper matching intelligence is richer for some records than others. Over time, more opportunities will gain structured eligibility, technology, skills, requirements, team rules, provenance and readiness information.

I also plan to automate HackList’s ingestion pipeline. Instead of manually finding and entering every new opportunity, an ingestion agent will continuously discover new hackathons, grants, jobs, bounties, and programs, verify them against official sources, detect duplicates, structure the information, and queue high-quality records for publishing.

Built With

Share this project:

Updates