Quo 远程 MCP 服务器是什么?
Quo 的远程 MCP 服务器是一个托管的 Model Context Protocol 端点,地址是 https://mcp.quo.com/mcp,AI 助手无需在本地安装或运行任何东西即可连接。
Quo MCP Server已验证已精选
@Quo
基本信息
关于 Quo MCP Server
Give your agent a phone. Turn customer conversations into action: follow up by text, keep contacts current, uncover missed opportunities, and put Sona to work on calls and SMS conversations (beta), without leaving your AI assistant.
连接信息
https://mcp.quo.com/mcp接入方式
claude mcp add quo --transport http https://mcp.quo.com/mcpQuo MCP Server 工具
37List 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).
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).
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 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).
Create a new contact in the Quo workspace, 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. Returns the new contact ID and a compact pipe-separated row that can be chained into `update-contact` or `get-contact`. Only `firstName` is required; all other fields are optional.
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.
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.
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.
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.
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). To find a particular contact by name, company or phone number, use `search-contacts` where it is available. 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.
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.
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).
Add a note to a Quo contact — for example a call summary, a follow-up reminder, or context for teammates. Adding a note does not send anything to the contact. 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. Returns the new note ID, which `update-contact-note` takes. Use `list-contacts` or `get-contact` to find the contact ID.
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.
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.
Create this Quo workspace's A2P 10DLC carrier registration as a DRAFT. A workspace has one registration, covering its numbers. Creating the draft is free and sends nothing to carriers: nothing is billed until submit-a2p-registration. Every field is required (alternateName, address.line2, ticker and exchange may be null), so collect the real values from the user rather than guessing: carriers check the business against its tax registration, and mismatches get it rejected. Before asking for the fields one by one, offer to read them from a document: the user can share their business registration in the chat, such as the IRS EIN letter (CP 575 or 147C), articles of incorporation or organization, a state business registration, or a Canadian business number confirmation. It is optional, so ask for the details directly if they would rather not. From a document, take only what it shows: usually the legal name, legal structure (businessType), tax ID type and number, and registered address. Show the user what you read and have them confirm it, then ask for whatever the document does not cover, such as the website, industry, employee count, call volume, regions, contact person and message types. Never fill a field the document does not show and the user has not given. ticker and exchange are required for Public companies. After creation, Quo writes the messaging details carriers vet in the background; before submitting, review the business details with the user via get-a2p-registration. 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. Fails with a conflict if the workspace already has a registration. Requires a workspace owner or admin and an active paid subscription.
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.
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.
List tasks in the Quo workspace. Returns compact rows with task ID, status, title, due date, assignee, linked phone number/conversation/activity, creation time, completion time (empty while the task is open), and revision. Supports pagination via `pageToken` (1-100 results per page).
Create a task in Quo linked to exactly one inbox, conversation, or conversation activity. Pick the most specific link target available: if a fetch result row gives you an AC… activity ID (a specific call or message), prefer `activityId` — it ties the task to exactly what the user is referring to. Use `conversationId` (CN…) when the user means the whole thread with a contact (also from fetch-* results). Use `inboxPhoneNumber` (E.164 or PN… ID, from list-inboxes) only when the task isn't about any specific call/message/thread.
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.
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.
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.
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.
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.
Cancel a Sona call started with start-agent-call, hanging up if it is in progress. A call that already ended is returned unchanged.
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.
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.
Stop a Sona SMS conversation started with start-agent-conversation. Sona stops texting; texts already sent stay sent. One that already ended is returned unchanged.
Talk to Sona, your Quo agent that knows your business. Sona keeps the workspace's business knowledge: the one document every Quo AI agent in the workspace, including the one that answers new leads, reads to know what the business does, its services and prices, hours, service area, policies and FAQs. Use this tool whenever the user wants to check or change what Quo's AI agents know about their business, or gives feedback on how an agent described it (e.g. "we don't open on Sundays anymore", "the agent quoted the wrong price for a haircut", "add our new gift cards"). Sona asks follow-up questions and keeps the knowledge to business information only, about one business, in the standard sections, with no invented prices or policies. It saves nothing until the user approves its draft. Only workspace admins and owners can use it. One conversation spans several calls, and each call does exactly one of these: - Start: message, and no interviewId. Opens a NEW conversation and returns its interviewId. Start once per topic. - Send: interviewId and message. Sends the user's next message in that conversation. Pass the same interviewId on every follow-up; leaving it out starts a second conversation. - Get: interviewId, and no message. With the messageId from a response that said Sona is still working, gets that turn (never resend the message instead); without one, gets the conversation's latest turn. Never make up an interviewId or messageId: copy them from this tool's responses. Sona leads the conversation. Relay Sona's messages to the user verbatim, pass on only what the user actually said, and never answer Sona's questions or invent business details yourself. When Sona proposes a draft, Quo shows the user the draft and its new or changed prices and policies and saves only if they approve; where Quo cannot ask them directly, this returns the draft and a toolCallId for decide-knowledge-save. 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.
Approve or decline the knowledge draft Sona proposed in an ask-knowledge-agent conversation. Before approving, show the user the full draft and its new or changed prices and policies, and get their explicit go-ahead. Sona leads the conversation. Relay Sona's messages to the user verbatim, pass on only what the user actually said, and never answer Sona's questions or invent business details yourself. Declining saves nothing, and the conversation continues.
Fetch call transcripts for a Quo inbox. Requires the Quo Business plan and calls where transcription was enabled. Optionally filter by `userId` to return only calls handled by a specific team member (use `list-users` to look up user IDs). Each result row is `id | participant | direction | status | 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. When `participantPhoneNumber` is omitted, the tool aggregates across participants discovered from conversations, and the trailing `conversationId` (CN…) is populated for thread-level task linking. Set `excludeDoneConversations` to true when the user wants only conversations that are still active in the inbox; omit it to include done conversations. Set `createdAfter` to bound the window — the tool filters conversation discovery by that time server-side, so a call whose conversation is old but had recent activity is still found. Single-participant queries always return that contact's transcript history even when its conversation is marked done, and leave the `conversationId` column blank since the per-call `activityId` is already a precise link target. To page through additional results, use `participantPhoneNumber` + `pageToken` for a single participant, or `conversationPageToken` if you hit the conversation-discovery safety cap. 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.
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.
Fetch message history for a Quo inbox. Two modes: • Single thread (`participantPhoneNumber` for one contact, or `participantPhoneNumbers` for a group thread) — DEPTH: returns that thread's full message history, most-recent-first, with pagination via `pageToken` (up to 100 per page). Each message is `id | participant | direction | timestamp` followed by the text; in a GROUP thread the `participant` column is the message's sender — the external number for an incoming message, or the Quo user ID (US…) of the teammate who sent an outgoing one (resolve US… IDs with `list-users`). A group thread is matched by its EXACT participant set, so pass every other member — whole-inbox results list each group's members on its header. The leading `id` is the message's activity ID (AC…) — pass it to `create-task` as `activityId`. A message with MMS attachments is followed by one indented `media: <mime-type> <url>` line per attachment; text-only messages have none. A message may carry both text and attachments — when it does, the body is the text and the media lines follow it. ALWAYS pass the attachment URL through to the user as a clickable markdown link (e.g. [image/png](https://example.com/image.png)); stating that an attachment exists without giving its URL is not useful, since the user cannot open a link they were not shown. Never shorten, truncate, or omit the URL. When an attachment arrives with no accompanying text the body shows `(no text)`; describe that to the user as a photo or file, not as an empty message. Single-thread queries always return the thread's history even when its conversation is marked done. • Whole inbox (no participant filter) — BREADTH: returns the most-recent messages for EVERY conversation with messages in the window, grouped by conversation (up to 10 messages each), so a daily-summary query never silently drops a contact. Set `createdAfter` to the start of the period the user asked about: the tool then reads every message in that window and represents every conversation in it. Without `createdAfter` it reads only the inbox's 1,000 most recent messages. A group thread is its own conversation, headed `Group: <members>`, and its rows carry an extra sender column (`id | sender | direction | timestamp | text`). Set `excludeDoneConversations` to true when the user wants only conversations that are still active in the inbox; omit it to include done conversations. Each conversation ID (CN…) is on its header for `create-task` linking. A conversation with more than 10 in-window messages is flagged (`[more than 10 …]`) with the exact parameter to fetch its full thread. If the read stops early — no `createdAfter`, or a window too large to read in one call — an `[incomplete: …]` line says where it stopped and a `[next_conversations: …]` token continues it via `conversationPageToken`. `maxResults` is ignored in this mode. 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.
Query workspace-level aggregate analytics over CALLS or MESSAGES — counts, durations, segment/media counts, and rates grouped by time, user, phone number, direction, status, or outcome. Use for questions like "how many missed calls last week?", "average talk time per user", or "message volume by day". Returns summarized grouped rows only, not individual records or transcripts. Query workspace call or message analytics using the parameter schema. Returns aggregate metrics only, never individual records or transcripts. CALL ATTRIBUTION: - Calls have one row per associated user per call: shared-inbox calls expand per user status, including unavailable users who were not rung; calls without per-user entries have a single fallback row. Messages have one row per message. - calls COUNT_DISTINCT grouped by user counts associated calls, including unanswered ones. A shared call can count for several users. Never sum per-user counts for a workspace total; query that total separately. - For inbound calls handled by human teammates, group by user and filter direction EQ incoming, dialStatus EQ answered, incomingOutcome EQ answered-by-user. Use calls COUNT_DISTINCT for volume or talkDuration AVG for average answered-call talk time. - dialStatus is per-user; status and incomingOutcome are call-level. incomingOutcome EQ answered-by-user alone can credit non-answering users. A user not answering does not mean the workspace missed the call. - For outbound connected calls, filter direction EQ outgoing and outgoingOutcome EQ connected. Do not apply the inbound dialStatus recipe. Resolve ambiguous "handled" scope from context or ask whether it includes inbound, outbound, or both; query directions separately for both. - Call-level durations/flags repeat across user rows. SUM/AVG/percentiles over these rows can misstate unique-call workspace metrics. talkDuration is elapsed call talk time (zero if unanswered), not per-user speaking time. ringDuration comes from the user status when available. OUTCOMES: incomingOutcome: answered-by-user (human answer), answered-by-agent (AI answer with talk time >= 10s), agent-abandoned (AI answer with talk time < 10s), voicemail (no answer, voicemail >= 5s), missed (no answer meeting those criteria), abandoned (caller abandoned the phone menu), forwarded (routed elsewhere); empty for outgoing calls. outgoingOutcome: connected (answered timestamp exists), no-answer, busy, canceled, failed; empty for incoming calls. Connected does not establish a human answer or a business outcome. actorType describes the creator/initiator, not who answered; an empty value is unknown. Use incomingOutcome to distinguish human and AI answers. AGGREGATIONS: Boolean SUM counts true rows; AVG is a rate from 0 to 1. Durations are seconds. For workspace call counts and rates, use calls COUNT_DISTINCT with call-level filters. For example, voicemail rate is distinct inbound calls with incomingOutcome EQ voicemail divided by all distinct inbound calls in the same timeframe and scope, not hasVoicemail AVG over user rows. === entityType: "calls" === METRIC FIELDS + ALLOWED AGGREGATIONS: - calls, users, phoneNumbers, conversations, fromNumbers, toNumbers → COUNT_DISTINCT - duration, ringDuration, talkDuration, voicemailDuration (seconds) → SUM, AVG, MIN, MAX, P50, P75, P90, P95, P99 - hasVoicemail, isForwarded → SUM, AVG === entityType: "messages" === METRIC FIELDS + ALLOWED AGGREGATIONS: - messages, users, phoneNumbers, conversations, fromNumbers, toNumbers → COUNT_DISTINCT - segments, media, recipients → SUM, AVG, MIN, MAX, P50, P75, P90, P95, P99 - hasBody, hasMedia, isGroup, isAutoReply, isScheduled → SUM, AVG TIME AND RESULTS: - Filter createdAt with GTE start and LT end using ISO timestamps for the user's timeframe. The server requires a date filter, including for all-time requests. Use the workspace timezone, otherwise UTC. Bucket time series explicitly; createdAt defaults to TRUNCATE_MONTH when grouped without a function. Use EXTRACT_H…
Read the workspace's automation credit (sometimes called AI credit) allowance, usage and reset date. Use for questions about the workspace's automation credits: how many are left, how many were used, overages, or when usage resets. The result shows the allowance, automation credits used and automation credits left (or that they are unlimited), when usage resets, whether overages are on and, if so, the overage rate per block of overage credits, overage credits used and the overage charge so far in dollars, and whether a tier change is scheduled. Automation credits left is already worked out; do not recompute it. Overage credits used counts automation credits used beyond the allowance, and the overage charge is billed in blocks of credits. Usage resetting is when the count returns to zero. This tool only reads; plan changes and purchases happen in Quo's billing settings.
Search the workspace's contacts by name, company, keyword or part of a phone number, ranked by combined keyword and meaning relevance. Use it to find a contact or a contact's ID: "find Jane Doe", "who is +1 555 010 0100", "contacts at Acme". Only contacts the user can see are searched. - `query` is matched by keyword and by meaning: names and parts of names ("jan" finds Jane), company, or part of a phone number ("0100"). Up to 100 characters. - Filters narrow the contacts that can match, and `query` ranks what is left. Every filter must match; within one filter, any listed value can match. Filters match exactly: `phoneNumbers` (any format, converted to E.164), `emails` (also tried in lowercase), `companies` (the full company name, including capitalization), `sources`, `createdBy` (user IDs from list-users) and `createdAfter` / `createdBefore` (when the contact was created). For a partial phone number, or a company name you are not sure of exactly, put it in `query`, which ignores case. - Leave out `query` to list the contacts that match the filters. Give a query or at least one filter. - Returns up to `maxResults` contacts (default 10, max 100), best match first. There is no next page and no total count: when a search returns `maxResults` contacts, more may match, so narrow the search or raise `maxResults`. For a complete list of contacts, or filtering by external ID, use list-contacts. - Each row is `id | name | company | role | phone numbers | source`. Results show at most 10 phone numbers and no emails; get-contact with the id shows the full contact. Pass the id to get-contact, update-contact or list-contact-notes. - No results does not mean the contact does not exist: try a shorter or different query, fewer filters, or list-contacts.
概览
Your business runs on conversations. Quo lets your AI assistant help you keep up with them and do something about what comes next.
Turn conversations into progress
- Follow up faster. Draft and send texts, so a missed response doesn’t become a missed opportunity.
- Know what needs attention. Find patterns in calls and messages, spot unanswered questions, and see where leads are getting stuck.
- Keep customer details current. Create and update contacts without switching tools.
- Put Sona to work. Have Quo’s AI agent make calls or handle SMS conversations on your behalf (beta).
Connect and get going
Use Quo’s official Claude or ChatGPT connector, or add https://mcp.quo.com/mcp to a compatible MCP client. Sign in with Quo and authorize access to your account. Quo hosts the server, so there is nothing to run locally.
Access follows the permissions of the Quo account you connect. Features and usage requirements are covered in the Quo MCP documentation.
常见问题
怎么连接 Quo 的 MCP 服务器?
把端点 https://mcp.quo.com/mcp 添加到任意支持 MCP 的客户端,比如 Claude Code、Cursor 或 VS Code。本页的接入代码块可以一步配置好每个客户端。
Quo 的 MCP 服务器需要认证吗?
需要。Quo 使用 OAuth——第一次连接时,你的 MCP 客户端会打开浏览器窗口登录并授权,之后会复用这个凭证。
Quo 的 MCP 服务器用的是哪种传输方式?
Quo 暴露的是 Streamable HTTP 端点,这是远程 MCP 服务器普遍使用、主流客户端都支持的传输方式。
更多远程 MCP 服务器
AQL PropertyCheck — Physical check of one exact address
Check one exact Gold Coast or Brisbane City property address. Free address/coverage check and short summary; paid structured Agent JSON adds available building, street and surrounding context, with Brisbane routed journe
9apes
The 9apes MCP server lets an AI assistant read the GitHub Actions data 9apes already collects for your organization: runs, jobs, steps, and their durations. Ask it why a build got slower, which jobs take the longest, or
A
Ad Library Intelligence
Ask your assistant what a competitor is advertising and get the ads themselves: text, links, images, videos, platforms and dates from the Meta Ad Library (Facebook and Instagram), Google's Ads Transparency Center and the LinkedIn Ad Library
A
AI-Ready Webpage Extractor (Apify)
Convert web pages to clean Markdown and retrieval-ready chunks with browser rendering support.
APIXO AI
Remote MCP for AI image, video, music, speech and custom voice generation. Discover models and input schemas for free; authorize your APIXO account to generate media and check results.
评论