Gong MCP Server

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation4/5
Most tools have clearly distinct purposes, but search_calls and search_calls_by_account overlap somewhat since search_calls already supports customerName filtering via email domain. However, the custom account search tool explicitly explains its unique post-filtering role, reducing confusion.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case: list_*, get_*, search_*. Multi-word names like search_calls_by_account and get_library_folder_calls are consistent with this pattern. There are no mixed conventions or vague verbs.
Tool Count5/5
15 tools is within the well-scoped range for a comprehensive read-only API integration. Each tool covers a specific need such as call search, summary, transcript, user lookup, trackers, workspaces, and library folders, without unnecessary bloat.
Completeness5/5
The tool set covers the full lifecycle of exploring Gong call data: searching/filtering calls, retrieving metadata/summaries/transcripts, resolving users, managing trackers, and accessing library folders. There are no obvious dead ends—every tool feeds into others or serves a standalone purpose.
Average 4.4/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- Last stable release on August 2, 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?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the list of fields returned and the use case, but no additional behavioral traits such as error handling or rate limits. Given the annotations, this is sufficient but not rich.
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 concise sentences. The first sentence specifies the action and result, the second gives the primary use case. No unnecessary words.
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?
For a simple read tool with one parameter and no output schema, the description conveys the purpose, the data returned, and the typical use case. It does not need to explain return structure because the fields are listed. The annotations further clarify safety. Overall, it is complete for the tool's simplicity.
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 covers 100% of the parameter (userId: 'Gong user ID (numeric string up to 20 digits)'). The description does not add format or constraints beyond the schema, though it does provide context that the ID comes from call data. This context is minor, so 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 a specific user profile and lists the included fields (name, email, title, phone, settings). It distinguishes itself from sibling tools like list_users and search_users by specifying the use case of resolving a specific user ID from call data.
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 provides a clear usage context: 'Use to resolve user IDs returned from call data.' This tells the agent when to use this tool, but does not explicitly exclude alternatives or mention any other tools, so it stops short of a 5.
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 already declare read-only and open-world hints. The description adds value by specifying the return payload is minimal metadata (ID, title, date, duration) and that date filtering is supported, giving context beyond the annotations.
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 that are front-loaded with the core purpose, followed by return info and alternative guidance. Every sentence contributes meaningful content without 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?
The description sufficiently covers the tool's purpose, return behavior, and alternatives for a listing function. Pagination and workspace filtering are documented in the schema, and the annotations cover safety and world assumptions, making it complete for tool selection.
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 all four parameters with detailed descriptions, so the baseline is 3. The description only mentions 'optional date filtering', which adds no new semantic detail beyond what the schema already provides for fromDateTime/toDateTime.
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 'List Gong calls' with a specific verb and resource. The mention of 'optional date filtering' scopes the functionality, and the directive to use get_call_summary or get_call_transcript for other needs distinguishes it from sibling tools.
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?
Provides explicit alternatives for when details or transcripts are needed, guiding tool selection. However, it does not explicitly mention when to use list_calls versus search_calls or other search variants, so it falls short of a full exclusion set.
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 already declare readOnlyHint and openWorldHint, so the description need not restate safety. It adds return-field info but does not disclose pagination behavior or whether deactivated users are included. The added value is modest, consistent with a simple read-only list 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?
Two sentences only. The first states purpose and return fields; the second gives usage guidance and alternatives. Every word earns its place, with no fluff or 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?
For a simple list tool with no output schema and good annotations, the description covers return fields and usage context. It lacks explicit mention of pagination mechanics, though the cursor parameter implies it, making it 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 description coverage is 100% (cursor and includeAvatars have descriptions), so the baseline is 3. The description does not add extra meaning to the parameters beyond what the schema already provides, so no higher score is warranted.
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 lists all Gong users in the organization, specifies return fields (name, email, title, user IDs), and distinguishes from siblings like get_user and search_users by emphasizing the 'all users' scope and its role in providing IDs for search_calls filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool (need a Gong user ID for search_calls filters) and provides a concrete alternative for most cases (pass email directly to primaryUserEmails/participantEmails), giving clear when/why guidance.
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 already declare readOnlyHint=true. The description adds valuable behavior beyond that: it fetches calls and post-filters on parties[].emailAddress, and auto-paginates up to maxCalls. It also discloses the API limitation. This is more than the bare minimum, though it doesn't mention performance implications 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?
Three sentences, each earning its place: purpose, implementation detail, and use-case extension. The description is front-loaded with the main purpose and contains no fluff or repetition of schema fields.
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 8 parameters, full schema coverage, and annotations that establish safety, the description covers the core algorithm, pagination behavior, and an advanced use case. It does not specify default date ranges or what happens when no date range is provided, but the schema covers those details. Overall, it's sufficiently complete for an agent to invoke correctly.
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%, and the schema descriptions are detailed for each parameter. The description adds some relational context (e.g., domains matching parties[].emailAddress, auto-pagination tied to maxCalls) but mostly reinforces what the schema already states. 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 opens with a specific verb and resource: 'Find calls involving a specific account/company by matching email domains of external participants.' It clearly distinguishes this tool from siblings like list_calls and search_calls_by_opportunity by its domain-based account matching approach.
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?
It explains when to use this tool (account/company domain filtering) and notes that the Gong API doesn't natively support account-name filtering, giving context for the workaround. It also mentions a specific external tech-stack use case. However, it doesn't explicitly contrast with sibling tools such as search_calls or search_calls_by_opportunity.
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 already declare readOnlyHint=true and openWorldHint=true, covering the safety profile and incomplete-result behavior. The description adds the filtering-by-IDs-or-creation-date capability but does not disclose additional behavioral specifics like pagination mechanics or response format. Given the annotations, a score of 3 is appropriate.
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, front-loaded with the primary verb and resource, and includes a comparative clause for differentiation. Every word earns its place with no redundancy or fluff.
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 search tool with four optional parameters and no output schema, the description sufficiently conveys its core purpose and use case, and the annotations cover safety and open-world behavior. It does not explicitly mention pagination, but openWorldHint already signals that. The description is complete enough for most scenarios, though adding a note about pagination would make it fully comprehensive.
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 already documents all four parameters. The description mentions 'IDs or creation date' which loosely maps to the userIds and createdFrom/ToDateTime params, but it does not add syntax or format detail beyond what the schema provides. Baseline of 3 is warranted.
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's function: 'Search and filter users by IDs or creation date.' It also differentiates from the sibling tool list_users by noting it is 'More flexible than list_users for resolving specific user IDs from call data,' which provides a specific and distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names an alternative (list_users) and specifies when this tool is preferable: for resolving specific user IDs from call data. This provides clear guidance on when to use this tool versus list_users, fulfilling the 'when/when-not/alternatives' criterion.
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 already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the 'AI-generated' nature, implying non-deterministic output, but doesn't disclose additional behavioral traits like potential latency or variability. This is acceptable given the annotations, but minimal beyond them.
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, front-loaded with the core purpose, and every clause adds value. There is no redundant phrasing or filler, making it highly 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 the simple one-parameter schema, the presence of readOnly/openWorld annotations, and the absence of an output schema, the description is complete. It explains what the summary includes and offers clear usage guidance relative to sibling tools, so an agent can invoke it correctly without additional context.
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 sole parameter callId is fully documented in the schema with type, pattern, and description. The tool description does not add any extra meaning beyond the schema, so the baseline of 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's function: 'Get an AI-generated summary of a single call' and enumerates the summary components (brief overview, key points, topics, action items, detailed outline). It also distinguishes itself from the sibling get_call_transcript, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: 'This is the recommended way to understand a call - use get_call_transcript only if you need exact quotes.' This tells the agent when to use this tool and when to prefer an alternative, which is excellent.
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 already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds meaningful behavioral detail by specifying the returned fields (call IDs, titles, curator notes, snippet timing) and stating 'all calls' in a folder, which implies full retrieval. This goes beyond what annotations provide, though it doesn't mention pagination or rate limits. No contradictions with annotations.
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?
Three sentences, each earning its place: purpose, return fields, usage prerequisites/downstream. Front-loaded with the action, then details. No fluff or redundancy.
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?
The tool is simple (one required parameter, no output schema, read-only annotations). The description covers purpose, parameter source, returned fields, and how the output integrates with other tools. Given the complexity, this is complete enough for an agent to select and invoke the tool correctly.
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%: the folderId parameter is fully described as 'Library folder ID (numeric string, from list_library_folders)' with a regex pattern. The tool description repeats this source ('Use list_library_folders to find folder IDs') but adds no new meaning beyond what the schema already 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?
The description clearly states the tool's function: 'Get all calls saved in a specific Gong library folder.' It uses a specific verb (Get) and resource (calls in a library folder), and distinguishes itself from siblings like list_calls by the folder scoping. It also lists the returned data (call IDs, titles, curator notes, snippet timing), making the purpose unambiguous.
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 gives explicit guidance on prerequisites: 'Use list_library_folders to find folder IDs.' It also suggests downstream usage: 'Call IDs can be passed to get_call_summary or get_call_transcript.' While it does not explicitly name an alternative to avoid, the folder-specific scope clearly implies when this tool is appropriate vs. list_calls. Fairly clear context without explicit exclusions.
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 already declare readOnlyHint=true and openWorldHint=true, so the description's additional note that it lists 'all public' folders adds scoping behavior. It also discloses that the return includes folder IDs and names, which is useful given no output schema. No contradictions with annotations.
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, front-loaded with the core purpose, and no filler. Every sentence contributes either the action, the output, or the prerequisite.
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?
For a single-parameter list operation with good annotations, the description fully covers purpose, output, and usage context. The relationship to get_library_folder_calls and list_workspaces gives adequate integration guidance. No output schema exists, so the description appropriately covers return content.
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 workspaceId well-described including the hint to use list_workspaces. The tool description repeats this hint but adds no new parameter semantics. Baseline 3 is appropriate because the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('public Gong call library folders') and scope ('for a workspace'). It also distinguishes itself from siblings by explaining the output's purpose ('to use with get_library_folder_calls'), making it clear this is a lookup tool for folder IDs.
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 clearly states a prerequisite ('Use list_workspaces to find workspace IDs') and provides downstream context ('to use with get_library_folder_calls'). It doesn't explicitly contrast with alternative tools like list_calls, but the context makes the intended use unambiguous.
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 already declare readOnlyHint=true and openWorldHint=true, so safety is clear. The description adds value by disclosing the performance characteristic (faster than get_call_summary) and listing the specific metadata fields returned, which are behavioral traits beyond what annotations provide.
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, front-loaded sentence that communicates purpose, content, and usage guidance without any wasted words. Every clause earns its place.
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 metadata retrieval tool with one parameter and read-only annotations, the description is largely complete. It lists the key fields returned and provides a usage hint. Minor gap: no output schema exists, so the response structure is not fully specified, but the listed fields mitigate this.
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 has 100% coverage for the single callId parameter, including a pattern and description. The description does not add any extra meaning about the parameter, so the baseline of 3 is appropriate since the schema already fully documents it.
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 'Get metadata for a specific Gong call' with a specific verb and resource, and enumerates the metadata fields (URL, direction, scope, system, duration). It distinguishes from siblings by noting it is faster than get_call_summary when only metadata is needed, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: use this tool when only call metadata is needed, and names the alternative get_call_summary as a slower option. This meets the 'explicit when/alternatives' criterion.
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 already declare readOnlyHint=true, so the description's 'List' operation is consistent. It adds valuable context beyond annotations: naming varies by workspace, admins configure these, and it includes which side is tracked. This helps the agent understand potential variability in the data without contradicting the annotations.
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, dense sentence followed by a short 'Also useful' clause. It front-loads the core purpose and keeps the additional guidance relevant. Slightly verbose due to the example of naming variations, but earns its place by clarifying a real-world ambiguity.
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 the simple tool (one optional parameter) and no output schema, the description is complete. It states what is returned (every tracked phrase and side tracked), when to call it (before search_calls with trackers filter), and why it's useful (explaining tracker hits). No critical context is missing for an agent to invoke it correctly.
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 already covers workspaceId with a description ('Filter trackers by workspace ID') and pattern, so schema coverage is 100%. The tool description adds context that trackers are 'configured in a workspace' but does not clarify behavior when workspaceId is omitted beyond the schema's optional status. 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's function: 'List keyword tracker definitions configured in a workspace, including every tracked phrase and which side is tracked (company/customer).' It uses a specific verb ('List') and identifies the resource ('keyword tracker definitions'), fully distinguishing it from sibling tools like search_calls or get_call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Call this before using the trackers filter on search_calls so you know what names exist' and 'Also useful to explain tracker hits that appear in call summaries.' This clarifies when to use it and its relationship to search_calls, giving the agent concrete context for tool selection.
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?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses the prerequisite of CRM integration and the fact that non-linked calls won't match, which is a behavioral limitation not implied by the schema. It does not contradict the annotations and adds useful context about matching semantics.
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, front-loaded with the core purpose, then immediately covers prerequisites and parameter usage. Every clause earns its place, and there is no redundant restatement of schema details.
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 read-only search tool with no output schema, the description covers the essential usage context: what it finds, the required integration, and parameter relationships. It omits pagination and workspace filtering details, but those are adequately described in the schema, so the description is sufficiently complete for this complexity.
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 schema has high coverage (88%) and already describes each parameter individually. The description adds critical relational semantics by stating 'Provide opportunityIds OR opportunityNames (or both)', which clarifies the mutual exclusivity that is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Find' and clearly identifies the resource 'calls' filtered by 'CRM Opportunities' via ID or name substring. It distinguishes itself from siblings like search_calls_by_account by focusing on opportunities, and the mention of 'calls without CRM linkage will not match' adds operational context.
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?
It states a clear prerequisite ('Requires Gong-CRM integration') and the matching condition ('calls without CRM linkage will not match'), and instructs to provide opportunityIds OR opportunityNames. However, it does not explicitly name alternative tools for non-CRM scenarios, so it lacks explicit exclusion guidance.
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 already declare readOnlyHint=true, indicating the operation is safe and non-destructive. The description adds value by specifying that it returns 'all' workspaces and includes 'IDs and names,' which complements the openWorldHint by confirming the complete dataset is exposed. It does not detail pagination or authentication, but for a read-only list with no parameters, this level of transparency 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?
The description is two sentences with no redundant words. The first sentence immediately states the core action and output. The second sentence provides practical guidance on using the results, earning its place. It is front-loaded and easily scannable, exemplifying concise and structured documentation.
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 the tool's simplicity (no parameters, no output schema), the description is complete. It tells the user what the tool does, what it returns, and how to use the returned data. The sibling context reinforces that workspace IDs are needed for filtering other tools, and this description fully addresses that context.
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 zero parameters, so schema coverage is trivially 100%. The baseline for 0 params is 4, and the description adds no parameter-specific meaning since there are none. The description appropriately focuses on the output, and the lack of parameters needs no further explanation.
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's function with a specific verb and resource: 'List all Gong workspaces with their IDs and names.' It effectively distinguishes itself from sibling tools like list_users and list_calls by focusing on workspaces. The addition of 'with their IDs and names' clarifies the output scope, making the purpose unambiguous.
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 explicitly states when this tool is useful: 'Use workspace IDs as filters in list_calls, search_calls, get_trackers, and other tools.' This provides clear context on how to apply the results. However, it does not explicitly mention when not to use it or name alternative tools, though no other sibling lists workspaces, so the guidance is sufficient but not exhaustive.
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 already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable behavioral context: it returns sentence-level matches with speaker attribution and timestamps, and it mentions the >30-day narrowing requirement (a performance/scope behavior). No contradictions with annotations.
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?
Three sentences, each earning its place: purpose, usage/alternative guidance, and a critical constraint plus output summary. No fluff, front-loaded with the core action. It is concise yet information-dense.
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?
Despite no output schema, the description communicates the return format ('sentence-level matches with speaker attribution and timestamps') and the key scoping constraint. It also differentiates from 14 siblings. Minor gaps include lack of pagination details or error behavior, but for a read-only search tool with a well-annotated schema, this is sufficiently complete.
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?
Schema coverage is 90%, so most parameters are already described. The description adds meaning beyond the schema by tying keywords to an ad-hoc use case, and by specifying that primaryUserIds/domains are required for narrowing when date ranges exceed 30 days—a constraint not evident from the individual parameter descriptions. This enriches the parameter semantics.
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 opens with a clear verb+resource: 'Free-text keyword search across call transcripts within a bounded date range.' It explicitly differentiates from sibling tools by framing this as the ad-hoc transcript search while pointing to search_calls + get_call_summary for recurring tracker-based searches. The example 'calls mentioning competitor X' concretely illustrates the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('Use for ad-hoc searches') and when-not-to-use ('For recurring terms, prefer... Trackers'), naming specific alternative tools. It also gives a critical operational constraint ('Date ranges > 30 days require additional narrowing via primaryUserIds or domains') that informs parameter decisions. This is model-tier guidance.
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 already declare readOnlyHint and openWorldHint. The description adds meaningful behavioral details: default truncation to 10KB and pagination mechanism to avoid context overflow. This goes beyond annotations, though it stops short of describing the full return schema.
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 purpose; the second provides usage and behavioral caveats. No superfluous content, front-loaded with action.
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?
For a simple read-only tool with excellent annotations and a fully descriptive schema, the description covers purpose, when to use, and pagination behavior. The implied return format (speaker-attributed text) is sufficient given the lack of an output schema.
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 already fully documents all three parameters (100% coverage). The description adds value by explaining the rationale for truncation (context overflow prevention) and the pagination workflow, which reinforces the semantics of maxLength and offset.
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 raw transcript with speaker-attributed text for a single call. It explicitly distinguishes itself from get_call_summary by specifying use cases (exact quotes vs. understanding content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Only use this when you need exact quotes' and names the preferred alternative (get_call_summary). Also explains when and how to paginate (maxLength/offset) for long transcripts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, the description reveals auto-pagination up to ~5000 calls, automatic fallback to a compact table when output exceeds caps, AND-composition of filters, case-insensitive tracker matching, and performance implications of the include fields. This is rich behavioral disclosure.
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 long but appropriately structured: a one-line purpose, grouped filter list, behavioral notes, and a usage pattern. Headings and bullets make it scannable, and every section adds actionable guidance beyond the schema.
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 the tool's complexity (21 parameters, no output schema), the description covers return shape (always-returned fields, output size behavior), pagination limits, fallback behavior, and performance guidance. It gives the agent everything needed to decide when and how to invoke it.
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?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by grouping filters (e.g., 'Who hosted', 'Who participated'), warning about unbounded date ranges, recommending get_trackers first, and providing size estimates for include options (e.g., outline ~80KB/call). These are practical semantic additions.
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 states 'Search Gong calls with rich filters' and identifies itself as 'the primary tool for narrowing down calls before drilling in with get_call_summary or get_call_transcript.' This clearly distinguishes it from siblings like list_calls and the account/opportunity-specific search tools.
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?
It explicitly frames the tool as the primary narrowing step and names get_call_summary and get_call_transcript as follow-up alternatives. It does not explicitly exclude related search tools like search_calls_by_account, but it gives strong contextual guidance for when to use this tool.
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:

[![gongio-mcp MCP server](https://glama.ai/mcp/servers/JustinBeckwith/gongio-mcp/badges/card.svg)](https://glama.ai/mcp/servers/JustinBeckwith/gongio-mcp)

Score Badge

Copy to your README.md:

[![gongio-mcp MCP server](https://glama.ai/mcp/servers/JustinBeckwith/gongio-mcp/badges/score.svg)](https://glama.ai/mcp/servers/JustinBeckwith/gongio-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/JustinBeckwith/gongio-mcp'

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