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 targets, but there is meaningful overlap among conversation/inbox tools: list_conversations, open_customer_inbox_conversation, show_customer_inbox, and show_support_overview all surface metadata-only conversation activity and could be confused when an agent needs a simple conversation listing or overview. get_conversation and get_unresolved_conversation_counts are more distinct but still add to the conversation-centric cluster.
Every tool follows a snake_case verb_noun pattern: get_, list_, search_, resolve_, send_, show_, and open_. The longer names like open_customer_inbox_conversation and get_unresolved_conversation_counts are still predictable compound noun phrases, so the overall naming convention is consistent.
With 14 tools, the server is well within the typical coherent range and the count matches its apparent scope: websites, conversations, documents, campaigns, and a few aggregate views. No tool feels purely decorative or like an unexplained duplicate.
The core support workflows are covered: listing and viewing conversations, resolving them, sending messages, and listing/searching/viewing documents and websites. The main gaps are the lack of create/update/delete operations and the absence of campaign detail/send tools, but the server appears intentionally designed as a safe, metadata-focused surface, so agents can still accomplish monitoring and limited action tasks.
Summarize one organization-owned Supovia conversation using safe status fields and sender-category counts from at most 50 recent records. No message body, preview, message id, customer identifier, staff id, internal note, organization id, or arbitrary metadata is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| conversationId | Yes | Conversation id |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| conversation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint, idempotentHint, and destructiveHint false, so safety is covered. The description adds substantial behavioral context: it limits retrieval to at most 50 recent records, specifies the type of data returned (status fields and sender-category counts), and enumerates a long list of excluded data types. This goes well beyond annotations and clearly informs the agent of operational constraints and privacy boundaries.
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 two sentences with no wasted words. The core action and key limits are front-loaded, and the exclusion list is placed after the main intent. It is tightly written while conveying all essential 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?
The tool has a single parameter with full schema coverage and an output schema, so the return structure is documented elsewhere. The description covers the scope (one conversation), the data limits, and exclusions. 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% for conversationId ('Conversation id'), so the schema fully documents the parameter. The description adds the constraint that the conversation must be 'organization-owned', which is not in the schema and gives meaningful semantic context. This elevates it above the baseline for high coverage.
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 uses a specific verb 'Summarize' with a clear resource ('one organization-owned Supovia conversation') and explicitly states the returned data type ('safe status fields and sender-category counts'). It also enumerates what is excluded, which distinguishes it from siblings like list_conversations or open_customer_inbox_conversation. The purpose is unambiguous and not tautological.
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 description implies when to use this tool (for a summary of a single conversation with restricted fields) but does not explicitly name alternatives or state when not to use it. The exclusion list hints that other tools should be used for message bodies or IDs, but no direct routing to siblings is provided. Guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one support document owned by the authenticated Supovia organization, including its article text (capped at 20000 characters) and the contentFormat naming which syntax that text is written in (html, markdown, plain-text). A document owned by another organization returns the same bounded "not found" result. Organization ids, translator ids, deprecated slugs, embeddings, and arbitrary metadata are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Document slug. Used only when documentId is not supplied. | |
| locale | No | Locale for the slug lookup (e.g. en, it, fr). Defaults to en. | |
| documentId | No | Document id. Preferred over slug. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| document | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds substantial behavioral detail beyond that: the article text is capped at 20000 characters, the contentFormat field indicates the syntax, documents from other organizations return a bounded 'not found' result, and certain fields (organization ids, translator ids, deprecated slugs, embeddings, metadata) are never returned. This enriches the agent's understanding of side effects and edge cases.
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 compact and front-loaded: the first sentence states the core action and scope, and subsequent clauses add necessary constraints and exclusions without redundancy. Every sentence serves a purpose, and there is 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 an output schema present, the description need not explain return values. It covers all essential context for correct invocation: ownership scoping, the 20000-character cap, the contentFormat field, the uniform 'not found' behavior for cross-organization documents, and the fields that are never returned. This is sufficient for an agent to decide when and how to call the 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?
Schema description coverage is 100% – each parameter (slug, locale, documentId) has a descriptive schema entry. The tool description adds no additional meaning about the parameters; it only references output characteristics. Since the schema already carries the parameter documentation, the description meets the baseline but does not exceed 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?
The description states a specific verb ('Fetch'), a specific resource ('one support document'), and clarifies scope ('owned by the authenticated Supovia organization'). It distinguishes itself from list_documents and search_documents by specifying it retrieves a single document with full text. The phrase 'including its article text' and 'contentFormat' clearly defines what is returned.
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?
Usage is implied by the purpose: retrieve one document. However, the description does not explicitly contrast with sibling tools like list_documents or search_documents, nor does it state when to prefer this tool over alternatives. It provides no exclusions or explicit when-not-to-use guidance, so it falls at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count every unresolved conversation in the authenticated Supovia organization, grouped by website. Totals cover all returned count groups; the sorted per-website preview is capped at 100 and reports truncation. Customer identifiers, staff ids, message text, and organization ids are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| websites | Yes | |
| totalClamped | Yes | |
| websiteCount | Yes | |
| totalUnresolved | Yes | |
| websitesTruncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral detail beyond that: it discloses that the preview is capped at 100 and reports truncation, and it explicitly guarantees that customer identifiers, staff ids, message text, and organization ids are never returned. These privacy and data-scoping guarantees are important for agent decision-making and are not in 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?
Two sentences, each earning its place. The first sentence defines the core action and grouping; the second addresses the preview cap and privacy guarantees. Information is front-loaded and there is no fluff.
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 there are no parameters, an output schema exists (though not shown in the prompt), and annotations cover safety, the description covers all crucial aspects: what it counts, the grouping dimension, the cap on the preview, the truncation reporting, and the explicit data that will never be returned. An agent has everything needed to call this tool correctly and interpret the results.
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 has zero parameters, so the schema is trivially complete. The description doesn't need to explain any parameters. The absence of parameters is clear from the schema, and the description focuses on behavior rather than parameter details. Since there is nothing to clarify, a perfect score is appropriate.
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 verb ('count'), a clear resource ('unresolved conversations'), and the aggregation dimension ('grouped by website'). It clearly distinguishes this from siblings like list_conversations (which would return individual conversations) and get_conversation (a single conversation), by emphasizing the counting and grouping aspect.
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 description implies when to use this tool: when you need aggregate counts of unresolved conversations grouped by website, rather than the conversation list itself. It doesn't explicitly name alternative tools, but the phrasing 'Count every unresolved conversation... grouped by website' makes the use case self-evident. It also gives specifics about the capped preview and truncation reporting, which helps an agent decide if this tool meets its needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch safe metadata for one website owned by the authenticated Supovia organization. Organization ids, agent prompts, credentials, integration configuration, and arbitrary metadata are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| idOrName | Yes | Website id or exact name |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| website | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, destructiveHint) already establish safety, and the description adds significant behavioral detail: it explicitly lists excluded data (Organization ids, agent prompts, credentials, integration configuration, arbitrary metadata). This goes beyond annotations to set expectations about what the response will not contain, which is valuable for agents.
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 core action ('Fetch safe metadata for one website') and then a concise exclusion list. No redundant language; every word earns its place. Highly efficient.
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 provided (indicated by context), the description need not explain return values. It covers the tool's purpose, scope, ownership, and data safety exclusions. For a simple getter with complete annotations, nothing essential 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% (the parameter idOrName has a description 'Website id or exact name'). The tool description adds no additional parameter semantics, so the baseline of 3 applies. The schema fully documents the parameter, and the description doesn't compensate further.
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?
Description states a specific verb (fetch), a clear resource (one website metadata), and a distinguishing scope (owned by the authenticated Supovia organization). It also contrasts with list_websites by specifying 'one' website, making the purpose unambiguous.
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 clear context (single website, owned by the authenticated org) but does not explicitly name alternatives like list_websites or state when to use them. The guidance is implied by contrast with sibling tools but lacks explicit when/when-not phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a bounded page of campaign identities for one website owned by the authenticated Supovia organization. Recipient lists, subjects, message content, user ids, organization ids, and arbitrary metadata are excluded, and campaigns cannot be sent from this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum campaigns per page (default 20) | |
| cursor | No | Opaque pagination cursor from a previous call | |
| websiteId | Yes | Organization-owned website id whose campaigns to list |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| campaigns | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description doesn't need to restate those. It adds valuable context: the scope is limited to one website owned by the authenticated organization, pagination is bounded, and content fields are deliberately excluded. No contradiction with 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?
A single, dense sentence front-loads the purpose and immediately conveys the resource and scope. It efficiently lists exclusions and the sending prohibition without any filler or repetition.
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 comprehensive schema, an output schema, and annotations covering the read-only/idempotent nature, the description fully explains what is returned, what is excluded, and the operational constraint that sending is not possible. Nothing essential is missing for correct invocation.
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 fully documents limit, cursor, and websiteId. The description's mention of 'bounded page' adds only contextual framing that aligns with the limit/cursor parameters, providing no new technical meaning 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?
The description states a specific verb (List), a concrete resource (campaign identities), and a scope (one website owned by the authenticated Supovia organization). It also explicitly says what is excluded (recipient lists, subjects, message content, user ids, org ids, metadata) and that campaigns cannot be sent, differentiating it from sibling tools like send_message.
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 indicates the use case: retrieving a bounded page of campaign identities, and explicitly rules out getting content or sending campaigns. This implies when to use this tool versus ones that return full campaign details or send messages, though it does not name alternative tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a bounded newest-first page of conversation activity in the authenticated Supovia organization. Returns only the conversation id needed for an explicit follow-up, website id, channel, resolved state, unread count, and timestamps. Message bodies, message ids, customer identifiers, internal notes, arbitrary metadata, and organization ids are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum conversations per page (default 20) | |
| cursor | No | Opaque pagination cursor from a previous call | |
| resolved | No | Filter by resolved status (true = resolved, false = open) | |
| websiteId | No | Filter by website id |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| conversations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations already declare readOnlyHint and idempotentHint, the description goes beyond by detailing the bounded, newest-first nature and enumerating what is included and excluded in the response. It clarifies the scope without contradicting annotations, adding useful context about data returned.
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 a single well-structured paragraph that front-loads the core purpose ('bounded newest-first page') before detailing inclusions and exclusions. It is concise and avoids redundancy, though it could be slightly more scannable with bullet points.
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 paginated list tool with an output schema, the description provides complete contextual coverage: it defines the scope (organization), ordering (newest-first), bounded nature, included fields, and exclusions. Since the output schema exists, return details are covered, and pagination cursor guidance is in the schema. Nothing essential 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% with each parameter (limit, cursor, resolved, websiteId) already described. The tool description adds little beyond the schema, only implicitly referencing the pagination via 'bounded' and 'page'. It meets the baseline but does not enrich parameter understanding further.
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 clearly states the tool lists a bounded, newest-first page of conversation activity within the authenticated Supovia organization. It specifies the exact fields returned (id, website id, channel, resolved state, unread count, timestamps) and explicitly lists exclusions (message bodies, ids, customer identifiers, etc.), making its purpose unambiguous and distinct from siblings like get_conversation.
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 description implies its use case by noting it returns only the id needed for an explicit follow-up, suggesting pairing with get_conversation for details. However, it does not explicitly state when to use this tool versus alternatives like list_unresolved_conversation_counts or search_documents, nor does it mention when not to use it. Guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a bounded newest-first page of safe support-document metadata in the authenticated Supovia organization. Document content, embeddings, prompts, organization ids, and arbitrary metadata are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | Opaque pagination cursor from a previous call | |
| locale | No | Filter by locale (e.g. en, it, fr) | |
| websiteId | No | Filter by website id | |
| slugOriginal | No | Filter by original slug (base slug before localization) |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| documents | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context: it is 'bounded' (paginated), 'newest-first' (ordering), and excludes specific fields (content, embeddings, prompts, org ids, arbitrary metadata). This goes beyond the annotations and clarifies the response scope without contradiction.
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 a single, information-dense sentence that front-loads the core action and scope, then lists exclusions. There is no redundant wording; every clause adds value.
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 the tool's moderate complexity (5 optional params) and existence of an output schema, the description covers the key behavioral aspects: ordering, bounds, and field exclusions. It does not describe pagination mechanics (cursor) but those are in the schema. The description is sufficient for an agent to call it correctly; a small gap is not mentioning that the list is limited to a single page, but 'page' implies that.
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 80% (4 of 5 parameters have descriptions), so the schema already documents most parameters. The description does not add any parameter-level details beyond implying a 'bounded' limit, but the high schema coverage means the description is not required to compensate. Baseline of 3 is appropriate.
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 verb ('List'), a resource ('support-document metadata'), and scope ('bounded newest-first page' in the authenticated Supovia organization). It explicitly distinguishes itself from search by excluding content and arbitrary metadata, making it clear this is a metadata-only listing tool.
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 description indicates when to use it: to list a paginated page of document metadata. It implies this is for list operations, but does not explicitly name alternatives like search_documents or get_document, so it lacks exclusions. The context is clear but not fully explicit about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a bounded page of websites in the authenticated Supovia organization. Only safe website identity and status fields are returned; prompts, credentials, integration configuration, organization ids, and arbitrary metadata are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | Opaque pagination cursor from a previous call |
| Name | Required | Description |
|---|---|---|
| page | Yes | |
| websites | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context by specifying which sensitive fields are excluded (prompts, credentials, integration configuration, organization ids, arbitrary metadata) and by noting the bounded nature of the results. This goes beyond the annotation flags and helps the agent understand what to expect.
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 action and scope, followed by exclusion details. No filler or repetition. Every sentence carries value, and the structure is highly scannable.
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 an output schema exists (per context signal), the description doesn't need to explain return values. It covers the key behavioral nuance (excluded fields) and pagination concept. It doesn't mention sorting or default ordering, but for a simple list tool this is acceptable. Overall, enough for an agent to call it correctly.
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 50%: the cursor parameter has a description, but limit does not. The description adds no parameter-specific guidance, only a hint at pagination via 'bounded page' but no direct explanation of limit or cursor behavior. Since coverage is not high, the description should compensate, but it doesn't, so this is a gap.
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 clear verb ('List') and resource ('websites') within the specific context of the authenticated Supovia organization. It also clarifies that it returns a bounded page, distinguishing it from single-resource getters like get_website. The explicit list of excluded fields further sharpens the purpose.
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 description provides clear context: it is for listing websites in a paginated manner within the organization. It does not explicitly mention when not to use it or name alternatives, but the context is clear enough for an agent to infer it for list-style operations. It stops short of explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh safe activity metadata for one conversation selected in the embedded Supovia inbox. This app-only tool reads no thread and returns no message body, preview, message id, customer detail, or internal note.
| Name | Required | Description | Default |
|---|---|---|---|
| conversationId | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying that it 'reads no thread' and explicitly enumerates the data it does not return, which is behavioral context beyond the annotations. It also calls itself 'app-only', clarifying its operational scope. No contradiction with 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 with zero redundancy. The first sentence states the action and context; the second lists exclusions. This is front-loaded and every word earns its place, making it easy for an agent to parse quickly.
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?
The tool has only one parameter, an output schema, and rich annotations. The description covers what it does, what it does not return, and its app-only nature. It does not explain the output format, but that is handled by the output schema. It also does not mention how to obtain conversationId, but that is a common prerequisite implicit in the tool's name and context. Overall, sufficiently complete for a simple metadata-refresh 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?
Schema description coverage is 0%, so the parameter conversationId has no description in the schema. The description does not explicitly explain the parameter, but its name and the tool's purpose ('for one conversation') make it clear that conversationId identifies the conversation. This adds some meaning but does not fully compensate for the lack of schema documentation, such as whether it accepts an internal ID or external reference.
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 uses a specific verb ('Refresh') and a specific resource ('safe activity metadata for one conversation'), and explicitly lists what it does not return (no thread, message body, preview, message id, customer detail, or internal note). This clearly distinguishes it from sibling tools like get_conversation and send_message, making its purpose unambiguous.
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 description states it is for refreshing metadata for a conversation selected in the embedded Supovia inbox, which implies the agent should use it when a conversation is already in context and only lightweight metadata is needed. It also implicitly warns against using it to retrieve message bodies or details, but does not explicitly name alternative tools or provide a when-not-to-use condition. Thus, clear context but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark one organization-owned Supovia conversation resolved, or reopen it. This is idempotent: re-sending the same state is a no-op write. It broadcasts a conversation-updated event to the operator dashboard. No other conversation field can be changed through this tool, and customer identifiers, staff ids, and organization ids are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
| resolved | No | true marks the conversation resolved (default), false reopens | |
| conversationId | Yes | Conversation id to mark resolved or reopened |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| conversation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining that re-sending the same state is a no-op write, that the tool broadcasts a conversation-updated event, that no other conversation field can be changed, and that customer identifiers, staff ids, and organization ids are never returned. This adds meaningful behavioral and privacy context that the annotations alone do not provide.
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 sentences with no filler. The primary purpose is front-loaded, followed by idempotency, side-effect, and constraint information. Every sentence contributes distinct value.
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 the output schema exists and the annotations cover idempotency and destructiveness, the description supplies the remaining necessary context: mutation scope, event broadcasting, and return-value privacy guarantees. Nothing essential for correctly selecting and invoking this tool 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 already have clear descriptions in the schema. The tool description restates the resolved/reopened semantics but does not add meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 opens with a specific verb and resource: 'Mark one organization-owned Supovia conversation resolved, or reopen it.' It clearly defines the action, including the two possible states, and further disambiguates scope by stating that no other conversation field can be changed through this tool.
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 description establishes clear context: use this tool to resolve or reopen a conversation, and explicitly warns that no other conversation field can be changed through it. It does not name an alternative tool for other conversation updates, but the exclusion is clear enough for an agent to avoid using it for unrelated changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published support documents for one organization-owned Supovia website. Returns at most 5 safe document identities; content chunks, embeddings, scores, prompts, and arbitrary metadata are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Semantic search query | |
| locale | No | Filter by locale (e.g. en, it, fr) | |
| websiteId | Yes | Organization-owned website id to search |
| Name | Required | Description |
|---|---|---|
| documents | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false. The description additionally discloses that the tool returns only identities (not full content) and explicitly lists excluded fields (content chunks, embeddings, scores, prompts, arbitrary metadata). It also specifies the 'at most 5' cap, which is behavioral context not in the annotations. No contradictions; the description adds meaningful behavioral detail beyond the hint flags.
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?
Single, tightly scoped sentence. Every clause delivers value: the scope ('published support documents for one organization-owned Supovia website') and the output cap with exclusions ('Returns at most 5 safe document identities; content chunks, embeddings, scores, prompts, and arbitrary metadata are excluded'). Nothing redundant or wasted.
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 the tool has an output schema (not shown but referenced), the description needn't explain return structure beyond noting the identity-only shape and the cap. It clearly states the search domain, the filter (organization-owned website), and the output limitation. For a search tool with two required parameters and one optional locale, this is complete for correct invocation.
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?
Input schema already covers 100% of parameters with descriptions (query, locale, websiteId). The description adds no new parameter-level details but reinforces that the search is over 'published support documents' and 'organization-owned website', which clarifies the semantics of websiteId and the scope of the query. Since high schema coverage grants a baseline of 3, the description's confirmation of scope elevates it to 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?
Description clearly states a specific verb ('search') and resource ('published support documents'), scoped to 'one organization-owned Supovia website'. It explicitly limits the return to 'at most 5 safe document identities' and excludes content chunks, embeddings, scores, prompts, and arbitrary metadata, which sharply differentiates it from list_documents (which presumably returns all documents) and get_document (which likely returns full content). This is precise and distinguishes the tool from 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?
The description implies usage from the singular path ('Search published support documents') and the restriction to 'organization-owned' websites, but does not explicitly contrast with alternatives or state when not to use it (e.g., when full document content is needed). Since siblings like get_document and list_documents exist, the description could indicate 'when you want a filtered list of matches, use this; when you need full content, use get_document'. Still, the scope and the 'safe identities only' limitation effectively route an agent toward the right context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Idempotently send one exact operator reply in an organization-owned Supovia conversation. Reuse the same idempotencyKey only when retrying the same conversation and text. The result confirms the target and time without returning a message id or echoing the message body.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Message text content | |
| conversationId | Yes | Conversation id to send the message in | |
| idempotencyKey | Yes | Stable unique retry key for this exact conversation and reply text |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| creationTime | Yes | |
| conversationId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond the annotations: it is idempotent, it confirms target and time, and it does not return a message id or echo the body. This aligns with idempotentHint=true and destructiveHint=true without contradiction. It could also mention permission requirements, but the 'organization-owned' qualifier partially covers this.
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 two tightly written sentences, with the primary purpose front-loaded and the key idempotency caveat in the second. There is no fluff or repetition, and every sentence adds value.
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 simple send operation, the description covers purpose, idempotency, return behavior, and ownership constraint, while annotations handle side-effect hints and the output schema handles return details. Minor gaps remain around permission prerequisites and error handling, but these are not critical given the existing structured information.
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%, yet the description enriches parameter meaning: it clarifies that idempotencyKey must be reused only for identical conversation and text, and that conversation must be organization-owned, which is not explicit in the schema. This goes beyond the schema's descriptions by adding usage constraints tied to parameters.
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 uses a specific verb-resource pair, 'send one exact operator reply in an organization-owned Supovia conversation', which clearly differentiates it from read-only siblings like get_conversation and list_conversations. It also states the scope ('organization-owned') and the message type ('operator reply'), leaving no ambiguity about what the tool does.
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 description gives clear guidance on idempotency key reuse ('Reuse the same idempotencyKey only when retrying the same conversation and text'), but it does not explicitly state when to choose this tool over alternatives or when not to use it. The context implies it is for sending operator replies, yet no exclusions or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a metadata-only Supovia inbox and report only how many conversations have unread activity. The embedded view receives conversation ids needed for an explicit follow-up plus channel, status, unread count, and timestamps. It never receives message bodies, previews, message ids, customer details, or internal notes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| conversationsHaveMore | Yes | |
| unreadConversationCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond annotations: the data-privacy boundary (which data is excluded from the view, including customer details, message bodies, and internal notes). This scope limitation is valuable for an agent handling sensitive inbox data and complements rather than contradicts 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?
The description is tightly written: the core purpose is front-loaded, followed by what the view receives, then the privacy boundary. Every sentence earns its place. The five-item negative list is slightly lengthy, but it conveys an important privacy constraint that justifies the space. No filler or repetition.
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 simple 0-parameter tool with an output schema present (so return values need not be spelled out), the description covers what it does, what data it exposes, and what it excludes. The only gap is explicit sibling differentiation, which is mild given the tool's simplicity. An agent has enough to call it correctly.
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?
With 0 parameters, schema coverage is trivially complete and there is nothing to clarify. Per the rubric baseline for 0-param tools, a 4 is appropriate: the description correctly focuses on what the tool does rather than inventing parameter details that don't exist.
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 verb ('opens', 'reports'), resource (metadata-only Supovia inbox), and precise scope (how many conversations have unread activity). The negative-space list ('never receives message bodies, previews, message ids, customer details, or internal notes') actively differentiates it from siblings like list_conversations and get_unresolved_conversation_counts. An agent can tell exactly what this tool is and is not 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?
The description implies a workflow ('needed for an explicit follow-up') and clarifies the tool is a metadata-only counter of unread activity, which suggests when it applies. However, it never names sibling alternatives or states explicit exclusion conditions, such as 'use get_unresolved_conversation_counts for pure aggregate counts' or 'use list_conversations for detailed conversation access.' Given the overlapping sibling set, explicit routing guidance would strengthen this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a bounded organization-scoped snapshot of Supovia websites and recent conversations. Customer identifiers, internal record ids, message bodies, prompts, credentials, internal notes, organization ids, and arbitrary metadata are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| websiteId | No | Optionally limit the overview to one organization-owned website |
| Name | Required | Description |
|---|---|---|
| websites | Yes | |
| conversations | Yes | |
| websitesHaveMore | Yes | |
| conversationsHaveMore | Yes | |
| openConversationCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety. It adds valuable behavioral context by listing exactly what is excluded (customer identifiers, internal ids, message bodies, etc.), which is crucial for privacy expectations and beyond what the schema or annotations provide.
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?
A single, tightly worded sentence that front-loads the core action and scope, then lists exclusions without redundancy. Every word earns its place, making it easy for an agent to quickly grasp the tool's behavior.
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, the return format is covered elsewhere. The description adequately explains the scope and exclusions for a read-only overview tool with one optional parameter. It does not mention what 'recent' means in terms of time window, but the exclusions and bounded nature are sufficient for correct invocation.
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%, meaning the schema already fully documents the optional 'websiteId' parameter. The description adds the phrase 'bounded organization-scoped' which reinforces that the parameter filters within the organization's websites, but it does not introduce substantive new meaning beyond the schema's own description.
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 starts with a specific verb 'Render' and clearly identifies the resource as a 'bounded organization-scoped snapshot of Supovia websites and recent conversations'. It distinguishes itself from sibling list tools by framing the output as a composite snapshot rather than a list, making its purpose unambiguous.
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 description implies this is for getting a high-level overview, but it does not explicitly state when to use it versus the sibling list_websites, list_conversations, or show_customer_inbox tools. There is no mention of conditions under which one alternative is preferable, though the word 'snapshot' hints at a summary view.
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. Dates show when Glama detected each change.
get_conversationget_documentget_unresolved_conversation_countsget_websitelist_campaignslist_conversationslist_documentslist_websitesopen_customer_inbox_conversationresolve_conversationsearch_documentssend_messageshow_customer_inboxshow_support_overviewClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
