Chronograph

Calculate 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

If fund performance data is missing from the results (some funds may not have net cashflow data imported), try using the fund-returns tool for gross performance data as a fallback.

Query company-level financial metrics (Revenue, EBITDA, Net Debt, multiples, etc.) with filtering and currency conversion.

Before querying: Always call with help: true and the same filter.companyIds first. Use only metric types returned for each company. Never query metrics for company IDs without calling help first.

Required steps: 1. Use the entity-search tool to find company IDs by name. 2. Call this tool with help: true and filter: { companyIds: [...] }. 3. Only then call with a metric query.

Use this tool for questions like:

• "What is the latest quarterly Revenue for company ID 123?"
• "Give me Revenue for these company IDs: [1, 5, 10]"

Pagination:

• Results are paginated (100 per page). Check pagination.hasNextPage and pagination.totalCount in the response.
• Decide whether to fetch more pages based on your analysis needs:
• Compare totalCount vs returnedCount to see how much data remains
• If querying N companies and need data for all of them, you may need to paginate (results may have multiple rows per company)
• For exploration, sampling, or when a subset is acceptable, the first page may suffice
• To fetch more: call with the SAME query parameters plus pagination.after set to pagination.nextCursor
• When unsure if complete data is needed, ask the user before fetching many pages

Important:

• You MUST call with help: true first whenever you have new or unfamiliar company IDs. Never call this tool for a metrics query without having called help with those company IDs first.
• When company IDs are provided, metric type resolution is automatically filtered to only those companies, preventing false positives from other companies' metric types.

Using date='latest':

• Results are ordered by date descending (most recent first)
• The FIRST occurrence of each unique (company.id, metric_definition_set_item_id, period, scenario) combination is the latest value for that group

Standard Metrics vs Custom Metrics:

• When company IDs are provided, the help response returns ALL metrics for those companies in one list which are both: standard metrics (metric_type is set) and custom metrics (metric_type: null, metric_definition_id is set).
• Use metric.metricType for standard metric types when available (preferred).
• Use metric.metricDefinitionId when the item has its metric_type: null, at this point the metric_definition_id in that item is the direct query key, no metric-definition-search needed.
• When no company IDs are provided, the response only includes standard metric types. In the case that you need a custom metric by name, use the metric-definition-search tool to find its metric_definition_id.
• If a metric name doesn't match a standard metric type, you must use the metric-definition-search tool to find the metric definition ID, then call this tool again with metric.metricDefinitionId set to the numeric ID.
• Exactly one of metric.metricType or metric.metricDefinitionId must be provided.

REQUIRED WORKFLOW FOR METRIC QUERIES: 1. ALWAYS call with help=true FIRST (with filter.companyIds if applicable) 2. Check if the user's requested metric matches any metric_type in the help response 3. If found (metric_type is not null) -> use metric.metricType with the matching standard type 4. If NOT found as a standard type, check for custom metrics (metric_type: null) in the help response:

• If company IDs were provided: look for an item where labeled_as matches the requested metric name and use its metric_definition_id directly with metric.metricDefinitionId
• If no company IDs were provided: use the metric-definition-search tool with the metric name to get the metric_definition_id, then call company-metrics with that metricDefinitionId

5. If still NOT found -> only then attempt to derive/calculate from available data 6. NEVER skip steps 1-4 and go straight to calculation or assumptions

metric_type vs labeled_as: metric_type is the API key for standard metrics (e.g. "Profit"). For custom metrics, metric_type is null, in which case you should use metric_definition_id as the API key instead. Both standard and custom metrics include labeled_as as the display name (e.g. "Adjt/ EBITDA"), which can differ per company. Always use labeled_as when describing results to users, never metric_type or metric_definition_id.

Periods define what is collected on an ongoing basis:

• Trailing Period: Represents metrics that are measured over a period of time (e.g., Revenue). Includes Month, Quarter, Semiannual, Last Twelve Months (LTM) and Year to Date (YTD) periods.
• Point in Time: Measure for data points that are reported as of a certain date (e.g., Total Debt). Includes the "As Of" period.

Fiscal Year-End:

• When you call help with company IDs, each company in the help response includes fiscal_year_end (e.g., 'December 31', 'March 31'). Use the date parameter with specific fiscal year-end dates rather than 'latest' for accurate YoY comparisons. If null, assume calendar year (December 31).

When period is set to "Quarter", "Semiannual", "LTM", or "YTD", the date field represents the END date of that period. For example:

• period="Quarter" with date="2024-12-31" returns the 3-month period ending December 31, 2024 (Oct-Nov-Dec)
• period="LTM" with date="2024-12-31" returns the 12-month period ending December 31, 2024
• These are TRAILING periods from the specified date. Each data point has a date that represents the PERIOD END DATE. Multiple dates will be returned because each represents a different rolling period window.

Version Dates (versionDates):

• IMPORTANT: versionDates is a field inside the metric object — always pass it as metric.versionDates, NOT at the root query level.
• Use versionDates whenever the user uses ANY time-relative phrase: "last week", "last month", "a month ago", "yesterday", "before", "what did we have on [date]". Calculate the actual YYYY-MM-DD date and pass it in the array.
• IMPORTANT: date controls WHICH metric period row to return (e.g. Dec 2025). versionDates controls what the value was recorded as on a given calendar date. They are independent — do NOT use date to answer past-value questions.
• Optional array of YYYY-MM-DD dates (max 7). Each date adds a field value_on_YYYY_MM_DD to every result node.
• Example: metric.versionDates: ["2026-04-01", "2026-04-30"] adds value_on_2026_04_01 and value_on_2026_04_30 to each node.
• Each field reflects the metric value as recorded in the audit log on or before that date, excluding changes made after it.
• Always in the original reporting currency — there is no FX equivalent. Omit currency when using versionDates for value change comparison so all fields are in the same currency.
• Use cases:
• Point-in-time: "What was Revenue last week?" → metric.versionDates: ["<date 7 days ago>"], show only versioned field
• Value change detection: "Did Revenue change since Monday?" → metric.versionDates: ["<monday>"] + value; rows where they differ changed
• Changes throughout a week: metric.versionDates: ["<mon>", "<tue>", "<wed>", "<thu>", "<fri>"] — compare adjacent fields to find when the shift occurred
• When to use value vs versioned fields: for value change detection present value (current) alongside the versioned field. For point-in-time or cross-date comparisons, use only the versioned fields — do NOT present value to the user as it is today's live value and is not relevant.
• Not available for calculated or imported metrics — the aliased fields will be null for those rows.

Source Citations:

• Each result row may include a document_tags object, grouped by field name (e.g. { value: [...] }). 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.

Retrieve companies, funds, 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").

Query 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.

Retrieve 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.

Calculate 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.

Version Dates (versionDates):

• Optional array of YYYY-MM-DD dates (max 7). Each date adds a field value_on_YYYY_MM_DD to every result node showing the metric value as recorded in the system on or before that date.
• IMPORTANT: versionDates is a field inside the metric object — always pass it as metric.versionDates, NOT at the root query level.
• Use versionDates whenever the user uses ANY time-relative phrase: "last week", "last month", "a month ago", "yesterday", "before", "what did we have on [date]". Calculate the actual YYYY-MM-DD date and pass it in the array.
• IMPORTANT: date controls WHICH reporting period row to return (e.g. Q4 2024). versionDates controls what the value was recorded as on a given calendar date. They are independent — do NOT use date: "last" or date: "current" to answer past-value questions.
• Use cases:
• Point-in-time: "What was Revenue last week?" → metric.versionDates: ["<date 7 days ago>"], show only versioned field
• Value change detection: "Did Revenue change since Monday?" → metric.versionDates: ["<monday>"] + value; rows where they differ changed
• Changes over a period: metric.versionDates: ["<mon>", "<wed>", "<fri>"] — compare adjacent fields to find when the shift occurred

Search 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).

Search 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.

List/retrieve core entities and their details, or enumerate filter options and entity IDs for use in other tools

Filter and view scheduled tasks along with their details.

Retrieve event history for specific scheduled tasks by their IDs. Use the scheduled-tasks tool to retrieve task IDs.