Chronograph LP

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

commitment-history

Resolve 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 each match's dropdown_options. An option-list hit identifies both the field and the exact stored option. (dropdown_options is returned per match; format_as narrows to one shape, so omit it or search each select shape separately.) - Run those name searches without field_type: the request's wording does not reveal the entity type ("deals" can be a Company-level field), so a search narrowed to a guessed entity type that finds nothing proves nothing. If a narrowed search misses, retry the same name unnarrowed before concluding the field does not exist. - Match case-insensitively but resolve to the exact stored option string. A value that hits exactly one option unambiguously ("AUCTION" → "Auction") resolves that field and option — proceed. A fuzzy or partial phrase ("followup" → "Follow-up"), or a value that could be more than one option, is confirmed with the user against the exact stored option before filtering. - Keep near-miss options distinct: "Auction" and "Limited Auction" are different options — never treat one as the other, and never match by substring. - No candidate field's options contain the value: ask the user which field they mean — never guess, never answer "no data". - Once resolved, filter with custom-field-value using value_equals and the exact stored option string. Notes: - field_type accepts Company, Investment, and Fund; Commitment is available only on the LP tool surface. - Name mode returns at most 25 ranked matches, so a very broad term may be cut off — narrow with field_type or format_as, or search a more specific name.

custom-field-search

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

custom-field-value

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

semantic-search

List/retrieve core entities and their details, or enumerate filter options and entity IDs for use in other tools Client-reported qualitative data is not in these entity records. Status fields ("Fund Status", "Investment Status"), updates and disclosures ("Business Update", "Recent Events", financing-event questions), and survey answers are client-defined custom fields — resolve them with `custom-field-search` first. Numeric ownership, performance, exit, and date questions are served here directly.

run-query

Retrieve companies, funds, groups, general partners, commitments, and investments 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.*

entity-search

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.

fund-returns

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

chronograph-guides

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.* **Custom fields are not metrics.** A custom field is a client-defined attribute on an entity (e.g. "Deal Type", "Client Industry") — distinct from a custom *metric*, which is a client-defined metric definition and is served by this tool. The test is whether the name is a specific line item or a topic: "EBITDA", "Adjusted Revenue", and "Cloud Services revenue" are line items this tool serves, while "revenue drivers", "key initiatives", "recent events", and "business update" describe a topic and are custom fields until `custom-field-search` says otherwise, however financial the wording. This tool cannot answer a topic phrase, whether the question is a plain lookup ("what is X for Acme?") or an aggregate ("average X across the portfolio", "group by X"), and line items that happen to relate to the topic are not an answer to it. Call `custom-field-search` first; only treat the name as a metric once that returns no match. This takes precedence over any instruction to resolve an unfamiliar name through `metric-definition-search` — check the fields first. If `metric-definition-search` has already returned close matches for the name, present them rather than asking whether the name is a custom field; ask the user only when neither search matches. **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. **Source Citations**: - Each result row may include a `document_tags` array. Each entry 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.

investment-metrics

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). **A name that sounds like a metric, a KPI, or a reported figure may be a custom field.** Custom fields are client-defined attributes on portfolio entities, and their names routinely borrow this tool's vocabulary (a field literally named "Deal Type" is not a metric definition). A phrase that describes a topic rather than naming a specific item ("revenue drivers", "recent events", "key initiatives") is a field name until `custom-field-search` says otherwise, however much it borrows this tool's vocabulary. If the user names something that is not clearly served here, call `custom-field-search` first and only fall back to this tool when nothing matches. If this tool has already returned close matches for the name, present them rather than asking whether the name is a custom field; ask the user only when neither this tool nor `custom-field-search` matches.

metric-definition-search