Dayplay
Official# Dayplay MCP — Verified Real-Time Physical Intelligence for Major Metros Nationwide
**Dayplay MCP** · v2.2.2 · MIT
Dayplay gives AI agents verified real-time physical intelligence — places, events, and walkable itineraries — across **major metros nationwide**. The **SF Bay Area is our flagship live market**, with **additional major metros rolling out next**.
[](https://apify.com/dayplay/dayplay-local-intelligence)
[](https://smithery.ai/servers/dayplayai/dayplay)
[](https://glama.ai/mcp/servers/dayplayTeam/dayplay-mcp)
[](https://mcpservers.org/servers/dayplayteam/dayplay-mcp)
A zero-configuration MCP server that gives any AI agent a *locally grounded* concierge across **major metros nationwide** — curated places, verified real-time events, and neighborhood binding that eliminates cross-metro and cross-bay drift. The **SF Bay Area is the flagship live market**, with **additional major metros rolling out next**.
> 🔒 **Coverage: nationwide posture, verified per request.** Dayplay covers **major metros nationwide**, with the **SF Bay Area as the flagship live market** (San Francisco, Oakland, and Berkeley — 35 neighborhood centroids) and **additional major metros rolling out next**. Live inventory is **not** uniform across every metro yet, so the rule is simple: **call the coverage tools first and trust what they return.** If a location comes back as not-yet-live or out of market, the agent must say so plainly — *"Dayplay doesn't have live coverage for \<location\> yet"* — and must **not** fabricate venues, events, dates, hours, or neighborhoods for it. Zero results for a covered query are reported honestly, never filled with invented places. This per-request check is what keeps the nationwide posture truthful.
**Remote endpoint:** `https://api.dayplay.io/mcp` (Streamable HTTP / MCP)
---
## Quickstart
### Cursor
**Option A — direct remote server (recommended, no install).** Add to `~/.cursor/mcp.json` or this repo's `.cursor/mcp.json`:
```json
{
"mcpServers": {
"dayplay": {
"url": "https://api.dayplay.io/mcp"
}
}
}
```
**Option B — run from source (local stdio bridge for stdio-only clients):**
```bash
git clone https://github.com/dayplayTeam/dayplay-mcp.git
cd dayplay-mcp
npm install
node bin/dayplay-mcp.js
```
Then point your client at the local stdio process:
```json
{
"mcpServers": {
"dayplay": {
"command": "node",
"args": ["/path/to/dayplay-mcp/bin/dayplay-mcp.js"]
}
}
}
```
### Claude Desktop
Edit `claude_desktop_config.json`:
- macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`
- Windows: `%APPDATA%\Claude\claude_desktop_config.json`
**Option A — direct remote server (recommended):**
```json
{
"mcpServers": {
"dayplay": {
"url": "https://api.dayplay.io/mcp"
}
}
}
```
**Option B — run from source (stdio-only clients):** follow the [run-from-source setup](#option-b--run-from-source-local-stdio-bridge-for-stdio-only-clients) under Cursor, then register the local stdio process:
```json
{
"mcpServers": {
"dayplay": {
"command": "node",
"args": ["/path/to/dayplay-mcp/bin/dayplay-mcp.js"]
}
}
}
```
Restart Claude Desktop, then ask: *"What's happening in the Mission tonight?"*
### Grok Bot
Add the Dayplay remote connector:
```
https://api.dayplay.io/mcp
```
Prefer the direct remote connector above. For a stdio-only setup, run from source and bridge the local process in Grok's MCP config:
```json
{
"mcpServers": {
"dayplay": {
"command": "node",
"args": ["/path/to/dayplay-mcp/bin/dayplay-mcp.js"]
}
}
}
```
Pair it with the [`vibe-scout` skill](skills/vibe-scout/SKILL.md) for prompt-level scope enforcement.
### Terminal smoke test
```bash
node bin/dayplay-mcp.js --smoke
```
Run it from a [run-from-source](#option-b--run-from-source-local-stdio-bridge-for-stdio-only-clients) checkout. Prints the live endpoint and available tool names. Exits non-zero on failure.
---
## Tools
The catalog spans **major metros nationwide**, with the SF Bay Area as the flagship live market (San Francisco, Oakland, Berkeley — 35 centroids) and additional major metros rolling out next. Coverage is verified per request: a metro that isn't live yet is declined honestly, never fabricated.
**Open tools** run immediately — no account needed. **Gated tools** return `401` on first call. Every connection path — the remote URL and the local stdio bridge — serves this same 40-tool catalog, and a host connected through either path opens Google sign-in for gated tools.
### Discovery (open)
- `get_happening_today` — events + places happening today, by location and radius
- `get_live_now` — what is happening right now
- `get_weekend` — Saturday/Sunday feed (`weekend_day: "sat" | "sun"`)
- `get_decision_feed` — ranked decision feed (send `user_lat` / `user_lng`)
- `browse_places` — places inside a radius, sorted by distance
- `get_listing` — full detail for one place or venue by `id`
- `get_top_restaurants` / `get_top_venues` — ranked lists, optional city
- `get_local_gems` — curated local gems
- `get_locals_favorites` — locals' favorites
- `get_venue_events` — upcoming events at one venue (`id`)
- `get_subcategories` / `get_genres` / `get_event_bridge` — taxonomy feeds
### Marketing feeds (open, X-API-Key)
- `get_marketing_events` / `get_marketing_places` / `get_marketing_neighborhoods` — catalog feeds; forward an `X-API-Key` header. `get_marketing_neighborhoods` returns the **live-market neighborhood centroids with coordinates and radii** (currently the 35 SF Bay Area hubs; new metros appear here as they go live).
### Search 🔒 *free account*
- `search_smart`, `search_query_router`, `search_embed`, `search_parse_intent`, `search_rerank`, `search_web` — model-backed semantic search. Requires the user token via Google connect.
### Saves & Outings 🔒 *free account*
- `save_outing` — save a dated, neighborhood-bound outing plan to the signed-in user's Saved tab
- `get_my_itinerary` — retrieve the signed-in user's saved itineraries
- `list_saves`, `save_listing`, `unsave_listing`, `list_going`, `mark_going`, `unmark_going`, `get_profile` — saved places, event RSVPs, and the signed-in profile
- `upvote_listing`, `share_local_favorite`, `share_gem` — community signals
Requires the free-account connect. A host connected to the remote URL opens Google sign-in on the first gated call; the stdio bridge opened from a run-from-source checkout opens a browser for the same connect step. Saved plans appear on the Dayplay Saved tab across web and app.
Requires the free-account connect (`https://www.dayplay.io/link`). Saved plans appear on the Dayplay Saved tab across web and app.
Example prompts: *"What's happening in the Mission tonight?"* · *"Build me a Saturday itinerary that never leaves Bernal Heights."* · *"Save this outing to my Dayplay account."*
### Legacy compatibility
The original five names are part of the 40-tool catalog: `get_neighborhoods`, `get_events`, and `get_places` are open. `plan_outing` and `manage_saved_plans` need Google connect. `plan_outing` applies a comma-separated `interests` value as the catalog category filter.
## The Anti-Drift Guarantee
Most local AI answers fail the same way: a "Mission" recommendation lands in Oakland, a "Berkeley" event is actually in San Jose, and a walking itinerary silently requires a bridge crossing.
**Scope:** major metros nationwide, with the SF Bay Area as the flagship live market and additional major metros rolling out next. Live coverage is verified per request — the guarantee is that Dayplay never answers for a place it hasn't verified, not that every metro is live on day one.
**Dayplay receipts:**
- **Spatially verified.** Every place and event result is validated against neighborhood centroid coordinates and radii pulled live from `get_neighborhoods` (currently 35 SF Bay Area hubs; the same check applies to each metro as it comes online).
- **Neighborhood-bound queries.** `neighborhood` is an exact-match binding parameter, not a fuzzy keyword hint — results outside the bound radius are dropped, not ranked down.
- **Zero cross-metro drift.** No Oakland result in a San Francisco query. No Brooklyn result in a Manhattan query. No bridge, tunnel, or cross-river hop presented as a walkable leg.
- **Real-time, not stale.** `get_events` queries verified occurrences by `date`, so "tonight" means tonight — not an SEO page from last season.
- **Out-of-market refusal.** A market that isn't live yet is refused before any upstream call, and the surfaced copy states the coverage boundary rather than returning plausible-but-wrong geography. As new metros go live, the same guard extends to them automatically.
- **Honest emptiness.** If a bounded query has no verified matches, it returns nothing rather than padding with invented places.
That is the product: the answer stays where you are.
---
## Configuration
| Env var | Default | Purpose |
| --- | --- | --- |
| `DAYPLAY_MCP_URL` | `https://api.dayplay.io/mcp` | Override the remote endpoint (staging, self-hosted, local dev) |
No API key is required for the public endpoint. Optional auth tokens, if your deployment needs them, are passed through as standard `Authorization` headers by the MCP client — never commit them to config files.
---
## How the proxy works
```
MCP client (stdio) ⇄ bin/dayplay-mcp.js ⇄ https://api.dayplay.io/mcp (Streamable HTTP)
```
The shim lists tools and forwards `tools/call` verbatim to the remote endpoint, so new Dayplay tools appear automatically without waiting on a local update. It is a transport bridge, not a reimplementation — every schema, filter, and verification rule is served by Dayplay itself.
Prefer direct HTTP if your client supports it; use the shim for stdio-only clients.
---
## Repository layout
```
dayplay-mcp/
├── .cursor/
│ └── mcp.json # Direct Cursor MCP connection
├── .cursor-plugin/
│ └── plugin.json # Cursor Marketplace catalog plugin manifest
├── skills/
│ └── vibe-scout/
│ └── SKILL.md # Grok Bot & Cursor Agent prompt instructions
├── bin/
│ └── dayplay-mcp.js # Run-from-source stdio proxy
├── assets/
│ └── logo.svg
├── test/
│ └── e2e.mjs
├── smithery.yaml # Smithery.ai registry manifest
├── plugin.json # Agent Plugins standard manifest
├── package.json # Node metadata (v2.2.2, MIT)
├── README.md # This file
└── LICENSE # MIT (Dayplay Team)
```
---
## Development
```bash
node bin/dayplay-mcp.js --smoke # verify remote endpoint + tool discovery
node bin/dayplay-mcp.js # run the stdio proxy
node test/e2e.mjs # end-to-end stdio smoke (tools + 3 tool calls)
```
Run from a run-from-source checkout (`git clone` + `npm install`).
---
## License
MIT © Dayplay Team — https://www.dayplay.io
TDQS
Scored across 3 tools
Each tool targets a distinct resource type: neighborhoods, events, and places. Though get_events and get_places share geographic constraints and filtering by neighborhood, their domain nouns are unambiguous and the descriptions clearly separate them.
All three tools follow the same get_<plural-noun> naming convention. This is a consistent, predictable pattern with no mixed styles or vague verbs.
Three tools is well-scoped for a read-only local discovery service, with each tool covering one core data type. No tool is redundant, and additional tools would likely be unnecessary.
The server provides neighborhood lookup plus event and place discovery, which covers the core read-only domain. Minor gaps exist, such as no explicit category enumeration or individual detail-fetch tool, but filtered queries should handle most typical requests.