How do I use Genesys Cloud MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Genesys Cloud MCP Server show me conversation volumes for queue 'customer_support' yesterday" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Genesys Cloud MCP Server

by MakingChatbots

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Genesys Cloud MCP Server

npm

A Model Context Protocol (MCP) server for Genesys Cloud's Platform API.

Features

Tool	Description
Search Queues	Searches for queues by their name (supports wildcards)
Query Queue Volumes	Retrieves conversation volumes and member count by Queue IDs
Sample Conversations By Queue	Retrieves a representative sample of Conversation IDs for a Queue ID
Voice Call Quality	Retrieves voice call quality metrics for one or more conversations by ID
Conversation Sentiment	Retrieves the sentiment for one or more conversations by ID
Conversation Topics	Retrieves the topics for a conversation by ID
Search Voice Conversation	Searches voice conversations by optional criteria
Conversation Transcript	Retrieves conversation transcript
OAuth Clients	Retrieves a list of all the OAuth clients
OAuth Client Usage	Retrieves OAuth client usage for given period

Related MCP server: Google Analytics MCP Server

Usage with Claude Desktop

MCP Bundle

This MCP Server provides an MCP Bundle (.mcpb file) along with each release, which is a single-click installable package for Claude Desktop. To use it:

Download the .mcpb file from the latest release
In Claude Desktop navigate to Settings > Extensions.
Open the .mcpb file with Claude
Configure the Region and OAuth Client for the extension

The extension will now be available in your conversations.

NPX

Add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "genesys-cloud": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@makingchatbots/genesys-cloud-mcp-server"],
      "env": {
        "GENESYSCLOUD_REGION": "<PUT REGION HERE>",
        "GENESYSCLOUD_OAUTHCLIENT_ID": "<PUT OAUTHCLIENT ID HERE>",
        "GENESYSCLOUD_OAUTHCLIENT_SECRET": "<PUT OAUTHCLIENT SECRET HERE>"
      }
    }
  }
}

Usage with Gemini CLI

Add below to your .gemini/settings.json file. You can read more about the setup from the official guide.

{
  "mcpServers": {
    "genesysCloud": {
      "command": "npx",
      "args": ["-y", "@makingchatbots/genesys-cloud-mcp-server"],
      "env": {
        "GENESYSCLOUD_REGION": "${GENESYSCLOUD_REGION}",
        "GENESYSCLOUD_OAUTHCLIENT_ID": "${GENESYSCLOUD_OAUTHCLIENT_ID}",
        "GENESYSCLOUD_OAUTHCLIENT_SECRET": "${GENESYSCLOUD_OAUTHCLIENT_SECRET}"
      }
    }
  }
}

Authentication

This currently only supports a stdio server. To configure authentication you'll need to:

Create an OAuth Client in Genesys Cloud
Assign the permissions to it for the tools you want to be used
Provide the following environment variables when referencing the server:
- GENESYSCLOUD_REGION
- GENESYSCLOUD_OAUTHCLIENT_ID
- GENESYSCLOUD_OAUTHCLIENT_SECRET

Development

Getting Started

nvm use
npm install
npm run dev

Under active development

This is part of personal project to create a conversational Business Insights tool. It is a practical way for me to learn MCP servers, and how best to represent Genesys Cloud's Platform APIs in a way that can be easily consumed by LLMs.

There will be a lot of changes, and I will be sure to share my learnings in my newsletter.

Available Tools

10 tools

conversation_sentimentA

Retrieves sentiment analysis scores for one or more conversations. Sentiment is evaluated based on customer phrases, categorized as positive, neutral, or negative. The result includes both a numeric sentiment score (-100 to 100) and an interpreted sentiment label.

ParametersJSON Schema

Name	Required	Description	Default
`conversationIds`	Yes	A list of up to 100 conversation IDs to retrieve sentiment for

TDQS

A4/5.0

Behavior4/5

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

The description discloses the output format (numeric score -100 to 100 and label) and evaluation basis (customer phrases). No annotations beyond title, so description carries burden; it is fairly transparent but lacks details on failure modes 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?

Two sentences with no redundant information. Efficient and front-loaded.

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?

No output schema, but description explains output. Lacks error handling or edge case details. For a simple sentiment tool, it is nearly complete.

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% for the single parameter, so description adds minimal value (e.g., 'one or more conversations' is already in schema). Baseline 3 is appropriate.

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 tool retrieves sentiment analysis scores for conversations, using a specific verb and resource. It is distinct from siblings like conversation_topics and conversation_transcript.

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?

The description implies use for sentiment analysis but does not explicitly state when to use it over alternatives or any exclusions. No guidance on prerequisites or context.

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

conversation_topicsA

Retrieves Speech and Text Analytics topics detected for a specific conversation. Topics represent business-level intents (e.g. cancellation, billing enquiry) inferred from recognised phrases in the customer-agent interaction.

ParametersJSON Schema

Name	Required	Description	Default
`conversationId`	Yes	A UUID for a conversation. (e.g., 00000000-0000-0000-0000-000000000000)

TDQS

A4.3/5.0

Behavior4/5

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

The description states 'Retrieves', indicating a read-only operation. No annotations for destructive or read-only hints exist, so the description carries the burden. It does not mention authorization or rate limits, but for a simple retrieval, the behavior is fairly transparent.

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?

Two concise sentences. First sentence states action and target, second elaborates on topic meaning. No redundant information. Efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one required parameter, no output schema, and simple retrieval, the description is complete. It explains what topics are (business-level intents) and how they are derived. No 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 parameter 'conversationId' well-documented in schema. The description mentions 'a specific conversation' but adds no new semantic meaning beyond the schema. Baseline 3 is appropriate.

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 it retrieves topics for a specific conversation, using specific action 'Retrieves' and resource 'Speech and Text Analytics topics'. It provides examples (cancellation, billing enquiry) and implies difference from siblings like conversation_sentiment and conversation_transcript by focusing on business-level intents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly tells when to use it (when topics needed) but lacks explicit guidance on when not to use it or alternatives. However, the context of sibling tools makes the purpose sufficiently clear.

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

conversation_transcriptA

Retrieves a structured transcript of the conversation, including speaker labels, utterance timestamps, and sentiment annotations where available. The transcript is formatted as a time-aligned list of utterances attributed to each participant (e.g., customer or agent)

ParametersJSON Schema

Name	Required	Description	Default
`conversationId`	Yes	The UUID of the conversation to retrieve the transcript for (e.g., 00000000-0000-0000-0000-000000000000)

TDQS

A4/5.0

Behavior4/5

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

The description indicates a read-only operation ('Retrieves') and describes the output structure. Since annotations do not include readOnlyHint or destructiveHint, the description effectively communicates the non-destructive nature. However, it lacks details on potential error conditions or performance implications (e.g., large transcripts).

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?

Two concise sentences: the first states the action and included content, the second describes the format. No redundant information. Every word contributes to clarity.

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 simple retrieval tool with one parameter and no output schema, the description adequately explains the output format and contents. It could mention handling of invalid conversationIds or pagination for long transcripts, but the current information is sufficient for typical use.

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?

The single parameter conversationId is fully described in the schema with format and example. The description adds value by explaining the transcript contents (speaker labels, timestamps, sentiment) but does not add new semantic details about the parameter itself. With 100% schema coverage, baseline is 3.

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 uses 'Retrieves' as a verb and specifies the resource as a 'structured transcript' with details on what it includes (speaker labels, utterance timestamps, sentiment annotations). This distinguishes it from sibling tools like conversation_sentiment and conversation_topics, which focus on specific aspects.

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?

The description implies usage for obtaining a full transcript, but it does not explicitly state when to use this tool versus alternatives (e.g., use conversation_sentiment for sentiment only). No when-not or prerequisite conditions are provided.

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

oauth_clientsA

Retrieves a list of all OAuth clients, including their associated roles and divisions. This tool is useful for auditing and managing OAuth clients in the Genesys Cloud organization.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

The description uses 'Retrieves' indicating a read operation, but no annotations like readOnlyHint or destructiveHint are provided. It does not disclose permissions, rate limits, or other behavioral traits beyond the obvious listing functionality.

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 that front-loads the purpose. Every word adds value, and there is no redundancy.

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 no output schema and no parameters, the description explains what is retrieved (OAuth clients with roles and divisions). It does not specify the return format or pagination, but for a simple list without parameters, this is adequate.

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 input schema has no parameters, so the description cannot add meaning beyond the schema. With 0 parameters, the baseline is 4, and the description adds no parameter information because none exists.

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 tool retrieves a list of all OAuth clients, including roles and divisions. It uses a specific verb and resource, and distinguishes from sibling 'oauth_client_usage' which focuses on usage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions the tool is useful for auditing and managing OAuth clients, providing clear context. It does not explicitly exclude alternatives, but the sibling tool 'oauth_client_usage' implies when not to use this one.

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

oauth_client_usageA

Retrieves the usage of an OAuth Client for a given period. It returns the total number of requests and a breakdown of Platform API endpoints used by the client.

ParametersJSON Schema

Name	Required	Description
`oauthClientId`	Yes	The UUID of the OAuth Client to retrieve the usage for (e.g., 00000000-0000-0000-0000-000000000000)
`startDate`	Yes	The start date/time in ISO-8601 format (e.g., '2024-01-01T00:00:00Z')
`endDate`	Yes	The end date/time in ISO-8601 format (e.g., '2024-01-07T23:59:59Z')

TDQS

A3.5/5.0

Behavior3/5

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

With no readOnlyHint or other behavioral annotations, the description carries the full burden. It states 'retrieves' implying a read operation, and describes the return data (requests + endpoints breakdown). However, it does not disclose potential limitations such as data latency, rate limits, or required permissions.

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 sentence (~20 words) that is front-loaded with the verb and resource, followed by the output details. No extraneous information; 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?

The tool has no output schema, so the description must explain return values. It does so adequately by mentioning total requests and endpoint breakdown, but lacks details on the structure (e.g., nested objects, pagination) or any caveats about data freshness.

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 well-described parameters. The description adds context that the tool returns usage for a given period, but does not provide additional semantics beyond what the schema already offers. Baseline 3 is appropriate.

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 identifies the tool's action ('retrieves usage') and resource ('OAuth Client'), and specifies the output (total requests and breakdown by Platform API endpoints). It is distinct from sibling tools, which focus on conversations, queues, or voice calls.

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 does not provide guidance on when to use this tool versus alternatives, nor any prerequisites or constraints. It only states the period parameter, but there is no explicit when/when-not or mention of sibling tools.

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

query_queue_volumesA

Returns a breakdown of how many conversations occurred in each specified queue between two dates. Useful for comparing workload across queues. MAX 300 queue IDs.

ParametersJSON Schema

Name	Required	Description
`queueIds`	Yes	List of up to MAX of 300 queue IDs
`startDate`	Yes	The start date/time in ISO-8601 format (e.g., '2024-01-01T00:00:00Z')
`endDate`	Yes	The end date/time in ISO-8601 format (e.g., '2024-01-07T23:59:59Z')

TDQS

A4/5.0

Behavior3/5

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

Adds 'MAX 300 queue IDs' which is a constraint, but this is already present in the schema. No additional behavioral details like error handling, rate limits, or response format. Annotations are minimal, so description carries some burden but is adequate.

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?

Two sentences: first explains what it does, second provides usage context. No extraneous words or repetition. Front-loaded with the core action.

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 three parameters and lack of output schema, the description covers the core purpose and a use case. It does not detail the output shape, but for a simple aggregation tool this is acceptable. Could mention return format briefly, but not essential.

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% with examples. The description repeats the max constraint but does not add new meaning or clarify parameter behavior beyond what the schema provides. Baseline 3 is appropriate.

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?

Clearly states it returns a breakdown of conversation counts per queue in a date range. The verb 'returns' and resource 'breakdown of conversations per queue' are specific and distinguish from sibling tools like sample_conversations_by_queue.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states it is useful for comparing workload across queues. Does not mention when not to use or alternatives, but the context is clear enough for typical use.

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

sample_conversations_by_queueA

Retrieves conversation analytics for a specific queue between two dates, returning a representative sample of conversation IDs. Useful for reporting, investigation, or summarisation.

ParametersJSON Schema

Name	Required	Description
`queueId`	Yes	The UUID of the queue to filter conversations by. (e.g., 00000000-0000-0000-0000-000000000000)
`startDate`	Yes	The start date/time in ISO-8601 format (e.g., '2024-01-01T00:00:00Z')
`endDate`	Yes	The end date/time in ISO-8601 format (e.g., '2024-01-07T23:59:59Z')

TDQS

A3.6/5.0

Behavior3/5

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

No annotations exist beyond the title, so the description carries the behavioral burden. It discloses that the tool returns a 'representative sample' (not exhaustive), which is key. However, it omits details like required permissions, rate limits, or what happens with no matching data.

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 two sentences: one for the action and one for use cases. Every word adds value, with no repetition or fluff. It is well front-loaded.

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 tool's simplicity (3 required params, no output schema), the description is mostly complete. It explains the 'sample' behavior and general use. A minor gap: it doesn't clarify if results are paginated or the maximum sample size.

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?

The input schema covers 100% of parameter descriptions, so the baseline is 3. The description adds no extra meaning beyond the schema, which already explains queueId, startDate, and endDate adequately.

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 states that the tool retrieves a representative sample of conversation IDs for a queue in a date range. The verb 'retrieves' and the resource 'conversation analytics' are specific, and the term 'sample' distinguishes it from sibling tools that provide full data or aggregations.

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?

The description mentions use cases ('reporting, investigation, or summarisation') but does not specify when to avoid this tool or provide alternatives. It implies usage but lacks explicit guidance on exclusions.

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

search_queuesA

Searches for routing queues based on their name, allowing for wildcard searches. Returns a paginated list of matching queues, including their Name, ID, Description (if available), and Member Count (if available). Also provides pagination details like current page, page size, total results found, and total pages available. Useful for finding specific queue IDs, checking queue configurations, or listing available queues.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	The name (or partial name) of the routing queue(s) to search for. Wildcards ('') are supported for pattern matching (e.g., 'Support', 'Emergency', 'Sales'). Use '' alone to retrieve all queues
`pageNumber`	No	The page number of the results to retrieve, starting from 1. Defaults to 1 if not specified. Used with 'pageSize' for navigating large result sets
`pageSize`	No	The maximum number of queues to return per page. Defaults to 100 if not specified. Used with 'pageNumber' for pagination. The maximum value is 500

TDQS

A4/5.0

Behavior3/5

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

The description explains that the tool performs a read-only search and returns paginated results with specific fields. It does not mention permissions, rate limits, or edge cases like empty results. Since no annotations provide behavioral hints, the description carries the full burden, and while adequate, it lacks depth on potential side effects or constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is brief and front-loaded with the primary action. Each sentence adds value, though minor redundancies with the schema could be trimmed. Overall, it is clear and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema is provided, so the description must detail return values. It does so thoroughly, listing the fields and pagination metadata. The tool is simple, and the description covers all necessary aspects for an agent to understand what to expect.

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?

The input schema provides 100% coverage of parameter descriptions, including wildcard usage and default values. The description repeats this information without adding substantial new meaning. Therefore, per the rule that high schema coverage yields a baseline of 3, the score is appropriate.

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 tool searches for routing queues by name with wildcard support. It distinguishes itself from sibling tools like conversation_sentiment or oauth_clients, which deal with different domains. The verb-resource pairing is specific and unequivocal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description outlines use cases such as finding queue IDs, checking configurations, and listing queues. However, it does not explicitly state when to avoid using this tool or mention alternatives among siblings, though the sibling tools are sufficiently different to avoid ambiguity.

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

search_voice_conversationsA

Searches for voice conversations within a specified time window, optionally filtering by phone number. Returns a paginated list of conversation IDs and call duration for use in further analysis or tool calls.

ParametersJSON Schema

Name	Required	Description
`phoneNumber`	No	Optional. Filters results to only include conversations involving this phone number (e.g., '+440000000000')
`pageNumber`	No	The page number of the results to retrieve, starting from 1. Defaults to 1 if not specified. Used with 'pageSize' for navigating large result sets
`pageSize`	No	The maximum number of conversations to return per page. Defaults to 100 if not specified. Used with 'pageNumber' for pagination. The maximum value is 100
`startDate`	Yes	The start date/time in ISO-8601 format (e.g., '2024-01-01T00:00:00Z')
`endDate`	Yes	The end date/time in ISO-8601 format (e.g., '2024-01-07T23:59:59Z')

TDQS

A3.7/5.0

Behavior3/5

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

Annotations provide only a title. The description mentions pagination and returns but does not clarify side effects, auth needs, or rate limits. It adds basic transparency but lacks depth given no annotation support.

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 that front-loads purpose and includes result info. No unnecessary words, perfectly structured.

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?

No output schema exists, but description briefly mentions return fields. It omits pagination metadata, error handling, or defaults like page size limitations that are in the schema but not in description. Slightly lacking for completeness.

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 baseline is 3. The description does not add parameter details beyond echoing phone filter and time window, which are already in the schema.

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 it searches voice conversations with a time window and optional phone filter. It returns IDs and duration for further analysis, differentiating it from sibling analysis tools like conversation_sentiment or conversation_topics.

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?

The description implies use for further analysis but does not specify when not to use or compare to alternatives like search_queues. Sibling context suggests distinct purposes, but no explicit guidance is given.

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

voice_call_qualityA

Retrieves voice call quality metrics for one or more conversations by ID. This tool specifically focuses on voice interactions and returns the minimum Mean Opinion Score (MOS) observed in each conversation as structured JSON. MOS is a measure of perceived audio quality based on factors such as jitter, latency, packet loss, and codec. Use the following legend to interpret MOS values:

• Poor: MOS < 3.5 • Acceptable: 3.5 ≤ MOS < 4.3 • Excellent: MOS ≥ 4.3

ParametersJSON Schema

Name	Required	Description	Default
`conversationIds`	Yes	A list of up to 100 conversation IDs to evaluate voice call quality for

TDQS

A3.9/5.0

Behavior4/5

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

Annotations provide only a title, so the description carries full burden. It clearly indicates a read-only operation ('Retrieves') and describes the output metric (MOS) with a legend. No side effects or permissions are mentioned, but the behavioral trait is sufficiently disclosed for a simple read tool.

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 concise (5 lines) and front-loaded with the main action. It is well-structured, with clear sentences explaining scope, metric definition, and interpretation legend. No extraneous information.

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 tool with no output schema, the description partially compensates by defining MOS and its interpretation, but it lacks exact output structure (e.g., format of the returned JSON). Given low complexity, it is somewhat incomplete.

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%, providing a baseline of 3. The tool description adds context by explaining the purpose of the IDs (voice call quality) and the output (MOS), but it does not enrich the parameter definition beyond what the schema already provides.

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 the specific verb 'Retrieves' and identifies the resource as 'voice call quality metrics for one or more conversations by ID'. It clearly distinguishes from sibling tools like conversation_sentiment and conversation_transcript by focusing on voice interactions and MOS scores.

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?

The description does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. While the target use case (voice call quality) is implied by the name and explanation, no direct guidance is given about when not to use it or which sibling tool to choose instead.

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.

9 tool updatesv1.0.4May 4, 2026

Changedconversation_sentiment2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / conversationIds / items / pattern

Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

Changedconversation_topics2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / conversationId / pattern

Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

Changedconversation_transcript2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / conversationId / pattern

Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

Changedoauth_client_usage2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / oauthClientId / pattern

Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

Changedquery_queue_volumes2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / queueIds / items / pattern

Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

Changedsample_conversations_by_queue2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / queueId / pattern

Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

Changedsearch_queues2 fields changed
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / pageNumber / maximum
```
Added value: +9007199254740991
```
Changedsearch_voice_conversations2 fields changed
- removedInput schema / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / pageNumber / maximum
```
Added value: +9007199254740991
```

Changedvoice_call_quality2 fields changed

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / conversationIds / items / pattern

Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

10 tool updatesv1.0.0Jan 11, 2026
- First observedconversation_sentiment
- First observedconversation_topics
- First observedconversation_transcript
- First observedoauth_client_usage
- First observedoauth_clients
- First observedquery_queue_volumes
- First observedsample_conversations_by_queue
- First observedsearch_queues
- First observedsearch_voice_conversations
- First observedvoice_call_quality

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific Genesys Cloud resources and analytics functions. For example, conversation_sentiment analyzes sentiment, conversation_topics extracts business intents, and voice_call_quality measures audio quality - there is no functional overlap between tools, making selection unambiguous.

Naming Consistency4/5

Tools follow a consistent snake_case naming convention throughout. Most tools use descriptive verb_noun patterns (e.g., search_queues, query_queue_volumes), though a few like oauth_clients and oauth_client_usage use noun-based naming which slightly deviates from the action-oriented pattern of others.

Tool Count5/5

With 10 tools, this server is well-scoped for its Genesys Cloud analytics and management domain. Each tool serves a distinct purpose in conversation analysis, queue management, OAuth administration, and search functionality, with no redundant or trivial tools present.

Completeness4/5

The toolset provides comprehensive coverage for conversation analytics, queue management, and OAuth client administration. Minor gaps exist in the conversation analytics workflow - while tools retrieve sentiment, topics, transcripts, and call quality, there's no tool for creating or managing conversations, though this may be intentional given the server's analytics focus.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

RulebaseOAuth
co.rulebase
CX ops: read conversations, calls and QA evaluations from Zendesk, Freshdesk, Five9 and more.
Customer Support Communication Search
1
Famulor BOAuth
io.famulor
Manage AI assistants, history, calls, campaigns, contacts, knowledge, messaging, and automations.
Speech Processing Communication Knowledge & Memory
7621
oruk Speech A
ai.oruk
Hosted speech-to-text + speech emotion/tone analysis for agents. No install; trial keys built in.
Speech Processing AI & Machine Learning
71
Oi AOAuth
io.github.carhaix
Access Oi Contexts, Workflows, Skills, Guardrails, Connections, and reporting tools.
Workplace & Productivity Project Management
3821

Related MCP Servers

VerifyAX MCPofficial
Autonomous Agents AI & Machine Learning
verifyax
A
license
A
quality
A
maintenance
Enables conversational access to the VerifyAX agent-evaluation platform, exposing tools for agent evaluation workflows through natural language.
Updated a month ago (2026-07-28 15:00 UTC)
12
1
Apache 2.0
Google Analytics MCP Server
Sivakumar-intoaec
A
license
Not graded
quality
B
maintenance
Enables interaction with Google Analytics through Admin and Data APIs, allowing retrieval of account details, reports, and realtime data via natural language.
Updated 2 months ago (2026-07-20 09:57 UTC)
Apache 2.0
mcp-ga4
Search Research & Data
mharnett
A
license
Not graded
quality
A
maintenance
Enables natural language querying of Google Analytics 4, including reports, realtime data, custom dimensions, and property management.
Updated 2 days ago (2026-09-04 21:58 UTC)
174
MIT
genesys-mcp
Customer Support Communication
fsubzwari19
F
license
Not graded
quality
B
maintenance
Enables AI assistants to build and manage Genesys Cloud resources such as queues, skills, users, wrap-up codes, and Architect flows through natural language, including flow diagramming and server-side publishing.
Updated 12 days ago (2026-08-25 11:28 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/MakingChatbots/genesys-cloud-mcp-server'

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

Genesys Cloud MCP Server

Features

Usage with Claude Desktop

MCP Bundle

NPX

Usage with Gemini CLI

Authentication

Development

Getting Started

Under active development

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

VerifyAX MCPofficial

Latest Blog Posts

MCP directory API