360dialog

List the 360Dialog skills available to you. A skill is a curated, up-to-date how-to guide for a 360Dialog process (e.g. drafting a compliant WhatsApp template, diagnosing a channel that stopped sending). Call this tool BEFORE answering any "how do I..." question about 360Dialog products or processes - it tells you which skills exist and when to use them. Once you find a match, call 'get_skill' with its 'name' to read the full guide.

無需輸入參數。

Get the full guide for one skill returned by 'list_skills', as markdown.

Returns the URL where a user can create a 360Dialog account. Only relevant if the user has not created a 360Dialog account yet.

無需輸入參數。

Search the 360Dialog client documentation at https://docs.360dialog.com/docs. Search across the documentation to find relevant information, code examples, API references, and guides. Use this tool when you need to answer questions about Client Documentation, find specific documentation, understand how features work, or locate implementation details. The search returns contextual content with titles and direct links to the documentation pages.

Get a documentation page from the 360Dialog client documentation at https://docs.360dialog.com/docs. Fetch the full markdown content of a specific documentation page from Client Documentation. Use this when you have a page URL and want to read its content. Accepts full URLs (e.g. https://docs.360dialog.com/docs/getting-started). Since `searchDocumentation` returns partial content, use `getPage` to retrieve the complete page when you need more details. The content includes links you can follow to navigate to related pages.

Get balance for an account.

Find a channel by passing in an identifier. A channel is a phone number. By calling this tool you retrieve information about the phone number/channel in 360Dialog. Results are paginated; use the 'page' and 'size' arguments to page through results if there are more than fit in a single page. Returns: If not found, returns "Not found". If found, returns information of channels, like WABA ID, client ID, channel ID, and app ID, along with the current page, total pages, and total count.

Submit a new display name for this channel (a.k.a. phone number.) Calling this tool will submit a display name request to Meta. Meta takes up to 48 hours to review the submitted display name. The display name may be rejected if it does not comply with display name guidelines. The user will receive an email when their display name review is complete. When this tool is called, the user may be prompted by 360Dialog for an OTP code delivered to their email address.

Get a channel's (a.k.a. phone number) WhatsApp profile.

Update the WhatsApp profile for this channel (a.k.a. phone number.) The user may be prompted by 360Dialog for an OTP code delivered to their email address. Make them aware of the OTP requirement.

Get invoices for an account.

無需輸入參數。

Wait for a server-side onboarding step to finish, then report back. Embedded Signup and payment setup finish in the person's browser. This tool polls the hub every 5 seconds for up to 45 seconds and returns one of: - "done": The step finished. - "pending": Still not finished. Call this tool again to keep waiting. - "failed": There was an error. 'channel_id' and 'phone_number' are returned back once a channel is found so you can pass 'phone_number' into the next call once you have it. When 'phone_number' is omitted, 'candidates' lists the client's most recently created channels - check it if you're unsure the right number was picked (e.g. two users connecting numbers on the same 360Dialog client account). Only use this for the short waits during onboarding. This tool is NOT suitable for display name approval, WABA approval, or business verification scenarios, as they take days, not seconds.

Get the user's company's details from 360Dialog.

無需輸入參數。

Set the user's company's details on 360Dialog. This change does not affect Meta; only records on 360Dialog are affected by the update. Before calling this tool, make sure to: 1. Check if the `get_company_details` tool returns the correct company information already. 2. Check with the user if they want to change their company details in 360Dialog. 3. Get the user's approval/confirmation.

Check whether a phone number can be onboarded for this client before handing over the onboarding link. This tool only checks 360Dialog's own database and this client's channel quota. It does not ask WhatsApp/Meta anything, so a number already active on WhatsApp elsewhere (including the personal app) can still come back eligible here.

Get the link that lets the user connect a WhatsApp phone number in 360Dialog, plus what to tell them beforehand. This hands over 360Dialog's own onboarding page. The user clicks through Embedded Signup themselves; this tool cannot do it for them. The user must be signed in to 360Dialog Hub already, or the link sends them to login first and loses the destination. Tell them to make sure they're signed in first. The link given by this tool may not work if the user's 360Dialog client account is under a partner-paid channel. Make them aware of this. Returns the client's current channel IDs for future reference on recognizing which phone number was newly added.

無需輸入參數。

Get the link that lets the user add their credit card to their account. If this client was created through assistant-led onboarding and still has no company name or country on file, the payment page is kept behind a company details form instead. In that case this tool does not return the payment link; it says to call 'update_company_details' first and try again. The user must be signed in to 360Dialog Hub, or the link sends them to login first and loses the destination. The user enters the card themselves; this tool cannot do it for them.

無需輸入參數。

Get a phone number's status on whether a number is live, what type of messages it can send today, and suggestions for what's next. A live number can send free-form replies inside the 24-hour customer service window immediately (meaning if someone messages the number, the user can respond to the message using the API). Template messages are separately blocked until Meta reviews a submitted template (template reviews take up to 48 hours.) Lack of business verification is not a blocker. Unverified businesses can only send 250 templates to unique users per 24 hours.

Request an OTP code. Sometimes OTP is needed to complete invoking a tool. When tool invocation fails due to OTP reasons, you will be notified in the tool response, and be asked to rqeuest an OTP code. Only call after a tool call fails due to OTP.

無需輸入參數。

Verify the 6-digit OTP code from the user. Doing so will automatically replay the blocked tool call that required verification.

List templates for a WABA (WhatsApp Business Account). If you do not have a waba_account_id ending in 'WA' (case-insensitive), run the 'list_channels' tool first.

Show a preview of a given template to the user.

Sending messaging templates in WhatsApp API / 360Dialog API requires a JSON body in the API request. The API request can be hard to form, as the body must declare in JSON what each parameter in the JSON should be filled as. This tool creates a valid example JSON body that the user can later modify before sending the template to WhatsApp users. It is recommended that you use this tool after creating a template, or after the user asks how to send a template. Display the JSON result of this tool.

Use this tool to create a WhatsApp message template. For this tool's 'template_json' property, pass a JSON matching this shape: { "name": string, "language": string, "category": "MARKETING" | "AUTHENTICATION" | "UTILITY", "components": Component[], } General rules: - name must be lowercase snake_case. - category must be uppercase. - language must be a WhatsApp locale code such as "en_US", "tr", "es", "pt_BR". - Only include fields supported by the component variant. - Do not include null fields. - Components should normally be ordered as: 1. header, if any 2. body 3. footer, if any 4. buttons, if any - A template can have at most one header, one body, one footer, and one buttons component. - BODY is required unless the user is clearly creating a special authentication template handled elsewhere. - HEADER and FOOTER are optional. - BUTTONS are optional. Component variants: 1. Text header without variables { "type": "HEADER", "format": "text", "text": "Your order update" } Use this when the header is plain text. 2. Text header with variables { "type": "HEADER", "format": "TEXT", "text": "Hi {{1}}", "example": { "header_text": ["Alice"] } } Rules: - Text header supports template variables. - If text contains variables, include example.header_text. - The example array must contain sample values in the same order as the variables appear. - For named parameters, the placeholder names appear in text, but the examples are still values. 3. Image header { "type": "HEADER", "format": "IMAGE", "example": { "header_handle": ["https://example.com/sample-image.jpg"] } } Use this when the template header should contain an image. The example should be a sample image handle or URL when available. 4. Video header { "type": "HEADER", "format": "VIDEO", "example": { "header_handle": ["https://example.com/sample-video.mp4"] } } Use this when the template header should contain a video. The example should be a samp

Delete a WhatsApp message template by its internal template ID.

Get a channel's (a.k.a. phone number's) webhook URL, and check if the optional webhook headers are set. Webhook headers are optional. They can be set using the 'set_webhook' tool, which also sets the webhook URL. When webhook headers are set, 360Dialog will send webhooks to the channel's webhook URL and add the specified headers. This helps only authenticated requests pass through app firewalls, if the user has any. Example: If webhook URL is `https://foo.com/webhook`, and webhook headers are set to {"x-360dialog-webhook-security": "RANDOM-STRING"}, the webhook URL will receive POST requests like this: POST https://foo.com/webhook HEADERS x-360dialog-webhook-security: RANDOM-STRING

Set a channel's (a.k.a. phone number's) webhook URL and optionally webhook headers.

Test if a channel's (a.k.a. phone number's) webhook URL is functional. A total of 32 test cases will be run by sending sample POST requests to the user's webhook URL. During this test, the user may see 32 requests being made to their webhook server. Returns the test's results, showing which cases failed, and which succeeded.

Get currently logged in user's information in 360Dialog. You will get: - user's name, - user's email address, - partner name, - user's permissions in 360Dialog Hub, - user's roles

無需輸入參數。

List users for the selected account, including their roles and creation timestamps.

無需輸入參數。

Register the user's phone number on the 360Dialog sandbox. Upon registration, the user can send messages to this phone number from the 360Dialog sandbox account on WhatsApp. The user will be given a link to complete registration. When this link is used, they will send a verification code to 360Dialog sandbox phone number on WhatsApp. They can click the link, or alternatively scan the QR code.

Complete a phone number's registration. This will get you the API key to use when sending messages from the 360Dialog sandbox phone number to the user's registered phone number.

無需輸入參數。

Send a message on the 360Dialog sandbox. Messages can only be sent to the user's phone number that was used during sandbox registration. The payload must be a JSON string matching the WhatsApp messages endpoint body. Interactive message example: use this only when there is an active conversation window, which lasts 24 hours since the customer's last message. { "messaging_product": "whatsapp", "to": "{{recipient_phone_number}}", "type": "text", "text": { "body": "{{message_body}}" } } Template message example: use this when there is no active conversation window, or when sending an approved template message. You can only send the 'marketing_message' template. { "messaging_product": "whatsapp", "to": "{{recipient_phone_number}}", "type": "template", "template": { "name": "marketing_message", "language": { "policy": "deterministic", "code": "en" }, "components": [ { "type": "header", "parameters": [ { "type": "image", "image": { "link": "https://placehold.co/600x315/34D399/FFFFFF/png?text=Summer+Sale!" } } ] } ] } }

Set webhook for the channel on 360Dialog sandbox. Optional.

Get configured webhook for the channel on 360Dialog sandbox.

List webhook events received. This will show received messages from the user, and status of messages sent from the sandbox account.

Send a message into an existing conversation, as the business. This is inbox-scoped sending: it posts into an existing conversation with correct threading. Outside the 24-hour customer-care window, WhatsApp only permits template messages — other types are rejected with an explanation.

Assign or reassign one conversation to an agent and/or a group. Both fields are always set to exactly what you pass: calling with only `user_id` clears any group assignment and vice versa; calling with neither unassigns the conversation entirely.

Add or remove one tag on one conversation.

Mark one conversation's messages as read by the calling user. Pass `up_to_timestamp` after reviewing a conversation so that messages arriving in the meantime stay unread. The read mark only moves forward: a timestamp older than the caller's current mark changes nothing. Read state is per inbox user: this clears the unread count for the caller only, not for other agents. The inbox also marks the messages as read on WhatsApp, so the contact sees read receipts. Only conversations whose messages you can read can be marked.

Send a saved (canned) response into a conversation as a text message. Subject to the same 24-hour window rule as getchat_send_message.

List conversations of the inbox, newest activity first. Returns one entry per conversation with contact info, unread count, last message, current assignee (user and/or group), and tags.

Find conversations by contact name, phone number, tag name, or message content. Searches contact profiles and tags first, then message text and media captions; results from both are merged and deduplicated by conversation. Each match notes why it matched (`contact` or `message_content`).

Read one conversation: contact/assignment/tag details plus its message history. Messages are returned newest first. To page further back, call again with `before_time` set to the oldest returned message's timestamp.

List the WhatsApp inboxes the calling 360dialog user can access. Call this first when you don't know which `channel_id` to pass to the other tools: each entry pairs a `channel_id` with its inbox URL and WhatsApp number (`wa_id`). Entries without a `channel_id` cannot be driven through these tools. The listing covers the caller's own client accounts, plus every inbox under a partner the caller administers. It never reaches another tenant: a client user is not shown other clients' inboxes, including ones managed by the same partner. An empty list does not mean no inbox exists; pass a known `channel_id` to the other tools directly.

無需輸入參數。

List the inbox's agents (users) — for assignment via getchat_assign_conversation.

List the inbox's agent groups — for group assignment via getchat_assign_conversation.

List the inbox's tags — for tagging via getchat_tag_conversation and filtering via getchat_list_conversations.

List the inbox's saved (canned) responses — for use with getchat_apply_saved_response.

Check whether this channel's WhatsApp number is eligible for a Meta Business Agent. Returns {is_eligible: boolean}. Known limitation: a 403 from this call can mean the number is simply not eligible, rather than that the business has not accepted Meta's terms - do not report an unaccepted-terms problem on a 403 alone.

Create the Meta Business Agent for this channel on the given messaging channel. Creates the underlying entities and schedules asynchronous data-preparation jobs, so the agent is not immediately ready to answer. Returns {agent_id}. Onboarding does not switch the agent on: rollout stays disabled until mba_update_agent_settings enables it.

Remove the Meta Business Agent from this channel's WhatsApp number. Deletes the agent configuration and, when the last agent on the account is removed, disconnects the integration entirely. Returns {deleted_agent_id}. This is irreversible: knowledge, skills and connectors configured on the agent go with it, and restoring the setup means onboarding again from scratch.

Read the agent's current settings: rollout, handoff, followup and ai_audience. Known limitation: this returns an ARRAY with one entry per channel, not a single object. Read the entry whose `channel` you care about (usually "whatsapp") rather than treating the response as an object.

Replace the agent's settings and return the updated entry. Known limitation: this is a FULL REPLACEMENT, not a patch - every field you omit is reset, so read the current settings with mba_get_agent_settings first and send them back with your change applied. Note also that setting rollout.enabled to false stops the AI responding on all threads; re-enabling it makes the AI respond to new threads only, not to threads that were already open.

List the consumer phone numbers allowed to reach the agent while ai_audience is ALLOWLISTED_ONLY. Known limitation: this returns a BARE ARRAY of {id, consumer_phone_number}, not an object with a `data` key.

Add one consumer phone number to the allowlist. Returns the created {id, consumer_phone_number}. The allowlist only takes effect while ai_audience is ALLOWLISTED_ONLY; under EVERYONE the agent answers all consumers regardless of this list.

Remove one entry from the allowlist by its entry id, which comes from mba_list_allowlist_entries (it is not the phone number). Returns no content on success. While ai_audience is ALLOWLISTED_ONLY, removing the entry stops the agent answering that consumer.

Read the business information the agent uses to answer customers. Returns empty or default values when none has been configured. Known limitation: business info is a CLOSED six-field schema - business_description, contact_info, delivery_and_shipping, payment_method, purchase_info, return_policy. Any other key is rejected. Knowledge that does not fit one of these six fields belongs in an FAQ (mba_create_faq), an agent skill (mba_create_agent_skill), a crawled website (mba_create_website) or an uploaded file (mba_upload_file) - not here.

Replace the agent's business information and return the stored object. Known limitation: this is a FULL REPLACEMENT - fields you omit are cleared, so read mba_get_business_info first and send the existing values back with your change applied. Known limitation: business info is a CLOSED six-field schema - business_description, contact_info, delivery_and_shipping, payment_method, purchase_info, return_policy. Any other key is rejected. Knowledge that does not fit one of these six fields belongs in an FAQ (mba_create_faq), an agent skill (mba_create_agent_skill), a crawled website (mba_create_website) or an uploaded file (mba_upload_file) - not here.

Reset the agent's business information to empty defaults and return the emptied object. Unlike most deletes this does not 404 afterwards - mba_get_business_info keeps working and returns the defaults. Known limitation: business info is a CLOSED six-field schema - business_description, contact_info, delivery_and_shipping, payment_method, purchase_info, return_policy. Any other key is rejected. Knowledge that does not fit one of these six fields belongs in an FAQ (mba_create_faq), an agent skill (mba_create_agent_skill), a crawled website (mba_create_website) or an uploaded file (mba_upload_file) - not here.

List the agent's FAQ entries. Known limitation: this returns a BARE ARRAY, not an object with a `data` key.

Add one question-and-answer entry to the agent's knowledge. Returns the created entry with its id. FAQs are the right home for knowledge that does not fit business info's six fields.

Read one FAQ entry by its id, as returned by mba_list_faqs or mba_create_faq.

Replace one FAQ entry by its id. Both question and answer are required: this replaces the entry rather than patching it, so send the fields you want the entry to end up with.

Delete one FAQ entry by its id. Returns no content on success.

List the websites the agent crawls for knowledge, with their crawl status. Known limitation: this returns a BARE ARRAY, not an object with a `data` key.

Add a website URL for the agent to crawl into its knowledge base. Returns the entry with its id and crawl status. Crawling is asynchronous - the knowledge is not available immediately; poll mba_get_website for crawl_status.

Read one website crawl entry by its id, including crawl_status, pages_crawled and last_crawled_at. This is how you check whether a site added with mba_create_website has been ingested yet.

Replace the URL of one website crawl entry. Changing the URL restarts crawling.

Remove one website crawl entry by its id, dropping the knowledge crawled from it. Returns no content on success.

List the files in the agent's knowledge base, as {id, file_name}. Known limitation: this returns a BARE ARRAY, not an object with a `data` key.

Upload a file into the agent's knowledge base. Multipart uploads cannot travel over MCP, so pass the file EITHER as `url` (a publicly reachable https URL this service downloads) OR as `content_base64` (the file's bytes, base64-encoded) - exactly one of the two, always with `file_name`. This service performs the multipart upload to Meta for you and returns the created {id, file_name}. Known limitations: Meta caps a file at 100 MB and accepts PDF, DOC, DOCX, PNG, JPG and JPEG (CSV and XLSX where enabled). Base64 content is additionally capped by this endpoint's request size limit, so prefer `url` for anything larger than a few megabytes. A `url` must be https and must resolve to a public address - private, loopback and link-local addresses are refused.

Read one knowledge file's metadata by its id. Returns {id, file_name} - this returns metadata only, not the file's contents.

Delete one file from the agent's knowledge base by its id. Returns no content on success.

List the agent's skills - the instruction texts that shape how it behaves. Known limitation: this returns a BARE ARRAY, not an object with a `data` key.

Add a skill to the agent - an instruction text that changes how it answers. Returns the created skill with its id. Skills are the right home for behavioural instructions; facts the agent should know belong in FAQs, websites or files instead.

Read one agent skill by its id, as returned by mba_list_agent_skills or mba_create_agent_skill.

Replace one agent skill by its id. This replaces the skill rather than patching it, so send the title, description and skill text you want it to end up with.

Delete one agent skill by its id, so the agent stops following it. Returns no content on success.

List the agent's UI skills - the rich WhatsApp components (carousels, CTA URLs, flows, images, interactive lists and buttons, location) the agent may send, each with the instruction that says when to send it. A UI skill is NOT an agent skill (mba_list_agent_skills): an agent skill is instruction text that shapes what the agent says, a UI skill lets the agent send one kind of rich WhatsApp component and tells it when to send that component. This list is CURSOR-PAGINATED: it returns {data, paging} - page with the `after` cursor from paging.cursors, and stop when paging carries no `next` link, because a page can be empty and still have more after it.

Give the agent one more rich WhatsApp component to send, and the instruction that says when to send it. Returns the created UI skill with its id. A UI skill is NOT an agent skill (mba_list_agent_skills): an agent skill is instruction text that shapes what the agent says, a UI skill lets the agent send one kind of rich WhatsApp component and tells it when to send that component. Known limitation: component_type is FIXED AT CREATION and cannot be changed afterwards. flow_id is required when component_type is `flow`, and is refused for every other type; a flow UI skill also cannot be enabled until the flow itself is published.

Read one UI skill by its id, as returned by mba_list_ui_skills or mba_create_ui_skill. A UI skill is NOT an agent skill (mba_list_agent_skills): an agent skill is instruction text that shapes what the agent says, a UI skill lets the agent send one kind of rich WhatsApp component and tells it when to send that component.

Change the title, the status or the instruction of one UI skill by its id. This is a partial update: a field you omit keeps its stored value. Use it to enable or disable a component without deleting it. A UI skill is NOT an agent skill (mba_list_agent_skills): an agent skill is instruction text that shapes what the agent says, a UI skill lets the agent send one kind of rich WhatsApp component and tells it when to send that component. Known limitation: component_type and flow_id cannot be changed - delete the UI skill and create a new one instead. A flow UI skill cannot be enabled until its flow is published.

Delete one UI skill by its id, so the agent stops sending that component. Returns no content on success. To stop the component temporarily, set status to `disabled` with mba_update_ui_skill instead.

Read the usage caps in force for the agent, each with its budget_id. Returns {budgets}; an empty array means no cap is set and usage is unlimited. Known limitations: budgets are ONLY SERVED for the business that owns this number's WABA; any other business_id is refused with an error that says so. For a number whose business is not known to 360dialog yet, budgets are not available and this tool returns an error that says so. When several caps are set, whichever is reached first stops the agent until its window resets, and the agent then hands conversations to the business. Token caps apply across the WHOLE BUSINESS MANAGER, so every agent in that portfolio shares them; AI-turn caps apply per conversation. These tools set and read caps and do not report usage against them: mba_get_agent_usage_insights reports billed usage, keyed on the billable account ID and not on business_id.

Set the usage caps for the agent. Returns the caps in force after the write. This is a FULL REPLACEMENT of the set: send again every cap to keep, because any cap left out is removed, and an empty array clears all caps and returns the agent to unlimited. To edit an existing cap, pass back its budget_id from mba_get_agent_budgets; omit budget_id to add a new cap. Two caps with the same unit_type and time_window pair are rejected. Known limitations: budgets are ONLY SERVED for the business that owns this number's WABA; any other business_id is refused with an error that says so. For a number whose business is not known to 360dialog yet, budgets are not available and this tool returns an error that says so. When several caps are set, whichever is reached first stops the agent until its window resets, and the agent then hands conversations to the business. Token caps apply across the WHOLE BUSINESS MANAGER, so every agent in that portfolio shares them; AI-turn caps apply per conversation. These tools set and read caps and do not report usage against them: mba_get_agent_usage_insights reports billed usage, keyed on the billable account ID and not on business_id.

List the agent's connectors - the third-party systems it can call. Each carries a connection_status (PENDING_OAUTH, ACTIVE, EXPIRED or ERROR) worth checking before relying on its tools. Known limitation: this returns a BARE ARRAY, not an object with a `data` key.

Create a connector so the agent can call a third-party system. Returns the connector with its id and connection_status. A connector on its own does nothing - add connector tools with mba_create_connector_tool to expose individual operations to the agent.

Read one connector by its id, including its connection_status and mTLS metadata. Credentials are never returned - the private key and secrets stay at Meta.

Replace one connector by its id. This replaces the connector rather than patching it, so send the full definition you want it to end up with - read mba_get_connector first.

Delete one connector by its id. Its tools and stored credentials go with it. Returns no content on success.

Set or rotate the API key credentials for a connector. This is an upsert: if credentials already exist they are REPLACED and the connection is re-established. It cannot be used to remove credentials - the payload is required.

Set or rotate the OAuth 2.0 client credentials for a connector. This is an upsert: if credentials already exist they are REPLACED and the connection is re-established. It cannot be used to remove credentials - the payload is required.

Upload or rotate the mTLS client certificate for a connector. This is an upsert: if credentials already exist they are REPLACED and the connection is re-established. It cannot be used to remove credentials - the payload is required. Certificates and keys are PEM-encoded; the private key is never returned by any read tool.

Read the connector's third-party error logs, or aggregated failure patterns when summary_only is true. Only errors from the third-party system are included, so an empty result means no failures, not no traffic. Known limitation: the time range must not exceed 7 DAYS, and only the last 7 days are retained - start_time defaults to 24 hours ago and end_time to now. Unlike the other list tools this one does return an object: {data: [...], stats: {...}}, with stats present only when include_stats is true.

List the actions defined on one connector. Known limitation: this returns a BARE ARRAY, not an object with a `data` key.

Define one action the agent can perform through a connector - an outbound HTTP request against the connector's base_url. Returns the created tool with its id. Known limitation: path_parameters, query_parameters and headers are NAME-TO-SCHEMA OBJECTS, not arrays - write {"order_id": {"type": "string"}}, never [{"name": "order_id", ...}]. And every {brace} token in `path` must have a matching key in path_parameters, or the definition is rejected.

Read one connector tool definition by its id.

Replace one connector tool definition by its id. This replaces the definition rather than patching it, so send the whole request_definition you want it to end up with - read mba_get_connector_tool first. Known limitation: path_parameters, query_parameters and headers are NAME-TO-SCHEMA OBJECTS, not arrays - write {"order_id": {"type": "string"}}, never [{"name": "order_id", ...}]. And every {brace} token in `path` must have a matching key in path_parameters, or the definition is rejected.

Delete one connector tool definition by its id, so the agent can no longer perform that action. Returns no content on success.

Execute one connector tool once, as the agent would, and return what the third-party system answered. Use it to check a definition works before relying on it. `input` is a JSON-ENCODED STRING of the arguments, not an object. Known limitation: the result is DOUBLY STRINGIFIED - the response is {output, status} where `output` is a JSON string; parse `output`, then parse its `.body` to reach the third-party system's actual response. What this call does depends entirely on the tool being run: it can create, change or delete data in the connected system.

Trigger the agent to act on a consumer conversation asynchronously - the event is queued and the call returns immediately with status "accepted" and an agent_event_id. Poll mba_get_agent_event with that id to find out what happened; a 202-style acknowledgement here does not mean the consumer was messaged. Known limitation: event.payload must be a JSON-ESCAPED STRING, not an object - pass "{\"order_id\":\"123\"}", not {"order_id": "123"}. Maximum 4096 characters.

Read the processing status of an event submitted with mba_send_agent_event. Status is one of request_received, processing, sent, failed, skipped or success; failed and skipped carry error_message and skipped_reason. This is the only way to find out whether an accepted event actually reached the consumer.

Send a test message through the full agent pipeline and read its reply, without needing a real consumer number. Pass conversation_id from a previous reply to continue the same test conversation. Known limitation: while ai_audience is ALLOWLISTED_ONLY this returns agent_response: "" with no_response_reason: "ELIGIBILITY_CHECK_FAILED", no matter which consumer number is involved - check mba_get_agent_settings before concluding the agent is broken.

Hand a consumer conversation back to the Meta Business Agent as the automatic responder, after a human agent has taken it over. Only releasing is supported here - taking control is restricted to configured escalation partners.

Send a WhatsApp message to a consumer and release thread control back to the agent. The body is the WhatsApp Cloud API message object - set `type` and the matching payload key (text, template, interactive, image, ...). This messages a real person: it is subject to the platform's send eligibility rules, and outside a 24-hour customer service window only an approved template will be delivered.

List the evaluation scenarios configured for this agent, each with its scenario text, categories, max_turns and success criteria. Their ids are what mba_start_eval_run takes.

Submit an evaluation job that simulates the listed cases against the agent, evaluates the conversations and optionally produces insights. Returns {job_id, status: QUEUED} - the work is asynchronous, so poll mba_get_eval_results with the job_id. Known limitation: eval_case_ids is read from the QUERY STRING, not the request body - pass it as the comma-separated argument here and this service puts it in the right place; the body is a separate object that accepts nothing else.

Read an evaluation job by its job_id. While the job runs this gives the status (QUEUED or RUNNING) and the progress. When the job fails it gives the error. When the job completes it gives the aggregated report: the summary text, the average conversation and turn scores, the highlights and the top failure categories. There is no separate summary call: a completed job already carries that report. For the per-conversation transcripts and per-turn labels, take the ids from `eval_ids_by_score` and call mba_get_eval_details. This tool adds a `details` key when it can read those ids for you.

Read per-conversation evaluation results - scores, per-turn labels, reasons and the transcript. Takes eval_ids, which is a different kind of id from the job_id that mba_get_eval_results takes. Read them from the eval_ids_by_score field of a completed job. mba_get_eval_results already adds these details when it can read that field, so call this tool when it could not.

Read what happened to the events sent to the agent (mba_send_agent_event) over a date range, one row per event type, busiest first: how many were received, how many the agent successfully processed, and the mean end-to-end latency. Successfully processed means the agent sent its message, not that the message was delivered. Figures are rolled up once a day, so the most recent day may still be incomplete. Known limitation: the dates are in PACIFIC TIME, not the business time zone, and the range may span at most 30 days, counting both ends.

Read the ordered turns of the most recent conversation between the agent and one customer. Each turn carries its turn_id, conversation_id and the observed steps - LLM calls with a preview of the model output, and tool calls with the tool name, input and output - plus latency and status where available. Use it to see why the agent answered the way it did. Malformed records, and tool responses that cannot be matched to a tool call, may be missing. This list is CURSOR-PAGINATED: it returns {data, paging} - page with the `after` cursor from paging.cursors, and stop when paging carries no `next` link, because a page can be empty and still have more after it.

Read how many conversations the agent replied in over a date range (ai_threads), and how many are currently handed from the agent to the business and still awaiting a business reply (ai_handoffs). Counts are per conversation, not per message, and match the business's own agent summaries. Returns {data: [one row]}, each metric as {count}, present only when requested. Known limitation: ai_handoffs is a SNAPSHOT of the present moment - it ignores start_date and end_date. The range may span at most 90 days, counting both ends, and each requested metric costs a separate scan, so ask only for what you need.

Read how each of the business's own tools performed over a date range, one row per tool, busiest first: how many conversations called it, its mean latency, and its success, error and timeout rates (0 to 1; timeouts count as errors too). Only tools the business supplied are reported. thread_count counts a conversation once per day, so one that called the tool on three days counts three times. Figures are rolled up once a day, so the most recent day may still be incomplete. Known limitation: the range may span at most 30 days, counting both ends.

Read the billed usage of a Meta Business Agent account over a billing date range, one entry per HOUR, DAY or MONTH bucket: billable messages, billable tokens, and cost in the account's currency. Returns {usage}; an empty array means no usage in the range. Each entry carries its bucket start and end (Unix seconds, end exclusive), plus channel and sender_id when they are in dimensions. Metrics left out of metric_types are omitted from every entry, not returned as null. Tokens are BILLED tokens, the figure on the invoice, which can be fewer than the tokens the agent consumed. Known limitations: usage insights are ONLY AVAILABLE for numbers whose stack uses its own WABA access token; for any other number this tool returns an error that says so. The range is start INCLUSIVE, end EXCLUSIVE, and dates are evaluated in the billable account's timezone, so a day bucket can be 23 or 25 hours long. MONTH needs a range of whole months: start on the 1st, end on the last day of a month.

Read whether this channel has ever been onboarded and whether its agent has ever been activated, as {onboarded, activated_once}. Known limitation: this is NOT a Meta call - it reads this service's own tracking record, written when onboarding or a settings read/write goes through here. It answers 'did onboarding ever succeed' and 'was rollout ever enabled', and nothing about the agent's current configuration. For live state call mba_get_agent_settings.