Guidepoint

Search the full text of completed expert interview transcripts — covering what experts said, think, or reported about a company, product, or trend. Each transcript is a structured Q&A exchange between an inquirer and a subject-matter expert, covering investment and market diligence, product and adoption research, and advisory and thematic research. Best for on-the-ground competitive intelligence, channel checks, and practitioner perspectives not available in public filings, news, or analyst reports. Each result returns: - transcript_name Name of the source transcript - date Date the expert call took place - inquirer Person or organization who posed the question - respondent Subject-matter expert who answered - question The specific question asked in the transcript - answer The expert's response - context Surrounding passage from the transcript (if available) - reference_url Link to the full transcript on the Guidepoint 360 platform - source_attribution Structured citation object designed for per-claim - description: Single-line Markdown citation for placing next to a supported claim, so users can trace each assertion to its source transcript. - markdown: Preformatted Markdown citation line: label, linked title, and URL in one line for consistent Guidepoint citation practices. Scope boundary — what this tool does not cover `search_library` searches the full text of COMPLETED interview transcripts only. It has no knowledge of upcoming or past event listings, event dates, event registration status, or credit-unit costs. - Scheduled expert events (teleconferences, roundtables, webinars, focus polls) — discovery and browsing of these is covered by `search_events`. Routing distinction: requests about what experts SAID — past commentary, opinions, quotes, channel checks ("what do experts say/think about X?") — are transcript-content requests answered by this tool, even when the phrasing mentions a "call" or "event" (transcripts originate from expert calls). Requests where the event itself is the object — a session to attend, a date, a registration to manage — are answered by the events tools, not this one. How to search: send a direct thematic `query`, concrete `keywords` (names, products, tickers) to narrow which **transcripts (calls)** matter, optional `start_date` / `end_date`, optional `recency_bias`, and `size` for how many ranked excerpts to return in one response. When both `query` and `keywords` are set, keywords narrow transcripts first; the query then ranks excerpts within that set. **Keywords need not appear in every returned chunk**—they gate which calls are in scope; individual excerpts may omit a keyword entirely. See the tool parameter descriptions for phrasing and limits. Expected behavior and limitations - Results reflect **expert opinions and experiences**, not verified facts - Content is conversational and may vary in depth or specificity - Highly niche, emerging, or hypothetical topics may return: - no results, or - loosely related excerpts from adjacent domains When this occurs, broader or more general formulations of the topic may yield more relevant material. Handling multi-part or comparative requests User queries may contain multiple components. These can behave differently depending on structure: - **Comparisons across distinct companies, products, or entities** (e.g., "Veeva vs Salesforce Health Cloud") → More reliable coverage is often achieved by **searching each entity separately** and then comparing results. - **Multiple aspects of the same topic** (e.g., "Ozempic adoption and payer coverage") → These are typically best handled in a **single combined search**, since relevant insights often appear together in the same transcripts. - **Broad or loosely related multi-topic queries** → May benefit from focusing on the **core shared theme** first, then expanding if needed. Error response behavior Tool calls may fail for operational reasons such as quota exhaustion, rate limits, authentication problems, permission restrictions, invalid parameters, unavailable upstream services, or transient infrastructure issues. Errors are distinguished from empty result sets by the `isError: true` flag on the MCP response. Error payload shape When `isError` is true, the payload carries two surfaces: - `content[0].text` — a human-readable error message authored by the tool. It contains the specific facts of the failure (what went wrong, any reset time, any contact address) and is the canonical user-facing wording. - `_meta` — structured fields for programmatic handling: `error_code`, `http_status`, `retryable`, `retry_after_seconds`, `severity`, and `contact` when applicable. These fields describe the failure; they do not duplicate the `text` content. Values in `text` and `_meta` — reset times, retry intervals, contact addresses, remediation steps — are populated server-side and reflect the actual state of the account or service at the time of the call. Values not present in either surface are not available from this response. Errors vs. empty results A successful call that found no matching excerpts returns `isError: false` with an empty result set. This is a normal outcome, not a failure. Only payloads with `isError: true` represent errors. Retryable vs. non-retryable errors The `retryable` flag distinguishes two failure classes: - Retryable errors (`retryable: true`) are typically transient: 5xx responses, network blips, short-window rate limits. When present, `retry_after_seconds` indicates the suggested wait interval before a retry could succeed. - Non-retryable errors (`retryable: false`, often paired with `severity: "error"`) reflect conditions the same request will not resolve on its own — exhausted quota, revoked credentials, disabled account, invalid parameters. These conditions change only when the underlying state changes: quota reset, plan upgrade, credential refresh, or parameter correction. Rendering contract for error-severity payloads When `isError: true` and `_meta.severity` is `"error"`, the `content[0].text` field is the canonical user-facing error message. It is authored server-side for direct display to the end user and is complete on its own. Characteristics of `content[0].text` for error-severity payloads: - The first line is a single `**bolded statement**` summarizing the failure. The bold is load-bearing — it is what draws the user's eye to the actionable headline among the surrounding detail lines. - Subsequent lines carry the full detail: quantitative facts (limits, quotas, consumed-vs-remaining), reset / retry / expiry timestamps with time zone, account or plan identifiers, support or billing contacts, documentation links, and remediation steps. - Every concrete value (timestamps, identifiers, contact addresses, dollar amounts) is calibrated for this specific failure and this specific account. These values are the user's path to resolution. The verbatim text — including the server-applied markdown bold, line breaks, and any links or code spans — is the highest-fidelity representation of the error. Paraphrasing, summarizing, reordering, or stripping formatting drops information the user needs: - Paraphrasing the headline removes the bold emphasis that distinguishes the failure summary from the detail lines. - Summarizing the detail lines tends to drop at least one concrete value (a timestamp, a request ID, a contact channel). - Stripping markdown collapses the visual hierarchy the message was designed around. Example. The fidelity-preserving rendering of an error-severity payload: **Your Guidepoint data pipeline quota for this month is full** — it resets on 2026-05-31. To get access restored sooner, reach out to Sales@guidepoint.com. request_id: req_011CbCFmMGYGotWo8bq3cLRR A lossy rendering of the same payload, for contrast: Your quota is exhausted and won't reset until the end of the month. You can email sales to restore access sooner. The lossy version omits the exact reset date, the contact address, and the request ID, and collapses the bolded headline into prose — all values the user needs to act on the failure.