Skip to main content
Glama
deenesjakoruzh
m-7-m

Genesys Flow MCP

by m-7-m
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Local

Genesys Flow MCP

Local MCP server that connects to Genesys Cloud, lists IVR routes, retrieves an IVR's configured open-hours flow, and produces readable Markdown documentation.

The generated document is structured for both business and technical readers:

  • Route — IVR name, ID, state, DNIS (when available), and configured flow.

  • Business Focus — the flow purpose and customer menu routing.

  • Technical Focus — flow settings, variables, prompts/TTS, tasks, menus, and decision paths.

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

Prerequisites

  • Node.js 18 or later

  • A Genesys Cloud OAuth client using the Client Credentials grant

  • Permissions to read Architect IVRs and flows in the relevant Genesys Cloud organisation

Related MCP server: Hive Mind MCP Server

Install and configure

Install dependencies:

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

Create a .env file in the project root:

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

Important: GENESYS_CLIENT_SECERET is intentionally spelled this way because it matches the current source code. Do not rename it to SECRET unless you also update src/config/env.ts.

Set GENESYS_REGION to your Genesys Cloud region suffix, for example ie for mypurecloud.ie.

Run locally

For development:

npm run dev

For the compiled server used by desktop clients:

npm run build
npm start

The server uses the MCP stdio transport. It is started by the MCP client; it does not expose a browser URL or HTTP port.

Test with MCP Inspector

Use the MCP Inspector to test the server directly before connecting it to Claude Desktop:

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

The Inspector opens a local browser interface. In it:

  1. Connect to the server using the default stdio configuration.

  2. Open the Tools tab.

  3. Run get_ivrs to confirm Genesys authentication and route retrieval.

  4. Run get_flow_by_name with an IVR name, for example:

    {
  "name": "testt call"
}

  5. Check that the response starts with the Route section and includes the configured flow, prompts, and integrations.

Available tools

get_ivrs

Returns the Genesys Cloud routing/IVR list.

Example request:

List the available Genesys IVRs.

get_flow_by_name

Looks up an IVR by name, retrieves its configured open-hours flow, and returns Markdown documentation.

Input:

{
  "name": "testt call"
}

Example request:

Use get_flow_by_name for the IVR named "testt call".

If the IVR is not found, or it has no open-hours flow, the tool returns an error describing the problem.

What the generated documentation includes

The documentation follows the relationship below:

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

Integration detection covers the common Architect dependencies below:

Architect element

Documented as

DataAction

Data Action / Web Services Data Action

CallBotFlowAction

Bot Flow, including name and flow ID

TransferPureMatchAction

ACD Queue

All TTS prompts found in tasks and menu greetings are included in the technical flow walk.

Test with Claude Desktop

  1. Build the project:

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

  2. In Claude Desktop, open:

    File → Settings → Developer → Edit Config

  3. Add the following at the top level of the opened JSON file. Preserve any existing settings such as 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"
      }
    }
  }
}

    Replace <path-to-genesys-flow-mcp> with the full path to your local project folder. If the file already contains properties, add mcpServers alongside them and ensure the preceding property ends with a comma.

  4. Fully quit and reopen Claude Desktop.

  5. Start a new chat and ask:

    What Genesys tools are available?

    Then test the documentation:

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

Do not commit or share the Claude Desktop config if it contains your client secret. For a local test on a personal device, passing the credentials through the MCP env block is acceptable. Use a dedicated OAuth client with the minimum required Genesys permissions.

Build check

Run the TypeScript build check after code changes:

npm run build

Project structure

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. Dates show when Glama detected each change.

  1. 2 tool updatesv1.0.0
    • First observedget_flow_by_name
    • First observedget_ivrs
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/m-7-m/genesys-flow-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server