Skip to main content
Glama
deenesjakoruzh
m-7-m

Genesys Flow MCP

by m-7-m
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Genesys Flow MCP

本地 MCP 服务器，连接 Genesys Cloud，列出 IVR 路由，检索 IVR 配置的营业时间流程，并生成可读的 Markdown 文档。

生成的文档面向业务和技术读者，结构如下：

  • 路由 — 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 区域后缀，例如 ie 对应 mypurecloud.ie。

本地运行

用于开发：

npm run dev

用于桌面客户端使用的编译后服务器：

npm run build
npm start

服务器使用 MCP stdio 传输。它由 MCP 客户端启动；不暴露浏览器 URL 或 HTTP 端口。

使用 MCP Inspector 测试

在连接到 Claude Desktop 之前，使用 MCP Inspector 直接测试服务器：

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