RUMO MCP

rumo_whoami — Returns the bound phone, account, and session info. In LOCAL_DEV mode this is read from env; in production it comes from the verified MCP session.

rumo_list_accounts — List the accounts this connection can act on, with the caller's role in each and which one is active. Pass account_id on any other tool to act on a different covered account. Read-only.

rumo_list_inboxes — List all RUMO inboxes (channels) for the bound account.

rumo_list_conversations — List account-scoped conversations with the canonical status, assignment, inbox, team, label, type, sorting, page, and delta-cursor filters.

rumo_filter_conversations — Apply the canonical Chatwoot advanced conversation filter DSL with AND/OR conditions.

rumo_search_conversations — Search account-scoped conversations by text using the canonical RUMO/Chatwoot conversation search endpoint. Returns compact matches and pagination metadata; call rumo_get_conversation for full chronology.

rumo_get_conversation — Retrieve one account-scoped conversation and normalize returned messages/events into evidence-grounded chronology, including assignments, labels, notes, activities, and attachment metadata where present.

rumo_list_conversation_messages — Page through the authoritative account-scoped conversation timeline. Returns message IDs for stable before/after pagination and never claims completeness without evidence.

rumo_analyze_conversation — Build a deterministic, evidence-grounded analysis bundle from the complete authorized timeline: counts, response timing, unanswered state, ownership, labels, and chronology. It does not invent sentiment or facts.

rumo_list_contacts — List contacts in the bound account.

rumo_search_contacts — Search account-scoped contacts by name, email, phone, or identifier using the canonical RUMO/Chatwoot search endpoint. Read-only: it does not import, merge, or synchronize contacts.

rumo_list_agents — List account agents available for conversation assignment.

rumo_list_teams — List account teams available for conversation assignment.

rumo_list_labels — List account labels usable for conversations, contacts, and campaign audiences.

rumo_list_segments — List the current user's saved contact filters (segments), including their exact filter query for campaign audience selection.

rumo_list_projects — List Studio AI projects for the bound account. Goes through the RUMO studio/* proxy → Studiochat (no direct Studiochat call).

rumo_list_kbs — List Knowledge Bases in a Studio project. If project_id is omitted, the account's default Studio project is used.

rumo_list_playbooks — List Suggestion Playbooks in a Studio project. If project_id is omitted, the account's default Studio project is used.

rumo_list_assistant_playbooks — List the assistant's playbooks — the behavior definitions. This is the entry point for the diagnosis workflow: the base_id it returns is what rumo_get_playbook, rumo_list_skills and rumo_list_eval_cases accept. NOTE: this is a different entity from rumo_list_playbooks, which lists *suggestion* playbooks and whose ids these tools will not accept. Read-only.

rumo_get_assistant — Read one Studio assistant: its identity plus its resolved settings, in a single call. Use this before explaining or changing an assistant so the description is grounded in configuration rather than inferred from conversations. Read-only.

rumo_get_playbook — Read one playbook — the assistant's behavior. Pass playbook_id for an exact version, or base_id for the current one. Returns the instruction body and version metadata. Read-only; use rumo_get_playbook_history to see how it got here, and rumo_update_playbook to edit the body.

rumo_get_playbook_history — List the version history of a playbook, newest first. Use this to explain what changed and when before proposing an edit or a rollback. Read-only.

rumo_list_skills — List the skills on a playbook — the individual behaviors the assistant can run, in execution order — with each one's trigger, on/off state and schedule window (active_from / active_until: a scheduled skill switches itself on and off). The list leaves out the skill bodies to stay small (content_chars gives each size); pass skill_name to read that one skill's full content before editing it. Read-only.

rumo_get_kb — Read one knowledge base: type, training status (only active is live; added/edited are waiting for rumo_train_assistant) and an item inventory with the ids rumo_patch_kb_items takes. Use it to check a KB is actually trained before blaming an assistant answer on its instructions, and to verify an edit went live. Read-only; 50 items per page (offset), search filters by text.

rumo_get_training_status — Read an assistant's training job: pending, running (with progress), completed (the knowledge base changes are live) or failed (with the error). Pass the job_id from rumo_train_assistant, or omit it for the latest job. Read-only.

rumo_list_api_tools — List the API tools an assistant may call, with method and endpoint. Use this to explain what external actions the assistant can take. Read-only; secrets and auth headers are never returned.

rumo_list_example_blocks — List the example blocks steering an assistant's tone and format (few-shot examples). Small surface, high leverage on how replies read. Read-only.

rumo_get_assistant_schedule — Read a playbook's schedule: the assistant's own office hours, the project schedule it falls back to, and date overrides. Check this before concluding an assistant ignored a conversation — it may simply have been off. If a schedule cannot be read the tool fails rather than guessing; never report such an assistant as always on. Read-only.

rumo_preview_jmespath — Preview how a JMESPath expression reshapes a sample API response. Makes no outbound request and saves nothing — use it to get response_transform right before saving an API tool.

rumo_list_eval_cases — List the eval cases of an assistant playbook — the test suite that says whether a change helped or hurt. Read-only. base_id is the playbook's base id (rumo_list_assistant_playbooks), NOT a version id; a version id is refused with the base id to use. Returns each case's id, name, enabled flag, assertion types and mocked tools; read one in full with rumo_get_eval_case. Deleted cases are hidden unless include_deleted is true.

rumo_get_eval_case — Read one eval case in full: scenario_blocks, assertions, tool mocks, user_context, flow steps and its enabled/deleted state. Read-only. Read this before rumo_update_eval_case: assertions, tool_mocks, user_context and scenario_blocks are replaced whole on update, so start from what is here. A legacy case (free-text scenario or uncategorized text assertions) is flagged in must_fix_before_editing — Studio refuses any edit until those are fixed. 404 = wrong id or a deleted case: pass include_deleted: true.

rumo_get_eval_case_history — Recent executions of one eval case (newest first): status, assertions passed, the playbook version and run of each. Read-only. Use it to tell a flaky case (mixed results on the same version) from a regression (passed on the old version, fails on the new). Open a result with rumo_get_eval_result.

rumo_list_eval_runs — List past eval runs for a playbook (newest first, one page), so run ids can be found without starting a new run. Each run names the playbook version it tested. Read-only — this is how you get the two ids rumo_diff_eval_runs needs. base_id is the playbook base id; filter one version with playbook_id (a version id).

rumo_get_eval_run — Read an eval run: its status, the playbook version it tested, and per-case results with the assertions that did not pass. Read-only. Status goes pending → running → completed | failed | cancelled. A pending or running run has no verdict — poll again in 30-60 s (a run of many cases takes minutes); a failed or cancelled run has none either. Never describe those as passing or failing. For why one case failed (conversation, tool calls), open its result_id with rumo_get_eval_result. A case in status error did not run to the end (see error_message): that is a test problem, not an assistant failure.

rumo_get_eval_result — Read one case's result in one run: every assertion's verdict (passed / failed / ambiguous) with the judge's explanation, and the simulated conversation with each assistant turn's tool calls (arguments, mocked or real, errors, results) and events (handoffs, labels, notes). Read-only. This is how you find WHY a case failed. status 'error' means the case could not run (error_message says why — often 'no mock matched call …' when a mocked tool was called with arguments no rule covers), not that the assistant behaved badly. Note: text assertions are judged on what the assistant said plus the names/arguments of its tool calls, never on tool results — check tool use with tool_called / tool_not_called assertions.

rumo_diff_eval_runs — Compare two eval runs case by case — the direct answer to 'did that playbook change make the assistant better or worse'. Read-only. Put the older run (before the change) as run_a and the newer as run_b. Cases are matched by name, so a renamed case shows as removed + added. Diff only finished runs: a pending/running run has no results yet.

rumo_get_eval_coverage — Which of an assistant version's configured tools and skills its eval suite exercises (overall %), plus informational categories (handoff, tags, knowledge bases, private notes). Read-only, computed on demand, no model cost. An item is covered 'static' (a case asserts or mocks it), 'executed' (seen in the latest completed run) or 'both'. The item keys of the tools category are the exact tool names to use in tool_called assertions and tool_mocks. base_id is the playbook base id; version is a version NUMBER (default latest), not a version id.

rumo_get_eval_metrics — Health of an assistant's eval suite: case counts, the latest completed run's case and assertion pass rates, the pass-rate trend, pass rate per assertion type, per-case recent outcomes, and eval cost. Read-only. Pass matrix_runs (1-30) to also get the cases × recent runs matrix (each cell's status and result_id), which shows flaky cases and regressions at a glance. base_id is the playbook base id.

rumo_get_performance_report — Account performance over a date range, assembled from both halves of the platform: conversation handling by human agents (Rumo) and assistant behavior (Studio). The two halves count different populations over different denominators and are returned separately, each labelled with what it measures. Never combine them into one figure — there is no shared denominator, so a 'deflection' or 'automation' rate cannot be derived from this tool. Read-only.

rumo_list_report_definitions — List Studio report *definitions* — the scheduled, assistant-scoped narrative reports configured for an assistant, delivered to Slack. This returns their configuration, not their content: there is currently no tool that reads what a report said. Covers assistant behavior only; for account conversation metrics use rumo_get_performance_report. Read-only.

rumo_list_templates — Discover WhatsApp templates for one account-scoped inbox, including language, category, review status, placeholders, and whether the current status is eligible for sending. Read-only; APPROVED status is required for send eligibility.

rumo_preview_template — Preview a WhatsApp template as a rendered MCP-UI card (a real Meta-accurate WhatsApp bubble the client shows inline). Call this DIRECTLY — inbox_id is OPTIONAL and you should NOT ask the user for it; if omitted, a sample/first template is previewed. Optionally pin a template by template_id or name, and pass sample_variables to fill {{placeholders}}. To let someone compare and pick, pass versions (2–10): each is an existing template (template_id/template_name, own sample_variables) or a draft given inline (body, plus optional header, footer, buttons, category); they come back as one swipeable carousel. The JSON carries preview_url, a short link to the interactive preview (or carousel) shown in a phone with the client's WhatsApp line name and picture, and for a single template image_url, a PNG of that phone with the sample variables filled in. Where the card can't render — WhatsApp, SMS, email, chat apps — send image_url as an image and/or preview_url as a link; a carousel has no image, send its preview_url. image_url may be null; never invent a link.

rumo_parse_contacts — Parse and clean a raw CSV before any contact import. Uses international libphonenumber metadata, understands national/international formats and per-row country columns, normalizes valid recipients to E.164, and conservatively excludes ambiguous, invalid, duplicate, extension, or spreadsheet-corrupted numbers. Returns row-level correction evidence; read rumo://guide/csv-phone-normalization first.

rumo_get_contact_import — Poll one account-scoped asynchronous contact import receipt.

rumo_list_campaigns — List canonical campaigns for the bound account, including optional archived filtering, pagination, and sorting.

rumo_get_campaign — Get the canonical configuration for one account-scoped campaign after creation.

rumo_get_campaign_status — Get current delivery-processing status for one account-scoped WhatsApp campaign.

rumo_get_campaign_analytics — Analyze account-scoped campaign delivery and engagement events with optional status filtering and pagination.

rumo_preview_campaign_audience — Resolve the exact account-scoped SQL union of Label and Segment audience sources, de-duplicate it, exclude blocked/missing recipients, and return capped synthetic-safe samples. This is read-only even though the filter body uses POST.

rumo_preview_campaign_message — Test a campaign's variables on REAL contacts before creating it: fills the template's slots from the same variable mapping the campaign will send, resolves every {{contact…}} reference against real contact records the way the platform does, and returns the final message per contact. Reports slots that are literal (same text for everyone), unresolved for a given contact (missing attribute), or mismatched with the template. Pass the audience (Label/Segment) to sample from it, or explicit contact_ids. Read-only.

rumo_build_campaign — Show an INTERACTIVE campaign confirmation card for the user to review and approve. It renders the template, a summary (how many contacts, what time it sends), and a contact picker that live-updates the real WhatsApp preview so the user can see the exact final message per contact. It has an Approve button. Call this to confirm a campaign before scheduling — pass the parsed contacts (the sample from rumo_parse_contacts) so the picker works. After the user approves in the card, you will get a message to call rumo_create_campaign, which is the single tool that creates and schedules the campaign.

rumo_send_direct — Preview and send a WhatsApp Direct template message either through an existing wrapper or by inbox/template name. The approval response includes MCP UI plus copyable secret-free REST/MCP requests. STEP-UP REQUIRED. LOCAL_DEV is always a synthetic dry run.

rumo_label_conversation — Set the full label list on a RUMO conversation (replaces existing labels). STEP-UP REQUIRED: first call returns approval token + summary; second call with `approval_token` applies.

rumo_manage_conversation — Manage one authorized conversation: status/snooze, priority, assignment, append-or-replace labels, mute/read state, participants, or custom/additional attributes. Every mutation requires bound single-use approval. Bulk changes are intentionally unavailable until the upstream bulk authorization path is repaired.

rumo_send_conversation_message — Send a customer-visible reply or add a private note to one conversation. The exact content and privacy flag are bound to a single-use approval token.

rumo_import_campaign_contacts — Re-run standards-based phone normalization, attach one dedicated campaign label to every unique valid row, and upload only that normalized E.164 CSV through the canonical asynchronous contact-import API. Invalid or ambiguous rows are excluded and summarized before bound approval.

rumo_manage_contact — Create one contact, or update one by contact_id: name, email, phone (E.164), custom attributes, and labels (added by default, or replaced with label_mode=replace). For many contacts from a file use rumo_parse_contacts + rumo_import_campaign_contacts. Never messages anyone. NEEDS APPROVAL: the first call returns a plain-language summary and an approval token; re-call with the same arguments plus approval_token to apply.

rumo_create_campaign — Create a canonical scheduled campaign from server-resolved Label and/or Segment audience sources after the full campaign preview. Returns exact REST and MCP request forms without secrets. Bound single-use approval is required; LOCAL_DEV remains synthetic and never enqueues a provider send.

rumo_update_campaign — Update an existing campaign configuration after a bound approval. Re-preview audience/template details before changing them.

rumo_archive_campaign — Archive a campaign after bound approval. Use this reversible action to remove it from the active campaign list.

rumo_unarchive_campaign — Restore an archived campaign to active status after bound approval.

rumo_create_template — Create a WhatsApp message template. STEP-UP REQUIRED: first call returns an approval token + a rendered MCP-UI preview of exactly what will be submitted; the user confirms, then the second call (with approval_token) submits it. In LOCAL_DEV / test mode it composes and previews the template without calling Meta (status TEST_DRAFT); in production it POSTs to the WhatsApp Cloud inbox. Every value that differs per recipient (name, order, date, amount) MUST be a placeholder — NAMED ({{nombre}}) or positional ({{1}}); text without placeholders reaches every recipient identically. Name NAMED slots after the CSV columns they will be filled from so the campaign mapping is one-to-one. Placeholders may not sit at the very start or end of the body.

rumo_create_kb — Create a knowledge base on an assistant from text, FAQ pairs, or snippets. STEP-UP REQUIRED: the first call returns a summary and an approval token; re-call with the token to create it. The new KB is saved but NOT live: the assistant only answers from it after rumo_train_assistant, and rumo_get_training_status reports when that finished. kind=faq: items [{questions: ["..."], answer}] (one `question` string is accepted); kind=snippets: items [{title, content}]; kind=text: content. File upload is not exposed here.

rumo_update_kb — Replace a knowledge base's title, text content (kind text) or WHOLE item list (kind faq / snippets). STEP-UP REQUIRED. Items replace the entire list: every current item you leave out is DELETED. To add, change or remove single FAQ/snippet items, use rumo_patch_kb_items instead. The change is saved but NOT live until rumo_train_assistant; rumo_set_kb_state action=rollback undoes it while it is still untrained.

rumo_patch_kb_items — Add, change or delete single items of a faq or snippets knowledge base without resending the rest. STEP-UP REQUIRED. add: new items without id (faq {questions, answer}; snippets {title, content}). update: {id, ...only the fields to change} (item ids come from rumo_get_kb). delete: item ids. All-or-nothing: if any part is invalid nothing changes. Saved but NOT live until rumo_train_assistant.

rumo_set_kb_state — Archive, unarchive, restore, or roll back a knowledge base. STEP-UP REQUIRED. rollback undoes the last change that has NOT been trained yet (status added or edited); after training it is refused. Prefer this over deleting, which this MCP does not expose.

rumo_train_assistant — Train an assistant: apply every pending knowledge base change (KBs in status added or edited) so the assistant starts answering from it. STEP-UP REQUIRED. Until this runs, KB edits are saved but not live. Training runs in the background: the result carries a job id; poll rumo_get_training_status until it is completed. While it runs, knowledge base edits are locked. Many accounts require a person to approve training: then it comes back pending_approval with a review_url and nothing trains until it is approved.

rumo_upsert_skill — Create or update one skill on a playbook — this changes what the assistant actually does. STEP-UP REQUIRED. Read rumo_list_skills (with skill_name for the current content) and rumo_get_playbook first; a skill edit creates a new playbook version, and rumo_rollback_playbook is the undo. For a temporary skill (a promotion, a holiday notice, "for two days") set active_until (and optionally active_from): outside that window the skill is off by itself. Each bound needs a timezone: an offset (2026-11-05T09:00:00-03:00) or schedule_timezone with local times. On update, null clears a bound; omitted keeps it. Errors: a bound without a timezone, an unknown IANA zone, or active_until not after active_from are refused before approval; an unknown argument is refused instead of being silently dropped.

rumo_reorder_skills — Set the evaluation order of a playbook's skills. STEP-UP REQUIRED. Order is behavior: the assistant evaluates skills in this sequence, so reordering can change which one fires.

rumo_rollback_playbook — Restore an earlier version of a playbook — the undo for a bad skill or instruction edit. STEP-UP REQUIRED. Use rumo_get_playbook_history first and pass the version you want back; this creates a NEW latest version with that version's content (history is never deleted).

rumo_manage_example_block — Create or update a few-shot example block steering the assistant's tone and format. STEP-UP REQUIRED. Small surface, strong effect on how replies read.

rumo_manage_api_tool — Create or update an API tool the assistant may call. STEP-UP REQUIRED. Validate the request with rumo_test_api_tool before saving. Credentials passed here are written upstream and are never echoed back.

rumo_create_assistant — Create a new assistant (a playbook) in the account's AI Studio project: its name, its instructions, and optionally the knowledge bases and API tools it may use. It answers nobody until rumo_deploy_assistant puts it on an inbox. Administrators only. NEEDS APPROVAL: the first call returns a summary and an approval token; re-call with the same arguments plus approval_token.

rumo_set_assistant_tools — Choose exactly which API tools an assistant may call: pass the full list (tools not in it are switched off). Saves a new playbook version, so rumo_rollback_playbook undoes it. Administrators only. NEEDS APPROVAL: the first call returns a summary of what is switched on and off and an approval token; re-call with the same arguments plus approval_token.

rumo_deploy_assistant — Put an assistant on one of the account's inboxes: from then on it answers new conversations there (replacing the assistant that answered before, if any). Uses the assistant's latest version. Administrators only. NEEDS APPROVAL: the first call returns a summary and an approval token; re-call with the same arguments plus approval_token.

rumo_test_api_tool — Execute an API tool definition against its real endpoint and return the response, without saving it. STEP-UP REQUIRED: this makes a real outbound request to a third-party system from the platform. Use it to validate a tool before rumo_manage_api_tool.

rumo_create_eval_cases — Create one or more eval cases (up to 100) on an assistant playbook. STEP-UP REQUIRED. base_id is the playbook base id (rumo_list_assistant_playbooks), not a version id. Every case needs name, complete scenario_blocks and assertions; text assertions need a category. The shape is checked BEFORE the approval token is issued and every problem is listed, so fix them all and call again. Common refusals: a version id as base_id (the message names the base id), a duplicate name (change the existing case with rumo_update_eval_case instead), an unknown assertion type, a mock rule with both/neither return_value and error, flow_steps on an account without the flow_eval_steps flag. Creating cases runs nothing: then rumo_run_eval with the new case_ids.

rumo_update_eval_case — Change an eval case: rename, enable/disable (is_enabled), or replace its scenario_blocks, assertions, tool_mocks, user_context, max_turns or flow_steps. STEP-UP REQUIRED. Each field you pass REPLACES the stored one (assertions is the whole list; tool_mocks the whole map; scenario_blocks the whole tree): read rumo_get_eval_case first and send the edited complete value. Studio validates the case that would result, so a legacy case (free-text scenario or uncategorized text assertions) cannot be changed at all — not even disabled — until the same call brings complete scenario_blocks and categorized assertions. Disabling (is_enabled: false) keeps a case out of full runs without deleting it; past results are unaffected by edits (each result keeps a snapshot of the case it ran).

rumo_delete_eval_case — Delete an eval case (soft delete: it leaves the list and stops running; rumo_restore_eval_case brings it back). STEP-UP REQUIRED. Past runs and results keep their own snapshot of the case, so deleting a case that runs reference is safe and does not change those results or diffs. Needs the ai_studio:delete permission (account administrators); with only ai_studio:write, disable the case instead: rumo_update_eval_case with changes {is_enabled: false}.

rumo_restore_eval_case — Bring back a deleted eval case. STEP-UP REQUIRED. Find deleted cases with rumo_list_eval_cases include_deleted: true. Refused when a live case now has the same name: rename or delete that one first.

rumo_run_eval — Start an eval run against ONE exact playbook version. STEP-UP REQUIRED: a run executes the assistant against every case and consumes model budget. base_id is the playbook base id; playbook_id is a VERSION id (rumo_get_playbook_history or rumo_get_playbook), not the base id — passing the base id, or a version of another playbook, is refused with the id to use. The approval names that version, so the verdict is evidence about it and nothing else. Omit case_ids to run every ENABLED case (refused when there are none); case_ids may name disabled cases. Returns a run id with status pending; it does not wait. Poll rumo_get_eval_run every 30-60 s until status is completed, failed or cancelled — never report a verdict before that. Wrong version or cases? rumo_cancel_eval_run.

rumo_cancel_eval_run — Stop a pending or running eval run, e.g. one started against the wrong version or with the wrong cases, to stop spending model budget. STEP-UP REQUIRED. Cases already executing finish their result; no further cases start; a cancelled run has no verdict. A run that already ended cannot be cancelled (the tool says so before asking for approval).

rumo_list_automation_rules — List the account's automation rules: what event triggers each one, its conditions and actions, and whether it is on. Read-only.

rumo_invite_agent — Invite a person to the account as an Agent or Administrator. Someone without a Rumo login is emailed an invitation to set a password. They start in no inbox and no team — add them with rumo_set_inbox_members and rumo_set_team_members. Invite as Agent unless the user explicitly asks for Administrator: administrators can change every setting, including who has access. NEEDS APPROVAL: the first call returns a plain-language summary and an approval token; re-call with the same arguments plus approval_token to send the invitation.

rumo_update_agent — Change a person's role (agent ↔ administrator), availability (online, busy, offline), or whether they go offline automatically when they disconnect. Use rumo_list_agents for the id. Cannot change your own role — this connection acts as you. NEEDS APPROVAL: the first call returns a plain-language summary and an approval token; re-call with the same arguments plus approval_token to apply.

rumo_remove_agent — Remove a person from the account. They lose access immediately, are taken off every team and inbox in this account, and their assigned conversations become unassigned. If this was their only account, their Rumo login is deleted too. Re-inviting does not restore teams, inboxes or assignments. Cannot remove yourself. NEEDS APPROVAL: the first call returns a plain-language summary and an approval token; re-call with the same arguments plus approval_token to remove them.

rumo_create_team — Create a team (a group of people conversations can be assigned to). The platform stores team names in lowercase. The team starts empty — add people with rumo_set_team_members. NEEDS APPROVAL: the first call returns a plain-language summary and an approval token; re-call with the same arguments plus approval_token to create it.

rumo_set_team_members — Change who is in a team: action=add puts the listed people in it, action=remove takes them out, action=replace makes the listed people the whole team (everyone else is taken out). Use rumo_list_teams and rumo_list_agents for ids. NEEDS APPROVAL: the first call returns a plain-language summary naming everyone added and removed, plus an approval token; re-call with the same arguments plus approval_token to apply.

rumo_get_notification_settings — Read which events send a person an email or a push notification (browser and mobile app) in this account: a new conversation, a conversation assigned to them, a mention, new messages in their conversations, customer reactions, missed SLAs; plus whether they get their teams' notifications. Omit user_id for yourself. Only an administrator can read someone else's.

rumo_update_notification_settings — Turn email or push notifications (browser and mobile app) on or off for specific events for a person in this account, and whether they get their teams' notifications. Only the events you name change; everything else stays as it is. Omit user_id for yourself; only an administrator can change someone else's. Read the current settings first with rumo_get_notification_settings. NEEDS APPROVAL: the first call returns a plain-language summary and an approval token; re-call with the same arguments plus approval_token to apply.

rumo_manage_label — Create a label, or update one by label_id: title, description, color (#RRGGBB) and whether it shows in the sidebar. Titles are stored in lowercase and may contain only letters, numbers, - and _. Renaming a label renames it on every conversation and contact that carries it. NEEDS APPROVAL: the first call returns a plain-language summary and an approval token; re-call with the same arguments plus approval_token to apply.

rumo_update_inbox_settings — Change an inbox's basic settings: name, greeting_enabled, greeting_message, enable_auto_assignment, working_hours_enabled, out_of_office_message, timezone. Nothing else can be changed here — channel credentials, webhooks, CSAT and business-hours schedules stay in the dashboard, and any other field is refused. Use rumo_list_inboxes for the id. NEEDS APPROVAL: the first call returns a plain-language summary and an approval token; re-call with the same arguments plus approval_token to apply.

rumo_set_inbox_members — Change which people work an inbox: action=replace (default) makes the listed people its whole agent list and takes everyone else off, action=add puts the listed people on it, action=remove takes them off. Agents taken off lose access to that inbox's conversations; administrators still see everything. Use rumo_list_inboxes and rumo_list_agents for ids. NEEDS APPROVAL: the first call returns a plain-language summary naming everyone added and removed, plus an approval token; re-call with the same arguments plus approval_token to apply.

rumo_set_automation_rule_active — Turn an automation rule on or off. Its conditions and actions are kept either way, so this is reversible. A rule that is turned on acts on new events right away — check its actions with rumo_list_automation_rules first, since some send messages to customers. NEEDS APPROVAL: the first call returns a plain-language summary and an approval token; re-call with the same arguments plus approval_token to apply.

rumo_app_list — List the apps this account has built with Rumo Builder: id, name, status, draft version and build, live version, URLs, whether the app serves WhatsApp Flows (a 'flows' placement) and the flows linked to it.

rumo_app_create — Create a new app from the Rumo template: its own code repo, database (live + preview) and a first preview build. Returns the app and a job; poll the job with rumo_app_job. Then read AGENTS.md and README.md with rumo_app_files before changing anything. Read rumo://guide/apps first.

rumo_app_get — One app in full: draft (version + build status), live version, preview/live URLs, placements from rumo.app.json, and its resources. flows says whether the app serves WhatsApp Flows (a 'flows' placement), which flows are linked to it, and the gateway's routes and recent requests.

rumo_app_files — Read the app's code. Without path (or with a directory) returns the file tree; with a file path returns its content. ref is 'draft' (default), 'live', or a version number. The result's commit is what you pass as base to rumo_app_save. Read AGENTS.md and README.md first in every app.

rumo_app_save — Save a small, coherent change to the app's draft: pass ONLY the files that changed ({ path, content } to write, { path, delete: true } to remove), at most 60 files and 2 MB per save, paths relative to the app root. base is the commit your edit is based on (the commit from rumo_app_files, or the version.commit of your previous save): if someone saved since, nothing is written and you get conflict: true with what changed — re-read, merge and save again with the new base. message says what changed and why, in plain words (it becomes the commit message, with you and 'via Rumo MCP · Claude' as the author). Creates a new draft version and queues a build (checks, bundle, the app's tests, preview deploy, smoke checks); follow it with rumo_app_build_status. Never put secrets in files — use rumo_app_set_secret. Nothing goes live until rumo_app_publish.

rumo_app_versions — The app's versions, newest first: number, note, author, build status (with log_tail and checks), and which one is live.

rumo_app_diff — Per-file patches. Two uses: (1) between versions or commits — defaults from = the live version, to = 'draft'; use it to tell the person what a publish would change. (2) with files (same shape as rumo_app_save): what that save WOULD change against base (default: the draft), without writing anything.

rumo_app_job — Status of a long-running app job (create, build, publish, restore): steps, result, error. Pass wait_seconds (up to 25) to wait on the server, checking every 2 seconds, until the job is ok or failed. When a publish or restore job is ok, the app's screens show in Rumo for the account within a minute.

rumo_app_preview — The preview (draft) URLs of the app — the full-screen page and the conversation panel when the app has them — with an inline card when the client can show one. Share the link with the person and ask them to try it before publishing. The preview uses the preview database, never live data.

rumo_app_publish — Make a version live for the account (default: the draft's latest version). Backs up the live database, runs the version's migrations on it, deploys it, and updates the app's screens in Rumo. Only a version whose build is ok AND whose tests and smoke checks passed: otherwise it is refused with the failures (fix and save again). An administrator may override with force_reason (why the failures don't matter); it is recorded. Ask the person first, after they have tried the preview. Administrators only. NEEDS APPROVAL: the first call returns a plain-language summary and an approval token; re-call with the same arguments plus approval_token. Then poll the returned job with rumo_app_job.

rumo_app_restore — Roll the live app back (or forward) to an earlier version: redeploys that version live and, if its database schema differs from the live one, restores the database backup taken for it — data written since that backup is lost. Administrators only. NEEDS APPROVAL: the first call returns a plain-language summary and an approval token; re-call with the same arguments plus approval_token. Then poll the returned job with rumo_app_job.

rumo_app_db — The app's database at a glance: branches, tables with row counts, size, backups, and how far back it can be restored.

rumo_app_db_query — Run a read-only SQL query against the app's database — the preview branch by default; branch 'main' reads live data. At most 200 rows. Schema changes are never made here: they are migrations in the repo, run at publish.

rumo_app_backup — Take a manual backup of the app's live database now (publishes also back up on their own). Optional label.

rumo_app_metrics — Live usage of the app: requests, errors, p95 latency, per placement, and a time series. range is 1h, 24h (default) or 7d.

rumo_app_logs — Recent requests to the app (live and preview): time, env, method, path, status, duration, placement. limit 1–200, default 50. placement narrows to one kind: 'flows' for WhatsApp Flows gateway requests (screens Meta asked the app for), or fullscreen, panel, tools, outbound (blocked outbound calls).

rumo_app_set_secret — Store a secret (an API key, a password) the app reads from its environment, for the live or the preview app. The value is never shown again — not by this tool, not by any other. Never put secrets in files. Names are UPPER_SNAKE_CASE. Administrators only. NEEDS APPROVAL: the first call returns a summary (without the value) and an approval token; re-call with the same arguments plus approval_token.

rumo_app_clone_url — A READ-ONLY git clone URL for the app's repo (token valid for one hour), for reading many files locally. It is a credential: do not save it in files or share it. Pushing with it is refused. To change the app use rumo_app_save; for plain-git pushes an administrator can approve rumo_app_git_credentials.

rumo_app_build_status — A build of the app: status per step (checks, bundle, test, migrate-preview, deploy-preview, smoke-preview, flows), timings, test and smoke-check summary, whether it can be published and why not. Default: the draft's build. Pass wait_seconds (up to 25) to wait until it ends. Also lists the latest builds.

rumo_app_build_logs — Full logs of a build's steps (default: the draft's build, all steps). Pass step (e.g. 'bundle', 'test', 'smoke-preview') to read one. Long logs keep their end.

rumo_app_test — The app's test results for a build (default: the draft's build): every test (file, name, passed/failed/skipped, duration, error), captured output, each smoke check against the preview (path, expected and actual status, error) and flow scenarios. Read-only; to run them again, rebuild with rumo_app_rebuild.

rumo_app_history — The app's commit history (newest first): sha, message, author (who, via what), version, build verdict, and which commit is live. Pass commit to show one commit in full with its per-file patches. ref is 'main' (the draft, default), 'live' or a branch.

rumo_app_revert — Undo one commit of the draft as a NEW commit (history is kept): every file that commit changed goes back to how it was before it. Refused when those files changed again later (then edit them by hand with rumo_app_save). Builds like a save; nothing goes live until rumo_app_publish. Pass base = the draft's current commit, like rumo_app_save.

rumo_app_rebuild — Rebuild the draft (the head of main) to run its tests and smoke checks again, e.g. after a flaky check. It redeploys the PREVIEW only; nothing goes live until rumo_app_publish. Follow it with rumo_app_build_status (wait_seconds up to 25), then read rumo_app_test.

rumo_app_git_credentials — Write access to the app's git repo for one hour, for people who work with plain git or push from their own repo/CI. A push to main builds a new version exactly like a save (tests, preview); other branches are built and tested only; live cannot be pushed (only rumo_app_publish moves it). There are no server-side hooks: a push that fails the checks lands and its build fails. The URL is a credential: give it only to the person, never put it in files. Administrators only. NEEDS APPROVAL: the first call returns a summary and an approval token; re-call with the same arguments plus approval_token.

rumo_app_gateway — What the app exposes outside Rumo's login, per environment (live and preview): public pages (/p/..., anyone can open them, with their URLs and rate limits), webhooks (/hooks/, URL, signature scheme, the secret's NAME and whether it is set — never its value) and scheduled jobs with their state and last run. Everything here is declared in rumo.app.json and enforced by Rumo; anything not listed answers 404.

rumo_app_schedules — The app's scheduled jobs (placements.schedules): cron, time zone, state (active, paused, disabled), next run and last run. With job, also that job's run log (start, end, status ok/failed/timeout/skipped/lost, reason, duration; newest first; limit 1-100, default 20; env narrows to live or preview). Only the live version runs on schedule; the preview runs a job only when asked (rumo_app_schedule_control run).

rumo_app_webhook_deliveries — Recent deliveries to one of the app's webhooks, newest first: time, delivery id, the status Rumo answered, why it was refused (bad_signature, stale_timestamp, rate_limited, duplicate, ...) and the app's own status. Bodies are never stored. env: live (default) or preview; limit 1-200, default 50.

rumo_app_schedule_control — Pause, resume or run now one of the app's scheduled jobs, without publishing. pause stops it from running on schedule (it stays paused across publishes); resume starts it again (administrators); run queues one run now — env live (administrators) or preview (to try a job before publishing) — and it starts within a minute. Follow it with rumo_app_schedules (job). NEEDS APPROVAL: the first call returns a summary and an approval token; re-call with the same arguments plus approval_token.

rumo_list_flows — List the WhatsApp Flows (native in-WhatsApp forms) of one WhatsApp Cloud inbox: name, status (draft, published, deprecated, throttled, blocked), static or powered by a Rumo app, published/draft versions, sends and completions in the last 30 days, and the templates that use each. Read rumo://guide/flows before building or changing a flow.

rumo_get_flow — One WhatsApp flow with its current Flow JSON (the draft if there is one, else the published version), Meta's validation errors, and the field map (key → label, screen, type, sensitive). Read it before editing: rumo_draft_flow replaces the whole Flow JSON.

rumo_draft_flow — Create a new WhatsApp flow as a draft, or replace an existing flow's draft (pass flow_id), from Flow JSON. Nothing reaches customers: a draft can only be previewed until rumo_publish_flow. Returns Meta's validation errors; fix and call again until there are none, then rumo_preview_flow. Pass endpoint {app_id} only when a Rumo app serves dynamic screens (data_exchange). Flow JSON rules (Meta rejects violations — do not guess): use "version": "7.3"; screens[] each with a unique id of letters and underscores ("SUCCESS" is reserved), an optional title, and layout {type: "SingleColumnLayout", children: [...]}; at most 50 components per screen; at most ONE Footer per screen and every terminal screen ("terminal": true) must have one; the last screen's Footer uses on-click-action {name: "complete", payload: {...}} and that payload is exactly what Rumo stores as the response, so name its keys clearly ("email", not "field_1"); earlier screens use {name: "navigate", next: {type: "screen", name: "NEXT_ID"}}; reference inputs as ${form.} and screen data as ${data.}; labels ≤20 chars on TextInput, Footer label ≤35, TextHeading/TextSubheading ≤80, 1–20 options for RadioButtonsGroup/CheckboxGroup, ≤200 for Dropdown, at most 5 OptIn and 2 EmbeddedLink per screen, one PhotoPicker/DocumentPicker per screen. Mark personal data with the screen's "sensitive": [field names]. A static flow (no app) has no data_api_version or routing_model. A flow powered by a Rumo app (endpoint) needs "data_api_version": "3.0" and a "routing_model" {SCREEN: [next screens]} with at most 10 branches. Keep a flow under 5 minutes for the customer. NEEDS APPROVAL: the first call returns a summary and an approval token; re-call with the same arguments plus approval_token.

rumo_preview_flow — Show a WhatsApp flow as a tappable phone preview the person can walk through screen by screen (an inline card in clients that show MCP Apps or MCP-UI; otherwise a link). Previews the draft when there is one, else the published version. Always preview before asking to publish.

rumo_publish_flow — Publish a flow's draft so templates, campaigns, assistants and agents can send it to customers. Only after the person tried rumo_preview_flow. Later edits become a new draft and the published version keeps running. Administrators only. NEEDS APPROVAL: the first call returns a summary and an approval token; re-call with the same arguments plus approval_token.

rumo_deprecate_flow — Retire a published flow permanently: it can no longer be sent, and templates whose button opens it stop working. Cannot be undone. Administrators only. NEEDS APPROVAL: the first call returns a summary and an approval token; re-call with the same arguments plus approval_token.

rumo_send_flow — Send a published WhatsApp flow inside an open conversation, as a message with a button that opens the form. Only within 24 hours of the customer's last message (otherwise use a template with a FLOW button: rumo_create_template, then rumo_send_direct or a campaign). The answers come back into the conversation and to rumo_list_flow_responses. NEEDS APPROVAL: the first call returns a summary and an approval token; re-call with approval_token.

rumo_list_flow_responses — Completed answers to one flow, newest first: contact, conversation, answers by field, whether the send token verified, the source (campaign, direct, composer, assistant) and attached media. Sensitive fields are masked unless the connected person is an administrator. Never repeat answers outside what the person asked for.

rumo_export_flow_responses — Start an export of a flow's responses (CSV one column per field, Excel, or raw JSON), optionally including sends nobody answered, or check an export's status by passing export_id. Large exports are emailed to the person. The download link expires; share it only with them.

rumo_simulate_flow — Test a WhatsApp flow without a phone. Rumo plays WhatsApp's part with a real flow token, calls the flow's Rumo app (live or preview version) through the same gateway Meta uses — the app is told the call is simulated — and checks the answers as it would for a real customer. Give a `scenario` (what the customer taps and what must happen), or `explore: true` to walk every branch, or neither for a smoke run of the first path. Returns a transcript: screens per run, each app call with its time against the 2.5 s budget, failures, and whether Rumo verified the answer. completion dry_run (default) also shows what the assistant would see; no customer is contacted and no answer is saved (Rumo only logs the run as simulated). The flow's app IS called for real, marked as a simulation (x-rumo-flows-sim: 1), and is expected to skip side effects such as bookings. Scenario: {prefill?, steps: [...]}; each step is one of {expect_screen: ID, expect_data?: {key: matcher}}, {select: {field: value}, tap?: label}, {fill: {field: value}, tap?: label}, {tap: "button label or NavigationList item"}, {back: true}, {expect_endpoint_ms: {max: 2500}}, {expect_error_message: text}, {expect_complete: {answers: {key: matcher}, verified: true}}. Values: a literal, "$first", "$last" or "$index:N" (options of that field). Matchers: a literal, "$any", or {min_items, max_items, equals, contains, matches}.

rumo_agentforce_get_agent — Read the account's Salesforce Agentforce agent as Rumo sees it: agent-level instructions, every subagent (scope, instructions, actions, whether Rumo created it), the actions available to attach, the revision to pass back on edits, whether "Gestión desde Rumo" management is granted, and whether the Rumo sets action is installed. Call this first, before any Agentforce change. Read-only.

rumo_agentforce_list_tools — List the tools (Salesforce External Services) Rumo deployed for the Agentforce agent: operations, base URL, auth type, which subagents use each, deploy status and last error. Secrets are never returned (has_secret says whether one is stored). Read-only.

rumo_list_sets — List the account's Rumo sets: predefined buttons, lists and cards that live in Rumo and that the Agentforce agent can show by key. Returns key, kind, item count and titles; read one in full with rumo_get_set. Read-only.

rumo_get_set — Read one Rumo set with every item. With preview: true it also returns the message Rumo would send for it (content, content_type, content_attributes) on an Embedded inbox. Read-only; nothing is sent.

rumo_agentforce_trusted_domains — List the Salesforce trusted domains (CSP trusted sites) of the Agentforce org. An image or link whose domain is not trusted reaches the customer as URL_Redacted. Read-only.

rumo_agentforce_list_tests — List the Salesforce Testing API tests (AiEvaluationDefinition) that target this Agentforce agent, with case counts and the last run's result. Read-only.

rumo_agentforce_get_test_run — Read one Salesforce test run started with rumo_agentforce_run_test: status, per-case pass/fail and the failed expectations (expected vs actual). Poll until finished is true before reporting a verdict. Read-only.

rumo_agentforce_versions — List the snapshots Rumo took of the Agentforce agent before each change it deployed (newest first, last 30): id, when, who, what changed. Use with rumo_agentforce_restore_version. Read-only.

rumo_agentforce_activity — Summarize how the Agentforce agent has been answering in Rumo: replies, conversations, median latency, handoffs, failures and images/links Salesforce blocked (blocked_urls), plus the latest turns. Read-only.

rumo_agentforce_update_agent — Replace the Agentforce agent's agent-level instructions (the planner description). Use for rules that apply to every subagent; put topic-specific rules in rumo_agentforce_upsert_subagent. Needs approval: the first call returns a summary and token. Never put secrets in instructions.

rumo_agentforce_upsert_subagent — Create or replace one Agentforce subagent (topic): label, description, scope, its instruction list and the actions it may use (tools, the Rumo sets action, existing Salesforce actions). Send the full definition; omitted instructions or actions are removed. Needs approval: the first call returns a summary of what changes and a token.

rumo_agentforce_manage_tool — Create, update or delete a tool for the Agentforce agent. A tool is an HTTP API Rumo deploys to Salesforce as an External Service (Named + External Credential, registration, agent actions, permissions) and attaches to the listed subagents. Put an API key or token ONLY in auth_secret: it is stored encrypted and never shown again. Test with rumo_agentforce_test_tool after saving. Needs approval: the first call returns a summary and token.

rumo_agentforce_test_tool — Call one operation of a saved Agentforce tool from Rumo with its stored configuration and credential, and return the HTTP status, latency and the first 4 KB of the body. Saves nothing, but the third-party API really receives the call. Needs approval.

rumo_manage_set — Create, update or delete a Rumo set: predefined buttons (≤3), a list (more options) or cards (with images, badges and actions) that the Agentforce agent shows by key through the "show Rumo set" action. Max 10 items; title 40, description 80, badge 12 characters. Image/link domains are added to Salesforce trusted domains automatically. Needs approval.

rumo_agentforce_install_sets — Install the "show Rumo set" action in the Salesforce org (Apex action RumoShowSet and its test, Named Credential, MessagingSession field, context variable, permission set) and attach it to the listed subagents, so the agent can show Rumo sets by key. Run once per org, or again to change the subagents. Needs approval.

rumo_agentforce_add_trusted_domain — Add a domain to the Salesforce org's trusted domains so images and links from it reach customers instead of URL_Redacted. Use when rumo_agentforce_activity reports blocked_urls. Needs approval.

rumo_agentforce_upsert_test — Create or replace a Salesforce Testing API test (AiEvaluationDefinition) for the Agentforce agent: test cases with an utterance, optional history and the expected subagent, actions and response. Replaces all cases of an existing test. Run it with rumo_agentforce_run_test. Needs approval.

rumo_agentforce_run_test — Start a run of a Salesforce test against the live Agentforce agent. Returns a run_id at once; results arrive later, so poll rumo_agentforce_get_test_run and never report a verdict from this call. Each case really talks to the agent in Salesforce. Needs approval.

rumo_agentforce_restore_version — Redeploy an earlier snapshot of the Agentforce agent (from rumo_agentforce_versions), undoing every Rumo change made after it. Rumo snapshots the current state first, so a restore can itself be undone. Use when a test fails after a change. Needs approval.

rumo_list_pending_changes — List change requests waiting for approval in Studio Chat — changes to assistants made through this connection (or by Studio Chat's own agents) that a person has not approved yet. Pass base_id for one assistant, or status to see the history (executed, rejected, superseded, expired). Each comes with a review_url for the person.

rumo_get_change — Show one change request: what it changes (current vs proposed, as Studio Chat read it from the assistant when the request was made), who asked for it and through what, and its status.

rumo_approve_change — Approve a pending change request so it goes live on the assistant now. Use it only when the person explicitly asks to approve here instead of in Studio Chat. NEEDS APPROVAL: the first call returns the change itself (current → proposed) and an approval token; show it word for word and repeat the identical call with approval_token only after the person says yes. Studio Chat records the person as the approver and that it was approved through the MCP. If the assistant changed since the request was made, nothing is applied.

rumo_reject_change — Reject a pending change request: nothing is applied and it stays in the history as rejected. NEEDS APPROVAL: the first call returns a summary and an approval token; repeat the identical call with approval_token after the person says yes.

rumo_list_assistant_responses — Read an assistant's predefined responses — button sets (reply buttons / suggestion chips), carousels (card sets), WhatsApp Flow sets and template sets — on its latest version, by type, each with its id, its full definition, the pill that offers it ({{ buttons: id }}, {{ suggestions: id }}, {{ cards: id }}, {{ flow: id }}, {{ template: id }}) and which instructions/skills reference it. Also lists pills that point at a set that does not exist. Read it before rumo_manage_assistant_response. Read-only.

rumo_manage_assistant_response — Create, update or delete ONE predefined response on an assistant: a button set (type buttons: reply buttons or suggestion chips), a carousel (type carousel), a WhatsApp Flow set (type flow) or a template set (type template). Only that set changes; every other set and setting stays as it is. `set` is the complete definition for the type (update replaces the whole set: read it first with rumo_list_assistant_responses). For a flow or template, build and publish it first (rumo_list_flows / rumo_draft_flow / rumo_publish_flow, rumo_list_templates / rumo_create_template). The assistant only offers a set where its instructions or a skill carry the pill ({{ buttons: id }}, {{ suggestions: id }}, {{ cards: id }}, {{ flow: id }}, {{ template: id }}); add it with rumo_upsert_skill. Each type needs the account's flag (button_sets, card_sets, flow_sets, template_sets). Saves a new version; rumo_rollback_playbook undoes it. Administrators only. NEEDS APPROVAL: the first call returns a summary and an approval token; re-call with the same arguments plus approval_token. It may come back pending_approval with a review_url.

rumo_update_playbook — Edit an assistant's main instructions (the playbook body that rumo_get_playbook returns as content) and/or its name. STEP-UP REQUIRED. Read the current body with rumo_get_playbook (base_id) first. For a few lines, pass edits: [{old, new}] — exact replacements applied in order; each old must appear exactly once, otherwise the call is refused before any approval and nothing changes. To rewrite the whole body pass content instead (replaces it entirely; not together with edits). Skills are changed with rumo_upsert_skill, not here. The summary shows the changed lines (- removed, + added). Saving creates a new playbook version; rumo_rollback_playbook with the previous version id (returned) is the undo. If the playbook changes between the two calls, the second call is refused: ask for approval again. On accounts that require a person to approve AI changes it comes back pending_approval with a review_url.