gong-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
The tools have distinct purposes: generating briefs, retrieving calls, GDPR activities, listing users, filtering calls, and downloading transcripts. There is some potential overlap between getv2callsbyid and postv2callsextensive (both involve call data), but their descriptions clarify that one retrieves a single call while the other filters lists, reducing confusion.
Naming Consistency2/5
The naming is inconsistent, mixing HTTP methods (get, post) with descriptive suffixes in a non-uniform pattern. For example, getv2askanythinggeneratebrief includes an action verb 'generate' in the name, while others like getv2users do not. This lack of a clear, predictable naming convention makes the set harder to navigate.
Tool Count4/5
With 6 tools, the count is reasonable for a Gong CRM integration server. It covers key areas like calls, users, and data privacy without being overwhelming. However, it feels slightly thin for comprehensive CRM operations, such as missing update or delete functionalities.
Completeness3/5
The toolset covers core read operations for calls, users, and GDPR activities, but lacks obvious CRUD completeness. There are no tools for creating, updating, or deleting resources, which are essential for full CRM workflows. This creates gaps that agents might struggle with for comprehensive task handling.
Average 2.3/5 across 6 of 6 tools scored. Lowest: 1.5/5.
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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to describe what 'generate' entails—whether it creates a new document, triggers a process, returns data, or modifies state. It doesn't mention permissions, rate limits, side effects, or output format, leaving critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Generate account/deal brief')—just three words. While this avoids waste, it's under-specified rather than efficiently informative. It's front-loaded but lacks necessary detail, making it more of a placeholder than a helpful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 5 required), lack of annotations, and no output schema, the description is severely incomplete. It doesn't explain what the tool does, how to use it, what parameters mean, or what to expect as output. This leaves the agent with insufficient information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 7 parameters are documented in the schema. The description adds no information about any parameters—it doesn't explain what 'workspace-id', 'brief-name', 'entity-type', 'crm-entity-id', 'period-type', or date ranges mean or how they affect the brief generation. This leaves all parameters semantically undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generate account/deal brief' states the general purpose but lacks specificity. It doesn't clarify what 'brief' means (report, summary, document?), what content it contains, or how it differs from other tools. While it mentions the resource types (account/deal), the verb 'generate' is vague without context about the output format or process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or how it relates to sibling tools like getv2callsbyid or postv2callsextensive. Without any usage context, an agent cannot determine when this tool is the correct choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only hints at GDPR-related activities without detailing operational traits such as read-only vs. destructive actions, authentication needs, rate limits, or response format. This lack of information makes it inadequate for understanding how the tool behaves beyond its vague purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with a single phrase, which is appropriately sized for its limited content. However, it is not front-loaded with critical information and lacks structure, as it only offers a vague hint without actionable details. While concise, it under-specifies rather than efficiently conveying value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involving GDPR data retrieval), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It fails to address key aspects like what 'activities' entail, how results are returned, or any behavioral constraints. This leaves significant gaps for an agent to understand and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description does not add any meaning beyond what the schema provides—it mentions 'email address' but does not explain the 'cursor' parameter or provide context for either. With two parameters and no compensation in the description, this fails to clarify parameter roles or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Activities for an email address (GDPR helper)' states a general purpose but lacks specificity. It mentions retrieving 'activities' related to GDPR compliance, which distinguishes it from sibling tools like user or call operations, but does not specify the exact verb (e.g., 'retrieve' or 'list') or resource details beyond email addresses. This is vague and borders on tautology with the tool name, which implies getting data privacy data.
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 provides no guidance on when to use this tool versus alternatives. It mentions GDPR compliance, implying usage for data privacy requests, but does not specify scenarios, prerequisites, or exclusions. Without explicit when/when-not instructions or named alternatives, it offers minimal usage context, leaving the agent to infer based on the GDPR hint alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Download transcripts' implies a read-only retrieval operation, but it doesn't specify whether this requires authentication, involves pagination (hinted by the 'cursor' parameter), returns structured data or files, has rate limits, or what happens on errors. For a tool with complex filtering parameters and no annotation coverage, this is a significant gap in transparency.
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 extremely concise with just two words, 'Download transcripts', which is front-loaded and wastes no space. While this conciseness comes at the cost of clarity and completeness, it earns a high score for brevity and lack of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (1 parameter with nested objects for filtering), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the tool's behavior, output format, or how to interpret results, leaving the agent with insufficient context to use it effectively. The high schema coverage helps with parameters, but overall guidance is inadequate.
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 the schema fully documenting the 'requestBody' parameter and its nested 'filter' and 'cursor' properties. The description adds no parameter-specific information beyond what the schema provides—it doesn't explain the meaning of 'filter' fields (e.g., date ranges, call IDs) or how 'cursor' works. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to heavily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Download transcripts' is a tautology that essentially restates the tool name 'postv2callstranscript' without adding meaningful specificity. It doesn't clarify what 'transcripts' refer to (call transcripts), what 'download' entails (retrieval vs. file generation), or how this differs from sibling tools like 'getv2callsbyid' or 'postv2callsextensive'. The purpose remains vague and indistinguishable from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, nor does it reference sibling tools like 'getv2callsbyid' (which might fetch call details) or 'postv2callsextensive' (which might handle broader call data). Without any usage instructions, the agent has no basis for selecting this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'rich payload' but doesn't explain what that entails (e.g., data format, pagination, rate limits, or authentication needs). For a tool with complex filtering and content selection parameters, this lack of detail is a significant gap in transparency.
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 a single, efficient sentence that is front-loaded with key information ('Filtered call list'). However, it could be more structured by explicitly stating the verb (e.g., 'Retrieve') and separating purpose from output details for better clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple nested parameters, no output schema, and no annotations), the description is incomplete. It doesn't address the tool's behavior, output format, or error handling, leaving the agent with insufficient context to use it effectively beyond what the input schema provides.
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 the schema fully documents the parameters (e.g., filter fields like fromDateTime, contentSelector options). The description adds no additional meaning beyond the schema, such as explaining parameter interactions or usage examples, but the baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Filtered call list with rich payload' states the purpose (filtering calls) and hints at the output ('rich payload'), but it's vague about what 'rich payload' means and doesn't distinguish this tool from its sibling 'postv2callstranscript' which also deals with calls. It lacks a specific verb and clear resource scope differentiation.
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 guidance is provided on when to use this tool versus alternatives like 'getv2callsbyid' or 'postv2callstranscript'. The description implies filtering capabilities but doesn't specify scenarios, prerequisites, or exclusions for usage, leaving the agent without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Retrieve' implies a read operation, it doesn't specify authentication requirements, rate limits, error conditions, or what happens with invalid IDs. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 maximally concise with a single clear sentence that states the core functionality. There's no wasted language or unnecessary elaboration, making it easy to parse and understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 0% parameter documentation, the description is insufficiently complete. It doesn't address what format the retrieved call data will be in, what fields are included, or provide any context about the 'id' parameter that's essential for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and one required parameter ('id'), the description provides no information about what the 'id' parameter represents, its format, or valid values. The description doesn't compensate for the complete lack of parameter documentation in the schema.
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 the verb ('Retrieve') and resource ('a single call'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling retrieval tools (like 'getv2users' or 'postv2callsextensive'), which would require more specific scope information.
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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'postv2callsextensive' and 'postv2callstranscript' available, there's no indication whether this is for basic call retrieval versus more comprehensive or transcript-focused operations.
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?
With no annotations provided, the description carries the full burden. It discloses the pagination behavior ('100-row pages'), which is a key trait beyond the input schema. However, it doesn't mention other important behaviors like authentication requirements, rate limits, error handling, or what data fields are returned. The description adds some value but leaves significant gaps.
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 extremely concise with just one short phrase ('List Gong users (100-row pages)'). It's front-loaded with the core purpose and includes essential behavioral detail (pagination) in parentheses. Every word earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage (0%), the description is incomplete. It covers the basic purpose and pagination but misses critical context: parameter meaning, authentication, rate limits, return format, and error handling. For a tool with one undocumented parameter and no structured metadata, this leaves too many gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('cursor') with 0% description coverage, so the schema provides no semantic information. The description doesn't mention the 'cursor' parameter at all, failing to compensate for the schema's lack of documentation. It only implies pagination indirectly through '100-row pages', but doesn't explain how the cursor relates to this.
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 the verb 'List' and the resource 'Gong users', making the purpose specific and understandable. However, it doesn't differentiate this tool from potential sibling user-related tools (none are listed among siblings, but the description doesn't address this explicitly).
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 provides no guidance on when to use this tool versus alternatives. It mentions pagination ('100-row pages') but doesn't explain when to use this paginated list versus other user-related operations or how it fits into workflows. No exclusions or prerequisites are stated.
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:

[![gong-mcp MCP server](https://glama.ai/mcp/servers/max-paulus/gong-mcp/badges/card.svg)](https://glama.ai/mcp/servers/max-paulus/gong-mcp)

Score Badge

Copy to your README.md:

[![gong-mcp MCP server](https://glama.ai/mcp/servers/max-paulus/gong-mcp/badges/score.svg)](https://glama.ai/mcp/servers/max-paulus/gong-mcp)

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/max-paulus/gong-mcp'

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