Manage websites, help documents, campaigns, and customer-support conversations with safe, organization-scoped tools and interactive support views.
Scored across 14 tools
Most tools have clearly distinct purposes, and descriptions explicitly state what each is not for. However, six conversation-related tools (get_conversation, list_conversations, get_unresolved_conversation_counts, show_customer_inbox, show_support_overview, open_customer_inbox_conversation) have some overlap in scope and UI context that could cause misselection. The document tools are better separated.
All names use snake_case with a leading verb, following a predictable verb_noun pattern (get_, list_, search_, send_, resolve_, show_, open_). Minor deviations exist, such as open_customer_inbox_conversation being unusually long with multiple nouns. Overall the convention is consistent and readable.
14 tools is well-scoped for a customer support platform, falling within the ideal 3-15 range. Each tool appears to earn its place by covering a specific resource or view. No excessive or redundant tools are present.
The surface covers reading websites, documents, conversations, and campaigns, plus actions like resolving conversations and sending messages. However, there are notable gaps: no create/update/delete for help articles, no create/update for websites, and campaigns can only be listed, not sent or managed. These missing operations limit full lifecycle coverage.
Use this when someone asks about one customer conversation's status, such as whether it is resolved or unread and how many messages the customer, staff and AI agent sent. Returns its channel, status, unread count, times and sender counts from the latest 50 public messages (no message text or internal notes). Not for reading or quoting what was said.
| Name | Required | Description | Default |
|---|---|---|---|
| conversationId | Yes | Conversation id, up to 200 characters |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| conversation | Yes | Safe conversation metadata with sender counts over at most the 50 most recent public messages; null when not found. No message body, preview, message id, customer identifier, staff id, internal note, organization id or arbitrary metadata is returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds material behavioral scope the annotations cannot convey: counts are derived only from 'the latest 50 public messages', message text and internal notes are excluded. These constraints directly shape what an agent can claim from the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, with the use condition front-loaded before the return summary and the exclusion last. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be spelled out, yet the description still summarizes them usefully. For a single-parameter read tool, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One required parameter with 100% schema coverage ('Conversation id, up to 200 characters'), so the schema fully documents syntax and the description adds nothing about parameter format. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource with explicit scope: 'one customer conversation's status' and enumerates exactly what status means (resolved/unread, sender counts). The singular framing distinguishes it cleanly from sibling list_conversations and get_unresolved_conversation_counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear triggering condition ('when someone asks about one customer conversation's status') and an explicit exclusion ('Not for reading or quoting what was said'). It does not name an alternative sibling tool by name, but the singular-vs-list distinction is implied strongly enough to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone needs the text of one help-center article, to quote it or answer a customer from it. Returns the article's title, slug, language, published flag and text up to 20000 characters, with the text's format (html, markdown, plain-text). Not for finding articles on a topic.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Article slug, used only when documentId is omitted | |
| locale | No | Language code for the slug lookup, e.g. en, it or fr; defaults to en | |
| documentId | No | Article id; takes precedence over slug |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| document | Yes | The article; null when it is missing or belongs to another organization. Organization ids, translator ids, deprecated slugs, embeddings and arbitrary metadata are never returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a 20000-character text cap and the returned format variants (html, markdown, plain-text), though some of this is duplicated by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with the trigger front-loaded and the exclusion last. The enumeration of return fields is slightly redundant given the output schema exists, but it costs little.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich output schema, complete parameter descriptions and full annotation coverage, the description supplies exactly the remaining missing piece – when to reach for this tool versus a search – and nothing an agent needs is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so slug, locale and the documentId-over-slug precedence are already documented in the schema. The description adds no parameter-level meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('returns the text') and resource ('one help-center article'), and explicitly separates itself from topic-search behavior with 'Not for finding articles on a topic,' which routes an agent away from search_documents/list_documents without needing their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear triggering condition ('when someone needs the text of one help-center article, to quote it or answer a customer') plus an explicit exclusion. It stops short of naming the alternative tool (search_documents) outright, so the routing is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks how many customer conversations are still open or unresolved, in total or per website. Returns the total plus a per-website count, largest first, listing up to 100 websites (no customer or message data). Not for finding which conversations are open.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| websites | Yes | Up to 100 websites with the most unresolved conversations, largest first. Customer identifiers, staff ids, message text and organization ids are never returned. |
| totalClamped | Yes | |
| websiteCount | Yes | |
| totalUnresolved | Yes | Unresolved conversations across every website, listed or not |
| websitesTruncated | Yes | True when more than 100 websites have unresolved conversations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation. The description adds useful behavioral detail by explaining the return shape, ordering, and a 100-website limit, plus that no customer or message data is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no filler. It is front-loaded with the usage condition, then the return behavior, then the exclusion, which is an effective structure for an agent deciding whether to call it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters and an output schema exists, the description already provides more than enough context: when to use it, what it returns, ordering, a limit, and what it does not cover. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics for the description to clarify. Per the rubric, a zero-parameter tool has a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: it counts customer conversations that are open or unresolved, either in total or per website. It also explicitly distinguishes itself from sibling tools like list_conversations or get_conversation by saying it is not for finding which conversations are open.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use the tool: when someone asks how many customer conversations are still open or unresolved, in total or per website. It also provides a negative condition, 'Not for finding which conversations are open,' though it does not name the alternative tool to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks about one of their Supovia websites by name or id, such as whether its AI customer agent is on. Returns the website's id, name, domain, AI-agent status and created and edited times, or not-found. Not for the help articles published on it.
| Name | Required | Description | Default |
|---|---|---|---|
| idOrName | Yes | Website id, exact vanity id (its lowercase public address) or exact display name |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| website | Yes | Safe website metadata; null when not found. Organization ids, agent prompts, credentials, integration configuration and arbitrary metadata are never returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the concrete return fields and the 'or not-found' outcome, which tells the agent a missing website is a normal result rather than an error. It does not mention auth or rate limits, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded: the usage trigger leads, followed by the return/negative-scope clause. No filler, and the example ('whether its AI customer agent is on') makes the intent immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape need not be spelled out, yet the description still summarizes the key fields and the not-found case. For a single-parameter read tool with full annotation coverage, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is well documented there (id, vanity id, or exact display name). The description echoes 'by name or id' but adds no format or edge-case detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource ('get ... website details') and names the exact lookup keys (name or id). It also explicitly carves out what this tool is not for ('Not for the help articles published on it'), which cleanly separates it from get_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the triggering situation ('when someone asks about one of their Supovia websites by name or id'), gives a concrete example intent ('whether its AI customer agent is on'), and provides an explicit exclusion pointing at the sibling domain (help articles). Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks which email campaigns one of their websites has. Returns each campaign's id, name and created and edited times, 20 per page by default (no recipients, subject or content). Not for sending a campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Campaigns per page, from 1 to 50; defaults to 20 | |
| cursor | No | The page.nextCursor of the previous page for the same website; absent for the first page | |
| websiteId | Yes | Website whose campaigns to list |
| Name | Required | Description |
|---|---|---|
| page | Yes | hasMore is true when more campaigns follow; pass nextCursor as cursor to get them |
| campaigns | Yes | Campaign identity only. Recipient lists, subjects, message content, user ids, organization ids and arbitrary metadata are excluded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. The description adds genuinely useful behavior: default page size, cursor pagination context, and the fact that sensitive fields (recipients, subject, content) are omitted from results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: the trigger first, then the returned shape and pagination, then the exclusion. Nothing is padded and each sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the return-shape sentence is a bonus rather than a necessity, and the pagination and exclusion notes complete the picture. Nothing an agent needs to invoke this list tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both limit and cursor are fully documented at 100% coverage, so the schema carries the parameter meaning. The description's mention of '20 per page by default' merely repeats the schema default and adds no format or usage syntax beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (email campaigns), scoped to a website. It also clarifies what is deliberately excluded from the payload (no recipients, subject or content), so an agent can tell it apart from anything that fetches full campaign detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('when someone asks which email campaigns one of their websites has') plus an exclusion ('Not for sending a campaign'). It stops short of naming the concrete alternative tool for sending, so it is clear but not fully routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks which customer conversations are open, unread or recently active, optionally for one website. Returns conversation ids with website, channel, resolved flag, unread count and times, most recent activity first, 20 per page by default (no message text or customer details). Not for open-conversation totals.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Conversations per page, from 1 to 50; defaults to 20 | |
| cursor | No | The page.nextCursor of the previous page with the same filters; absent for the first page | |
| resolved | No | true for resolved conversations, false for open ones; omit for both | |
| websiteId | No | Only conversations on this website; every website when absent |
| Name | Required | Description |
|---|---|---|
| page | Yes | hasMore is true when more conversations follow; pass nextCursor as cursor to get them |
| conversations | Yes | Most recent activity first: the id needed for a follow-up call, website id, channel, resolved state, unread count and timestamps. Message bodies, message ids, customer identifiers, internal notes, arbitrary metadata and organization ids are excluded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description still adds ordering (most recent activity first), default page size, and explicitly what is NOT returned (no message text or customer details). An output schema exists, so the listed return fields are partly redundant, keeping this from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the trigger, then output shape, then pagination; nothing is wasted. It is compressed into very long clauses, which slightly reduces scannability but not content quality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema is present, the description supplies everything else an agent needs: filter semantics, sort order, page size default, and the exclusions. Nothing required for a correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each of the four parameters is fully documented in the schema, making 3 the baseline. The description only restates the website filter ('optionally for one website') and adds no syntax, default, or edge-case detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (customer conversations) with the exact scope — open, unread or recently active, optionally per website. An agent can distinguish it from get_conversation and get_unresolved_conversation_counts without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with an explicit trigger ('Use this when someone asks which customer conversations are open, unread or recently active') and closes with an explicit exclusion ('Not for open-conversation totals'), routing the agent away from the counts sibling. When-to-use and when-not are both present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks which help articles or support docs exist, optionally for one website, language or article. Returns each article's id, title, slug, language, website and published flag, most recently edited first, 20 per page by default, without the article text. Not for finding articles about a topic.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Articles per page, from 1 to 50; defaults to 20 | |
| cursor | No | The page.nextCursor of the previous page with the same filters; absent for the first page | |
| locale | No | Only articles in this language code, e.g. en, it or fr; every language when absent | |
| websiteId | No | Only articles on this website; every website when absent | |
| slugOriginal | No | Only the language versions of one article: its original slug before translation |
| Name | Required | Description |
|---|---|---|
| page | Yes | hasMore is true when more articles follow; pass nextCursor as cursor to get them |
| documents | Yes | Article metadata, most recently edited first. Document content, embeddings, prompts, organization ids and arbitrary metadata are excluded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, non-destructive). The description adds substantial beyond-annotation behavior: sort order (most recently edited first), default page size (20 per page), and that article text is excluded from results. It doesn't state total counts or cursor exhaustion behavior, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler, front-loaded with the use condition, then the return shape, then the negative routing. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety and an output schema covering return structure, the description needn't explain return values, yet it usefully summarizes the returned fields and pagination default. Complete enough to call correctly; a minor gap remains around total-count or last-page signaling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented. The description restates the filterable dimensions (website, language, article) but adds no syntax, format, or edge-case detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('list help-center articles') with scope clarified ('without the article text'). Explicitly distinguishes from the sibling search_documents by stating 'Not for finding articles about a topic,' so an agent can route correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear when-to-use trigger ('when someone asks which help articles exist') and an explicit when-not-to-use exclusion naming the topic-search alternative's domain. Both directions of the routing decision are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks which websites their Supovia support chat runs on, or a website's id is needed. Returns each website's id, name, domain and whether its AI customer agent is on, most recently edited first, 20 per page by default. Not for customer conversations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Websites per page, from 1 to 50; defaults to 20 | |
| cursor | No | The page.nextCursor of the previous page; absent for the first page |
| Name | Required | Description |
|---|---|---|
| page | Yes | hasMore is true when more websites follow; pass nextCursor as cursor to get them |
| websites | Yes | Websites in the signed-in organization, most recently edited first. Prompts, credentials, integration configuration, organization ids and arbitrary metadata are excluded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description adds real behavioral context: ordering is most-recently-edited first and pagination defaults to 20 per page. It does not need to restate the read-only nature given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with a clear front-loaded usage trigger, then return shape, then an explicit exclusion. No filler and nothing repeated for its own sake.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, zero-required list tool with annotations and an output schema, the description supplies everything an agent needs: when to reach for it, what it returns, ordering, and paging defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both limit and cursor are fully documented in the schema, including the 1–50 range and the 20 default. The description only restates the page size default and adds no syntax or semantics beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('list'/'websites') and names the scope (websites the Supovia support chat runs on). It also enumerates the returned fields (id, name, domain, agent status), so an agent can distinguish it from get_website and from the conversation-oriented siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives two concrete triggers: when someone asks which websites the chat runs on, or when a website id is needed. The trailing exclusion ('Not for customer conversations') usefully routes away from the conversation tools, though it does not name the specific alternative (get_website/list_conversations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the embedded Supovia inbox opens a conversation the user selected. Returns whether it was found and gives the view its channel, status, unread count and times (no message text or customer details). Not for questions asked in chat.
| Name | Required | Description | Default |
|---|---|---|---|
| conversationId | Yes | Conversation id the user selected in the inbox view |
| Name | Required | Description |
|---|---|---|
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds real value beyond them by disclosing the negative return scope ('no message text or customer details'), which prevents the agent from expecting conversation content, plus the found/not-found outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences ordered as trigger, return shape, exclusion – front-loaded and free of filler. The final exclusion is terse enough to be slightly ambiguous about what 'chat' means here, but it still earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be enumerated, and the description covers trigger, outcome, and what is deliberately omitted. The remaining gap is sibling routing – it never says when to prefer get_conversation over this UI-context tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage, so the schema already defines conversationId. The description adds no syntax, format, or sourcing detail beyond 'the user selected', so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('opens a conversation the user selected') and scopes it to the embedded Supovia inbox view, so the agent knows it is an inbox-driven open, not a generic fetch. It does not name or contrast the closest sibling, get_conversation, so differentiation is left partly to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The trigger condition is explicit ('Use this when the embedded Supovia inbox opens a conversation the user selected') and there is one exclusion ('Not for questions asked in chat'). It stops short of routing the agent to an alternative such as get_conversation when full message content is needed, which is the obvious adjacent case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants to mark a customer conversation resolved or done, or reopen it. Returns the conversation id, resolved state and last edit time, and the operator dashboard updates live. Repeating the same state has no further effect. Not for replying to the customer.
| Name | Required | Description | Default |
|---|---|---|---|
| resolved | No | true to mark it resolved (the default), false to reopen it | |
| conversationId | Yes | Conversation to update |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| conversation | Yes | Only the id, resolved state and last edit time; null when not found. Customer identifiers, staff ids and organization ids are never returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the idempotency sentence largely restates structured data. However, the description adds genuine non-schema context: the operator dashboard updates live (an external side effect) and it names the returned fields, giving the agent information annotations can't convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the trigger, then the effect, then the exclusion. No filler; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be spelled out, and annotations carry the safety profile. The description still supplies trigger, exclusion, idempotency, and the live-dashboard side effect, so nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are already documented in the schema, so the description needn't explain them. The text hints at the two-state nature ('resolved or reopen it') but adds no format or default details beyond what the schema provides; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource pair (resolve/reopen a conversation) and explicitly carves out the adjacent sibling behavior with 'Not for replying to the customer,' which separates it from send_message. An agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear trigger ('when someone wants to mark a customer conversation resolved or done, or reopen it') and an explicit when-not ('Not for replying to the customer'). It stops short of naming the alternative tool to use instead, so it falls just under full marks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks which help article covers a topic or question on one of their websites. Returns up to 5 matching published articles with id, title, slug and language, matched by meaning in one language (English by default). Not for reading an article's text.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What the article should cover, in natural language, up to 500 characters | |
| locale | No | Language code to search in, e.g. en, it or fr; defaults to en | |
| websiteId | Yes | Website whose help center to search |
| Name | Required | Description |
|---|---|---|
| documents | Yes | Closest matches first. Content chunks, embeddings, scores, prompts and arbitrary metadata are excluded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world hint, so the safety profile is covered. The description adds useful behavior the annotations cannot convey: a hard result cap of 5, semantic rather than keyword matching, restriction to published articles, and single-language matching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no filler: the use case and return shape come first, the scope limit and the negative boundary follow. Every clause carries information an agent needs before calling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are already specified, and annotations carry the safety profile. The description nevertheless fills the remaining gaps — result cap, semantic matching, published-only scope, one-language constraint, and the read-vs-read-text boundary — leaving nothing material for an agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each of the three parameters is documented in-schema, including the en default for locale. The description only lightly reinforces this ('matched by meaning in one language (English by default)'), so the baseline of 3 is appropriate rather than anything higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('search help-center articles') and adds precision: 'Returns up to 5 matching published articles with id, title, slug and language.' It also distinguishes itself from adjacent document tools with 'Not for reading an article's text,' so an agent can separate it from get_document and list_documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete triggering condition ('when someone asks which help article covers a topic or question on one of their websites') and an explicit exclusion ('Not for reading an article's text'). The exclusion is implied rather than naming the alternative tool (get_document), so it stops just short of the full when/when-not/alternative pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user approves an exact reply to send to a customer in one Supovia conversation. Returns the conversation id and send time. The reply reaches the customer on the conversation's own channels (chat, email, WhatsApp or Messenger); replies to app-store reviews are public. Not for internal notes or closing the conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Exact reply text the user approved, 1 to 4,000 characters | |
| conversationId | Yes | Conversation to reply in | |
| idempotencyKey | Yes | Unique key you generate for this conversation and text, up to 255 characters; reuse it only to retry the same send |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| creationTime | Yes | When the reply was recorded; no message id or text is echoed |
| conversationId | Yes | Conversation the reply was added to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety profile is covered. The description adds genuine context beyond that: replies land on the conversation's own channels (chat, email, WhatsApp, Messenger), app-store review replies are public, and it returns the conversation id and send time. The one gap is that it never explains why the operation is marked destructive/irreversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with the usage condition and followed by output and scope exclusions. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety, an output schema covering return values, and 100% schema description coverage, the description supplies the remaining operational context: approval precondition, delivery channels, and public-visibility caveat. It is essentially complete, though it could note the idempotency retry contract explicitly rather than relying on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents content (with its 4,000-character cap), conversationId, and idempotencyKey ('reuse it only to retry the same send'). The description's phrase 'exact reply' reinforces content semantics but adds no new parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('send an exact reply to a customer in one Supovia conversation') and immediately distinguishes itself from siblings like resolve_conversation by stating it is 'Not for internal notes or closing the conversation.' An agent can tell exactly what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the triggering condition explicitly ('when the user approves an exact reply'), names the excluded actions (internal notes, closing the conversation), and the context signals inside it ('approves an exact reply') route the agent to this tool rather than the other conversation siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants to see their unread customer conversations in an inbox view. Returns how many of the 50 most recently active conversations have unread messages; the view lists up to 20 with channel, status, unread count and times (no message text or customer details). Not for complete open-conversation totals.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| conversationsHaveMore | Yes | True when conversations exist beyond the 50 sampled or the 20 the view lists |
| unreadConversationCount | Yes | Conversations with unread messages among the 50 most recently active |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which already declare read-only, idempotent, non-destructive), the description discloses the concrete sampling window (50 most recently active conversations), the display cap (up to 20), the returned fields, and what is deliberately omitted (no message text or customer details). This is meaningful behavioral context an agent cannot get from the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the usage condition, followed by the precise return semantics. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with annotations and an output schema, the definition covers everything needed: when to call it, what it returns, its caps, and what it excludes. No gaps remain that would cause a misselection or misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly adds no parameter content and instead clarifies the implicit scope of the query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('see their unread customer conversations in an inbox view') and scopes it precisely to unread items in an inbox view. This clearly separates it from siblings like list_conversations and get_unresolved_conversation_counts, which the agent could otherwise confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Opens with an explicit usage trigger ('Use this when someone wants to see their unread customer conversations') and adds an exclusion ('Not for complete open-conversation totals'). It stops short of naming the alternative tool for that excluded case, so the routing cue is present but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants a quick visual summary of their customer support. Returns a card with up to 20 websites (name, domain, AI agent on or off) and the 20 most recently active conversations (channel, open or resolved, times), optionally for one website. Not for complete open-conversation totals.
| Name | Required | Description | Default |
|---|---|---|---|
| websiteId | No | Only this website; every website when absent |
| Name | Required | Description |
|---|---|---|
| websites | Yes | Up to 20 websites: name, domain and AI-agent status only |
| conversations | Yes | The 20 most recently active conversations: channel, resolved state and timestamps. Customer identifiers, internal record ids, message bodies, prompts, credentials, internal notes, organization ids and arbitrary metadata are excluded. |
| websitesHaveMore | Yes | |
| conversationsHaveMore | Yes | |
| openConversationCount | Yes | Open conversations among the 20 shown, not the organization total |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds useful behavioral context beyond that: hard limits of 'up to 20 websites' and '20 most recently active conversations', plus the optional single-website scoping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the when-to-use condition and then the when-not/return detail. The return description is somewhat verbose ('AI agent on or off', 'channel, open or resolved, times'), but each detail aids routing rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema already exists so return values need not be explained, yet the description's card contents and the 20-item limits are still useful for tool selection. Complete for a read-only, single-parameter tool, with minor redundancy against the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single websiteId parameter, and the description's 'optionally for one website' merely restates the schema's 'Only this website; every website when absent'. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and scope: a 'quick visual summary of their customer support' returning a card of websites and recent conversations. It differentiates from siblings only via the negative 'Not for complete open-conversation totals', without naming the alternative (get_unresolved_conversation_counts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear when-to-use condition ('when someone wants a quick visual summary of their customer support') and a when-not clause ('Not for complete open-conversation totals'). It stops short of naming the sibling to use instead, leaving that to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_conversation3 fields changedInput schema / properties / conversationId / descriptionPrevious value: -"Conversation id"New value: +"Conversation id, up to 200 characters"Output schema / properties / conversation / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "activity": {
- "additionalProperties": false,
- "properties": {
- "agentMessages": {
- "maximum": 50,
- "minimum": 0,
- "type": "integer"
- },
- "customerMessages": {
- "maximum": 50,
- "minimum": 0,
- "type": "integer"
- },
- "internalNotesExcluded": {
- "const": true,
- "type": "boolean"
- },
- "latestPublicActivityTime": {
- "anyOf": [
- {
- "maxLength": 100,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "operatorMessages": {
- "maximum": 50,
- "minimum": 0,
- "type": "integer"
- },
- "sampleHasMore": {
- "type": "boolean"
- },
- "sampledPublicMessages": {
- "maximum": 50,
- "minimum": 0,
- "type": "integer"
- },
- "unknownSenderMessages": {
- "maximum": 50,
- "minimum": 0,
- "type": "integer"
- }
- },
- "required": [
- "sampledPublicMessages",
- "customerMessages",
- "operatorMessages",
- "agentMessages",
- "unknownSenderMessages",
- "latestPublicActivityTime",
- "sampleHasMore",
- "internalNotesExcluded"
- ],
- "type": "object"
- },
- "channel": {
- "anyOf": [
- {
- "maxLength": 100,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "creationTime": {
- "anyOf": [
- {
- "maxLength": 100,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "id": {
- "maxLength": 200,
- "type": "string"
- },
- "lastEditTime": {
- "anyOf": [
- {
- "maxLength": 100,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "resolved": {
- "type": "boolean"
- },
- "unreadMessageCount": {
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
- },
- "websiteId": {
- "anyOf": [
- {
- "maxLength": 200,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "id",
- "websiteId",
- "channel",
- "resolved",
- "unreadMessageCount",
- "creationTime",
- "lastEditTime",
- "activity"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "activity": {
+ "additionalProperties": false,
+ "properties": {
+ "agentMessages": {
+ "maximum": 50,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "customerMessages": {
+ "maximum": 50,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "internalNotesExcluded": {
+ "const": true,
+ "type": "boolean"
+ },
+ "latestPublicActivityTime": {
+ "anyOf": [
+ {
+ "maxLength": 100,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "operatorMessages": {
+ "maximum": 50,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "sampleHasMore": {
+ "description": "True when the conversation has more than 50 recent records",
+ "type": "boolean"
+ },
+ "sampledPublicMessages": {
+ "maximum": 50,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unknownSenderMessages": {
+ "maximum": 50,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "sampledPublicMessages",
+ "customerMessages",
+ "operatorMessages",
+ "agentMessages",
+ "unknownSenderMessages",
+ "latestPublicActivityTime",
+ "sampleHasMore",
+ "internalNotesExcluded"
+ ],
+ "type": "object"
+ },
+ "channel": {
+ "anyOf": [
+ {
+ "maxLength": 100,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "creationTime": {
+ "anyOf": [
+ {
+ "maxLength": 100,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "maxLength": 200,
+ "type": "string"
+ },
+ "lastEditTime": {
+ "anyOf": [
+ {
+ "maxLength": 100,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "resolved": {
+ "type": "boolean"
+ },
+ "unreadMessageCount": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "websiteId": {
+ "anyOf": [
+ {
+ "maxLength": 200,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "websiteId",
+ "channel",
+ "resolved",
+ "unreadMessageCount",
+ "creationTime",
+ "lastEditTime",
+ "activity"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / conversation / descriptionAdded value: +"Safe conversation metadata with sender counts over at most the 50 most recent public messages; null when not found. No message body, preview, message id, customer identifier, staff id, internal note, organization id or arbitrary metadata is returned."get_document5 fields changedInput schema / properties / documentId / descriptionPrevious value: -"Document id. Preferred over slug."New value: +"Article id; takes precedence over slug"Input schema / properties / locale / descriptionPrevious value: -"Locale for the slug lookup (e.g. en, it, fr). Defaults to en."New value: +"Language code for the slug lookup, e.g. en, it or fr; defaults to en"Input schema / properties / slug / descriptionPrevious value: -"Document slug. Used only when documentId is not supplied."New value: +"Article slug, used only when documentId is omitted"Output schema / properties / document / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "content": {
- "maxLength": 20000,
- "type": "string"
- },
- "contentFormat": {
- "anyOf": [
- {
- "enum": [
- "html",
- "markdown",
- "plain-text"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "contentTruncated": {
- "type": "boolean"
- },
- "creationTime": {
- "anyOf": [
- {
- "maxLength": 32,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "id": {
- "pattern": "^[0-9a-f]{24}$",
- "type": "string"
- },
- "lastEditTime": {
- "anyOf": [
- {
- "maxLength": 32,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "locale": {
- "anyOf": [
- {
- "maxLength": 20,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "published": {
- "type": "boolean"
- },
- "slug": {
- "anyOf": [
- {
- "maxLength": 300,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "title": {
- "anyOf": [
- {
- "maxLength": 200,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "websiteId": {
- "anyOf": [
- {
- "pattern": "^[0-9a-f]{24}$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "id",
- "title",
- "slug",
- "locale",
- "websiteId",
- "published",
- "content",
- "contentFormat",
- "contentTruncated",
- "creationTime",
- "lastEditTime"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "content": {
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "contentFormat": {
+ "anyOf": [
+ {
+ "enum": [
+ "html",
+ "markdown",
+ "plain-text"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Syntax the content is written in; null for an empty article"
+ },
+ "contentTruncated": {
+ "description": "True when the content was cut at 20000 characters",
+ "type": "boolean"
+ },
+ "creationTime": {
+ "anyOf": [
+ {
+ "maxLength": 32,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "pattern": "^[0-9a-f]{24}$",
+ "type": "string"
+ },
+ "lastEditTime": {
+ "anyOf": [
+ {
+ "maxLength": 32,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "locale": {
+ "anyOf": [
+ {
+ "maxLength": 20,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "published": {
+ "type": "boolean"
+ },
+ "slug": {
+ "anyOf": [
+ {
+ "maxLength": 300,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "title": {
+ "anyOf": [
+ {
+ "maxLength": 200,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "websiteId": {
+ "anyOf": [
+ {
+ "pattern": "^[0-9a-f]{24}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "slug",
+ "locale",
+ "websiteId",
+ "published",
+ "content",
+ "contentFormat",
+ "contentTruncated",
+ "creationTime",
+ "lastEditTime"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / document / descriptionAdded value: +"The article; null when it is missing or belongs to another organization. Organization ids, translator ids, deprecated slugs, embeddings and arbitrary metadata are never returned."get_unresolved_conversation_counts3 fields changedOutput schema / properties / totalUnresolved / descriptionAdded value: +"Unresolved conversations across every website, listed or not"Output schema / properties / websites / descriptionAdded value: +"Up to 100 websites with the most unresolved conversations, largest first. Customer identifiers, staff ids, message text and organization ids are never returned."Output schema / properties / websitesTruncated / descriptionAdded value: +"True when more than 100 websites have unresolved conversations"get_website2 fields changedInput schema / properties / idOrName / descriptionPrevious value: -"Website id, exact vanity ID, or exact display name"New value: +"Website id, exact vanity id (its lowercase public address) or exact display name"Output schema / properties / website / descriptionAdded value: +"Safe website metadata; null when not found. Organization ids, agent prompts, credentials, integration configuration and arbitrary metadata are never returned."list_campaigns5 fields changedInput schema / properties / cursor / descriptionPrevious value: -"Opaque pagination cursor from a previous call"New value: +"The page.nextCursor of the previous page for the same website; absent for the first page"Input schema / properties / limit / descriptionPrevious value: -"Maximum campaigns per page (default 20)"New value: +"Campaigns per page, from 1 to 50; defaults to 20"Input schema / properties / websiteId / descriptionPrevious value: -"Organization-owned website id whose campaigns to list"New value: +"Website whose campaigns to list"Output schema / properties / campaigns / descriptionAdded value: +"Campaign identity only. Recipient lists, subjects, message content, user ids, organization ids and arbitrary metadata are excluded."Output schema / properties / page / descriptionAdded value: +"hasMore is true when more campaigns follow; pass nextCursor as cursor to get them"list_conversations6 fields changedInput schema / properties / cursor / descriptionPrevious value: -"Opaque pagination cursor from a previous call"New value: +"The page.nextCursor of the previous page with the same filters; absent for the first page"Input schema / properties / limit / descriptionPrevious value: -"Maximum conversations per page (default 20)"New value: +"Conversations per page, from 1 to 50; defaults to 20"Input schema / properties / resolved / descriptionPrevious value: -"Filter by resolved status (true = resolved, false = open)"New value: +"true for resolved conversations, false for open ones; omit for both"Input schema / properties / websiteId / descriptionPrevious value: -"Filter by website id"New value: +"Only conversations on this website; every website when absent"Output schema / properties / conversations / descriptionAdded value: +"Most recent activity first: the id needed for a follow-up call, website id, channel, resolved state, unread count and timestamps. Message bodies, message ids, customer identifiers, internal notes, arbitrary metadata and organization ids are excluded."Output schema / properties / page / descriptionAdded value: +"hasMore is true when more conversations follow; pass nextCursor as cursor to get them"list_documents7 fields changedInput schema / properties / cursor / descriptionPrevious value: -"Opaque pagination cursor from a previous call"New value: +"The page.nextCursor of the previous page with the same filters; absent for the first page"Input schema / properties / limit / descriptionAdded value: +"Articles per page, from 1 to 50; defaults to 20"Input schema / properties / locale / descriptionPrevious value: -"Filter by locale (e.g. en, it, fr)"New value: +"Only articles in this language code, e.g. en, it or fr; every language when absent"Input schema / properties / slugOriginal / descriptionPrevious value: -"Filter by original slug (base slug before localization)"New value: +"Only the language versions of one article: its original slug before translation"Input schema / properties / websiteId / descriptionPrevious value: -"Filter by website id"New value: +"Only articles on this website; every website when absent"Output schema / properties / documents / descriptionAdded value: +"Article metadata, most recently edited first. Document content, embeddings, prompts, organization ids and arbitrary metadata are excluded."Output schema / properties / page / descriptionAdded value: +"hasMore is true when more articles follow; pass nextCursor as cursor to get them"list_websites4 fields changedInput schema / properties / cursor / descriptionPrevious value: -"Opaque pagination cursor from a previous call"New value: +"The page.nextCursor of the previous page; absent for the first page"Input schema / properties / limit / descriptionAdded value: +"Websites per page, from 1 to 50; defaults to 20"Output schema / properties / page / descriptionAdded value: +"hasMore is true when more websites follow; pass nextCursor as cursor to get them"Output schema / properties / websites / descriptionAdded value: +"Websites in the signed-in organization, most recently edited first. Prompts, credentials, integration configuration, organization ids and arbitrary metadata are excluded."open_customer_inbox_conversation1 field changedInput schema / properties / conversationId / descriptionAdded value: +"Conversation id the user selected in the inbox view"resolve_conversation3 fields changedInput schema / properties / conversationId / descriptionPrevious value: -"Conversation id to mark resolved or reopened"New value: +"Conversation to update"Input schema / properties / resolved / descriptionPrevious value: -"true marks the conversation resolved (default), false reopens"New value: +"true to mark it resolved (the default), false to reopen it"Output schema / properties / conversation / descriptionAdded value: +"Only the id, resolved state and last edit time; null when not found. Customer identifiers, staff ids and organization ids are never returned."search_documents4 fields changedInput schema / properties / locale / descriptionPrevious value: -"Filter by locale (e.g. en, it, fr)"New value: +"Language code to search in, e.g. en, it or fr; defaults to en"Input schema / properties / query / descriptionPrevious value: -"Semantic search query"New value: +"What the article should cover, in natural language, up to 500 characters"Input schema / properties / websiteId / descriptionPrevious value: -"Organization-owned website id to search"New value: +"Website whose help center to search"Output schema / properties / documents / descriptionAdded value: +"Closest matches first. Content chunks, embeddings, scores, prompts and arbitrary metadata are excluded."send_message5 fields changedInput schema / properties / content / descriptionPrevious value: -"Message text content"New value: +"Exact reply text the user approved, 1 to 4,000 characters"Input schema / properties / conversationId / descriptionPrevious value: -"Conversation id to send the message in"New value: +"Conversation to reply in"Input schema / properties / idempotencyKey / descriptionPrevious value: -"Stable unique retry key for this exact conversation and reply text"New value: +"Unique key you generate for this conversation and text, up to 255 characters; reuse it only to retry the same send"Output schema / properties / conversationId / descriptionAdded value: +"Conversation the reply was added to"Output schema / properties / creationTime / descriptionAdded value: +"When the reply was recorded; no message id or text is echoed"show_customer_inbox2 fields changedOutput schema / properties / conversationsHaveMore / descriptionAdded value: +"True when conversations exist beyond the 50 sampled or the 20 the view lists"Output schema / properties / unreadConversationCount / descriptionAdded value: +"Conversations with unread messages among the 50 most recently active"show_support_overview4 fields changedInput schema / properties / websiteId / descriptionPrevious value: -"Optionally limit the overview to one organization-owned website"New value: +"Only this website; every website when absent"Output schema / properties / conversations / descriptionAdded value: +"The 20 most recently active conversations: channel, resolved state and timestamps. Customer identifiers, internal record ids, message bodies, prompts, credentials, internal notes, organization ids and arbitrary metadata are excluded."Output schema / properties / openConversationCount / descriptionAdded value: +"Open conversations among the 20 shown, not the organization total"Output schema / properties / websites / descriptionAdded value: +"Up to 20 websites: name, domain and AI-agent status only"get_unresolved_conversation_counts1 field changedInput schema / additionalPropertiesAdded value: +falseopen_customer_inbox_conversation3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"show_customer_inbox2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"show_support_overview3 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_website1 field changedInput schema / properties / idOrName / descriptionPrevious value: -"Website id or exact name"New value: +"Website id, exact vanity ID, or exact display name"get_conversationget_documentget_unresolved_conversation_countsget_websitelist_campaignslist_conversationslist_documentslist_websitesopen_customer_inbox_conversationresolve_conversationsearch_documentssend_messageshow_customer_inboxshow_support_overview
Add one secure layer between your agents and this server.