Genesys Cloud MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.4
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.
Average 3.9/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![genesys-cloud-mcp-server MCP server](https://glama.ai/mcp/servers/MakingChatbots/genesys-cloud-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/MakingChatbots/genesys-cloud-mcp-server)

Score Badge

Copy to your README.md:

[![genesys-cloud-mcp-server MCP server](https://glama.ai/mcp/servers/MakingChatbots/genesys-cloud-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/MakingChatbots/genesys-cloud-mcp-server)

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