Show HN: Statey – the database your AI shares across every chat, over MCP

Hey all - Scott here,

I was a heavy Linear user until I noticed I hadn't opened the UI in days. I was just asking Claude to pull up the tickets I cared about and draw whatever view I needed in the moment. At some point it clicked that I didn't need Linear, I needed the database underneath it. Then I realized it was the same for Confluence, Jira, and Pipedrive. But I didn't want to stand up Postgres and babysit schemas and migrations to get structured, collaborative data into Claude. I just wanted structured storage I could talk to and that followed me from Claude Desktop to Claude Code to Codex to ChatGPT. I wonder if you do to?

That's what Statey is: a database with no UI, used entirely through MCP tools. You don't design a schema up front. You just tell your LLM what you want to store and Statey creates the collection. If you change your mind later it versions the schema and handles the migration invisibly (additive changes apply immediately, breaking ones ask first and return a diff). All you concern yourself with is getting work done and improving your methods.

Also, while I was in there I built out agent key management, multi-user, full attribution and activity logs so we can always trace who changed what and why. What I haven’t built yet is the reactive part, triggers that fire an agent when data changes. I can find about 100 uses for it, so that’s coming soon.

One thing I'm genuinely unsure about and would also like feedback on is the security model. It's a store any connected MCP client can write to, so prompt injection and over-broad agent access might be concerns. Attribution and the event log let you see what an agent did after the fact, but the issue has already happened. If you've thought about this for agent-writable data, tell me where I'm wrong.

To try it: mcp add mcp.statey.ai in Claude, Claude Code, or Cursor, or get the connect steps at statey.ai. Happy to answer anything!

Thanks hackers!

▲

evilstar 2 hours ago | parent [-]

How are you thinking about preventative controls before a write happens, such as per-client scopes or approval gates for schema changes and reactive triggers?

	▲	scottwillman an hour ago \| parent [-]
		So far I've been attribution/after the fact heavy, but I have the groundwork for some real controls. I'll kinda break it into chunks: No Multi-tenancy: Each workspace is a dedicated database to there's no opportunity for crosstalk. Least-privilege Scopes: Agent access is already provided via agent keys. They are currently scoped to a particular set of collections, but that could be increased down to the operation and field level. This could be hairy to maintain though as schemas evolve. Rate limiting: Per-key rate limits and bulk caps prevent runaway loops or a compromised agent from crushing 10k records in one go. Reversibility: DB snapshotting and soft deletion are already happening. Powerful operation gating: This is probably what you're thinking about the most. Schema changes, bulk deletes, and/or permission changes should optionally have a human approval gate (on by default?). Thanks for thinking about this, would love to know if you've taken it for a test drive and your thoughts!