get_websiteFetch 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 | Default |
|---|---|---|---|
| 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.
Add one secure layer between your agents and this server.
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.