Caroush Developers

Each tool returns MCP content and structuredContent. The structured envelope contains a server-generated request_id, status, and, when appropriate, data, operation_id, approval_url or error. The machine-readable catalog provides the full output schema for every tool.

Illustrative approval response; IDs are examples, not real resources:

{
  "request_id": "11111111-1111-4111-8111-111111111111",
  "operation_id": "22222222-2222-4222-8222-222222222222",
  "status": "approval_required",
  "approval_url": "https://app.caroush.com/settings/integrations/mcp/requests/22222222-2222-4222-8222-222222222222"
}

State	Meaning	Client action
`approval_required`	Exact request recorded; effect has not run	Show the URL to the user; never approve on their behalf
`approved` / `queued`	User approved, or background request accepted	Poll `get_job_status` with `operation_id`
`running`	One worker owns execution	Wait; do not generate a new key
`succeeded`	Tool handler finished	Inspect `data` for native run or provider state
`failed`	Validation, access or application failure	Read error; correct the cause before a new intentional action
`dispatch_failed`	Queue dispatch failed	Retry the identical call with the same key; automatic recovery also runs
`denied`	User declined or approval expired	Stop; a new request requires renewed user intent
`outcome_unknown`	Worker stopped or an unexpected error prevented confirmation	Inspect existing records before any new request; no blind replay

status=succeeded at the MCP envelope means the handler returned successfully. It does not promise AI generation, provider processing or publication finished. generate_carousel, regeneration and retry queue native jobs and return the actual post/run IDs. Poll get_carousel using its documented post_id. run_automation returns a native run: poll get_automation_run using kind and run_id. Publishing can remain pending; inspect returned schedules with get_schedule. Confirm completion from real statuses and post_url values, never invented permalinks.

get_job_status itself is a successful read, so the operation's state is inside its data.status. It is visible only to the connection that created it. Stored arguments and successful results are encrypted with the Laravel application key. Keep that key stable on redeployment.