u/tomerlrn

I’m testing a niche travel discovery product and wanted to share the thinking behind it, since I’m trying to figure out whether the pain point is real or if the niche is too focused.

The idea started last year when some friends were visiting Greece and wanted to find good beaches.

Their discovery process was basically:

• search “beaches” on TikTok
• open Google Maps
• click through random travel guides
• ask locals if they happened to know the area

That generally works, especially for the popular beaches, but it breaks down when you have a specific situation in mind.

For example, people do not always want “best beaches in Greece.”

They want things like:

• sandy beach in Corfu with parking nearby
• calm water near Naxos with a taverna
• quiet beach in Crete with shade
• family-friendly beach that is not packed in August
• beautiful beach that does not require a 4x4

I realized there was a gap between generic travel content and actual intent-based discovery.

So I started cataloguing beaches with practical details like sand vs pebbles, shade, parking, tavernas, water conditions, crowds, access difficulty, photos, and map location. Then I built a natural-language search layer on top so people can search by what they actually want instead of browsing generic blogs.

I also added some guide-style content for SEO, but the main thing I’m testing is whether a very narrow search experience can beat generic content for a specific travel use case.

Current status:

• free product
• no signup
• around 500 views per week
• started ranking on Google even though I initially made it last September, but just last month I discovered a huge bug so it got wrongly crawled and never ranked
• mostly trying to understand if people find this useful enough to come back or share it

The questions I’m thinking through now:

1. Is this too niche, or is the niche the reason it might work?
2. What would you test first for monetization?
3. What metric would you care about most at this stage: traffic, repeat usage, email capture, search volume, affiliate intent, or something else?
4. How would you approach distribution beyond SEO, Reddit, and basic social posting?

After planning a lot of beach days in Greece, I realized that “best beaches” lists are often not very useful.

They usually optimize for popularity, but not for the things that actually decide whether the day is good:

• Is the water calm or windy?
• Is it sandy or pebbly?
• Is there natural shade?
• Can you park nearby?
• Is it packed in July/August?
• Is there a taverna nearby?
• Is it good for kids?
• Is it easy to reach without a 4x4?

My personal rule now is to search by situation, not by ranking.

For example:

• With kids: calm water, sand, easy parking, some shade
• As a couple: smaller cove, nice water, maybe harder access
• In August: avoid the famous “top 10” beaches unless going very early
• Windy day: look for beaches protected from the current wind direction
• Full-day beach: taverna, shade, parking, toilets matter more than photos

How do you choose beaches in Greece? Do you mostly rely on Google Maps, local recommendations, blogs, or just drive around and explore?

After planning tons of beach days in Greece, I realized that “best beaches” lists are often not very useful.

They usually optimize for popularity, but not for the things that actually decide whether the day is good:

• Is the water calm or windy?
• Is it sandy or pebbly?
• Is there natural shade?
• Is there ample parking?
• Is it packed in July/August?
• Is there a taverna nearby?
• Is it good for kids?
• Is it easy to reach without a jeep?

My personal rule now is to search by situation, not by ranking.

Some examples:

• With kids: calm water, sand, easy parking, some shade
• As a couple: smaller cove, nice water, maybe harder access
• In August: avoid the famous “top 10” beaches unless going very early
• Windy day: look for beaches protected from the current wind direction
• Full-day beach: taverna, shade, parking, toilets matter more than photos

How do you choose which beach to spend your beach days in Greece? Do you mostly rely on Google Maps, local recommendations, blogs, or just drive around and explore?

My co-founder and I have spent weeks building Bridge. A platform that converts REST APIs into MCP tools automatically. Parse an OpenAPI spec, get MCP tools, agents call them.

The 1:1 endpoint to tool mapping created bloat. 200 endpoints = 200 tools = the agents pick the wrong one half the time.

The obvious fix: group related endpoints under one tool with an action field. Clean. Agent sees 20 tools instead of 200.

Here's the trap, let's say you take a customers resource. If you shove every customer-related endpoint under one tool, you get 15+ actions: find, search, create, update, delete, list_orders, list_invoices, merge, archive, export, import, add_note, assign_agent, send_email, etc.

You just moved the problem one level deeper. The agent is now scanning a giant action enum instead of a giant tool list. Same confusion, different shelf.

We've been building an OpenAPI to MCP gateway and hit this immediately.

Our solution: cap at 8 actions per grouped tool. If a resource has more than 8 operations, the optimizer has to split it into meaningful sub-groups like customers, customer_billing, customer_engagement, customer_admin, etc.

Without this, everything gets dumped into the biggest bucket. With it, the LLM is forced to name sub-groups by what they actually do. customer_billing is a better tool name than customers with 8 unrelated billing actions crammed inside.

We're calling this the "fan-out problem" and we're building the cap into our optimizer.

Curious if anyone else has hit this, if so, what's your rule for how many actions is too many under one tool?

After spending the last couple months building production MCP infrastructure, here are the decisions that mattered most and the ones I'd do differently.

1. OpenAPI → MCP conversion is the easy part. Auth is the hard part.

Auto-generating MCP manifests from OpenAPI specs is straightforward — map paths to tools, extract schemas, done. The real complexity is auth. OAuth 2.1 + RFC 9728 (PRM) + PKCE is ~4 specs you need to get right before one tool call works. If you're building multiple MCP servers, do NOT implement OAuth in each one. Centralize it.

2. Credential injection is the right pattern.

Never let the MCP client see the upstream API key. Issue each end user their own OAuth client_id/client_secret. The dispatch layer validates the OAuth token, looks up the user's encrypted credential, decrypts it, and injects it into the upstream request. The MCP server is a dumb proxy — it receives identity headers and forwards to the API.

Benefits: per-user revocation (invalidate their OAuth tokens, done), per-user rate limiting, audit trail of who called what, credential rotation without touching client configs.

3. Authorization at the dispatch layer, not the MCP server.

OAuth gets you authentication ("who is this?"). Authorization ("can they call this tool?") is entirely custom. The cleanest approach: check permissions at the dispatch layer before the request reaches the MCP server. One place to enforce policy, consistent across all your MCPs.

4. STDIO is dev-only. Streamable HTTP for anything multi-user.

STDIO is single-client by design. Under concurrent load it falls apart. The spec moving to Streamable HTTP was the right call. Stateless, standard HTTP, no SSE complexity.

5. Context window is the hidden cost.

A 1:1 OpenAPI→MCP mapping gives you 30+ tools from a typical REST API. That's thousands of tokens of tool schemas in every context window. Solution: dynamic tool filtering — only expose the tools the user actually needs, not all of them. Cuts schema waste by 60-70%.

Things I'd do differently:

• Don't bother with DCR (Dynamic Client Registration). Pre-register clients. Much simpler, fewer moving parts.
• Start with a single D1/KV setup for all MCPs. Don't over-shard early.
• Log every OAuth handshake step from day one. Debugging "invalid_grant" with no context is miserable.

Happy to dive deeper on any of these. Curious what others have landed on for multi-tenant auth and tool-level authorization.