Statey

Docs

Setup guide & tool reference.

Connect Statey to your agent in under a minute, then ask it anything. This page walks you through the connection, your first session, and the complete tool surface.

What is Statey

Statey is a database your AI uses on your behalf. Connect it once (it's an MCP server, like any other connector) and every chat gains a permanent place to put work: tell Claude "track this bug" and it becomes a record in your tickets collection; ask Cursor next week "what's still open?" and it queries the same data. You never design a schema and never open an app. Describe what you want to track, and Statey builds the structure, validates every write, and logs who (you or an agent) changed what. One workspace, every client, persistent across sessions.

Connect

Statey speaks the MCP streamable-HTTP protocol. Add the endpoint below to any MCP-compatible client and you're done.

MCP endpoint

mcp addmcp.statey.aiCopied!(click to copy)

Claude (web or desktop)

1. Open Settings.
2. Go to the "Connectors" tab.
3. Click "Add custom connector".
4. Paste the endpoint URL and save.

The connector uses OAuth; you will be prompted to sign in on first use.

Claude Code

1. Run the command below in your terminal.

claude mcp add --transport http statey https://mcp.statey.ai/mcp

Copied!

Adds Statey to your local Claude Code config. The --transport http flag tells Claude Code to use the streamable-HTTP protocol.

Cursor, Windsurf, or any MCP client

1. Open your client's MCP settings (usually a JSON config file or a "MCP Servers" panel).
2. Add a new server entry with transport type set to streamable-HTTP (or "http") and the URL set to the endpoint above.
3. Save and reload the client.

If your client only supports SSE transport, use https://mcp.statey.ai/sse instead.

Sign in

The first time your agent calls a Statey tool, you will be prompted to authenticate via OAuth. Follow the link, sign in with your Google or GitHub account, and your workspace is provisioned automatically, with no extra setup required.

You can also visit console.statey.ai to view your workspace, manage your account, and check usage from a browser.

Quickstart

Here is what a first session looks like. You don't type any of this. Just describe what you want and the agent picks the right tools.

1See what's in your workspace

what's in my workspace?

get_workspace_overviewtool called

Returns your collections, record counts, and the calling agent's permissions. On a brand-new workspace, you'll see an empty list and two starter templates available.

2Create a collection

spin up a task tracker with title, status (todo / in-progress / done), priority, and assignee

create_collectiontool called

Statey generates a schema from your description, validates the field types, and returns a summary. The collection is ready immediately.

3Add some records

add three tasks: set up CI (high priority, todo), write the readme (medium, todo), deploy to staging (high, in-progress)

create_recordstool called

All three records land in a single all-or-nothing write. Each gets an id, a version counter, and an attribution entry in the activity log.

4Query your data

show me all high-priority tasks that aren't done yet

query_recordstool called

Returns a filtered, paginated result with a total count. You can group, sort, or filter by any field, all in plain language.

Tool reference

The complete tool surface for the current release, grouped by what they do. You don't call these directly; your agent selects the right one based on what you ask.

Getting your bearings

Two tools provide context: one lists what exists in the workspace, the other returns the schema for a single collection.

get_workspace_overview

Returns your collections, record counts, schema versions, active triggers, actors, and the calling agent's permissions.

Example requests

give me the lay of the land

describe_collection

The full schema for one collection: every field and its description, relations, sample records, and available indexes.

Example requests

what fields does Tasks have?

how are tickets structured?

Shaping your data

Create collections from a description, and evolve them over time. Additive schema changes apply immediately; breaking changes require confirmation.

create_collection

A new collection from a plain description or a starter template (Tasks or Tickets). Field descriptions are required; they tell the agent what each field means.

Example requests

spin up a ticket tracker

make a customers collection with name, plan, mrr

update_schema

Evolve a collection. Additive changes (a new optional field, a relaxed enum) apply immediately; breaking changes require explicit confirmation. Returns a diff.

Example requests

add a renewal date to customers

add an 'urgent' status option

Working with records

Create, read, query, update, and delete records. Writes are attributed and guarded by optimistic concurrency.

create_records

Insert 1–100 records at once, validated all-or-nothing so a bad row never lands half-written.

Example requests

new ticket: runner retry loop drops deliveries, high priority

import these 30 tasks

get_record

Fetch one record by id, optionally resolving one level of its relations (a linked task, a parent customer).

Example requests

pull up TIC-206

show that customer + the linked deal

query_records

Filter, sort, and paginate (up to 200 per page) with a total count. Grouping by a field returns per-group counts in a single call.

Example requests

open tickets grouped by assignee

what's in progress rn?

update_record

A partial update guarded by optimistic concurrency. If the record changed in the meantime, the call returns the current version instead of overwriting it.

Example requests

move TIC-206 to in progress

bump that ticket to high priority

delete_record

A soft delete. The record drops out of queries but is retained in the activity log.

Example requests

archive that ticket

drop the duplicate customer

Reacting to changes

Soon

Part of the phase-2 reactive loop. Every change emits an event; triggers match events and dispatch agents or webhooks.

create_trigger

Watch a collection for create, update, or delete events and dispatch an agent or webhook when they match a filter. Causation is tracked across cascades.

Example requests

when a ticket comes in, have triage-bot look at it

ping ops when inventory drops below 10

list_triggers · delete_trigger

See what automations are running and turn them off.

Example requests

what automations do i have?

turn off the triage trigger

get_queue_status

Per-agent backlog: pending count, the age of the oldest event, and whether the queue is paused.

Example requests

anything waiting on my agents?

is the queue backed up?

resume_queue

Resume a paused queue: replay each event in order, or reconcile the whole backlog against current state in a single pass.

Example requests

catch up on whatever piled up while the runner was down

Audit & usage

The activity log records what changed and why; usage reports consumption against your cap.

query_activity

Search the immutable log by collection, record, actor, action, or time range, and follow causation chains to see what triggered what.

Example requests

who touched this ticket and why?

what happened in tickets this week?

get_usage

Current-period consumption, spend, and remaining budget against your spend cap. Readable by agents as well as people.

Example requests

how much have i used this month?

how close am i to my cap?

Reference notes

This is the complete tool surface for the current release. All writes are attributed and recorded in the activity log. Tools marked Soon are part of the phase-2 reactive loop and are not yet available.