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!