Skip to main content
Glama
deenesjakoruzh
m-7-m

Genesys Flow MCP

by m-7-m
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Genesys Flow MCP

Genesys Cloud に接続し、IVR ルートを一覧表示し、IVR の設定済み営業時間内フローを取得して、読みやすい Markdown ドキュメントを生成するローカル MCP サーバーです。

生成されたドキュメントは、ビジネス関係者と技術者の両方を対象とした構成になっています。

  • ルート — IVR 名、ID、状態、DNIS（利用可能な場合）、および設定済みフロー。

  • ビジネス面 — フローの目的と顧客メニューのルーティング。

  • 技術面 — フロー設定、変数、プロンプト/TTS、タスク、メニュー、分岐パス。

  • 統合とルーティングの依存関係 — データアクション、ボットフロー、ACD キュー。

前提条件

  • Node.js 18 以降

  • クライアント認証情報 付与を使用する Genesys Cloud OAuth クライアント

  • 関連する Genesys Cloud 組織で Architect IVR とフローを読み取る権限

Related MCP server: Hive Mind MCP Server

インストールと設定

依存関係をインストールします。

cd <path-to-genesys-flow-mcp>
npm install

プロジェクトのルートに .env ファイルを作成します。

GENESYS_CLIENT_ID=your-client-id
GENESYS_CLIENT_SECERET=your-client-secret
GENESYS_REGION=ie

重要: GENESYS_CLIENT_SECERET は、現在のソースコードに一致するため、意図的にこのように綴られています。src/config/env.ts も更新しない限り、SECRET に名前を変更しないでください。

GENESYS_REGION を Genesys Cloud リージョンのサフィックス（例: mypurecloud.ie の場合は ie）に設定します。

ローカルでの実行

開発用:

npm run dev

デスクトップクライアントが使用するコンパイル済みサーバーの場合:

npm run build
npm start

サーバーは MCP stdio トランスポートを使用します。MCP クライアントによって起動されます。ブラウザの URL や HTTP ポートを公開しません。

MCP Inspector でテストする

MCP Inspector を使用して、Claude Desktop に接続する前にサーバーを直接テストします。

cd <path-to-genesys-flow-mcp>
npm run inspect

Inspector によってローカルブラウザのインターフェースが開きます。その中で:

  1. デフォルトの stdio 設定を使用してサーバーに接続します。

  2. ツール タブを開きます。

  3. get_ivrs を実行して、Genesys の認証とルートの取得を確認します。

  4. IVR 名を指定して get_flow_by_name を実行します。例:

    {
  "name": "testt call"
}

  5. レスポンスが ルート セクションで始まり、設定済みのフロー、プロンプト、統合が含まれていることを確認します。

利用可能なツール

get_ivrs

Genesys Cloud のルーティング/IVR リストを返します。

リクエスト例:

List the available Genesys IVRs.

get_flow_by_name

名前で IVR を検索し、設定されている営業時間内フローを取得して、Markdown ドキュメントを返します。

入力:

{
  "name": "testt call"
}

リクエスト例:

Use get_flow_by_name for the IVR named "testt call".

IVR が見つからない場合、または営業時間内フローがない場合は、問題を説明するエラーが返されます。

生成されるドキュメントの内容

ドキュメントは以下の関係に従います:

Genesys IVR Route
        ↓
Configured Open-Hours Flow
        ├── Business Focus: customer routing and menu choices
        └── Technical Focus: prompts, variables, tasks, menus, integrations

統合の検出は、以下の一般的な Architect の依存関係を対象としています:

Architect 要素

ドキュメント上の表記

DataAction

データアクション / Web サービスデータアクション

CallBotFlowAction

ボットフロー（名前とフロー ID を含む）

TransferPureMatchAction

ACD キュー

タスクやメニューの挨拶で見つかったすべての TTS プロンプトは、技術的なフローの説明に含まれます。

Claude Desktop でテストする

  1. プロジェクトをビルドします:

    cd <path-to-genesys-flow-mcp>
npm run build

  2. Claude Desktop で、以下を開きます:

    File → Settings → Developer → Edit Config

  3. 開いた JSON ファイルの最上位レベルに次を追加します。preferences など既存の設定は保持してください。

    {
  "mcpServers": {
    "genesys-flow": {
      "command": "node",
      "args": [
        "<path-to-genesys-flow-mcp>\\dist\\index.js"
      ],
      "env": {
        "GENESYS_CLIENT_ID": "your-client-id",
        "GENESYS_CLIENT_SECERET": "your-client-secret",
        "GENESYS_REGION": "ie"
      }
    }
  }
}

    <path-to-genesys-flow-mcp> をローカルプロジェクトフォルダのフルパスに置き換えます。ファイルにすでにプロパティが含まれている場合は、mcpServers をそれらに追加し、前のプロパティがカンマで終わっていることを確認します。

  4. Claude Desktop を完全に終了して、再度開きます。

  5. 新しいチャットを開始して、次のように尋ねます:

    What Genesys tools are available?

    次に、ドキュメントをテストします:

    Use get_flow_by_name for the IVR named "testt call" and document its route, configured flow, prompts, and integrations.

クライアントシークレットが含まれている場合は、Claude Desktop の設定をコミットしたり共有したりしないでください。個人用デバイスでのローカルテストでは、MCP の env ブロックを介して認証情報を渡しても問題ありません。最小限の必要な Genesys 権限を持つ専用の OAuth クライアントを使用してください。

ビルドチェック

コード変更後に TypeScript のビルドチェックを実行します:

npm run build

プロジェクト構成

src/
├── config/       Environment variable validation
├── mcp/          MCP server and tool registration
├── services/     Genesys authentication, API access, and documentation generation
├── tools/        MCP tool handlers
└── types/        Genesys Cloud response types

Available Tools

2 tools
get_flow_by_nameB

Get a documented Genesys flow by IVR name.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesIVR name

TDQS

B3.3/5.0
Behavior2/5

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

No annotations exist, so the description carries the full burden. It only states the action (get by name) and adds the adjective 'documented' as a constraint, but does not disclose output format, error behavior, authentication needs, or whether the operation is safe/read-only. Minimal behavioral context beyond the name.

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, front-loaded sentence with the verb and resource clearly stated. No filler or redundancy. 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 one-parameter lookup tool, the description covers the core purpose. However, with no output schema, it omits return value details (what a 'documented flow' looks like) and does not disambiguate from the sibling tool. Adequate but with notable gaps.

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 the 'name' parameter described as 'IVR name'. The description repeats this same context, adding no new meaning beyond the schema. Baseline of 3 applies.

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 'Get' and resource 'documented Genesys flow' with a clear lookup scope ('by IVR name'). It effectively distinguishes itself from the sibling tool 'get_ivrs' by targeting flows rather than IVR lists.

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 explicit when-to-use or alternatives are provided. The sibling tool 'get_ivrs' is not mentioned, and the description does not clarify when to choose this over getting IVRs. Guidance is only implicit via the IVR name parameter.

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

get_ivrsA

Get all available IVRs from Genesys Cloud.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior2/5

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

No annotations exist, and the description does not disclose any behavioral aspects such as permissions, side effects, 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.

Conciseness5/5

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

The description is a single, concise sentence with no superfluous words, perfectly sized for its simplicity.

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?

Given the absence of an output schema, the description adequately conveys that the tool returns all available IVRs, satisfying the need for a simple list retrieval.

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 fully covers the input schema; no additional explanation 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 clearly states the verb 'Get' and the resource 'all available IVRs', distinct from the sibling tool 'get_flow_by_name' which targets flows.

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?

No explicit guidance on when to use this tool versus alternatives; usage is implied as the go-to for fetching all IVRs.

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. 2 tool updatesv1.0.0
    • First observedget_flow_by_name
    • First observedget_ivrs
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

B3.4/5.0

Scored across 2 tools

Disambiguation4/5

The two tools are distinct: one retrieves IVRs, the other retrieves a flow by name. However, the second tool's description is unclear about what 'documented' means and how it relates to the IVR name, which could cause slight confusion.

Naming Consistency4/5

Both tools follow the get_ pattern with noun complements (ivrs, flow_by_name). The naming is mostly consistent but 'flow_by_name' includes a qualifier that 'ivrs' lacks, a minor deviation.

Tool Count3/5

With only two tools, the server covers a very narrow scope. While this may be appropriate for a minimal integration, it feels thin and may not justify a dedicated server.

Completeness2/5

The domain appears to be IVR and flow management, but only retrieval operations are present. Missing operations like creating, updating, or deleting flows/IVRs are significant gaps, leaving the surface incomplete.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Related MCP Connectors

Related MCP Servers

  • Hive Mind MCP Server

    Jahanzaib-Kaleem
    A
    license
    Not graded
    quality
    D
    maintenance
    Automatically generates and maintains living documentation for codebases by creating hierarchical hivemind.md files and flowchart diagrams at every directory level, enabling AI navigation and real-time or retroactive documentation of code structure, requirements, and dependencies.
    MIT

  • Documentation MCP Server

    esola-thomas
    A
    license
    A
    quality
    C
    maintenance
    Enables AI assistants to navigate and query hierarchical documentation structures, supporting markdown files with YAML metadata and OpenAPI 3.x specifications. It features intelligent full-text search, metadata filtering, and a built-in web interface for both human and AI-driven documentation access.
    6
    MIT