What can you do with this server?

The viber-mcp server enables AI assistants to fully interact with the Viber Bot API through the Model Context Protocol, providing tools to send messages, manage media, handle webhooks, and query user/account data. Messaging * Send text messages to individual users (up to 7,000 characters) * Send images with optional captions * Send videos (MP4/H.264, up to 26MB, 180s) with optional thumbnails * Send file attachments (up to 50MB) with custom file names * Send clickable URLs (up to 2,000 characters) * Send GPS location coordinates (latitude/longitude) * Send contact cards with name and phone number * Broadcast text messages to up to 300 Viber users simultaneously Account & User Management * Retrieve bot account info including subscriber count and member list * Fetch user profile details (rate-limited to 2 calls per 12 hours per user) * Check online status of up to 100 Viber users at once Webhook Management * Register a webhook URL to receive Viber events (delivered, seen, failed, subscribed, unsubscribed, conversation_started, message) * Remove/disable the currently registered webhook General * All tools support optional sender name and avatar overrides per message * Input validation before API calls with human-readable error responses for graceful AI handling

Which integrations are available for this server?

Provides tools to interact with the Viber Bot API for sending messages, media, files, broadcasting, managing webhooks, and querying user data.

viber-mcp

by serhiizghama

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

The first MCP server for Viber. Connect any MCP-compatible client -- Claude Desktop, Claude Code, Cursor, Windsurf, and others -- to the Viber Bot REST API and control your Viber bot through natural language.

Viber has over 1 billion registered users, particularly strong in Ukraine, Eastern Europe, Greece, and Southeast Asia. This server gives AI assistants full access to the bot API: send messages, media, files, broadcast to groups, manage webhooks, and query user data.

How it works

┌──────────────────────┐         stdio           ┌──────────────────────┐
│                      │  ◄───────────────────►  │                      │
│   MCP Client         │    JSON-RPC over        │   viber-mcp          │
│                      │    stdin/stdout         │                      │
│   - Claude Desktop   │                         │   13 tools           │
│   - Claude Code      │                         │   Zod validation     │──── HTTPS ───►  Viber API
│   - Cursor           │                         │   Error handling     │                 chatapi.viber.com
│   - Any MCP client   │                         │   Typed responses    │
│                      │                         │                      │
└──────────────────────┘                         └──────────────────────┘

Related MCP server: mcp-connect

Quick start

Try it instantly -- no install required:

VIBER_AUTH_TOKEN=your-token npx @serhii.zghama/viber-mcp

Or install globally:

npm install -g @serhii.zghama/viber-mcp

Setup

Claude Desktop

Add to your config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "viber": {
      "command": "npx",
      "args": ["-y", "@serhii.zghama/viber-mcp"],
      "env": {
        "VIBER_AUTH_TOKEN": "your-bot-token-here",
        "VIBER_SENDER_NAME": "MyBot"
      }
    }
  }
}

Windows note: Replace "command": "npx" with "command": "cmd" and "args" with ["/c", "npx", "-y", "@serhii.zghama/viber-mcp"].

Restart Claude Desktop. The Viber tools will appear in the tools menu.

Claude Code

claude mcp add viber-mcp -e VIBER_AUTH_TOKEN=your-bot-token-here -- npx -y @serhii.zghama/viber-mcp

Cursor

Open Settings > MCP Servers, click + Add, and paste:

{
  "viber": {
    "command": "npx",
    "args": ["-y", "@serhii.zghama/viber-mcp"],
    "env": {
      "VIBER_AUTH_TOKEN": "your-bot-token-here"
    }
  }
}

VS Code (Copilot)

Add to .vscode/mcp.json in your workspace:

{
  "servers": {
    "viber": {
      "command": "npx",
      "args": ["-y", "@serhii.zghama/viber-mcp"],
      "env": {
        "VIBER_AUTH_TOKEN": "your-bot-token-here"
      }
    }
  }
}

Tools

13 tools covering the full Viber Bot API surface:

Messaging

Tool	Description	Key parameters
`send_message`	Send a text message	`receiver`, `text` (up to 7000 chars)
`send_picture`	Send an image with optional caption	`receiver`, `media` (URL), `text` (caption)
`send_video`	Send a video	`receiver`, `media` (URL), `size` (bytes)
`send_file`	Send a file attachment	`receiver`, `media` (URL), `size`, `file_name`
`send_url`	Send a clickable link	`receiver`, `media` (URL, max 2000 chars)
`send_location`	Send GPS coordinates	`receiver`, `latitude`, `longitude`
`send_contact`	Send a contact card	`receiver`, `name`, `phone_number`
`broadcast_message`	Broadcast to up to 300 users	`receivers` (array), `text`

Account & Users

Tool	Description	Key parameters
`get_account_info`	Get bot profile and subscriber count	none
`get_user_details`	Fetch user profile (rate-limited: 2/12h per user)	`id`
`get_online`	Check online status of up to 100 users	`ids` (array)

Webhooks

Tool	Description	Key parameters
`set_webhook`	Register a webhook URL	`url`, `event_types` (optional)
`remove_webhook`	Disable the current webhook	none

All tools validate inputs with Zod schemas before calling the Viber API. On errors, tools return human-readable messages with isError: true so the AI can decide how to proceed.

Full schema details and examples in docs/API_REFERENCE.md.

Configuration

Environment variables, read once at startup:

Variable	Required	Default	Description
`VIBER_AUTH_TOKEN`	yes	--	Bot auth token from the Viber Admin Panel
`VIBER_SENDER_NAME`	no	`Bot`	Default sender display name (max 28 chars)
`VIBER_SENDER_AVATAR`	no	--	Default sender avatar URL
`VIBER_BASE_URL`	no	`https://chatapi.viber.com/pa`	API base URL override
`VIBER_REQUEST_TIMEOUT_MS`	no	`15000`	Per-request timeout in milliseconds

Getting a Viber bot token

Open the Viber Admin Panel
Create a new bot account (or select an existing one)
Copy the token from the bot's settings page
Set it as VIBER_AUTH_TOKEN in your MCP client config

Note: Since February 2024, new Viber bot accounts may require commercial onboarding through Viber partners. Existing bot tokens continue to work.

Development

git clone https://github.com/serhiizghama/viber-mcp.git
cd viber-mcp
pnpm install

Command	Description
`pnpm build`	Build with tsup (ESM, Node 20+)
`pnpm dev`	Build with file watching
`pnpm typecheck`	Run TypeScript strict checks
`pnpm test`	Run vitest (43 tests)

Project structure

src/
  index.ts           -- Entrypoint: config -> client -> server -> stdio
  config.ts          -- Environment variable parsing
  errors.ts          -- ViberApiError class
  server.ts          -- MCP server builder with tool registration
  viber/
    client.ts        -- Typed HTTP client for the Viber REST API
    types.ts         -- Request/response TypeScript interfaces
  tools/
    send-message.ts  -- One file per tool, Zod schema + handler
    ...              -- 12 more tool files
tests/
  viber-client.test.ts   -- Client unit tests (mocked fetch)
  server.test.ts         -- Integration test (spawns server, queries tools/list)
  tools/*.test.ts        -- Per-tool success + error path tests

Architecture decisions

Zero console.log -- stdout is the MCP protocol channel; only console.error for diagnostics
Native fetch -- no axios/node-fetch; minimal runtime dependencies
No retries -- Viber REST calls are user-driven via MCP; silent retries would hide real problems from the AI
Zod validation -- every tool input is validated before reaching the Viber API
Tools never throw -- errors are caught and returned as { isError: true } so the AI can handle them gracefully

Roadmap

Future work -- contributions welcome:

Rich media / carousels -- send_rich_media tool with carousel layout
Keyboards -- interactive button keyboards on messages
Webhook receiver -- sibling package for incoming events via HTTP
Stickers -- send_sticker tool
HTTP transport -- Streamable HTTP for remote MCP deployments

License

MIT © Serhii Zghama

Available Tools

13 tools

broadcast_messageB

Send the same text message to up to 300 Viber users at once

ParametersJSON Schema

Name	Required	Description
`receivers`	Yes	Up to 300 receiver IDs
`text`	Yes	Message text, up to 7000 characters
`sender_name`	No	Display name override (≤28 chars)
`sender_avatar`	No	Avatar URL override

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behaviors. It only states the basic action and limit, but omits important details like whether delivery status is returned, error handling, rate limits, or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence of 12 words with no unnecessary information, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool sends messages and has no output schema. The description fails to explain what the function returns (e.g., success status, failed receivers), leaving a significant gap for an agent to understand the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with adequate descriptions for each parameter. The tool description adds no additional meaning beyond 'send the same text message,' so it does not improve upon the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Send the same text message to up to 300 Viber users at once' clearly states the action and resource, and distinguishes from siblings like send_message (single user) by specifying the broadcast nature and user limit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for broadcasting to multiple users but does not explicitly mention when to use or avoid this tool, nor does it reference alternatives like send_message for individual messages.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_account_infoA

Get the Viber bot account configuration including subscriber count and member list

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states what is returned without mentioning any behavioral traits like authentication, rate limits, or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise and front-loaded, containing no unnecessary words or information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description is clear and specific for a parameterless tool, it lacks context about authentication or whether the tool is read-only. Given no output schema, it is mostly complete but could benefit from a note on safety.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters and 100% schema coverage, the description adds value by specifying that the tool returns subscriber count and member list, which goes beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('Viber bot account configuration') with specific details ('subscriber count and member list'). It effectively distinguishes from sibling tools which focus on messaging and webhook management.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving account configuration but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_onlineB

Check online status of up to 100 Viber users

ParametersJSON Schema

Name	Required	Description	Default
`ids`	Yes	Array of Viber user IDs (max 100)

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description implies a read operation but does not disclose any behavioral traits like permissions, rate limits, error handling, or what happens with invalid IDs. Since no annotations are present, the description should cover these aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that effectively communicates the core action and constraint (up to 100 users). No unnecessary words; it is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (only one parameter, no output schema, no annotations) and the presence of many sibling tools, the description is insufficient. It omits return values, error handling, and when to use, making it incomplete for adequate agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% parameter description coverage, so baseline is 3. The description adds minor context by stating the purpose (online status), but the parameter description already specifies 'Viber user IDs'. No significant new meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('check') and the resource ('online status of up to 100 Viber users'). It distinguishes this tool from siblings like 'get_user_details' or 'send_message' which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, such as when to check online status vs. using other tools. The description lacks context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_user_detailsA

Fetch profile details of a Viber user

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Viber user ID. Note: Viber rate-limits this to 2 calls per 12h per user — cache results if possible.

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It explicitly mentions the Viber rate limit of 2 calls per 12 hours per user and advises caching, which is a valuable behavioral disclosure beyond the input schema. However, it does not describe return format, permissions, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that clearly states the purpose. Every word is useful, and there is no unnecessary content. It is appropriately sized for a simple tool with one parameter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the tool is simple with one parameter and no nested objects, the absence of an output schema means the description should explain what profile details are returned. It does not, leaving that information implicit. The description covers the input and rate limit but lacks output information, making it partially complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already includes a detailed description of the 'id' parameter, including the rate-limit note. The tool description adds no additional semantic meaning beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Fetch') and clearly identifies the resource ('profile details of a Viber user'). Among sibling tools, which are primarily messaging and account tools, this description uniquely identifies its purpose and scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used to get user details, but it does not provide any context about when to use it versus alternatives, nor does it mention any prerequisites or post-conditions. No guidance on exclusion or alternative tools is given, so it only minimally guides usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

remove_webhookA

Disable the currently registered webhook

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states basic purpose. It lacks details on reversibility, authentication, or behavior when no webhook exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with 5 words, extremely concise and front-loaded. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple action with no parameters, the description is adequate but lacks behavioral details that would inform the agent about side effects or prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. Baseline of 4 is appropriate as description adds no param info, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Disable' and resource 'currently registered webhook', clearly distinguishing it from siblings like set_webhook and send_message.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied (after registering a webhook), but no explicit guidance on when not to use or alternatives is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_contactB

Send a contact card to a Viber user

ParametersJSON Schema

Name	Required	Description
`receiver`	Yes	Viber user ID of the receiver
`name`	Yes	Contact name
`phone_number`	Yes	Contact phone number
`sender_name`	No	Display name override (≤28 chars)
`sender_avatar`	No	Avatar URL override

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description must convey behavioral traits. It only states what the tool does ('send a contact card') but omits details like whether it's idempotent, required permissions, rate limits, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no filler words. It's appropriately front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 5 parameters, 3 required, no output schema, and no annotations, the description is too brief. It doesn't explain what a contact card contains, how overrides work, or what the user receives, leaving the agent under-informed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 5 parameters have descriptions in the input schema (100% coverage), so the description adds minimal additional meaning. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Send'), the resource ('contact card'), and the target ('Viber user'), distinguishing it from sibling tools like send_message, send_picture, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like send_message or send_file. There is no mention of prerequisites, restrictions, or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_fileC

Send a file attachment to a Viber user

ParametersJSON Schema

Name	Required	Description
`receiver`	Yes	Viber user ID of the receiver
`media`	Yes	Public URL of the file (≤50MB; see Viber docs for forbidden extensions)
`size`	Yes	File size in bytes
`file_name`	Yes	File name with extension
`sender_name`	No	Display name override (≤28 chars)
`sender_avatar`	No	Avatar URL override

TDQS

C2.9/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description does not disclose any behavioral traits beyond the basic action. It fails to mention important aspects like file size limits, required public URL, or that the user must be online to receive the file. The entire burden is on the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence conveys the core purpose efficiently. However, it could be slightly more structured to include key constraints.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the parameter count (6) and absence of output schema and annotations, the description is too minimal. It does not cover return values, error scenarios, or prerequisites (e.g., ensuring the file URL is accessible).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each parameter having a clear description. The tool description adds no additional meaning beyond what the schema provides, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Send a file attachment to a Viber user' clearly states the action (send) and resource (file attachment), distinguishing it from sibling tools like send_picture or send_video by specifying 'file'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like send_picture or send_video. Missing context on prerequisites or conditions (e.g., user must be a Viber user with an active chat).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_locationB

Send GPS coordinates to a Viber user

ParametersJSON Schema

Name	Required	Description
`receiver`	Yes	Viber user ID of the receiver
`latitude`	Yes	Latitude
`longitude`	Yes	Longitude
`sender_name`	No	Display name override (≤28 chars)
`sender_avatar`	No	Avatar URL override

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states the basic action. It does not disclose any behavioral traits such as error handling, delivery guarantees, or format of the sent message.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the core action. It is not verbose, but could be more informative without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is too minimal for a tool with 5 parameters and no output schema. It does not explain the optional parameters or the return value, leaving gaps in understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description adds no additional meaning beyond the parameter names and types already specified in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action: sending GPS coordinates to a Viber user. It uses a specific verb and resource, distinguishing it from sibling tools like send_message or send_picture.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus other send tools, nor any context about prerequisites or alternative approaches.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_messageB

Send a text message to a Viber user

ParametersJSON Schema

Name	Required	Description
`receiver`	Yes	Viber user ID of the receiver (obtained from a previous incoming event)
`text`	Yes	Message text, up to 7000 characters
`sender_name`	No	Display name override (≤28 chars). Defaults to VIBER_SENDER_NAME env var.
`sender_avatar`	No	Avatar URL override. Defaults to VIBER_SENDER_AVATAR env var.
`tracking_data`	No	Opaque data echoed back in delivery callbacks

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It only says 'send a text message' without disclosing behavioral traits like API call behavior, error handling, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that delivers the core purpose with no wasted words, though it could include more context without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is too sparse. It omits important context such as expected return values, error conditions, or integration requirements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the description does not need to add parameter details. It adds no extra meaning beyond the tool's purpose, which is acceptable for high-coverage schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('send a text message') and target ('to a Viber user'), which effectively distinguishes it from sibling tools like send_picture or send_video.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives (e.g., other send_* tools) or prerequisites (e.g., receiver must be a valid Viber user ID from a prior event).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_pictureA

Send an image with optional caption to a Viber user

ParametersJSON Schema

Name	Required	Description
`receiver`	Yes	Viber user ID of the receiver
`media`	Yes	Public URL of the image (JPEG/PNG, ≤1MB iOS / ≤3MB Android)
`text`	No	Caption, ≤120 chars
`thumbnail`	No	Thumbnail URL
`sender_name`	No	Display name override (≤28 chars)
`sender_avatar`	No	Avatar URL override

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose behavioral traits. Only mentions optional caption; does not explain mutability, required permissions (e.g., user must have subscribed), error handling, or delivery behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no superfluous words. Front-loaded with the verb and core purpose. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 6 parameters with 2 required and no output schema, the description lacks context on success/error responses, prerequisites (e.g., user must be subscribed), and platform-specific behavior beyond schema constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%; the schema already details each parameter's purpose, constraints, and formats. The description adds only 'optional caption' which is redundant with the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action 'send', the resource 'image', and the target 'Viber user'. Distinguishes from sibling tools like send_file and send_video by specifying image format and platform.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implicitly indicates usage for sending images, but does not explicitly contrast with siblings like send_file (which may also handle images) or provide when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_urlB

Send a clickable URL to a Viber user

ParametersJSON Schema

Name	Required	Description
`receiver`	Yes	Viber user ID of the receiver
`media`	Yes	The URL to send
`sender_name`	No	Display name override (≤28 chars)
`sender_avatar`	No	Avatar URL override

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It only says 'Send', implying mutation but offers no details about side effects, restrictions, error states, or success indicators.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence of six words with no extraneous information, perfectly concise for the simple action it describes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and simple parameters, the description provides the basic purpose but omits details like response format, error handling, or usage context, leaving some gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the input schema already documents all parameters. The description adds only 'clickable' beyond schema, which is minimal additional value, meeting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Send'), the object ('clickable URL'), and the recipient ('Viber user'), distinguishing it from sibling tools like send_message or send_file which send other content types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., send_file, send_message) and no prerequisites or context for proper invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_videoC

Send a video to a Viber user

ParametersJSON Schema

Name	Required	Description
`receiver`	Yes	Viber user ID of the receiver
`media`	Yes	Public URL of the video (MP4/H.264, ≤26MB, ≤180s)
`size`	Yes	Video size in bytes
`duration`	No	Video duration in seconds
`thumbnail`	No	Thumbnail URL
`sender_name`	No	Display name override (≤28 chars)
`sender_avatar`	No	Avatar URL override

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not mention that the video must meet format/size constraints, that the message is private, or any potential side effects like delivery status.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise but under-specified. While it has no wasted words, it fails to include necessary context, making it somewhat insufficient for an agent to understand when and how to use it properly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 7 parameters, no annotations, and no output schema, the description is incomplete. It does not explain the delivery process, error scenarios, or how the video is displayed to the user.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions for each parameter, so the description does not need to add further meaning. It neither detracts nor adds value beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action (send) and resource (video) to a Viber user, which distinguishes it from siblings like send_picture or send_file. However, it is not explicit about when to choose this tool over others.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as send_picture or send_file. The description lacks context about the type of video allowed or the user's requirement for URLs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_webhookB

ParametersJSON Schema

Name	Required	Description
`url`	Yes	HTTPS URL with valid CA-issued SSL cert
`event_types`	No	Defaults to all events if omitted
`send_name`	No	Include sender name in callbacks
`send_photo`	No	Include sender photo in callbacks

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description does not disclose side effects (e.g., replaces existing webhook), authorization needs, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is efficient, but lacks necessary detail; still front-loaded with core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema or annotations; description omits critical info like return values, idempotency, and prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'Register' and resource 'webhook URL for receiving Viber events' distinguishes it from siblings like remove_webhook.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like remove_webhook or other messaging tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

13 tool updatesv0.1.0May 26, 2026
- First observedbroadcast_message
- First observedget_account_info
- First observedget_online
- First observedget_user_details
- First observedremove_webhook
- First observedsend_contact
- First observedsend_file
- First observedsend_location
- First observedsend_message
- First observedsend_picture
- First observedsend_url
- First observedsend_video
- First observedset_webhook

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Scored 2026-05-26 13:50 across 13 tools

Disambiguation5/5

Each tool serves a unique purpose: broadcasting vs single messaging, distinct media types for sends, separate info queries, and webhook management. No overlap.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case, e.g., send_message, get_account_info, set_webhook.

Tool Count5/5

With 13 tools, the set is well-scoped for a Viber bot, covering essential operations without excess.

Completeness4/5

Covers key bot operations: sends, broadcasts, user info, webhooks. Minor gaps like interactive keyboards exist but not critical.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

sendbird A
io.usefulapi
MCP server for Sendbird — chat users, channels, members, and messages from your AI client.
Communication Customer Support
142
QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
RogerRat A
io.github.opcastil11
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Communication Agent Orchestration
21

Related MCP Servers

Mattermost MCP Server
Communication Workplace & Productivity
conarti
A
license
A
quality
D
maintenance
MCP Server for the Mattermost API, enabling Claude and other MCP clients to interact with Mattermost workspaces.
Updated 9 months ago (2025-12-20 09:29 UTC)
9
21
3
MIT
mcp-connect
Developer Tools
myat-kyaw-thu
A
license
Not graded
quality
B
maintenance
A dead simple MCP server for exposing your app functions to AI agents like Claude Desktop.
Updated 2 months ago (2026-07-22 16:19 UTC)
21
5
MIT
MCP-manychat
Communication Marketing
vdloureiro
F
license
A
quality
D
maintenance
MCP server for ManyChat API integration that enables Claude and other AI assistants to manage subscribers, tags, custom fields, flows, and send messages through natural language.
Updated 6 months ago (2026-03-04 16:56 UTC)
17
-
VibeKit MCP
Cloud Platforms Agent Orchestration Developer Tools
VibeKit-Bot
A
license
A
quality
A
maintenance
MCP server for VibeKit — build, deploy, and manage hosted apps and chat with each app's persistent server-side AI agent from Claude Desktop, Cursor, or any MCP client. Every app gets its own agent and a live URL; bring your own Claude/OpenAI key or pay-as-you-go.
Updated 17 days ago (2026-08-24 18:15 UTC)
36
39
1
MIT