Log events with Claude or Gemini via MCP
- In this guide
- 1.Understand what the MCP connection is
- 2.Connect your assistant and sign in with OAuth
- 3.Choose which kids and scopes to grant
- 4.Ask about your baby with the read tools
- 5.Log an event with log_event
lindly speaks the Model Context Protocol (MCP), the open standard AI assistants use to connect to real tools and data. That means you can point an MCP-capable assistant — Claude, Gemini, or any other — at your Home and ask it things like “how much did she eat today?” or tell it “log that he just had a wet diaper.” You stay in control of exactly what it can see and do.
Available at launch. The MCP endpoint (
mcp.lindly.app) goes live when lindly launches. This guide describes the real connection flow and the real tools so you know what to expect. As with any AI you connect, whichever provider you choose becomes a data processor acting on your behalf — the connection is entirely opt-in and scoped by you.
1. Understand what the MCP connection is
This is different from the public llms.txt file, which just lets an AI read about lindly. MCP is authenticated, live access to your Home’s actual data. It runs as its own service and uses standard OAuth, so a real client completes a proper sign-in — not a shared API key.
2. Connect your assistant and sign in with OAuth
In your assistant’s settings, add lindly’s MCP server URL (mcp.lindly.app). Because the server supports dynamic client registration and PKCE, your assistant onboards with no manual key setup: it discovers the sign-in endpoints automatically and walks you through an OAuth login. You authenticate as yourself — the same account you use in the app.
3. Choose which kids and scopes to grant
This is the important step, and it’s finer-grained than most OAuth you’ve seen. The consent screen lets you grant access per Home, per child, and per scope. You can, for example, let an assistant read everything about one child but write nothing, or read across all your kids while it can never log on your behalf. The access it’s given is exactly what you pick — nothing broader.
4. Ask about your baby with the read tools
Once connected, your assistant has a small set of read-only tools:
list_kids— the kids you can access, with names, birth dates and ages. Assistants start here to get the ID other tools need.get_kid_summary— the “how is she doing right now” answer for one child: last feed, last diaper, whether she’s asleep (and for how long) or awake, today’s counts, and how many reminders are active.list_recent_events— a child’s recent events, newest first, each tagged with its type.list_active_reminders— reminders that have fired and haven’t been dismissed, for one child or all of them.
Because these run as you, your assistant sees exactly what you’d see in the app — a caretaker’s assistant only sees that caretaker’s granted kids.
5. Log an event with log_event
There’s one write tool, log_event, which records a single event — a feed, diaper, sleep, activity, growth measurement, health entry, milestone or note — to your Home’s real log. It’s flagged as a write, so a well-behaved client will ask you to confirm before it runs; only call it when you actually mean to log something. Under the hood it goes through the exact same validation and per-child access checks as the app, and it’s idempotent, so a retry never creates a duplicate. The server stamps the entry to your identity — the assistant doesn’t get to say it was someone else.
That’s the whole surface: four ways to look, one careful way to log, and consent you hold. If you’d rather wire lindly into a smart-home setup than a chat assistant, see connecting lindly to your smart-home hub.