chronograph-guides
ChatGPTChronograph expert guides — when a name in the guide parameter matches the user's request, call this FIRST, before the help center and before answering from your own knowledge. A guide is a package of authoritative reference documentation written for you, not for the end user. It grounds you in Chronograph's business domain, shows you how to complete a task on the platform, and explains how to drive the other tools in this server. Request a guide at the start of a sequence, before you plan an answer — not after you have drafted one. The help center covers a different need: it answers questions about how an end user navigates and configures the product interface. Use the help center when no guide name matches the request. Call with no arguments to get a one-line description of every guide available to the current user, then call again with guide to get one guide's full markdown. Always fetch a group's <group>__overview guide first. It states that group's scope and names which other guides in the group to fetch for the request — fetch those and read them before you answer. Do not answer from an overview alone when it directs you elsewhere. The guide parameter lists every name that exists, but availability varies by user and environment — an unavailable name returns an error that names what is available, and an empty listing means this user has no guide documentation.
commitment-history
ChatGPTCalculate aggregate net performance values (NAV, Called, Distributed, Unfunded, Net IRR, Net MOIC, Commitment Amount) across commitment history. Use this tool when: - The user requests net fund performance metrics (e.g., "what is the net IRR for Fund X?") - The user requests commitment-level values (e.g., "what is my NAV?", "how much has been called?") - The user asks about portfolio performance without specifying gross (net is the default) CRITICAL: - These are net performance values. For gross performance values (Gross IRR, Gross MOIC, cost, realized, unrealized), use the fund-returns tool instead. - If you are unsure whether the user is asking for gross or net performance, you MUST get explicit confirmation before proceeding. - Do NOT assume a currency. When querying specific funds, use the run-query tool to query funds with reporting_currency: true filtered by fund ID to determine the fund's reporting currency, then use that currency. Only ask the user if the reporting currency cannot be determined. Context: Users MUST trust the values provided; therefore, it's imperative that you reference the response's context object to contextualize results when presenting them: - context.currency: The currency of the returned values; always include unless the user explicitly specified a currency in their request - context.date: The as-of date for the returned metrics; always include unless the user explicitly specified a date in their request - context.type: Always "net" — distinguish this from gross performance when presenting to the user
custom-field-search
ChatGPTResolve a custom field to its definition, by name or by a bare value. Custom fields are client-defined attributes on portfolio entities (e.g. "Deal Type", "Client Industry") — not standard or time-series metrics like Revenue; for those use metric-definition-search instead. Call this before reading any field value with custom-field-value — that tool requires the resolved field id. name mode — resolve a field by its NAME: Each match carries id (the field id custom-field-value needs), labeled_as, field_type, format_as, description, dropdown_options (for select fields), rank, and exact_match — plus is_table_column, table_columns, and also_standalone when the field is a table column (see below). Decision rule, applied to the returned matches: - exact_match is true, or there is only one match: proceed directly with that field. - The top-ranked match's rank is roughly 1.5x or more the runner-up's: proceed with the top match. - Several matches rank closely together: present the top 3-5 to the user and ask which they mean. - No matches: if the search was narrowed by field_type or format_as, retry it unnarrowed first — a narrowed miss does not mean the field is absent, it may live on another entity type or format. Only then ask the user to confirm the field name — never invent or guess a match. A match with is_table_column true is a column inside a table-format field: its table_columns array lists each parent table field (parent_table_field_id, parent_table_labeled_as). If also_standalone is also true, the field is directly usable on its own too — try a direct read with custom-field-value using the match's own id first, and only redirect to a parent table if that comes back empty. If also_standalone is absent, redirect to a parent table rather than treating the column as directly readable. When table_columns has more than one entry, the field is a column in more than one table: name them to the user and pick the one relevant to their question (or ask, if ambiguous) rather than assuming the first. reverse_value mode — resolve a bare VALUE (e.g. "climate", "Austin") to the text-format field(s) it might live in, via a live, index-backed scan of stored values: - Only covers text-format fields (text, text_area) — not dropdown options, dates, or table cells. If the value is a known dropdown option, use name mode with the reverse-resolution guidance below instead. - field_type narrows the scan to one entity type (cheaper, and useful when you already know the entity type); format_as cannot be combined with reverse_value. - Each candidate's entity_match_count is the number of distinct entities, among those scanned, with a matching value for that field — rank candidates by this count. When the scan truncates, it is a floor rather than a census, and which entities were scanned is not guaranteed stable between identical calls. - The response also discloses the scan's caps (entities scanned per entity type, fields read per entity, candidates returned), the per-entity-type scan counts (scan_by_entity_type), and whether any of them truncated the result — a candidate near candidates_returned_cap, or a non-null deepest_fields_per_entity_total, means there may be more matches than shown; narrow with field_type and re-run rather than assuming completeness. - Note the two modes report "nothing found" differently, on purpose: name mode returns an error steering you to metric-definition-search, because a name that matches nothing is probably the wrong tool. reverse_value returns an empty result, because a value that matches nothing is a complete answer. - No matches is a normal, complete result (an empty candidates array) — it does not mean the tool failed. Ask the user to confirm the value or try name mode if you have a field name to try instead; never invent a match. Reverse resolution — the request names a value but no field (e.g. "show me all buyout deals"), for select fields: - Infer plausible field names from the request's own nouns ("buyout deals" → "deal type", "investment type"), run a name search for each, and match the named value against ea…
custom-field-value
ChatGPTRead custom field VALUES, or select entities BY a custom field value. Custom fields are client-defined attributes; for standard metrics like Revenue use the metric tools. A field-scoped read needs the field_id from custom-field-search; enumeration needs neither a field_id nor a prior search. - Point lookup ("What is the Deal Type for Company A?"): entity_ids + field_id. Empty fields list = field not set; entity absent from response = not found or not visible. - Filtered lookup: field_id + ONE of: value_equals (dropdown/multiselect: an exact dropdown_options value), value_contains / value_not_contains (substring match; on a multiselect field, matches any selected option containing the text), date_after / date_before (date-format fields). Empty result = no entities match. - Select-value filter: for a dropdown/multiselect field, value_equals matches one EXACT stored option (from custom-field-search's dropdown_options); value_contains matches any option whose text contains the substring, so it lumps near-misses ("Auction" also catches "Limited Auction"). Use value_equals when you mean one specific option; confirm a fuzzy user phrase against the exact option first. - Enumerate: entity_ids (max 10) with NO field_id returns every populated field, latest value each; a non-null date means history exists (fetch with history: true). An entity that comes back with fields: [] has no populated custom fields — report that plainly and stop; definitions may exist that hold no value for it, and neither custom-field-search nor the metric tools will find more. - Enumerate as of a date, or over a window: add as_of to an enumeration for a point-in-time snapshot — every field at its value in effect on/before the date, static (undated) fields included — OR period_after / period_before for a window listing only fields with a value dated in that range, static fields excluded. The two are mutually exclusive in enumeration, and history still needs a field_id. A window matches the value's PERIOD, not when it was edited: a value backfilled this quarter for an old period counts for that old period. An entity with no in-window (or no as-of) field returns fields: [] with a note saying why — not the "no populated custom fields" note. - Multi-field AND: and_where entries, each with its own field_id and one predicate. - Conditional (Yes/No) fields: reading one also returns its follow-up fields, nested under dependent_fields on the parent's entry, values from the same date as the parent's answer. Follow-ups appear even when the answer is "false" — stored values persist after an answer changes, so never infer Yes from a follow-up having data; the parent's value is the answer. A follow-up with is_conditional: true is itself a Yes/No field whose own follow-ups are NOT included — query its field_id to go one level deeper. A follow-up whose own time-series cadence differs from the parent's (e.g. a static field with a dated series) has values: null with a note — date alignment doesn't apply between them; read that field_id directly instead. history: true reads the parent's series only. Response: each field carries values, {date, value} entries (static: one entry, date null). values: null = populated but unreadable in this read — read its note: a table field's data lives in rows, so never report a table as empty; a conditional follow-up with a mismatched cadence needs its own read instead. [] = nothing stored. Time-series (Company/Investment only): as_of reads the value in effect on that date; omitted = latest. history: true returns the dated series newest-first; total_values is the true length if capped. period_after / period_before select entities holding a value for a period in that window (combinable with one value predicate). Results are unsorted; to sort by a metric (IRR, MOIC), filter here, fetch it for the returned entities via company-metrics / investment-metrics (net: commitment-history), and order by it. Pagination: when has_next_page is true, pass end_cursor as pagination.after.
entity-search
ChatGPTRetrieve companies, funds, groups, and general partners via substring similarity search. Use run-query to filter by specific properties like industry or sector (GICS naming, e.g. "Health Care", not "Healthcare"). Do not include "group" in the query when searching for groups.
fund-returns
ChatGPTQuery gross fund-level performance data (cost, realized, unrealized, gross MOIC, gross IRR). Use this tool when: - The user requests gross fund performance metrics (e.g., "what is the gross MOIC for Fund X?") - The user requests fund-level cost, realized, and unrealized values (e.g., "what is the total cost for Fund X?") - The user asks about a fund's investment performance or returns (e.g., "how is Fund X performing?", "what are the returns for Fund X?") CRITICAL: - These are gross performance values. For net performance values (Net IRR, Net MOIC, DPI, RVPI, NAV, Called, Distributed), use the commitment-history tool instead. - If you are unsure whether the user is asking for gross or net performance, you MUST get explicit confirmation before proceeding. - Unless the user asks for historical or multi-period data, you MUST pass the date argument. Context: Users MUST trust the values provided; therefore, it's imperative that you reference the response's context object to contextualize results when presenting them: - context.currency: The currency of the returned values; always include unless the user explicitly specified a currency in their request - context.date: The as-of date for the returned aggregate metrics or null for time series; always include unless the user explicitly specified a date in their request - context.type: Always "gross" — distinguish this from net performance when presenting to the user Source Citations: - Each fund return record may include a document_tags object, grouped by field name (e.g. { cost: [...], realized: [...] }). Each annotation provides filename, page, and document_id identifying the source document the value was extracted from. - When presenting values to the user, cite the source filename and page number alongside the relevant value so the user can verify the data against its source. If multiple values share the same source document and page, a single citation after the group is sufficient.
get-help-center-article
ChatGPTRetrieve the complete content of a specific Chronograph help center article using its article ID. This tool fetches the full text content of documentation articles, typically used after finding relevant articles with the "query-help-center-documentation" tool. The article ID can be obtained from the search results of help center queries.
investment-metrics
ChatGPTCalculate a single metric across investments. Useful for aggregating and tracking performance metrics. Call this tool with `query: {help: true}` first to enumerate options and required params before attempting to query. REQUIRED WORKFLOW — never skip step 1: 1. ALWAYS call with query: {help: true} first. The help response contains usage_hints that are the authoritative guide for how to interpret the user's request and which fields to use. If the user's intent is ambiguous after reading usage_hints, ask the user to clarify before querying. 2. Only then call with a metric query using the guidance from step 1. CRITICAL — choosing metric.type vs metric.metricDefinitionId (decide BEFORE calling this tool): - The hardcoded performance types are: gross_irr, gross_moic, cost, realized, unrealized (plus LP-only calculated_gross_irr, reported_gross_irr, remaining_cost, ownership). - If the user asks for one of the hardcoded performance types above, set metric.type to that value. - For ANY other metric the user mentions by name — Revenue, EBITDA, headcount, named KPIs, custom or user-defined metrics, anything that sounds like a company financial — you MUST call the metric-definition-search tool first. It performs fuzzy matching (e.g., "Revenu" => "Revenue") and returns the canonical metric definition with a numeric id. Pass that id to this tool as metric.metricDefinitionId. Do this even if the metric appears in help mode's metric_type_options. - Do NOT guess or infer metric.type values. Do NOT call this tool with a speculative metric.type and rely on errors to redirect you. - Exactly one of metric.type or metric.metricDefinitionId must be provided. Date Resolution: - If the user asks for "latest available data", "most recent", or "most recent reporting date", set date = "last" (when the metric accepts "last" as a valid date input). - If the user asks for "earliest" data, set date = "initial" (when the metric accepts "initial" as a valid date input). Context: Users MUST trust the values provided; therefore, it's imperative that you reference the response metadata to contextualize results when presenting them: - currency: The currency of the returned values; always include unless the user explicitly specified a currency in their request - metricParams.date: The as-of date for the returned metrics; always include unless the user explicitly specified a date in their request - metricParams.period: The period used (e.g., LTM, Quarter); always include when applicable - metricParams.scenario: The scenario used (e.g., Actual); include when not the default - metricParams.applySplit: When present, true means the value is the LP's share (commitment-scaled); false means the fund-level total. Always include this in responses to the user when applySplit was relevant. - metricParams.navScaling: When present (only on unrealized), true means LP-share was NAV-scaled; false means commitment-scaled. Include when explaining unrealized results. - investmentsCount: The number of investments contributing to the result (after null-value filtering); omitted for grouped aggregations — use result.groupedAggregates[].investmentCount instead - When date is "current", "initial", or "last", the as-of date varies per investment ("current" resolves to each fund's current reporting date; "initial"/"last" resolve based on data availability). result.investments[].metric_date shows the actual resolved date for each investment.
metric-definition-search
ChatGPTSearch for metric definitions by name using fuzzy matching. Returns matches to help find the correct metric even with typos or variations (e.g., "Revenu" => "Revenue"). Use this when the user mentions a metric by name or you need a metric definition ID. Results include id, labeled_as (display name), description, base_metric_entity (can be: 'Company', 'Investment', or null), format_as, and is_balance. When is_balance is true, use period 'As of' for point-in-time; when false, use trailing periods (e.g. LTM, Quarter).
query-help-center-documentation
ChatGPTSearch and discover relevant help documentation articles for the Chronograph platform. This tool queries the help center knowledge base to find articles that match your search term and returns a list of relevant articles with their metadata (id, name, preview, etc.). Use this tool for questions about how Chronograph features work, platform capabilities, user guides, and troubleshooting. This tool should also serve as a fallback when other specialized Chronograph MCP tools cannot directly address a user's request. Note: This tool returns article previews and metadata only - use the "get-help-center-article" tool with the returned article id to retrieve the full content of any specific article.
run-query
ChatGPTList/retrieve core entities and their details, or enumerate filter options and entity IDs for use in other tools
semantic-search
ChatGPTSearch reporting and financial documents for specific information such as business updates, key initiatives, financial performance, or investment activity. Returns relevant document pages matching the query. Do not use this as a general search — use entity-search to look up companies, funds, or other entities.
top-exposures
ChatGPTList your top LP-level company exposures by invested, realized, or unrealized amount, along with company details. Returned cost, realized, unrealized, and remaining_cost values are the LP's share (commitment-scaled by default; pass navScaling: true to use NAV scaling on unrealized).
commitment-history
Claudeentity-search
Claudeget-help-center-article
Claudeinvestment-metrics
Claudequery-help-center-documentation
Clauderun-query
Claudetop-exposures
Claude
