AI assistant recipes for your backend

Each recipe is a prompt you give an assistant that's connected to your project through a local anythink-mcp server. It shows what the assistant does, the commands it runs through the cli tool, and what comes back. To connect one, see Connect Claude to your backend with MCP. For every tool and argument, see MCP server tools reference.

The recipes share one example: a small support desk with a tickets entity. Try them in a test project first. The exact wording of a reply will differ from run to run, but the commands and results are what your assistant should produce.

Before you let an assistant write

An assistant acts with your permissions, and it can change or delete data as easily as it can read it.

• Connect with a scoped API key. A key holds only the permissions you gave it, so a key with :read permissions on the entities involved lets an assistant look at your data and not change it. Create keys in the dashboard or in a terminal, so the key never passes through the conversation. See API keys and Control access: roles, permissions and field-level security.
• Review every write. Most MCP clients show each tool call and ask before it runs. Read create, update and delete commands before you approve them. A delete can't be undone.
• Ask for a plan first. Add "show me the commands before you run them" to any prompt that changes things, and "read the records first" to any prompt that fixes them.
• Use a test project for new ideas. Build and try things in a project you can throw away, then repeat them where it matters.
• Check the numbers. The model does the counting and the arithmetic. Check any figure that feeds billing or reporting.

Step 1: Model an entity from a description

Goal: describe a feature in plain language and get the entity and its fields.

You say:

I'm building a simple support desk. Create a "tickets" entity with a
subject (short text, required), a body (long text), a status (short
text, default "open"), a priority (short text) and a resolved_at
timestamp.

What Claude runs:

cli: entities create tickets
cli: fields add tickets subject --type varchar --required --label Subject
cli: fields add tickets body --type text
cli: fields add tickets status --type varchar --default open
cli: fields add tickets priority --type varchar
cli: fields add tickets resolved_at --type timestamp
cli: fields list tickets

What you get:

✓ Entity tickets created (id: 684).
✓ Field subject (id: 3377) added to tickets.
✓ Field body (id: 3378) added to tickets.
…
── tickets → Fields (8) ──

The final table lists the five fields you asked for and the three the platform adds to every entity: id, created_at and updated_at. The entity appears in the Anythink dashboard straight away.

• --type varchar is a single-line text field and --type text is a text area. timestamp is a date and time.
• --required and --default belong to the field, so they apply to records created through the API or the dashboard too.

Adapt it: ask for relationships. fields add tickets customer --type many-to-one --target customers links each ticket to a customer. For the field types, see Model your data: entities, fields, relations.

Step 2: Seed test records

Goal: fill the entity with realistic sample data so you can build against it.

You say:

Add five sample tickets to tickets: a mix of open, closed and
in-progress, with high, medium and low priorities. Use realistic
subjects for a web shop.

What Claude runs:

cli: data create tickets --data '{"subject":"Checkout button unresponsive","body":"Nothing happens on mobile","priority":"high"}'
cli: data create tickets --data '{"subject":"Typo on invoice PDF","body":"Total label is misspelled","status":"closed","priority":"low"}'
cli: data create tickets --data '{"subject":"Slow dashboard load","body":"Takes 8 seconds","status":"in_progress","priority":"medium"}'
…

What you get: each command prints the saved record, with its generated id.

✓ Record created in tickets (id: 1).
{
   "id": 1,
   "subject": "Checkout button unresponsive",
   "body": "Nothing happens on mobile",
   "status": "open",
   "priority": "high",
   "resolved_at": null,
   …
}

The first ticket has no status, and it comes back as open. That's the field's default, applied by the platform.

Adapt it: say how many records you want and what the data is for. Ask for deliberately awkward values, such as empty fields, long text and unusual characters, to test your forms. Keep seeded data to a test project, and ask the assistant to list what it created so you can delete it later.

Step 3: Find and fix messy data

Goal: spot inconsistent values and correct them, with you approving the changes.

Say a few tickets came in from an import or a form, and some values are wrong.

You say:

Read every ticket and tell me about inconsistent values in status or
priority: different capitalisation, spelling mistakes, anything outside
open, in_progress and closed, and low, medium and high. Don't change
anything yet.

What Claude runs:

cli: data list tickets --all --json

--all --json returns every page of results. Each page is an object with total_count, has_next_page and items, so the assistant can check that it has seen all of the records.

What Claude says:

I read 5 tickets and found three problems:

• Ticket 3: status is Open and should be open.
• Ticket 4: status is OPEN and should be open.
• Ticket 5: priority is mdium, probably medium.

I can fix all three. Shall I go ahead?

You say: Yes, fix them.

What Claude runs:

cli: data update tickets 3 --data '{"status":"open"}'
cli: data update tickets 4 --data '{"status":"open"}'
cli: data update tickets 5 --data '{"priority":"medium"}'

✓ Record tickets/3 updated.
✓ Record tickets/4 updated.
✓ Record tickets/5 updated.

Adapt it: to confirm, ask it to count tickets by status with data list tickets --filter '{"status":"open"}' --json. For a lot of records, ask for a list of the fixes first and approve them as a batch. An update replaces only the fields you send, so each fix is small and easy to check. If the same mistakes keep coming back, make the field a select in the dashboard so they can't.

Step 4: Build a workflow

Goal: have the assistant set up an automation, and read the plan before it runs.

You say:

Create a workflow called purge-closed-tickets that I can run on demand
and that deletes every ticket whose status is closed. First show me
which tickets it would delete. Then show me the commands. Don't run
anything that changes data until I say so.

What Claude runs, as a read:

cli: data list tickets --filter '{"status":"closed"}' --json

It reports one match, ticket 2 ("Typo on invoice PDF"), and proposes:

cli: workflows create purge-closed-tickets --trigger Api --api-route purge-closed-tickets --description "Delete closed tickets" --enabled
cli: workflows step-add 240 delete_closed --name "Delete closed tickets" --action DeleteData --start --enabled --params '{"entity_name":"tickets","filter_conditions":[{"field":"status","operator":"eq","value":"closed"}]}'

You say: Create it, but don't run it yet.

✓ Workflow purge-closed-tickets created (id: 240).
✓ Step delete_closed (id: 624) added to workflow 240.

The workflow has an API trigger, so it runs only when something calls it. The step deletes the records that match its filter. A Delete data step refuses to run without a filter, so it can't clear the whole entity by accident.

You say: Now run it and show me the result.

cli: workflows trigger 240
cli: workflows jobs 240
cli: data list tickets --json

✓ Workflow 240 triggered.
Job #133245 Success

The ticket list no longer includes ticket 2.

Adapt it: for a workflow that reacts to new records, ask for --trigger Event --event EntityCreated --entity tickets, with a --filter to limit which records fire it. Set up schedules in the dashboard, where you can check the cron expression. Steps that use values from the record that triggered them are easiest to write in the workflow editor in the Anythink dashboard. See Triggers and scheduling and Step types.

Step 5: Diagnose and fix a failed job

Goal: find out why a workflow's job failed, then correct the step.

You say:

The job for workflow 242 failed. Find out which step failed and why,
tell me what to change, and wait for me to approve the fix.

What Claude runs:

cli: workflows jobs 242
cli: workflows get 242

workflows jobs returns recent jobs with each job's status and error message. It's the same information as Job History in the dashboard (see Test workflows and read job history). workflows get lists the workflow's steps with their ids.

What Claude says:

Job 133247 failed with 404 Not Found: Entity 'ticket' not found. The step delete_resolved (id 627) is looking at an entity called ticket, but yours is called tickets. I'd change the step's entity_name to tickets. Shall I update it?

You say: Yes.

cli: workflows step-update 242 627 --params '{"entity_name":"tickets","filter_conditions":[{"field":"status","operator":"eq","value":"resolved"}]}'
cli: workflows trigger 242
cli: workflows jobs 242

✓ Step Delete resolved tickets updated.
✓ Workflow 242 triggered.
Job #133251 Success

step-update --params replaces the step's whole parameter object, so ask the assistant to show you the new parameters before it runs the update. The step's fields are in Step types.

These commands are reads and one write. Your key needs anythink_workflows:read to read jobs and anythink_workflows:update to change a step.

Step 6: Audit who can do what

Goal: get a plain-language report on roles, users and API keys, without changing anything.

You say:

Audit access to this project. Read only, change nothing. Which roles can
delete entities or read secrets? Which users hold those roles? Which
API keys are still valid?

What Claude runs:

cli: roles list
cli: roles permissions list 104
cli: fetch /roles/105
cli: users list
cli: api-keys list

Each command only reads. fetch /roles/105 confirms whether a role is an administrator. A trimmed roles permissions list 104 looks like this:

── Role Standard User — Entity Permissions (18 entities) ──
│ anythink_entities │ read, create, update, delete │
│ anythink_secrets  │ read, create, update, delete │
│ blog_posts        │ read, create, update         │
│ publish_log       │ read                         │
…

What Claude says:

In this project, the Standard User role (id 104) can read, create, update and delete entities and secrets. Admin User (id 105) is an administrator role. Three users hold Standard User and one holds Admin User. Of the six API keys, none are still valid: two have expired and four are revoked.

Standard User probably doesn't need write access to entities or secrets. Do you want me to draft the permission changes for you to review?

The example data here is from a test project. api-keys list shows each key's name, how many permissions it holds, its expiry date and its status, and never the key itself.

Adapt it: ask for a table of every entity against every role, or for the permissions a single feature needs. Make permission changes in the dashboard or with a command you've read, and re-run the audit afterwards. See Control access: roles, permissions and field-level security.

Step 7: Summarise records

Goal: get an answer you can check, computed from your records rather than guessed.

You say:

Summarise the open tickets: how many there are, how many are high
priority, and which one has been open longest.

What Claude runs:

cli: data list tickets --filter '{"status":"open"}' --json

The filter runs on the server, so only the open tickets come back. In the example, that's four records. The assistant reads them and does the rest itself.

What Claude says:

There are 4 open tickets. Three are high priority: "Checkout button unresponsive", "Cannot reset password" and "Payment page returns 500". One is medium: "Slow dashboard load". The longest-open ticket is "Checkout button unresponsive", created first.

• Every matching record passes through the model, so this suits entities with hundreds of records, not hundreds of thousands. Filter as tightly as you can.
• Filters take JSON, such as {"priority":"high"} or {"id":{"gte":4}}. Without --all, a list returns one page of 20 records, so ask for --all when you need everything, and check total_count in the result.
• To keep a figure up to date, ask the assistant to build a workflow instead of re-reading the records each time. See Build your first workflow.

Adapt it: ask for the records it counted as well as the total, so you can spot-check the filtering. Ask for the answer as a table, or as a short update you can paste into a message.

Next steps