Loading ToolBench
A Model Context Protocol (MCP) server for Gong API integration providing access to sales call data and transcripts from Gong's sales intelligence platform
The server defines 2 tools with HTTP transport (Streamable HTTP). Tool names follow verb_noun convention (list_calls, retrieve_transcripts). However, critical gaps exist: input schemas are incomplete or missing type definitions for parameters, descriptions lack LLM-optimization guidance, no output schemas are documented, and error handling is absent. The code fragment in app/gong_mcp.py cuts off mid-validation function, preventing full assessment of schema rigor. Based on what is visible, this server exhibits significant definition quality issues typical of early-stage implementations.
List Gong calls with optional date range filtering. Returns call details including ID, title, start/end times, participants, and duration. IMPORTANT: When referencing any call, always note the participants and client firm information from the title. The title typically contains the client's company name and key participants. This information will be needed when analyzing transcripts later.
Retrieve transcripts for specified call IDs. Returns detailed transcripts including speaker IDs, topics, and timestamped sentences. IMPORTANT: When analyzing any transcript, always reference the participant and client firm information from the original call listing. The call title and participant details from the list_calls tool should be used to provide context about who was involved in the conversation.
Input parameter schemas lack complete type definitions. 'from_datetime' and 'to_datetime' are marked as strings but no format constraint (ISO 8601) is enforced in the schema itself, only in the description. 'call_ids' array element type is declared but no string format or length constraints visible.
No output schema is documented for either tool. LLMs cannot plan downstream calls or extract specific fields without knowing what structure to expect. Per pattern baseline, 100% of A+ tools have documented return types.
Tool descriptions mention important context (e.g., 'participant and client firm information from the title') but are wordy and include procedural guidance ('When analyzing transcripts, always reference...') that should be implicit in the tool design. Descriptions at ~180 - 220 chars approach the upper bound and could be tightened. No guidance on when to use list_calls vs retrieve_transcripts for different agent intents.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
No error handling or recovery guidance visible in tool definitions. If retrieve_transcripts is called with invalid call_ids, or if the Gong API is unavailable, the tool provides no guidance on retryability or alternative actions.
list_calls accepts optional date-range parameters but provides no pagination support (no limit, offset, page_size, or cursor). The description states 'Returns call details' but does not specify if results are capped, how many, or how to iterate through large result sets.
Parameter naming inconsistency: list_calls uses 'from_datetime' and 'to_datetime' (snake_case with 'from_'/'to_' prefix), while the schema fragment shows 'fromDateTime' (camelCase). Ambiguous which is canonical. Tool-to-parameter naming mismatches force LLMs to reason about field mappings.
Source code is incomplete: app/gong_mcp.py validation functions are cut off mid-definition (is_gong_retrieve_transcripts_args incomplete). Cannot verify that schemas are actually enforced or that input validation is complete. Assuming schemas are enforced at runtime, but evidence is absent.