> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tagada.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Tools Reference
> The nine tools on the Tagada Config MCP, what each one reports, and the one that writes.
Nine tools. Eight only read; `canvas_apply` is the one that writes, and it writes nothing but a funnel. Every tool except `list_stores` and `search_docs` takes a `storeId`.
| Tool | Input | Answers |
| ------------------ | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------ |
| `list_stores` | — | Which stores can I reach, in which organisation, in which currency? |
| `get_setup_status` | `storeId` | Which required steps does the checklist consider done? |
| `check_catalog` | `storeId` | Are there active products, with active variants, priced in the store currency? |
| `check_shipping` | `storeId` | Are there live rates, covering which countries, for the shippable products? |
| `check_payment` | `storeId` | Is the payment flow live, and can any processor actually take a charge? |
| `check_checkout` | `storeId` | Is a funnel active, published, on a verified domain? |
| `canvas_get` | `storeId`, `funnelId?` | What does this funnel actually look like — entries, pages, exits, wires, satellites, what fires where? |
| `canvas_apply` | `storeId`, `commandId`, `expectedSeq`, `command` | **Writes.** One command on one funnel: `add`, `remove`, `connect`, `bind` or `set` |
| `search_docs` | `query` | What do the Tagada docs say about this? |
Call `list_stores` first — it is the only source of valid store ids, and it spans every organisation you belong to. Every diagnosis echoes the store name it inspected.
Rate limit: 120 tool calls per minute per signed-in user, separate from your API keys. `canvas_apply` has a second, tighter budget: 60 commands per minute per funnel, so an agent cannot starve the merchant editing the same canvas.
## How a diagnosis reads
The four `check_*` tools share one output shape.
```text theme={null}
Store: Acme EU (store_7f3a91c2)
Check: payment — PROBLEMS FOUND
[ERROR] Processor "Stripe EU" is archived.
evidence: {"processorId":"proc_x9y8","processorName":"Stripe EU","archivedAt":"2026-06-02T09:14:00.000Z"}
[ERROR] No processor can currently take a charge — the checkout will decline every card even though the setup checklist shows green.
Learn more: https://help.tagada.io/articles/19-add-processors-to-your-organization
```
Severities are `OK`, `WARNING`, `ERROR`. `evidence` carries the rows and values that prove the claim. Each finding also has a stable `code` — `processor_archived` above — that survives a change of wording.
## `get_setup_status`
The five required steps (`store`, `catalog`, `shipping`, `payment`, `checkout`) and their status: `completed`, `pending`, `not_started`, or `locked`.
This is the shallow view. A 5/5 checklist and a store that declines every card are compatible states, which is why the `check_*` tools exist.
## `check_catalog`
At least one active product, with active variants, each priced in the base currency and in every presentment currency.
`catalog_empty` · `no_active_product` · `product_without_active_variant` · `all_variants_out_of_stock` · `variant_missing_base_currency_price` · `variant_missing_presentment_currency_price` · `variant_priced_only_on_legacy_fields`
The last one catches a quiet failure: a variant priced only on the legacy field looks priced in the CRM and is invisible to the checkout.
## `check_shipping`
Live (non-deleted) rates that name countries, are priced in the base currency, and cover every shippable product. Digital stores return `shipping_not_applicable`.
`shipping_rates_all_deleted` · `shipping_rate_without_country` · `shipping_rate_missing_base_currency` · `shippable_products_without_rate`
Amount and weight brackets are not evaluated. A rate no real cart reaches is still reported as live.
## `check_payment`
A payment flow that is selected, found and not archived, with processors that are not all disabled; then, per enabled processor, that it is enabled, not archived, and lists the store's base currency.
`payment_flow_not_selected` · `payment_flow_not_found` · `payment_flow_archived` · `payment_flow_has_no_processors` · `payment_flow_all_processors_disabled` · `processor_not_found` · `processor_disabled` · `processor_archived` · `processor_currency_unsupported` · `no_usable_processor`
Needs store-read **and** processor-read permissions; it names the missing one rather than returning a partial answer. Processor credentials are never read from the database, so they cannot reach the assistant even in an error path.
Monthly processing capacity is not checked. A processor over its cap is reported as usable.
## `check_checkout`
An active, published funnel whose production domains are registered, enabled and verified.
`no_funnel` · `no_active_funnel` · `funnel_not_published` · `domain_not_registered` · `domain_disabled` · `domain_not_verified`
An unverified domain is the classic silent outage: the funnel is live, the CRM is green, and the URL you gave your customers does not resolve.
## `canvas_get`
The whole canvas of one store in a single reply: `store`, `funnel` (with its sequence numbers, drift flag and publication state), `entries`, `nodes` with their typed `exits`, `edges`, `satellites` and `bindings`. Pass `funnelId` to pick a funnel when the store has several; leave it out for the default one.
Read this before every `canvas_apply`: the ids you need — node ids, exit ids, integration ids — and the `funnel.pendingSeq` you must echo back all come from here.
## `canvas_apply`
The only tool on this server that changes anything. It takes one command out of five, refuses everything it cannot prove, journals it, and lets the compile queue write the funnel.
```json theme={null}
{
"storeId": "store_abc123",
"commandId": "01J9Z2X4V7A8B9C0D1E2F3G4H5",
"expectedSeq": 12,
"command": {
"type": "add",
"kind": "page.offer",
"after": { "node": "step_checkout", "exit": "step_checkout:paid" },
"props": { "name": "Post-purchase upsell", "offerId": "offer_2f1c" }
}
}
```
* **`commandId` is yours, and replaying it is safe.** An id already seen returns the original reply, never a second command. Retry a timeout with the same id.
* **`expectedSeq` is the `funnel.pendingSeq` you just read.** If the canvas moved in between, the command is refused with `stale` and the fresh document comes back with the refusal.
* **A refusal is data, not an exception.** It carries `code`, `message`, `cause`, `fix` and `docs`. Act on `fix`; branch on `code`, which is versioned and never changes meaning.
* **A malformed command is a different answer.** The tool re-validates its input, so a name over 120 characters or an `http://` address comes back as *"This command is not valid"* naming the field — `command.props.url` — and never reaches the refusal codes.
The five commands, the exits each block has, and the fifteen refusal codes are in the [Funnel Canvas](/developer-tools/funnels/canvas) reference.
`canvas_apply` edits a live funnel. It publishes on its own once the funnel compiles, so a command an agent sends is a change a customer can hit. Show the merchant what you are about to send.
## `search_docs`
Searches the public documentation behind [docs.tagada.io](https://docs.tagada.io). Use it to turn a finding into a fix. If it is unavailable it says so, and the rest of the session keeps working.
## Next
Three prompts, ready to copy.
Connect your client.