Skip to main content
Glama
deenesjakoruzh
alexbo-git

kalyvox-mcp

by alexbo-git
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Kalyvox MCP

小規模ビジネス向けのAI電話受付サービス Kalyvox の公式公開Model Context Protocol (MCP) サーバーです。

Kalyvox は、自然言語で24時間365日着信電話に応答し、発信者の意図を特定し、構造化された情報を取得して、リクエストを転送またはエスカレーションし、予約を設定し、実用的な通話サマリーをビジネスに送信します。

ウェブサイト： https://kalyvox.ai/en/
ChatGPTインテグレーション： https://kalyvox.ai/en/integrations/chatgpt
ヘルプセンター： https://kalyvox.ai/en/help

このMCPサーバーが公開するもの

このリポジトリには、ディスカバリーおよびインテグレーションツール向けに設計された、小規模で公開された読み取り専用のMCPサーバーが含まれています。顧客アカウントや内部APIを公開することなく、Kalyvoxに関する公開情報を公開します。

ツール

ツール

目的

get_kalyvox_overview

Kalyvoxとその主なユースケースの簡潔な概要を取得します。

get_kalyvox_features

主なAI電話受付機能を一覧表示します。

get_kalyvox_integrations

主な対応インテグレーションを一覧表示します。

get_kalyvox_links

Kalyvox公式の製品、ヘルプ、インテグレーションのリンクを返します。

find_kalyvox_help

セットアップや製品に関する質問をKalyvox公式ヘルプセンターに案内します。

Related MCP server: SeedanceAI MCP Server

顧客アカウントデータ

Kalyvox は、顧客が選択したアカウントデータや通話データを自然言語で照会できる、認証付きChatGPTインテグレーションも提供しています。

その認証付きインテグレーションは、この公開リポジトリとは別のものです。このリポジトリは、顧客の通話データ、通話文字起こし、発信者の電話番号、APIトークン、Kalyvoxの非公開エンドポイントを公開しません。

詳細はこちら： https://kalyvox.ai/en/integrations/chatgpt

インストール

npm install
npm run build

stdioでMCPサーバーを実行します：

npm start

ビルド後のMCPクライアント設定例：

{
  "mcpServers": {
    "kalyvox": {
      "command": "node",
      "args": ["/absolute/path/to/kalyvox-mcp/dist/index.js"]
    }
  }
}

開発

npm install
npm run build
npm start

サーバーは、公式のModel Context Protocol TypeScript SDKを使用してTypeScriptで実装されています。

Kalyvox の機能

Kalyvox は、着信電話に依存し、チームが忙しいときや対応できないときでもすべてのリクエストを確実に記録する必要があるビジネス向けに構築されています。

主な機能は次のとおりです：

  • 24時間365日のAI電話応答

  • 自然言語による音声会話

  • 発信者の意図の検出と判定

  • カスタムの顧客シナリオと優先順位

  • 構造化された通話サマリーとチケット

  • メールとSMSアラート

  • 人間へのエスカレーションと電話転送ルール

  • Google CalendarとMicrosoft Outlookによる予約設定

  • Zapierオートメーション

  • アカウントと通話分析のためのChatGPTインテグレーション

  • 多言語対応の通話処理

セキュリティ

この公開MCPサーバーには、Kalyvoxの本番環境の認証情報は含まれておらず、Kalyvoxの顧客トークンも必要ありません。アカウント固有の機能は、Kalyvoxの認証とユーザーが制御する共有設定の背後にあります。

MCP Registry

レジストリ識別子：

io.github.alexbo-git/kalyvox-mcp

同梱のserver.jsonは、npmパッケージ公開後にMCP Registryへ公開できるよう準備されています。

ライセンス

MIT © 2026 KALYVOX SASU

Available Tools

5 tools
find_kalyvox_helpFind Kalyvox helpA

Return the official Kalyvox help-center URL for a setup, configuration or product question.

NameRequiredDescriptionDefault
queryYesThe Kalyvox setup or product question.

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the disclosure burden, and it clearly states the observable behavior: returning a URL rather than article content or a search result list. It does not discuss failure behavior or authentication, but for a simple read-only lookup that is a minor gap.

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?

A single sentence that leads with the action and object, with no filler or repetition. Every word contributes to telling the agent what the tool does and when it applies.

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?

For a one-parameter lookup tool with no output schema, the description is nearly complete: it specifies the input type, the return value, and the domain. The only missing context is explicit guidance about which sibling tools cover other question types, but that is more of a usage-guideline nicety than a correctness gap.

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 baseline is 3; the schema already explains that 'query' is the Kalyvox setup or product question. The description's addition of 'configuration' broadens the term slightly but provides no examples or syntax guidance.

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 names a specific verb ('Return'), a concrete resource ('official Kalyvox help-center URL'), and a clear scope ('setup, configuration or product question'). This makes it easy to distinguish from sibling tools like get_kalyvox_overview or get_kalyvox_features without opening their schemas.

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?

It says the tool is for setup, configuration, or product questions, which gives useful context for when to use it. However, it never names alternatives or states when not to use it, leaving the choice among the get_kalyvox_* siblings implicit rather than explicit.

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

get_kalyvox_featuresGet Kalyvox featuresB

List the main capabilities of the Kalyvox AI phone receptionist.

NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does state the action ('list') and the general subject, which is minimally adequate. However, it does not disclose the return format, level of detail, or any limitations (e.g., whether it omits detailed specifications).

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, direct sentence with no filler. The key information ('List', 'main capabilities', 'Kalyvox') is front-loaded, and 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 zero-parameter tool with no output schema, the description is mostly sufficient. However, given the sibling tools, some context about how 'features' differs from 'overview' would improve completeness. As is, it is adequate but leaves minor ambiguity.

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?

There are no parameters, so the description is not required to add parameter-level meaning. The baseline of 4 applies because the schema has no properties and the description correctly focuses on the operation itself.

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 uses a specific verb ('List') and identifies the resource ('main capabilities of the Kalyvox AI phone receptionist'). It is clear about what the tool returns, though it does not explicitly distinguish itself from get_kalyvox_overview, which could overlap in scope.

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 its siblings such as get_kalyvox_overview or get_kalyvox_integrations. The agent must infer the appropriate context from the tool name alone, with no exclusions or alternatives mentioned.

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

get_kalyvox_integrationsGet Kalyvox integrationsA

List the main integrations available with Kalyvox.

NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation that returns a set of items, which is transparent for a simple zero-parameter tool. However, the qualifier 'main' is vague and does not explain filtering criteria or whether the result is exhaustive, leaving some ambiguity about the tool's exact 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, front-loaded sentence with no filler or repetition. It efficiently conveys the tool's core purpose without waste.

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?

For a zero-parameter list tool with no output schema, the description adequately states what is returned (main integrations). It is complete enough for basic invocation, though the vague 'main' qualifier and absence of any sibling differentiation slightly reduce completeness.

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?

The tool has zero parameters and the schema coverage is 100%, so the schema already fully describes the parameter surface. Per the baseline for zero-parameter schemas, a score of 4 is appropriate; the description does not need to add parameter information.

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 ('List') and resource ('main integrations available with Kalyvox'), clearly identifying what the tool does. It also distinguishes itself from siblings like get_kalyvox_features and get_kalyvox_links by naming a distinct resource type.

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. There is no mention of a preferred context, exclusions, or a pointer to a sibling, despite several closely related tools existing. The agent is left to infer usage solely from the name and description.

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

get_kalyvox_overviewGet Kalyvox overviewB

Get a concise overview of Kalyvox and what the AI phone receptionist does.

NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior3/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 of behavioral disclosure. It discloses that the output is a concise overview rather than detailed data, but does not mention whether it is purely read-only, what content it includes, or the response format. For a simple get tool this is thin but not misleading.

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, well-formed sentence that states the purpose directly with no filler. It is appropriately sized and front-loaded.

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?

The description is adequate for a zero-parameter overview tool, but it leaves out details about the response content and does not help an agent distinguish this from the overlapping sibling get_kalyvox_features. With no output schema and no annotations, slightly more context would make it fully complete.

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?

The tool has zero parameters, so there is no parameter documentation needed. The description adds useful context about what the response will cover, which satisfies the baseline for parameter-free tools.

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 tool as retrieving a concise overview of Kalyvox and its AI receptionist function. It names a specific resource, though it does not explicitly differentiate itself from get_kalyvox_features, which could partially overlap.

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?

There is no guidance about when to use this tool versus its siblings. It does not explain that get_kalyvox_features, get_kalyvox_integrations, or get_kalyvox_links are more specific alternatives, nor does it state any conditions for choosing the overview.

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.

  1. 5 tool updatesv0.1.0
    • First observedfind_kalyvox_help
    • First observedget_kalyvox_features
    • First observedget_kalyvox_integrations
    • First observedget_kalyvox_links
    • First observedget_kalyvox_overview
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 5 tools

Disambiguation3/5

Overview and features overlap conceptually, and both get_kalyvox_links and find_kalyvox_help can return help-center URLs. The descriptions provide enough distinction for most use cases, but some misselection is possible.

Naming Consistency4/5

Tool names follow a consistent get_kalyvox_* pattern with clear noun suffixes. find_kalyvox_help is the only deviation, but it still feels natural and readable.

Tool Count5/5

Five tools is well-scoped for a small informational product server. Each tool covers a distinct area of product information without unnecessary duplication.

Completeness4/5

The set covers overview, features, integrations, links, and help routing, which addresses the main informational needs for an AI phone receptionist product. Minor gaps such as use cases, pricing, or FAQ content are not exposed, but agents can work around them via the help-center tools.

Maintenance

ActivityStale
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers