Can I Get In?

Community-powered accessibility data that AI agents can search, compare, and help keep current—so people can know whether they can get in before they go.

Comment

Inspiration

For a lot of people, choosing a restaurant, hotel, store, or somewhere else to go isn't just about reviews, price, or distance. There can be a much more basic question that comes first:

Can I get in?

That's where CIGI started.

Accessibility information for real-world places can be surprisingly hard to find. Sometimes it's buried in reviews, sometimes it's outdated, and sometimes all you get is a generic "wheelchair accessible" label. That doesn't tell you whether there's a step at the entrance, an automatic door, accessible parking, enough room to move around inside, or any of the other details that might actually matter to you.

I originally built Can I Get In? (CIGI) as a community-powered way to document those details with structured accessibility observations and photos, so people can have a better idea of what they're going to encounter before they get there.

CIGI existed before the WebMCP Challenge. For this challenge, I extended the existing platform with WebMCP and gave AI agents a way to work directly with CIGI's structured accessibility data instead of trying to figure it out by reading the website like a person would.

What it does

CIGI collects accessibility information about real places across ten categories: step-free entrances, automatic doors, ramps, accessible parking, curb cuts, accessible restrooms, interior routes, seating access, counter access, and elevators.

Something that's always been important to the project is being comfortable saying "we don't know." If CIGI doesn't have evidence for something, it shouldn't guess. The same idea became even more important once I started giving AI agents access to the data.

With WebMCP, an agent can now:

  • Search CIGI for places based on the accessibility requirements someone actually asks for.
  • Look at the detailed accessibility evidence CIGI has for a specific place.
  • Compare multiple places and explain what matches, what might be a problem, and what is still unknown or conflicting.
  • Prepare an accessibility contribution or update and hand it back to the user for review instead of publishing it automatically.

How I use WebMCP

I added four WebMCP tools to CIGI:

cigi_search_accessible_places searches CIGI's published places and can filter them using specific accessibility requirements.

cigi_get_accessibility_details lets an agent inspect what CIGI knows about one place, including observations, unknowns, confidence, and available photo evidence.

cigi_compare_accessibility compares multiple places against the requirements the user gave it. Instead of producing an arbitrary accessibility score, it shows matches, possible barriers, unknowns, conflicting evidence, confidence, and how recent the information is.

cigi_start_accessibility_contribution brings the agent back into CIGI's existing contribution system. The agent can prepare an update and open the right form, but it stops there. The user reviews the information and decides whether to submit it.

One decision I made early on was that an agent shouldn't assume someone's accessibility needs based on a disability or the mobility device they use. If I tell CIGI "I use a power wheelchair," that is context, not permission to invent a list of things I must need. If I say "I need a step-free entrance," that's an explicit requirement the agent can actually use.

Human + agent collaboration

This is the part that became much more interesting than I expected.

At first I was mostly thinking about WebMCP as a way for an AI agent to search CIGI more effectively. During testing, I realized it could also help close the loop between the information in CIGI and what someone actually finds when they get there.

For example, I tested asking an agent to find hotels in Rapid City where I specifically needed a step-free entrance and an accessible restroom. The agent searched CIGI, compared the available places, explained what the evidence supported, and also told me what was unknown or conflicting.

Then I tried taking it one step further.

I told the agent to imagine I had arrived at one of those hotels and discovered that its accessible entrance was blocked by a large planter. I asked it to prepare an accessibility update for me.

The agent opened CIGI's existing update form for that hotel, selected the affected step-free entrance category, prepared a conservative description of what I found, and then stopped before submitting it.

I was looking at the completed form and the Submit button. The final decision was still mine.

That test ended up demonstrating the whole idea better than I had originally planned. CIGI helped someone make a decision based on accessibility information, and when they discovered something had changed in the real world, the same agent could help bring that information back to CIGI for the next person.

How I built it

CIGI is built with Next.js, React, TypeScript, Supabase/PostgreSQL, MapLibre, Google Places, Tailwind CSS, and OpenAI technology, and it's deployed on Vercel.

For the challenge, I added the WebMCP layer to the existing application along with dedicated API routes for searching places, retrieving accessibility details, comparing places, and preparing contributions.

I also added automated tests for the new WebMCP functionality and the accessibility matching logic.

I used Codex extensively during the challenge to work through the existing codebase, implement and test the WebMCP integration, debug problems, and iterate on the tool definitions.

Challenges I ran into

The biggest challenge wasn't getting an agent to call a function. It was figuring out what I was comfortable letting the agent conclude from the data.

Accessibility is extremely individual. Two people who both use wheelchairs might have completely different requirements. A place can also be accessible in one way and completely inaccessible in another.

So I made the WebMCP implementation intentionally conservative. Explicit requirements can be matched. Unknown information stays unknown. Conflicting evidence stays visible. The agent isn't supposed to manufacture certainty just because the user asked it for a recommendation.

I also learned that exposing the right tools doesn't guarantee an agent will use them the way you expected.

In one of my first live comparison tests, the agent called the single-place details tool twice and did the comparison itself instead of using the comparison tool I had specifically built for that job. I changed the descriptions of the WebMCP tools to make their intended roles clearer and tested it again in a fresh context. This time the agent correctly chose CIGI's comparison tool.

That was a pretty cool moment because I wasn't programming a fixed sequence of API calls. I was designing capabilities that an agent could understand and decide when to use.

What I learned

Before this challenge, I had heard of WebMCP but hadn't really explored it. Initially I thought of it as a better way for an AI to interact with a website.

Building this changed how I think about it.

The interesting part to me is that CIGI can tell an agent what the site actually knows and can do, along with the boundaries around those capabilities. The agent doesn't have to scrape text, guess what an icon means, or figure out how to operate the interface from scratch.

For accessibility data in particular, those boundaries matter just as much as the capabilities.

The agent can help someone search, understand, compare, and even prepare new information, but when that new information could affect what another person believes about a real-world place, a human stays in control of submitting it.

What's next

The WebMCP integration is still focused on a small set of capabilities, but there's a lot of room to build on it.

I'd like to improve how evidence is grounded to individual photos, expand the accessibility information CIGI can collect, better represent temporary barriers and changing conditions, and eventually bring CIGI to more cities.

The long-term goal hasn't changed: I want someone to be able to know whether they can get in before they go.

WebMCP just gave CIGI a new way to help answer that question.

Built With

Share this project:

Updates

Submission history