This week my ChatGPT plugin BeachFinder got approved and published. It lets ChatGPT answer questions like "warmest beach near Valencia right now?" or "compare three beaches near Miami for families" from live data — 184,900 real swim spots worldwide, with current sea temperature, waves, wind, UV and community reports.
Here is the architecture decision that made it worth writing about: the plugin is just a thin skin over a remote MCP server.
One backend, every assistant
The Model Context Protocol server lives at getbeachfinder.com/mcp (no auth, 12 read-only tools). The exact same endpoint serves:
- the ChatGPT plugin (published this week)
- Claude Desktop / Claude.ai connectors
- Cursor and any other MCP client
So every new "AI app store" that appears is mostly a metadata submission, not new code. If you are building anything data-backed for AI assistants in 2026, I would start with the MCP server and treat each assistant surface as a distribution channel.
What I learned in review
- Read-only tools sail through. Every tool is a search/read. No write, no auth, no user data. Review was smooth.
- Safety framing belongs in the tool descriptions. BeachFinder never declares a spot "safe to swim" — the tools say so explicitly, and defer to flags, lifeguards and local authorities. Reviewers notice.
- Example prompts are your listing's landing page. Ours map 1:1 to the strongest tools (conditions lookup, comparison, activity providers). Generic prompts waste the slot.
The data part
The hard work was never the plugin — it was the dataset: 184,900 deduplicated swim spots (OpenStreetMap + a long enrichment pipeline), live marine data via Open-Meteo, photos, community reports. The MCP layer is basically read-only RPC over that.
Try it: search "BeachFinder" in ChatGPT plugins, or point any MCP client at https://getbeachfinder.com/mcp (docs at getbeachfinder.com/tools). Feedback very welcome — solo developer, I will take all of it.
Top comments (0)