Quo

Fetch missed incoming calls for a Quo inbox, each enriched with the voicemail the caller left (transcript + recording URL) when there is one. Returns calls with an explicit unanswered status ('missed', 'no-answer', or 'abandoned') and calls Quo reports as 'completed' even though they have zero call duration and no human or AI answer signal. This fixed classification is not configurable. Use it for questions like 'what calls did I miss yesterday?' or 'any voicemails this week?'. Each result is a row `id | status | direction | participants | createdAt | duration | conversationId`; the leading `id` is the call's activity ID (AC…) — pass it to `create-task` as `activityId` to link a follow-up task to that specific call. The trailing `conversationId` (CN…) is for thread-level task linking and is populated only when discovering across multiple participants (single-participant queries leave it blank since the per-call `activityId` is already precise). Rows whose call has a voicemail are followed by an indented voicemail block (status, duration, recordingUrl, transcript). Voicemails are processed asynchronously — a voicemail with status 'in-progress' has null duration/transcript/recordingUrl, so retry in a few seconds. Missed calls where the caller hung up without leaving a message are still listed, just marked '(no voicemail)'. When `participantPhoneNumber` is omitted, the tool aggregates calls across all participants active in your `createdAfter` window — the tool filters conversation discovery by that time server-side, so a missed call whose conversation is old but had recent activity is still found. Without `createdAfter`, discovery falls back to the most recent conversations. For exhaustive single-contact pulls, use `participantPhoneNumber` + `pageToken`; if you hit the conversation-discovery safety cap, use `conversationPageToken` to continue. Timezone: `createdAfter`/`createdBefore` are treated as UTC — pass ISO 8601 with a 'Z' suffix or an explicit offset — and every timestamp in results is UTC. When the user asks in relative terms (e.g. 'yesterday', 'this week'), scope the window to THEIR local timezone and convert to the matching UTC instants before calling; if you don't know their timezone, ask. Present returned times in the user's local timezone. This tool makes many API requests per call. Run it sequentially — let one call finish before starting another, including for a different inbox — since several running at once can hit rate limits and return incomplete results. When showing a phone number to the user, render it as a click-to-call link, e.g. [(555) 555-5555](tel:+15555555555). Pass the bare E.164 value (not a tel: URI) into tool parameters.

Get this Quo workspace's A2P 10DLC carrier registration — the one-per-workspace registration US carriers require before a business can text people from local numbers. Shows where it stands in plain words (draft and not yet billed; submitted and awaiting carrier review; approved; or rejected, with the carriers' reasons and whether it can be fixed here or must be resubmitted in the Quo app), every business and messaging detail carriers vet, and the exact next step. Use this first in any A2P conversation, and to check status after submitting. Read-only; does not submit or charge anything.

Get a Sona call started with start-agent-call: its status and, once it has ended, its title, summary and collected data. A call typically takes 30–90 seconds, so poll about every 10 seconds until the status is final (completed, failed, no-answer, busy, voicemail, voicemail-left or canceled). `completed` does not mean a person answered or that the task succeeded; voicemail or an automated system can also end as completed, so read the summary.

Get a Sona SMS conversation started with start-agent-conversation: its status, why it failed or ended, and, once the agent has summarized it, its title, summary and collected data. It can run for minutes or hours, so check back every few minutes rather than polling rapidly, until the status is final (completed, failed or canceled). A failed one sent no texts; its failure reason says why. `completed` does not mean the task succeeded, so read the summary. Use fetch-messages to read the texts themselves.

Fetch a single Quo contact by ID, including its default fields (name, company, role, email, phone) and any custom fields configured on the workspace. Use `list-contacts` first if you need to discover contact IDs. When showing a phone number to the user, render it as a click-to-call link, e.g. [(555) 555-5555](tel:+15555555555). Pass the bare E.164 value (not a tel: URI) into tool parameters.

Get a Quo inbox's settings: its name, its business hours (whether they are enforced, the timezone, and each day's open window) and its call recording (whether calls are recorded automatically, and how callers are told a call may be recorded, for inbound and outbound calls). Read these before changing anything with update-inbox-settings, so you can tell the user what will change. Use list-inboxes to find the inbox. When showing a phone number to the user, render it as a click-to-call link, e.g. [(555) 555-5555](tel:+15555555555). Pass the bare E.164 value (not a tel: URI) into tool parameters.

List the notes on a Quo contact. Each note is a row `id | createdAt | updatedAt | authorId` followed by its text, indented; a note with attachments is followed by one indented `media: <mime-type> <url>` line per attachment. `authorId` is the Quo user (US…) who wrote the note — use `list-users` to show their name. Pass a note's `id` to `update-contact-note` to change it. Use `list-contacts` or `get-contact` to find the contact ID. Supports pagination via `pageToken` (1–50 results per page).

List contacts in the Quo workspace, optionally filtered by `externalIds` or `sources`. Returns a compact pipe-separated table (id | name | company | role | email | phone) and supports pagination via `pageToken` (1–50 results per page). When showing a phone number to the user, render it as a click-to-call link, e.g. [(555) 555-5555](tel:+15555555555). Pass the bare E.164 value (not a tel: URI) into tool parameters.

List the phone numbers (inboxes) available in the Quo workspace, including assigned users. Use this first to discover the correct `from` number for `send-message` or the `inboxPhoneNumber` for `fetch-messages` / `fetch-call-transcripts`. When showing a phone number to the user, render it as a click-to-call link, e.g. [(555) 555-5555](tel:+15555555555). Pass the bare E.164 value (not a tel: URI) into tool parameters.

List tasks in the Quo workspace. Returns compact rows with task ID, status, title, due date, assignee, linked phone number/conversation/activity, creation time, and revision. Supports pagination via `pageToken` (1-100 results per page).

List the users (members) in the Quo workspace. Returns each user's ID, name, email, and role. Use the returned `id` (US… format) to filter other tools like `list-inboxes` by user. Supports pagination via `pageToken` (1–50 results per page, max 50).

Mark one or more Quo conversations as read, done or open, the same as in the Quo app, without sending a message. `read` clears the unread indicator. `done` takes a conversation out of the inbox (it stays searchable, and fetch tools can exclude done conversations with `excludeDoneConversations`). `open` returns a done conversation to the inbox. Pass up to 50 conversation IDs per call; all get the same `markAs`. Each conversation succeeds or fails on its own, and the result lists both. Marking is safe to repeat, so retry failed IDs by calling again with just those. Conversation IDs (CN…) come from the `conversationId` column of fetch-messages (whole-inbox results), fetch-call-transcripts or fetch-missed-calls. Only mark the conversations the user asked about; don't sweep an inbox on your own initiative.

Send SMS to up to 40 recipients as SEPARATE individual (1:1) messages — a broadcast. Two modes: for the SAME text to everyone, pass `to` (2–40 numbers) + `content`; to personalize per recipient, pass `messages` as [{to, content}] instead. Provide one mode or the other, never both. Prefer `to` + `content` when the text is identical — it guarantees everyone receives exactly the same message. Each recipient gets their own private thread and does NOT see the other recipients; replies come back individually. Use this for announcements or blasts. This is different from send-group-message, which puts everyone in ONE shared thread that exposes their numbers to each other — use that only when recipients should see one another. For a single recipient use send-message. Sends cannot be undone. The `from` number must belong to the user's Quo workspace — use `list-inboxes` to discover available numbers. Recipients must be valid phone numbers in E.164 format (international supported).

Send a single SMS group message from a Quo inbox to 2–10 recipients in one shared thread. IMPORTANT: this creates a group conversation — every recipient can see all the other recipients' phone numbers and all replies, and it cannot be undone once sent. Use `send-message` instead when you want to text one person, or to text several people privately without exposing them to each other (call `send-message` once per recipient). The `from` number must belong to the user's Quo workspace — use `list-inboxes` to discover available numbers. Recipients must be valid phone numbers in E.164 format (international supported).

Send one SMS text, exactly as written, from a Quo inbox to a single recipient, right now. Use it when the user wants a specific message sent (they wrote or dictated it, or asked you to draft one) or a one-way notice such as a reminder, an address or a confirmation. It does not watch for or answer replies. To have Sona, Quo's AI agent, text someone and handle the back-and-forth until a goal is reached (confirm or reschedule an appointment, collect details, answer their questions), use start-agent-conversation instead. The `from` number must belong to the user's Quo workspace — use `list-inboxes` to discover available numbers. Recipient must be a valid phone number in E.164 format (international supported).

Have Sona, Quo's AI agent, place a real phone call from a user's Quo number to carry out a task. Use this tool when the user asks Sona to make a call. Before using this tool, ensure the intended outcome and the details needed to achieve it are clear from the conversation. If they are ambiguous or missing, ask targeted questions; do not guess or call yet. For example, 'schedule an appointment' needs acceptable dates, times and timezone. Restate your understanding of what the agent will do and confirm the from number, destination and specific task with the user. The call is real and cannot be undone. Each call uses 50 of the workspace's automation credits (a call that ends within 15 seconds is free), so mention the cost when you confirm the call with the user; if the workspace is out of credits, the call fails without dialing. Quo may also ask the user to confirm directly. Every call needs an idempotencyKey; reuse it for every retry of the same call to avoid duplicates. This returns an agent call ID immediately while the call runs in the background. Poll get-agent-call about every 10 seconds until its status is final. Use cancel-agent-call to stop it. Sona's tools are in beta: tell the user so if they ask, or when a result falls short of what they expected. When the user comments on how Sona or this tool performed (for example, Sona misunderstood, missed the goal or sounded unnatural), offer to send it to the Quo team with submit-feedback, including the ID of the Sona run or knowledge interview so the team can find it. Corrections to the business's own details, such as a wrong price or outdated hours, go to ask-knowledge-agent instead.

Hand an SMS conversation to Sona, Quo's AI agent, to get something done with one real person through back-and-forth texting. Sona texts as the user's business: it writes the first text itself, reads each reply, and keeps replying on its own until the goal is reached, the person replies STOP, someone on the user's team replies in the conversation (which takes over from Sona straight away), or it is canceled. Use this when the user wants Sona to handle a conversation, not just send a text, e.g. 'have Sona confirm Jane's appointment', 'get Mike to pick a delivery day', 'follow up with this lead and answer their questions'. To send one text the user wrote or dictated, or a one-way notice that needs no handling of replies, use send-message instead. Sona already knows the business (its services, prices, hours and policies), so the task only needs what is specific to this conversation. Before starting, make sure the goal and the details it needs are clear; if not, ask targeted questions rather than guessing. Restate what Sona will do and confirm the from number, the person to text and the task with the user: texts cannot be unsent, and Quo may also ask the user to confirm. Every request needs an idempotencyKey; reuse it for every retry of the same task. This returns an agent conversation ID straight away: check it with get-agent-conversation in a few minutes, read the texts with fetch-messages, and stop it with cancel-agent-conversation. Sona's tools are in beta: tell the user so if they ask, or when a result falls short of what they expected. When the user comments on how Sona or this tool performed (for example, Sona misunderstood, missed the goal or sounded unnatural), offer to send it to the Quo team with submit-feedback, including the ID of the Sona run or knowledge interview so the team can find it. Corrections to the business's own details, such as a wrong price or outdated hours, go to ask-knowledge-agent instead.

Submit this Quo workspace's draft A2P 10DLC registration to carriers. SUBMITTING IS BILLED AND IS A COMPLIANCE COMMITMENT: it charges the workspace a one-time $19.50 registration fee (paid to the Carrier Registry on the workspace's behalf; not a Quo fee), then a monthly fee of $1.50 ($3 for non-profits), and $15 for each resubmission after a rejection; the user attests the workspace will not send messages about forbidden topics (policy and fees: https://support.quo.com/getting-started/carrier-registration/carrier-registration#registration-process); and it cannot be undone through the API. It always takes TWO calls. (1) Call it with no confirmationToken: nothing is submitted or charged; it returns the registration for review, the disclosures the user must see, and a confirmationToken. Show the user every disclosure and the details, and get their explicit confirmation. (2) Only then call it again with that confirmationToken, billingAcknowledged: true and forbiddenMessageTopicsAcknowledged: true. Never set those acknowledgments without the user's explicit confirmation in this conversation. The token expires if the registration changes. If submit reports that auto-fill is still running, wait a minute and repeat step 2. Requires a workspace owner or admin and an active paid subscription.

Submit feedback from the user to the Quo product team about what would make Quo or their experience better. Ask for more details before use if the feedback is ambiguous or unclear. Proactively offer to submit feedback only when the user is trying to do something with their Quo phone line or communications that is not supported, or comments on how one of Sona's beta tools performed; do not solicit feedback otherwise. Only share what the user shared, preserving their main point and relevant context.

Change fields on this Quo workspace's DRAFT A2P 10DLC registration. Only the fields you pass change; everything else stays as it is (address and personOfContact merge field by field). Changing name, alternateName, businessType, websiteUrl, personOfContact.firstName, personOfContact.lastName has Quo write the messaging details again, so those changes must include `messageTypes`. Quo writes the messaging details carriers review (the description, sample messages and opt-in flow) for the user, from the business details and messageTypes, in the form carriers look for, to improve the chance of approval. They are not returned by these tools, so there is nothing to review or edit; only the use case is shown. Present this as a feature that handles the hardest part of registration for them, not as a limitation. It works the same way in the Quo app, which does not take custom wording either, so never suggest the app as a way to use the user's own text. If the user has their own use case or sample messages, explain that Quo writes these for them. What the user controls is the business details and messageTypes: keep those accurate, and to change what Quo writes, correct them with update-a2p-registration (include messageTypes, plus one of the business fields that trigger it, such as name resent with its current value), and Quo writes the messaging again. Editing is free and sends nothing to carriers. Only drafts can be edited: a registration awaiting carrier review cannot be changed, and one whose campaign carriers rejected must be corrected in the Quo app. Any change invalidates an earlier submit review, so run submit-a2p-registration's review again afterwards. Requires a workspace owner or admin.

Update fields on an existing Quo contact, including workspace custom fields. Make the best custom-field key match from the user's wording; if Quo rejects the custom-field input as invalid, the error includes exact workspace keys, names, and types so you can retry. Omit fields you want to leave unchanged; pass `null` for any default field or custom-field value you want to clear. Fields not included in the request are preserved through a full read-merge-write. Use `get-contact` first if you need to inspect current contact values.

Replace the text of an existing note on a Quo contact. The new `text` replaces the note's entire text, so to add to a note, pass its current text plus the addition — use `list-contact-notes` to read the current text and find the note ID. Text is 1–2000 characters. To mention a teammate, write `@` followed by their user ID from `list-users` (e.g. `@USabc123 can you follow up?`); Quo turns it into a mention.

Change a Quo inbox's settings: its name, its business hours, and its call recording. Pass only what should change; everything left out keeps its current value. Only the inbox's owners and the workspace's admins can change these. Business hours: `enabled` turns enforcement on or off (it has no effect until the inbox has a schedule), `timezone` is the IANA timezone the schedule is read in, and `schedule` sets the open window for the days you name, in local time as 24-hour HHMM (9am and 5:30pm are also accepted, but a time without am/pm is read as 24-hour, so write 5:30pm, not 5:30); a day set to null is closed, a day you leave out keeps its window, `{ start: '0000', end: '0000' }` is open all day, and `schedule: null` removes the schedule so business hours stop being enforced. Call recording: `autoRecord` records every call on the inbox (the workspace's plan must include it), and `callDisclosure` sets how inbound and outbound callers are told the call may be recorded. Recording disclosure can be a legal requirement where the user operates, so never turn it off unless the user asks. These changes take effect on live calls right away: call get-inbox-settings first, tell the user exactly what will change, and confirm it with them. Quo may also ask the user to confirm directly. Use list-inboxes to find the inbox. When showing a phone number to the user, render it as a click-to-call link, e.g. [(555) 555-5555](tel:+15555555555). Pass the bare E.164 value (not a tel: URI) into tool parameters.

Update a Quo task. Performs exactly one change per call, selected by which parameter is provided: title/description (counted as one change), assignToUserId, unassignUserId, dueDate, removeDueDate, completed (true marks the task done, false reopens it), linkConversationId, or unlinkConversationId. To make several changes, call this tool once per change.