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 문서를 생성합니다.

생성된 문서는 비즈니스 및 기술 독자 모두를 위해 구성됩니다:

  • Route — IVR 이름, ID, 상태, DNIS(가능한 경우), 구성된 플로우.

  • Business Focus — 플로우 목적 및 고객 메뉴 라우팅.

  • Technical Focus — 플로우 설정, 변수, 프롬프트/TTS, 태스크, 메뉴, 결정 경로.

  • Integrations and Routing Dependencies — Data Actions, Bot Flows, ACD 큐.

사전 요구 사항

  • Node.js 18 이상

  • Client Credentials 권한을 사용하는 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로 테스트

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. 응답이 Route 섹션으로 시작하고 구성된 플로우, 프롬프트 및 통합이 포함되어 있는지 확인합니다.

사용 가능한 도구

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

Data Action / Web Services Data Action

CallBotFlowAction

Bot Flow(이름 및 플로우 ID 포함)

TransferPureMatchAction

ACD Queue

태스크 및 메뉴 인사말에서 발견된 모든 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