Anythink

Anythink is a deep, all-in-one backend platform. A single project gives you: typed data modelling (22+ field types, relationships, polymorphic refs), row- and field-level security, full-text + semantic + geo search, RBAC (roles, permissions, API keys), a workflow/automation engine, third-party integrations (Claude, OpenAI, Slack, Google, GitHub…), file storage, and payments. Your job is to drive that platform competently — and the way you do almost everything is the MCP's cli tool.

The cli tool is the whole platform

The MCP exposes a few dedicated tools for auth and context — login / logout, config_show/use/remove, accounts_*, projects_*. Everything else is done through the generic `cli` tool, which runs any anythink command and returns its output: entities, fields, data, search, workflows, roles, users, api-keys, files, integrations, pay, oauth, menus, secrets, migrate, api, docs.

• Pass the command exactly as you'd type it after anythink — e.g. the cli

tool with entities list, or data create posts --data '{"title":"Hi"}'.

• Don't include anythink itself or --profile (the active profile is

injected for you).

• The CLI can do everything the Anythink API can do, so the cli tool can too.

If you're reaching for some other mechanism to talk to Anythink, you're almost certainly meant to use cli instead.

(On the CLI directly, these are the same commands without the tool wrapper: anythink entities list, etc. See references/setup.md.)

Discover the live surface — don't guess

The platform is broad and evolves, and it documents itself. Before composing non-trivial commands, read the live reference instead of guessing flags:

• cli → `docs --json` — the full, authoritative command + capability

reference, built for AI tooling. (docs for markdown.)

• cli → `<group> --help` — exact flags for a command, e.g.

entities --help, fields add --help, search query --help.

• cli → `api --json` — every REST endpoint.

This is cheaper than a wrong guess, and the real surface is richer than any list you'll have memorised. When unsure, ask the CLI.

Mental model — work in this order

Most confusion comes from skipping a level. The spine is:

account (billing) → project → entities (tables) → fields → data
                                  ↘ access: roles · permissions · RLS · api-keys
                                  ↘ features: search · workflows · integrations · files · pay

1. Authenticate & select context — login, then accounts_use and

projects_use. Confirm with config_show. Nearly every command acts on the active project, so this step is load-bearing — verify it before building.

1. Model the schema — entities, then their fields (and relationships),

before touching data.

1. Put data in — create/query records once the schema exists.
2. Set up access — roles, permissions, RLS, api-keys. (Skipping this causes

403s — see below.)

1. Layer features — search, workflows, integrations, files, payments.

Core workflows

Model data

cli: entities create posts --rls          # flags: --rls --public --lock --junction
cli: fields add posts title --type varchar --required
cli: fields add posts published --type boolean
cli: entities get posts                    # verify

Field types, relationships, and entity flags are deeper than this — see references/data-modeling.md. Design an entity's fields up front; it's cheaper than discovering them record by record.

Work with records

cli: data create posts --data '{"title":"Hello","published":true}'
cli: data list posts --limit 20 --json
cli: data update posts 42 --data '{"published":false}'

Search (full-text, semantic, geo)

cli: search query "hello" --filter "published=true" --sort "created_at:desc"
cli: search similar posts 42               # semantic / vector similarity
cli: search query "*" --filter "_geoRadius(51.5074,-0.1278,5000)"

Access control — do this, or you get 403s

Permissions are named {entity}:{action} (e.g. posts:read, posts:create). When you create an entity or a user, grant the relevant role the matching permissions — missing permissions cause 403 errors at runtime. API keys carry their own permission set. Full detail (roles, RLS, field access, key handling) in references/access-control.md.

Automate (workflows + integrations)

cli: workflows create daily-sync --trigger Timed --cron "0 6 * * *"
cli: integrations connect claude --name main
cli: integrations execute claude generate-text --input "prompt=Write a haiku"

Workflows are event/timed/manual/api-triggered, multi-step, and can call data ops, HTTP, scripts, email, push, and integrations. Explore with cli: workflows --help and cli: integrations --help.

Move between environments

cli: migrate --from my-app-staging --to my-app-prod --dry-run

Conventions that matter

• Permissions or 403. Always configure role permissions when creating

entities or users. This is the single most common cause of "it doesn't work".

• Destructive commands need `--yes` (delete, revoke, purge, rehydrate) to

skip the confirmation prompt — and they're not reversible by you, so surface what will happen first.

• Add `--json` where supported when you need to parse output.
• The profile is injected — never pass --profile through the MCP.
• Keep secrets out of the transcript. api-keys create prints the key to

stderr — let the user capture it; never echo keys/tokens. Use the secrets command group for workflow credentials.

• Confirm the active project (config_show) before schema or destructive

work — a wrong active project is the easiest way to make a mess.

When stuck

• "No active project" / wrong data → projects_use. Auth errors → login, or

config_show to check / config_use to switch the profile.

• Unknown command or flag → cli: <group> --help, or cli: docs.
• Full command map: references/commands.md · data

modelling: references/data-modeling.md · access: references/access-control.md · install/connect: references/setup.md.