Platform super-admin operations — suspend tenants, adjust billing, force-rotate user sessions, browse cross-team security signals. Restricted to users with is_super_admin=true (HTTP 403 for all other callers regardless of team role). Every write is audit-logged with the calling super-admin's id, target id, and reason.

When to use: incident response (suspend a compromised team, revoke leaked sessions), customer-success billing adjustments, or platform-wide security review. Do NOT use for routine tenant operations — those have team-scoped tools.

Actions (pass alongside action):

• team_suspend (DESTRUCTIVE — disables tenant logins) — team_id (UUID), reason (string). Existing API tokens for the team are invalidated; users see a 403 on all API calls.

• team_billing (read) — team_id. Returns current invoice + plan summary, including next-cycle estimate.

• billing_credit (write — moves money) — team_id, amount (positive integer cents), reason (string). Adds to the team's CreditLedger; reflects in the next invoice.

• billing_refund (DESTRUCTIVE — issues a real Stripe refund) — team_id, amount (cents). Refunds against the most recent successful charge; partial refunds supported.

• security_overview (read) — recent suspicious activity across all teams: failed logins, token leaks, abuse signals.

• user_revoke_sessions (DESTRUCTIVE) — user_id (UUID). Invalidates ALL sessions and Sanctum/Passport tokens for the user; they must re-authenticate everywhere.

• user_send_password_reset (write) — user_id. Emails a password-reset link with a 60-minute one-time token.

Cloud note: feedback management (feedback_list/feedback_update) lives under platform support tooling, not exposed via MCP. Errors: 401, 403 (not super-admin), 404, 422, 429, 503 (Stripe down for billing actions).

Auxiliary agent operations beyond core CRUD: configuration history, rollback, live runtime inspection, skill/tool wiring, user feedback. For create/update/delete/toggle use agent_manage. Every action requires agent_id; remaining params depend on action.

Actions:

• config_history (read) — agent_id. Past config snapshots with timestamps.

• rollback (DESTRUCTIVE) — agent_id, version. Overwrites the current config with the named snapshot — current state is lost unless already snapshotted.

• runtime_state (read) — agent_id. Last execution status, queue depth, error counters.

• skill_sync (write) — agent_id, skill_ids[]. Replaces attached skills (full set semantics).

• tool_sync (write) — agent_id, tool_ids[]. Replaces attached tools (full set semantics).

• feedback_submit (write) — agent_id, rating (1-5), comment.

• feedback_list (read) — agent_id. Recent feedback entries.

• feedback_stats (read) — agent_id. Aggregate score + sentiment.

Core CRUD for AI agents in the caller's team. For runtime inspection, rollback, skill/tool wiring or feedback use agent_advanced. provider and model are validated against team-configured BYOK and local-LLM credentials at create/update time.

Actions:

• list (read) — optional: status, limit (default 50), cursor.

• get (read) — agent_id.

• create (write) — name, role, goal; optional: backstory, provider, model, skill_ids[], tool_ids[].

• update (write) — agent_id + any creatable field. Partial updates allowed.

• delete (DESTRUCTIVE) — agent_id, confirm=true. Soft-deletes; recoverable for 30 days.

• toggle_status (write) — agent_id. Flips active ↔ disabled.

• templates (read) — pre-built agent templates from the platform catalog.

Human-in-the-loop approvals and workflow human-task completion. Use this to unblock workflow steps gated on reviewer decisions or to submit form data for human_task DAG nodes. Each decision is audit-logged and emits a domain event the workflow runtime listens for.

Actions:

• list (read) — optional: status (pending/approved/rejected/expired), assignee_id, limit.

• approve (write) — approval_id, optional comment. Unblocks the dependent step.

• reject (write) — approval_id, reason. Terminates the dependent step (workflow may branch on rejection).

• complete_human_task (write) — approval_id, form_data (JSON matching the node's form_schema). Validates against the schema before commit.

• webhook_config (write) — approval_id, webhook_url. Configures external notification when status changes.

Read-only access to artifacts produced by experiments, crew executions, and project runs (code, documents, data, media). Each artifact has 1..N ArtifactVersion entries; version defaults to latest when omitted. download returns a signed URL valid for ~5 minutes; content returns the body inline (base64 for binary MIMEs).

Actions:

• list (read) — exactly one of: experiment_id, crew_execution_id, project_run_id; optional limit.

• get (read) — artifact_id. Metadata only (size, mime, version count, created_by AiRun id).

• content (read) — artifact_id; optional version. Returns raw or base64 body.

• download (read) — artifact_id; optional version. Returns short-lived signed URL.

FleetQ AI assistant conversations — the in-app chat panel that can call MCP tools on the user's behalf with role-gated authorization (read for all, write for Member+, destructive for Admin/Owner). Conversations bind to a context object (experiment, project, agent, crew, workflow) on first message.

Actions:

• conversation_list (read) — optional: limit, context_type filter.

• conversation_get (read) — conversation_id. Full history including tool_calls / tool_results.

• send_message (write) — message; optional: conversation_id (omit to start new), context_type, context_id, attachments[]. Triggers a synchronous tool-loop LLM call; consumes team credits.

• conversation_clear (DESTRUCTIVE) — conversation_id. Erases all messages, retains the conversation shell.

Boruna deterministic capability-safe .ax script runtime (v1.x LTS) — execute, validate, and audit Boruna scripts. Side effects depend entirely on the script's declared capabilities. Requires an active mcp_stdio Tool record pointing to a working Boruna binary; otherwise every action returns dependency_unavailable.

Actions:

• run (write — side effects per script capabilities) — inline .ax source OR skill_id of a saved boruna_script skill; optional: timeout_ms, mem_limit_mb.

• validate (read) — .ax source. Syntax + semantic check, no execution.

• policy_validate (read; v0.4.0+) — policy JSON. Strict schema validation.

• evidence (read) — run_id. Capability/effect evidence record for an executed run.

• capability_list (read) — registered capabilities and capability_set_hash.

• skill_manage (write) — sub-actions list/get/create/update/delete on boruna_script-typed skills.

FleetQ Bridge — a WebSocket relay that lets cloud experiments reach private endpoints on a self-hosted runner (laptop, on-prem VPS): local Ollama instances, internal MCP servers, on-prem APIs. All actions operate on the team's currently-registered bridge.

Actions:

• status (read) — connection state, last heartbeat, registered endpoint count.

• endpoint_list (read) — local LLM agents + MCP servers announced by the bridge.

• endpoint_toggle (write) — endpoint_id, enabled (bool). Flips visibility to cloud experiments without redeploying the bridge.

• disconnect (DESTRUCTIVE) — terminates the active bridge session; the runner must re-register before agents can reach private endpoints again.

Team-wide credit budget overview, pre-flight cost guards, and spend forecasting. Read-only — does not move money. 1 credit ≈ $0.001 USD; balances and reservations track LLM + outbound + compute spend with pessimistic locking. Use check before dispatching any expensive job to avoid mid-run pause-on-budget-exhausted events.

Actions:

• summary (read) — current balance, pending reservations, MTD spend by category (llm/outbound/compute).

• check (read) — estimated_cost (credits). Returns pass/fail without reserving funds.

• forecast (read) — period (week|month|quarter), granularity (day|week). Projects spend by extrapolating recent ledger entries.

Embeddable chatbots backed by an existing FleetQ agent. Each instance issues per-widget tokens for embedding, tracks sessions, and exposes analytics + learning entries. Conversations consume team credits via the bound agent's provider.

Actions:

• list / get (read) — list all or fetch one (chatbot_id).

• create (write) — name, agent_id, config (theme, greeting, allowed_origins[]).

• update (write) — chatbot_id + any creatable field.

• delete (DESTRUCTIVE) — chatbot_id. Cascades — also revokes all widget tokens.

• toggle_status (write) — chatbot_id. Flips active ↔ disabled.

• token_create (write) — chatbot_id. Returns an embeddable widget token (display once).

• token_revoke (DESTRUCTIVE) — chatbot_id, token_id. Invalidates a single widget instance.

• session_list / analytics / learning_entries (read) — chatbot_id; optional date range.

Encrypted credential vault for external services (API keys, OAuth2 tokens, basic auth, bearer tokens). Secrets are encrypted at rest with the team's per-tenant key; secret_data is never returned by get — only metadata (name, type, expires_at, last_rotated_at).

Actions:

• list (read) — optional: type, status filter.

• get (read) — credential_id. Metadata only, secrets redacted.

• create (write) — name, type (api_key/oauth2/basic_auth/bearer_token/custom), secret_data (object).

• update (write) — credential_id + any creatable field.

• delete (DESTRUCTIVE) — credential_id. Hard delete; not recoverable.

• rotate (write) — credential_id, new_secret_data. Bumps last_rotated_at and re-encrypts.

• oauth_initiate (write) — provider, scopes[]. Returns authorization URL.

• oauth_finalize (write) — provider, code (from OAuth callback). Stores tokens, returns credential_id.

Multi-agent crews — coordinated teams of agents that decompose a goal across roles (sequential, parallel, or hierarchical process). execute is async: it queues ExecuteCrewJob and returns immediately with an execution_id; poll execution_status for progress. Each crew member must be a real agent_id in the same team.

Actions:

• list / get (read) — list all or fetch one (crew_id).

• create (write) — name, process_type (sequential|parallel|hierarchical), agents[] (array of {agent_id, role}).

• update (write) — crew_id + any creatable field.

• delete (DESTRUCTIVE) — crew_id. Soft-deletes the crew.

• execute (write — long-running) — crew_id, goal. Reserves budget, returns execution_id.

• execution_status (read) — crew_id, execution_id. Status, current task, partial results.

• executions_list (read) — crew_id; optional limit.

Email themes (visual styling) and templates (transactional + marketing copy). Templates can be hand-written MJML/HTML or AI-generated via template_generate (consumes credits). Deleting a theme used by templates is blocked unless those templates are deleted first.

Theme actions:

• theme_list / theme_get (read).

• theme_create (write) — name, styles (object: colors, fonts, spacing).

• theme_update (write) — theme_id + any creatable field.

• theme_delete (DESTRUCTIVE) — theme_id. Fails if any template references it.

Template actions:

• template_list / template_get (read).

• template_create (write) — name, subject, body (MJML/HTML); optional theme_id.

• template_update (write) — template_id + any creatable field.

• template_delete (DESTRUCTIVE) — template_id.

• template_generate (write — costs credits) — prompt. Calls the team's default LLM to produce a template, returns draft for review.

AI-generated improvement proposals — the platform analyzes recent agent runs and suggests prompt tweaks, model swaps, skill additions. Proposals must be reviewed (analyze), then either apply (mutates the target agent/skill) or reject. apply is irreversible without a manual rollback through agent_advanced.rollback.

Actions:

• list (read) — optional: status (pending/applied/rejected), target_type, limit.

• analyze (read) — proposal_id. Returns LLM-generated rationale, confidence score, diff preview.

• approve (write) — proposal_id. Marks as approved without applying (queue for batch apply).

• apply (DESTRUCTIVE) — proposal_id. Mutates the target entity in place; rollback only via config_history snapshot.

• reject (write) — proposal_id, reason. Closes the proposal.

Experiments — the platform's core unit of work. Each experiment runs a workflow (DAG) through a 20-state machine: Draft → Scoring → Planning → Building → AwaitingApproval → Approved → Executing → CollectingMetrics → Evaluating → (Iterating | Completed). Lifecycle transitions are validated by ExperimentTransitionMap; use valid_transitions to discover what's currently allowed.

Actions:

• list (read) — optional: status, workflow_id, limit.

• get (read) — experiment_id.

• create (write) — name, hypothesis; optional workflow_id (else uses default workflow).

• start (write) — experiment_id. Transitions Draft → Scoring; reserves budget.

• pause / resume (write) — experiment_id. Pause holds at the current stage.

• retry (write) — experiment_id. Re-runs the failed stage.

• retry_from_step (write) — experiment_id, step_id. Graph-aware BFS reset of step + downstream.

• kill (DESTRUCTIVE) — experiment_id. Terminal; cannot resume.

• valid_transitions (read) — experiment_id. Allowed next states for current state.

• cost / steps / share (read) — experiment_id. Cost breakdown / step list / public share token.

Connect, browse, and modify external git repositories (GitHub, GitLab, Bitbucket, generic SSH). Repo connections store encrypted credentials and use phpseclib for SSH. File and commit ops happen through the platform's AtomicCommittingGitClient so concurrent agent edits don't corrupt working trees.

Repo actions:

• repo_list / repo_get (read).

• repo_create (write) — name, url, credentials (object).

• repo_update (write) — repo_id + any creatable field.

• repo_delete (DESTRUCTIVE) — repo_id. Drops connection; does not delete the remote repo.

• repo_test (read) — repo_id. Verifies connectivity + auth.

File / branch / commit actions:

• file_read (read) — repo_id, path, optional branch.

• file_write (write — pushes to remote) — repo_id, path, content, branch, message.

• file_list (read) — repo_id, optional path, branch.

• branch_create (write) — repo_id, name, source branch.

• commit (write — pushes to remote) — repo_id, message, files[].

• pr_create (write) — repo_id, title, body, source branch, target branch. Returns PR URL.

• pr_list (read) — repo_id; optional state filter.

Execute an action on a connected integration, e.g. create_issue on GitHub, send_message on Slack.

Third-party service integrations (Airtable, Notion, Linear, Stripe, Slack, GitHub via OAuth2 + driver interface). Each integration declares typed capabilities (action endpoints) discoverable at runtime. execute invokes one capability with params validated against the driver's schema; output is normalized to JSON.

Actions:

• list (read) — optional: driver, status filter.

• connect (write) — driver, name, credentials (object — driver-specific). Initiates OAuth or stores API keys.

• disconnect (DESTRUCTIVE) — integration_id. Revokes tokens and deletes the connection.

• ping (read) — integration_id. Health-check the upstream API.

• execute (write — side effects on upstream) — integration_id, integration_action (capability name), params (object).

• capabilities (read) — integration_id. Available actions + parameter schemas.

Per-team knowledge bases — vector-indexed document collections agents can search at runtime. Ingestion runs an embedding job (consumes credits via the team's embedding provider). search is hybrid: cosine similarity over pgvector + keyword fallback.

Actions:

• list (read) — all knowledge bases for the team.

• create (write) — name, description.

• ingest (write — costs embedding credits) — knowledge_base_id; one of: content (raw text), url (fetched + extracted), file_id.

• search (read) — knowledge_base_id, query; optional limit (default 10), threshold.

• delete (DESTRUCTIVE) — knowledge_base_id. Drops all ingested chunks and embeddings.

Cross-team marketplace for shared skills, agents, and workflows. browse and categories are public (no auth scope); publish, install, review operate within the caller's team. Installing a listing copies the artifact into the team and increments the listing's install count.

Actions:

• browse (read) — optional: query, category, sort. Public.

• categories (read) — taxonomy of available categories. Public.

• publish (write) — listing data: target_type (skill/agent/workflow), target_id, name, description, visibility (public/private/team).

• install (write) — listing_slug. Copies the listed entity into your team.

• review (write) — listing_slug, rating (1-5), comment. One review per user per listing.

• analytics (read) — listing_slug. Install counts, ratings (publisher only).

Team-scoped semantic memory — short notes agents store and retrieve across conversations (preferences, constraints, prior decisions). Backed by pgvector with HNSW indexing; cross-team isolation enforced by TeamScope. Distinct from knowledge_manage: this stores unstructured short notes (1-2 paragraphs), knowledge_manage stores document corpora.

When to use: an agent needs to recall a stable fact about the user/team across runs, or wants to remember a decision so the next conversation starts with that context. Do NOT use for transient run-state — use the experiment artifact system instead.

Actions:

• search (read; semantic) — query (string), optional limit (default 20, max 100). Returns ranked entries with similarity score 0..1; entries below threshold 0.6 are filtered.

• list_recent (read) — optional limit (default 50). Reverse-chronological by created_at.

• stats (read) — returns { total_entries, embedding_dim, last_write_at, storage_bytes }.

• add (write — costs ~1 credit per ~1k tokens for embedding) — content (string, max 4000 chars), optional metadata (object).

• delete (DESTRUCTIVE) — memory_id (UUID). Hard delete; not recoverable.

• upload_knowledge (write — costs embedding credits, async) — one of: file content (string), url. Bulk-ingests into memory; returns job_id. Up to 50 MB per call.

Cloud note: supabase_provision not available in cloud (provisioning happens at platform level). Errors: 401, 403, 404 if memory_id missing, 413 on oversized payload, 422 validation, 429 rate limit, 503 if budget exhausted.

Outbound delivery connectors — channels through which agents send messages: email (SMTP), Slack, Telegram, generic webhook. One connector per channel per team (save uses upsert semantics). All sends pass through ChannelRateLimit and TargetRateLimit middleware and are recorded as OutboundActions.

Actions:

• list / get (read).

• save (write — upsert) — channel (email/slack/telegram/webhook), config (channel-specific). Replaces any existing connector for the channel.

• delete (DESTRUCTIVE) — connector_id. Pending outbound actions on this connector are cancelled.

• test (write — sends a real test payload) — connector_id, test_payload (object). Counts against rate limits and budgets.

Caller's own profile and account settings (name, email, password, 2FA, OAuth links). Operates on the authenticated user — there is no user_id parameter; super-admins managing other users use admin_manage instead. All actions are rate-limited per user (60/min) and audit-logged.

When to use: agent or assistant needs to read/update the current user's profile, list linked OAuth providers, or unlink a social provider. Do NOT use to create accounts (that's a self-service signup flow only).

Actions:

• get (read) — returns profile object: name, email, locale, timezone, current_team_id, last_login_at, email_verified_at.

• update (write) — optional fields: name, email, locale, timezone. Email change re-issues the verification mail and clears email_verified_at until confirmed.

• password_update (DESTRUCTIVE; rotates session) — current_password, password, password_confirmation. Verifies current password then bcrypts the new one; revokes all OTHER active sessions of this user.

• 2fa_status (read) — returns { enabled: bool, recovery_codes_remaining: int }.

• connected_accounts (read) — list of linked OAuth provider records (provider, provider_user_id, linked_at).

• social_list (read) — duplicate of connected_accounts kept for backward client compatibility.

• social_unlink (DESTRUCTIVE) — provider. Removes the OAuth link; rejected with 422 if it would leave the user with no remaining auth method.

Errors: 401 unauthenticated; 403 if Sanctum token lacks team:{id} ability; 422 for validation; 429 on rate limit.

Projects — recurring (continuous) or one-shot containers that schedule workflow runs against goals. Continuous projects spawn ProjectRuns on the configured cadence (cron-style or natural language); one-shot projects fire once on trigger_run. Lifecycle states: draft → active → (paused | archived). Each run reserves budget independently.

Actions:

• list / get (read).

• create (write) — name, type (one_shot | continuous), workflow_id.

• update (write) — project_id + any creatable field.

• activate / pause / resume / restart (write) — project_id. Lifecycle transitions.

• trigger_run (write — costs credits) — project_id. Dispatches a single run immediately.

• archive (write) — project_id. Stops scheduling and hides from default lists; reversible via restart.

• schedule (write) — project_id, frequency or cron expression.

• schedule_nlp (write) — project_id, natural language schedule (e.g. "every weekday at 9am"). Calls LLM, costs credits.

• run_list (read) — project_id; optional limit, status filter.

• run_get (read) — project_id, run_id.

Inbound signal SOURCES (ticketing, alerts, Slack, HTTP monitors, ClearCue, Telegram bots) plus the team's knowledge graph (KG) read/write surface. Distinct from signal_manage: this tool wires up connector configurations; signal_manage operates on already-ingested signals.

When to use: bind a new external system to FleetQ so its events become signals (which trigger rules → projects → agents), or query/extend the team's knowledge graph that agents reason over. Do NOT use to send outbound messages — use outbound_manage for that.

Connector actions (each accepts a config object specific to that channel; idempotent — re-call to update):

• ticket (write — upsert) — config (Jira/Linear/Zendesk fields). Polls every 5 min.

• alert (write — upsert) — config (PagerDuty/Opsgenie webhook). Pushes signals on incident events.

• slack (write — upsert) — config (workspace_id, channel_ids[], event filters).

• http_monitor (write — upsert) — config: url, interval_seconds (min 60), expected_status. Emits a signal when status flips.

• clearcue (write — upsert) — config (ClearCue API key, query).

• inbound_connector (write) — sub-actions: create, update, delete on generic connectors.

• subscription (write) — sub-actions: list, create, delete on per-connector subscriptions.

• telegram (write — upsert) — config: bot_token, allowed_chat_ids[]. Webhook auto-registered.

Knowledge graph actions:

• kg_search (read — hybrid semantic+symbolic) — query (string), optional types (array). Returns ranked entities with relevance score.

• kg_facts (read) — entity_id (UUID). All facts attached, paginated.

• kg_add_fact (write) — entity_id, fact: { predicate (string), object (string), source (string), confidence (0..1) }.

• intent_score (read — costs ~1-2 LLM credits) — company (string), query (string). Returns intent classification + confidence.

Cloud note: supabase connector not exposed in cloud (TeamProviderCredential handles per-team Supabase access through integration_manage). Side effects: writes update KG and trigger downstream rule evaluation (may dispatch agent runs and consume budget). Errors: 401, 403, 404, 422 (config validation), 429, 503 (upstream connector down).

Inbound signals — events from connectors (webhooks, RSS, email, Slack, ticketing) the platform processes through trigger rules into agent actions. Operates on already-ingested signals; for connector setup use signal_connectors.

Actions:

• list (read) — optional: status, source, channel, limit.

• get (read) — signal_id. Full payload + processing trail.

• ingest (write) — source, payload (object). Manually emits a signal as if from a connector; runs trigger evaluation.

• assign (write) — signal_id, assignee_user_id, reason.

• connector_binding (write) — connector_id, channel_id. Links a connector to a logical channel.

• connector_binding_delete (DESTRUCTIVE) — binding_id. Severs the link; future signals from that connector go unrouted.

• contact (write) — sub-actions on Contact (action, contact data).

• imap (write) — mailbox config object. Sets/updates IMAP poller settings.

• email_reply (write — sends email) — signal_id, body. Replies to the originating email signal via the team's outbound email connector.

AI skills — reusable units agents invoke (LLM prompt templates, connector calls, rules, hybrid pipelines, guardrails). Skill executions are versioned (SkillVersion) and metered against the team budget. Direct execution actions (guardrail, multi_model, code_exec, browser) bypass the agent layer for ad-hoc invocation by humans/assistants.

When to use: build reusable prompt or workflow primitives that multiple agents share, or run a one-off skill (e.g. code_exec to evaluate Python in a sandbox). Do NOT use for raw LLM calls — use assistant_manage instead.

CRUD actions:

• list (read) — optional: type (llm|connector|rule|hybrid|guardrail), status, limit (default 50).

• get (read) — skill_id. Returns full config + latest version.

• create (write) — name, type, config (type-specific JSON). Returns skill_id.

• update (write) — skill_id + any creatable field. Bumps version; old version retained.

• delete (DESTRUCTIVE) — skill_id. Soft-deletes; existing version history retained for 30 days.

• versions (read) — skill_id. Version log with diffs and created_by AiRun id.

Direct execution (each costs credits; rate-limited per skill):

• guardrail (read — costs ~1-3 LLM credits) — input (string), rules (array). Returns { passed: bool, violations: [...] }.

• multi_model (write — costs ~N × LLM credits where N=models[].length) — prompt, models[]. Runs same prompt across providers and returns consensus.

• code_exec (DESTRUCTIVE — runs in sandboxed Docker, costs sandbox-minute credits) — code, language (python|node|bash). Network-disabled by default; max 60s wall-clock; max 256 MB memory.

• browser (write — costs browser-minute credits) — url, actions (array of {type, selector, value}). Headless Chromium with SSRF guards.

Cloud note: supabase_edge_function not exposed in cloud (use integration_execute with a Supabase integration instead). Errors: 401, 403, 404, 422, 429, 503 (sandbox/browser worker pool exhausted).

Platform system administration, monitoring, and infrastructure control — KPIs, health checks, audit log, semantic cache, GPU compute providers, browser-relay bridge. Mixed permission tiers: read actions (dashboard_kpis, health, version_check, audit_log, cache_stats) need any authenticated user; write actions marked PLATFORM ADMIN require the user's is_super_admin=true flag (HTTP 403 otherwise). Every write is audit-logged.

When to use: agent monitoring platform health, on-call investigating an incident via audit log, super-admin adjusting platform-wide settings or purging the semantic cache after a model swap. Do NOT use for tenant-level operations — those have dedicated tools (e.g. team_manage).

Read actions:

• dashboard_kpis — { active_users, runs_today, spend_today_credits, ... }.

• health — { status: ok|degraded|down, db, cache, queue, providers[] }.

• version_check — { current, latest, update_available }.

• audit_log — optional: actor_id, action, entity_type, since, limit (max 100). Cursor-paginated.

• cache_stats — semantic cache hit/miss/savings since last purge.

Write actions:

• global_settings (write — PLATFORM ADMIN) — settings object. Replaces platform-wide settings.

• blacklist (write — PLATFORM ADMIN) — sub-actions: list, add, remove. Affects email/domain blocklists for sign-ups.

• security_policy (write — PLATFORM ADMIN) — sub-actions: list, save, delete on security policies.

• cache_purge (DESTRUCTIVE — PLATFORM ADMIN) — purges semantic cache CROSS-TEAM. All teams lose cached LLM responses; first calls after purge will be slower and more expensive.

• compute (write — PLATFORM ADMIN) — sub-actions on compute provider records (Replicate, Fal.ai, Vast.ai, RunPod).

• runpod (write — PLATFORM ADMIN, costs real $) — sub-actions on RunPod GPU pods. Spinning up a pod bills the platform Stripe account immediately at the pod's per-minute rate.

• browser_relay (write — relays through local bridge) — sub-actions for browser automation through the team's connected FleetQ Bridge runner. Requires an active bridge.

Errors: 401, 403 (insufficient role for PLATFORM ADMIN action), 404, 422, 429, 503 (provider down).

Caller's team — settings, membership, BYOK provider credentials, API tokens, notifications, and KMS-managed encryption keys. Most write actions require team role owner or admin (HTTP 403 otherwise); viewer and member are limited to read + their own profile-level toggles (notifications). Every write is audit-logged.

When to use: agent or assistant managing the current team's configuration — invite a member, mint an API token, register a BYOK Anthropic key, etc. Do NOT use for cross-team operations — those require admin_manage (super-admin only).

Core team actions:

• get (read) — returns team object (name, slug, plan, settings, owner_id, member_count).

• update (write — admin/owner) — optional: name, settings (object). Plan changes happen via Stripe webhook only.

• members (write — admin/owner) — sub-actions: list, invite (email, role), remove (user_id). Invitations expire after 7 days.

LLM provider config (admin/owner):

• local_llm (read) — bridge-discovered local LLM agents (Ollama, LM Studio, Codex, Claude Code).

• byok_credential (write) — sub-actions on BYOK keys (Anthropic, OpenAI, Google, Mistral, Perplexity). Keys encrypted at rest; never echoed back.

• custom_endpoint (write — plan-enforced; pro/enterprise only) — sub-actions on custom OpenAI-compatible LLM endpoints (vLLM, LiteLLM, custom proxies).

Tokens & access (admin/owner):

• api_token (write) — sub-actions: create (returns token once), list, revoke. Tokens are team-scoped and inherit the user's role; rotate on suspected leak.

Notifications & system:

• notification (write — any role) — sub-actions: list, dismiss, dismiss_all on the user's notification inbox.

• join_request (write — admin/owner) — sub-actions: list, approve, reject pending team join requests.

• kms (DESTRUCTIVE — owner only) — sub-actions on KMS encryption keys: list, rotate (re-encrypts all team credentials with new key — cannot be undone), revoke.

Errors: 401, 403 (insufficient role), 404, 409 (cannot remove self if last owner), 422, 429.

LLM tool management — registers MCP servers (stdio, HTTP, bridge) and built-in tools (bash, filesystem, browser, SSH) that agents can call at inference time. Tool execution may have any side effect declared by the underlying tool; the platform constrains bash/filesystem/SSH only via the agent's bash_policy. Tool credentials are encrypted at rest with the team's per-tenant key.

When to use: connect a new external MCP server (e.g. GitHub, Slack, Notion) so agents can call its tools, toggle a tool's availability without deleting it, or test a remote MCP server's reachability before wiring it to an agent. Do NOT use to invoke tools — agents call them automatically based on attached configuration.

CRUD actions:

• list (read) — optional: type (mcp_stdio|mcp_http|mcp_bridge|built_in), status, limit (default 50).

• get (read) — tool_id (UUID). Metadata only; credentials redacted in response.

• create (write) — name, type, config (type-specific JSON: command for stdio, url+headers for http, kind for built_in).

• update (write) — tool_id + any creatable field. Re-encrypts credentials if provided.

• delete (DESTRUCTIVE) — tool_id. Soft-deletes; agents lose access on next ResolveAgentTools call (cached up to 5 minutes).

• activate / deactivate (write) — tool_id. Flips active flag without deletion; affects all agents that reference the tool.

Discovery (cloud restricts these to safe operations):

• probe_remote (read — calls the remote URL, no registration) — url. Sends an MCP initialize request; returns server name, version, declared capabilities.

Cloud note: discover_mcp and import_mcp (which auto-register all tools from a remote server) are NOT available in cloud — they require explicit per-tool review under cloud's security policy. Use probe_remote then create per tool instead.

Errors: 401, 403, 404, 422 (config validation), 429, 503 (remote MCP server unreachable for probe_remote).

Event-driven trigger rules — when-this-then-that automations that fire on signals or domain events. Rules evaluate conditions (expression-based) against the event payload and execute actions (start_experiment, send_outbound, etc.). test is a dry-run that returns whether the rule would have matched without executing actions.

Actions:

• list (read) — optional: event filter, status filter.

• get (read) — trigger_id.

• create (write) — name, event (e.g. "signal.ingested"), conditions (array of expressions), actions (array of action specs).

• update (write) — trigger_id + any creatable field.

• delete (DESTRUCTIVE) — trigger_id. Future events stop matching this rule.

• test (read — costs no credits) — trigger_id, sample payload. Returns matched (bool), action_preview (what would have run).

Outbound webhook endpoints — URLs the platform POSTs to when subscribed events fire (experiment.completed, signal.ingested, approval.decided, etc.). Each delivery is HMAC-signed with the configured secret (header: X-FleetQ-Signature). Failed deliveries retry with exponential backoff up to 24h.

Actions:

• list (read) — all webhooks for the team.

• get (read) — webhook_id. Includes recent delivery stats.

• create (write) — url, events[] (array of event names), secret (used for HMAC signing; show once).

• update (write) — webhook_id + any creatable field. Updating secret invalidates the old one immediately.

• delete (DESTRUCTIVE) — webhook_id. In-flight deliveries are cancelled.

Surgical edits to a workflow's DAG (nodes + edges). For metadata changes (name, description, status, validation, AI generation) use workflow_manage. Every edit re-validates the graph; an edit that would create a cycle, an unreachable node, or an invalid edge type is rejected before commit.

Actions:

• save_graph (write — full replace) — workflow_id, nodes[], edges[]. Atomically replaces the entire graph; existing in-flight runs continue on the old graph.

• node_add (write) — workflow_id, type (start|end|agent|conditional|human_task|switch|dynamic_fork|do_while), config (type-specific).

• node_update (write) — workflow_id, node_id, config (partial).

• node_delete (DESTRUCTIVE) — workflow_id, node_id. Cascade-deletes incident edges; rejected if it would orphan nodes.

• edge_add (write) — workflow_id, source_id, target_id; optional condition / case_value for switch nodes.

• edge_delete (DESTRUCTIVE) — workflow_id, edge_id. Rejected if it would disconnect the graph.

Workflow templates — reusable DAGs that experiments and project runs execute. This tool covers metadata and lifecycle; for graph editing use workflow_graph. Lifecycle states: draft → active → archived. Activation is gated on validate passing.

Core actions:

• list / get (read) — optional: status filter.

• create (write) — name, description.

• update (write) — workflow_id + any creatable field.

• delete (DESTRUCTIVE) — workflow_id. Soft-deletes; running experiments continue on cached graph.

• validate (read) — workflow_id. Returns errors[] (cycles, orphans, invalid types) and warnings[].

• activate (write) — workflow_id. Requires validation to pass.

• duplicate (write) — workflow_id. Creates a draft copy with the same graph.

AI / cost:

• generate (write — costs LLM credits) — prompt. Decomposes natural language into a workflow graph and saves as draft.

• estimate_cost (read) — workflow_id. Projected per-run credit cost.

• suggestion (read — costs LLM credits) — context (object). Recommends improvements.

Advanced:

• time_gate (write) — workflow_id, config (delay/window). Adds time-based gating around step execution.

• execution_chain (write) — workflow_id, chain config. Configures sequential workflow chaining.