Each recipe is a conversation with Claude connected to your project through a local anythink-mcp server (see Connect Claude to your backend with MCP). Each one shows the prompt, the tool calls Claude makes and why they work. All of them use the cli tool, which is the only tool that reaches your entities, fields, data and workflows. For how the pieces fit together, see How AI chat and MCP work.
Goal: describe a feature in plain language and have Claude create the entity, its fields and some sample records.
You say:
I'm building a simple support desk. I need a "tickets" entity with a
subject (short text, required), a body (long text), a status (short text,
default "open") and a priority (short text). Create it, then add three
sample tickets with different statuses and priorities.
What Claude calls:
cli: entities create tickets
cli: fields add tickets subject --type varchar --required
cli: fields add tickets body --type text
cli: fields add tickets status --type varchar --default open
cli: fields add tickets priority --type varchar
cli: data create tickets --data '{"subject":"Checkout button unresponsive","body":"Customers report the button does nothing on mobile","status":"open","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":"Dashboard takes 8 seconds to load","status":"in_progress","priority":"medium"}'
How it works:
entities create makes the entity, and each fields add adds one field. --type varchar gives a single-line input in the Anythink dashboard and --type text gives a text area.--required and --default are set on the field itself, so they also apply to records created through the API or the dashboard, not only to this conversation.data create prints the saved record, including its generated id, so Claude can report exactly what it made.Adapt it: ask Claude to run entities get tickets before it adds records, so you can check the schema. For relationships, fields add takes --type many-to-one --target <entity>.
Goal: find out why a workflow's jobs are failing without opening its job history yourself.
You say:
The "Flag large orders" workflow has jobs failing. Find the failed jobs
and tell me which step is failing and why.
What Claude calls:
cli: workflows list
cli: workflows jobs 4
cli: workflows get 4
How it works:
workflows list returns every workflow with its id. Claude matches the name and reads the id (4 here), because workflows jobs takes an id, not a name.workflows jobs <id> returns recent jobs with each job's status and error, and each step's status, error and log. That's the same information as Job History in the dashboard (see Monitoring and testing).workflows get <id> shows the steps' parameters, so Claude can compare what a step was asked to do with what went wrong.anythink_workflows:read.Adapt it: once Claude has found the problem, ask it to fix the step. It uses workflows step-update <workflow-id> <step-id> --params '{...}', which replaces the step's parameters with the JSON you give it. Ask it to show you the new parameters before it runs the update, and check the step's fields in Step types.
Goal: get an answer you can check, computed from your records rather than guessed by the model.
You say:
How many orders are still pending with a total over 100, and what's
their combined value?
What Claude calls:
cli: data list orders --all --json
How it works:
--all --json returns every record in the entity, one page at a time. Claude then filters for status of pending and total over 100, and adds up the totals itself.fetch can't send query strings through the cli tool, so the filtering happens in the conversation.Adapt it: the same pattern works for any entity. Ask Claude to show you the records it counted as well as the total, so you can spot-check its filtering.