I upgraded my AI concierge by turning it to a plain search box

Tomer Liran — Mon, 29 Jun 2026 09:10:19 +0000

I wanted Beaches of Greece to be an AI concierge. You would describe your perfect beach day in plain language, and it would just understand you.

Under the hood that meant a proper NLP stack: wink-nlp for entities, compromise for parsing, a sentiment analyzer, fuzzy matching for place names. It felt smart.

It mostly produced confident nonsense. So I deleted it and shipped a plain search box, and search got faster, smaller, and genuinely better. Here is what went wrong.

The "smart" version wasn't

The failures were not subtle:

It scanned keywords as substrings, so "shade" matched inside "shaded", and "bar" (as in beach bar) matched inside "sandbar".
Place lookup did places.find(p => query.includes(p)), so "ios" inside "agios nikolaos" resolved to the island of Ios. Wrong island, zero results.
"near heraklion" returned nothing. It made Heraklion (a city) a location filter, but beaches are filed under their island, Crete, so the filter could never match.
Sentiment analysis scored "I hate crowds but love calm water" as mixed polarity. A fun trick that never changed which beaches to show.

Every time, the stack performed the look of understanding, then did something a human never would. And when it was wrong, I had to debug a model's guess.

Nobody writes paragraphs into a search box

They list wants: calm, sandy, shade, parking, near somewhere. The vocabulary is small and knowable, so I matched against it literally, on whole-word boundaries:

function hasPhrase(q: string, phrase: string): boolean {
  // matches "bar" but not "sandbar"
  return new RegExp(`(?:^|[^a-z0-9])${escapeRegExp(phrase)}(?:[^a-z0-9]|$)`).test(q);
}

That single boundary check erased the whole "bar inside sandbar" class of bug. The rest of the vocabulary is just data: lists of phrases mapped to filter values.

Boring matching also forces decisions the NLP layer used to hide. "quiet" now means few people, not flat water. "no parking" is checked before "parking" so it wins outright. Each one is a product call sitting in plain sight instead of inside a model.

Place names get the same treatment: whole-word, longest match, and every name resolves to an area that beaches actually live in, so "heraklion" maps to Crete instead of nuking the results. The one bit of fuzziness I kept is a tight typo fallback. And because each town carries a coordinate, "near heraklion" can now rank by real distance, which the AI version never managed.

What I gained, and gave up

Gained: predictable and debuggable (a wrong result is a phrase to fix, not a model to retrain), faster, a smaller bundle, and honest. It does what a human would do with those words, no theater.

Gave up: novel phrasing. Someone on Reddit instantly tried a mixed Greek-and-English query and it caught only half. Fair trade for this domain.

The takeaway

"Add AI" is not free. It costs latency, bundle size, and worst of all legibility: when the clever thing is wrong, you cannot tell why. For a bounded problem with a knowable vocabulary, a search box that makes no claim to intelligence can be the smarter build.

It is live at beachesofgreece.com. Throw a weird query at it and tell me what breaks.

Add an MCP server to your SaaS in 10 minutes (free, no credit card)

Tomer Liran — Tue, 12 May 2026 15:41:50 +0000

Originally published on bridge.ls/blog

70% of large SaaS brands now ship a remote MCP server.. The other 30% are about to find out what happens when their competitors become agent-callable and they don't.

If you're a SaaS founder or CTO who has been putting off MCP because the build looks expensive — multi-tenant auth, transport, hosting, credential management, the whole stack — this post is for you. We're going to take your existing OpenAPI spec and turn it into a live, hosted, agent-callable MCP server in about 10 minutes. Free tier. No credit card. No protocol code.

Why ship one now

The case for MCP keeps getting harder to argue against. Anthropic, OpenAI, Google, and Microsoft all natively support it. Over 10,000 MCP servers existed by early 2026.. ChatGPT, Claude, Cursor, and every serious agent runtime can connect to a remote MCP endpoint with two clicks.

For SaaS companies, the framing is competitive: the first product in each category that ships an agent surface owns the agent traffic. Your users' agents are already trying to interact with your product — they're just doing it badly, through brittle browser automation or hand-rolled API wrappers. An MCP server replaces all of that with a clean, structured surface.

The blocker has never been "should we?" It's been "what does this cost to build and maintain?"

What you'd have to build yourself

We covered the full picture in What I Learned Building a Managed MCP Infrastructure Layer, but here's the short version of what stands between an OpenAPI spec and a production MCP server:

Multi-tenant auth that scopes each call to the right customer
Credential management for upstream API tokens (per-tenant, rotatable, never in logs)
Streamable HTTP transport that survives load balancers and restarts
Session handling, retries, rate limit translation
Tool generation from your spec, with sensible defaults for what to expose and what to hide (you do not want DELETE endpoints agent-callable by default — see The Fan-Out Problem for why tool surface design matters)
Hosting, monitoring, audit logs

Industry estimates put a custom build at $25k–$120k and 8–12 weeks, with annual maintenance adding 20–30% on top.. That's before you've shipped a single feature.

Bridge does all of this from your existing OpenAPI spec. Here's what that looks like.

The 10-minute walkthrough

Step 1 — Create your Bridge account

Head to app.bridge.ls. Name, organization, email. No password — you'll get a six-digit code. Free tier, no credit card.

Step 2 — Publish your MCP

From the dashboard, drop your OpenAPI spec or MCP manifest into the publish flow. Bridge parses the spec and turns each operation into a tool.

In this example we uploaded an OpenAPI spec with 159 operations. Bridge automatically:

Generated 141 tools (DELETE endpoints are hidden by default — expose them only if you want agents performing destructive actions)
Detected the auth method (Bearer token)
Pulled the base URL
Flagged that 159 operations is past the point where flat tool surfaces start hurting agent accuracy, and offered Smart Discovery to collapse the surface (more on tool-count tradeoffs in the fan-out post)

Step 3 — Reserve your slug and go live

Pick a public URL slug, confirm the summary, click Go live.

Step 4 — You're live

That's the MCP server up. Endpoint ready. 141 tools exposed. Agents can call it right now.

But the server isn't useful yet without an end user. Which brings us to the part most MCP tutorials skip entirely.

Step 5 — Create an end user

This is where Bridge does the work that takes weeks to build yourself: multi-tenant auth.

Click "New end user." Bridge will issue an OAuth Client ID + Secret bound to this specific end user, plus collect the upstream Bearer token your API expects for that customer.

Behind the scenes: Bridge stores the upstream token securely, the OAuth credentials it just issued are the credentials the agent uses, and every agent call gets translated to an authenticated call to your API as the right tenant. The token never touches the agent.

After creating the end user, Bridge shows you the three values to send to that customer over a secure channel: MCP URL, OAuth Client ID, OAuth Client Secret. Client Secret is shown once. Copy now.

Step 6 — Connect from Claude Desktop

This is what your customer does. In Claude Desktop, Settings → Connectors → Add custom connector.

Paste the MCP URL, expand Advanced settings, paste Client ID and Client Secret. Click Add.

The browser flashes briefly. The connector is ready.

Step 7 — Use it

Open a new Claude chat. Ask it what tools it can use.

141 tools, scoped to that end user, authenticated, hosted, ready. Total time from signing up to a working agent call: about 10 minutes.

What's in the free tier

Free, forever:

1 hosted MCP server
Auto-generated tools from your OpenAPI spec
Multi-tenant auth (the whole OAuth + upstream credential dance shown above)
Up to 3 connected customers
1,000 tool calls per month
Community support

No credit card. The free tier exists because we want SaaS companies to ship their first agent surface without procurement friction. Once you outgrow 3 customers or 1k calls, paid tiers exist — but if you're testing the agent-callable thesis on your product, free covers it.

What's next

The 2026 MCP roadmap is moving fast: stateless transport, Server Cards for .well-known discovery, enterprise auth patterns. Bridge handles all of these as the spec evolves — your MCP server gets the upgrades without you redeploying.

If you want to read more on the engineering thinking behind Bridge, the infrastructure lessons post covers the architectural decisions, and the fan-out problem covers tool surface design.

Otherwise — start at app.bridge.ls. Your first MCP is 10 minutes away.

This post was originally published on bridge.ls/blog. If you have feedback or questions, happy to discuss in the comments here or reach out at bridge.ls.

DEV Community: Tomer Liran