Carta Explore Data

Explore Data

Query the Carta data warehouse for investors data — NAV, performance metrics, cash flow statements, balance sheets, portfolio financials, and more.

Schema-first rule for raw SQL: Whenever you fall through to dwh__execute__query directly — bypassing execute:question and the semantic-layer steps — you MUST call dwh__list__tables (omit schema to enumerate all schemas) and then dwh__get__table_schema to confirm the exact table path and every column name before composing the query. Never infer or guess column names from context or semantics; the live schema is the only source of truth. One preflight eliminates the two leading error classes: invalid identifier (wrong column name) and Object does not exist (wrong table name) on the first attempt.

When to Use

This is the skill for Carta Web / Fund Admin data work — the data warehouse. Note that Carta Fund Forecasting (formerly Tactyc) is a separate domain with its own funds and data; when a fund performance question could belong to either system, the fund-performance.md semantic layer will automatically check Fund Forecasting first before running DWH queries.

• Always use when the user context is set to a Firm and the request involves any Carta Web / Fund Admin data query, financial metric, or reporting question
• Do NOT use for funds that live in Carta Fund Forecasting (formerly Tactyc) — that is a separate domain with its own data; use carta-fund-forecasting for performance metrics (TVPI/DPI/IRR/MOIC/NAV/reserves) of those funds. When the fund system is unknown for a performance query, fund-performance.md probes Fund Forecasting automatically and redirects if the fund is found there
• Always use for portfolio queries, holdings questions, fund breakdowns, or "what is [firm/fund] invested in" phrasing — even though those phrases appear in carta-soi's trigger list; carta-soi is for building persistent Cowork artifacts, not answering data questions inline
• Always use for read-only valuation data (409a history, FMV, MOIC, investment metrics) — even though "valuations" and "portfolio companies" appear in carta-portfolio-valuations; that skill is for running and updating valuation projects, not reading data
• Also use when no context is set and the user asks an ambiguous investment or data question — this skill will guide them through context setup via list_contexts / set_context

Prerequisites

The user must have the Carta MCP server connected. If this is the first query in the session:

1. Call list_contexts to see which firms are accessible
2. Call set_context with the target firm_id if needed
3. For cap table queries — confirm the corporation ID before running. If the user names a portfolio company, resolve its CORPORATION_ID from CORPORATION_BASIC_INFO_V2 first (see Step 2 table below)

Named-entity queries do NOT need list_contexts. list_contexts only enumerates the Carta client firms the user has admin access to — never call it to search for a person, LP, or portfolio-company name. Once firm context is already set and the user names an entity that isn't the active firm (e.g. "Armstrong Capital Partners' capital activity inception to date"), that name is almost always an LP/investor within the current firm, not a request to switch firms — proceed straight to Step 1 (dwh__execute__question) with the question scoped to that name. Only call list_contexts again if the user explicitly asks to switch to a different firm.

Tool priority (firm context): fa:* MCP commands → dwh__execute__question → semantic-layer SQL (Steps 2–4) → raw dwh__execute__query. Never call cap_table:* or cap_table_chart in firm context — those require a direct tenant role unavailable to investor-portal portcos; use the DWH queries in cap-table.md instead.

Step 0 — Fetch portfolio companies (MANDATORY GATE)

After setting context, always fetch the list of portfolio companies the user has access to:

call_tool({"name": "fa__list__portfolio_companies", "arguments": {}})

Required even for specific-company queries — establishes accessible companies and resolves corporation_id values needed for cap table queries.

• If the result is empty, tell the user their firm context may not be set correctly and call list_contexts to diagnose.
• If the user asked about a specific company, use the result to resolve the exact corporation_id for that company before continuing to Step 1.

Step 1 — Try execute:question (PRIMARY query path)

Structural questions ("what tables exist?", "what columns does X have?") skip Steps 1–3 entirely. Go directly to dwh__list__tables (omit schema to list all) or dwh__get__table_schema. Do not run execute:question for schema discovery — it has no visibility into raw table structure and will hallucinate.

Before loading any semantic layer, call the plain-English query interface with the user's question verbatim (or lightly rephrased for clarity):

call_tool({"name": "dwh__execute__question", "arguments": {"question": "<user's question>"}})

If the call succeeds and returns meaningful rows → format and present the results using the General Presentation Rules below. Stop here — do not continue to Steps 2–4.

Fall through to Step 2 when any of the following occur:

• The tool returns an error or exception
• The result set is empty and the user's question implies data should exist
• The returned columns don't match what the user asked for (e.g. wrong metric, wrong granularity)
• The tool indicates it cannot interpret the question or lacks the required data

Do NOT retry execute:question with a rephrased question — fall through immediately.

Step 2 — Identify the Query Domain

Use this table to pick the right context file before running any query:

LOAN_OPS firm-scoping rule (MANDATORY — cross-tenant exposure risk): The active firm context does NOT scope LOAN_OPS tables. set_context does not filter them, and a fund-admin firm scope drops every LOAN_OPS table to 0 rows — the row-access policy does not resolve it (see carta-loan-dashboard). An unfiltered query therefore silently returns rows that belong to other firms, with no error or warning. Every query against LOAN_OPS.LOAN, LOAN_OPS.LENDER_POSITION, or any other LOAN_OPS table MUST include an explicit firm filter: WHERE LENDING_FIRM_NAME = '<firm name>' (or WHERE LENDING_FIRM_ID = <id>). Before you present the results, confirm that every returned row belongs to the expected firm — discard and re-query if any row does not. Note: dwh__list__tables does not enumerate LOAN_OPS; probe a table by name with SELECT * FROM LOAN_OPS.<TABLE> LIMIT 1 instead.

Step 3 — Load the Context File

Read the matching file from ${CLAUDE_PLUGIN_ROOT}/skills/carta-explore-data/semantic-layer/<domain>.md:

The file contains the SQL query, column reference, and presentation rules for that domain. Follow them exactly.

Cap table prerequisite check — before loading cap-table.md, verify:

1. The MCP context is set to a firm (not a fund or LP). Call list_contexts if unsure.
2. A CORPORATION_UUID is available. If the user named a company, resolve it from CORPORATION_BASIC_INFO_V2 — match by name, UUID, or integer ID depending on what the user supplied:

   -- CORPORATION_BASIC_INFO_V2.CORPORATION_ID is INTEGER. SUMMARY_CAP_TABLE / FUND_CORPORATION_OWNERSHIP
   -- match on UUID (TEXT). Pass CORPORATION_UUID — never CORPORATION_ID — to cap-table.md queries.
   SELECT DISTINCT CORPORATION_ID AS corporation_integer_id, CORPORATION_UUID, CORPORATION_NAME
   FROM FUND_ADMIN.CORPORATION_BASIC_INFO_V2
   WHERE LOWER(CORPORATION_NAME) LIKE '%<user-supplied name>%'
      OR CORPORATION_UUID = '<user-supplied uuid>'
      OR CORPORATION_ID = <user-supplied integer id>
   LIMIT 10
   

   If multiple matches are found, use AskUserQuestion to confirm which one before continuing.

• IMPORTANT: if a specific semantic layer was not found, check for Saved Questions by running call_tool({"name": "fa__list__saved_queries", "arguments": {}}) to get a list of existing questions and descriptions saved on the Data Warehouse. Use call_tool({"name": "fa__get__saved_query", "arguments": {"name": "<query_name>"}}) to retrieve the SQL of a matching saved query, where <query_name> is the name field returned by fa__list__saved_queries.

Step 4 — Execute the Query

MANDATORY pre-query checklist — run for every query, no exceptions:

1. Determine the schema from the domain routing table in Step 2: if the table is listed with an explicit schema prefix (e.g. LOAN_OPS.LOAN), use that schema. Otherwise FUND_ADMIN is the default and most common schema.
2. Verify the table exists: call_tool({"name": "dwh__list__tables", "arguments": {"schema": "<SCHEMA>"}}) — use the schema from step 2. If the target table does not appear in the result, it does not exist — check the wrong→right table name reference in ## SQL Compilation Safety Rules before continuing. Do not query a table that is not listed.
3. Verify column names: call_tool({"name": "dwh__get__table_schema", "arguments": {"table_name": "<TABLE>", "schema": "<SCHEMA>"}}) — use the schema from step 2. Confirm every column you plan to SELECT or filter on appears in the schema with its exact name. Check the wrong→right column name reference in ## SQL Compilation Safety Rules if a column is missing.

Then resolve any remaining uncertainty:

1. Unclear intent — ask immediately. If the user's request contains a term that doesn't map to any known domain, table, or Carta concept in the Step 2 table, immediately call AskUserQuestion with focused options. Do not respond in prose first — go straight to AskUserQuestion.
2. Ask up to 2 clarifying questions. If, after checking saved queries (Step 3) and schema inspection, you still cannot identify the right table or domain, use AskUserQuestion to ask the user at most 2 focused questions — e.g. fund-level vs company-level, metric type, entity name. After receiving answers, re-run Steps 2–3 before querying.

Never assume a table or column name. Every wrong guess produces a Snowflake compilation error visible in production logs.

Use the MCP commands in sequence, substituting <SCHEMA> with the schema determined in the checklist above:

1. Browse tables: call_tool({"name": "dwh__list__tables", "arguments": {"schema": "<SCHEMA>"}})
2. Inspect schema: call_tool({"name": "dwh__get__table_schema", "arguments": {"table_name": "<TABLE>", "schema": "<SCHEMA>"}})
3. Run the query: call_tool({"name": "dwh__execute__query", "arguments": {"sql": "..."}})

Output format: Present results as a markdown table. Use fund or company names as row headers — never raw UUIDs. Currency values use $X,XXX format with commas; percentages use X.XX%. Bold totals and summary rows.

General Query Rules

• Always include LIMIT — default LIMIT 200; use 50–500 for aggregations
• Only SELECT — no INSERT, UPDATE, DELETE, or DDL
• Single SELECT only — no UNION / UNION ALL, no SHOW commands — the tool enforces one SELECT at a time; SHOW TABLES LIKE '%...' and other SHOW * commands also return Only a single SELECT statement is allowed. Use call_tool({"name": "dwh__list__tables", ...}) for table discovery and run separate call_tool calls when you need counts from multiple tables.
• Do not query INFORMATION_SCHEMA — it is not supported in this data warehouse and returns a hard ValueError: Querying INFORMATION_SCHEMA is not allowed. Use call_tool({"name": "dwh__list__tables", ...}) to list tables and call_tool({"name": "dwh__get__table_schema", ...}) to inspect columns. These MCP tools are the only valid schema-discovery path.
• LATERAL (including LATERAL FLATTEN) is not permitted — returns ValueError: Lateral is not permitted in query execution. To access keys in a VARIANT/ARRAY column, use explicit JSON path notation (e.g. col:key::STRING) rather than LATERAL FLATTEN.
• Date fields — effective_date for JOURNAL_ENTRIES; month_end_date for MONTHLY_NAV_CALCULATIONS; investment_date for AGGREGATE_INVESTMENTS
• Deduplication — for MONTHLY_NAV_CALCULATIONS and AGGREGATE_FUND_METRICS, use QUALIFY ROW_NUMBER() OVER (PARTITION BY fund_uuid ORDER BY last_refreshed_at DESC) = 1
• ALLOCATIONS has multiple rows per fund — always GROUP BY fund_uuid with MAX(fund_name) when using it for fund metadata

SQL Compilation Safety Rules

• Always schema-qualify tables: FUND_ADMIN.TABLE_NAME (or LOAN_OPS.TABLE_NAME for loans). A bare name defaults to PUBLIC where no customer tables exist.
• Only query schemas visible in dwh__list__tables: never query a schema that does not appear in that tool's output — unrecognized schemas are either internal-only or non-existent and will always fail.
• dwh__execute__query does NOT accept a schema argument — the schema is encoded directly in the SQL as SCHEMA.TABLE_NAME. Never pass "schema" inside the arguments dict.
• set_context takes firm_id as a UUID string — pass the UUID value returned by list_contexts, not a bare integer.
• Use fund_uuid (VARCHAR), not fund_id — the integer fund_id is internal-only and not available in customer-facing views.
• Snowflake syntax only: LIMIT N not FETCH FIRST N ROWS ONLY; LIKE/RLIKE not SIMILAR TO; ROW_NUMBER() OVER (...) not bare ROW(); DATE_TRUNC not ROUND on dates; UUID values are strings (fund_uuid = '<uuid>').
• Wrong → right table names — if the user or context uses any name on the left, use the right instead:

• Wrong column names: Domain-specific corrections are in each semantic layer file's ⚠️ Common Mistakes section. Always run dwh__get__table_schema to verify column names before querying. Cross-domain shortcuts that frequently produce invalid identifier errors:

DWH Tool Invocations — Exact Forms Required

Use call_tool with these exact double-underscore names. Any other form (colon syntax, single underscores, direct tool invocations) returns NotFoundError: Unknown tool.

• dwh__execute__query key is sql (not query).
• dwh__execute__question keys: question (required). Do not pass sql, fund_uuid, firm_uuid, format, or any other key.
• JSON keys with spaces in VARIANT columns — col:'Key With Spaces' and col["Key With Spaces"] both fail with SQL compilation error. For keys containing spaces, use escaped inner quotes: col:'"Key With Spaces"'::STRING. This applies to AGGREGATE_INVESTMENTS.TAGS_JSON and any other VARIANT column with spaced key names.
• ORDER BY with SELECT DISTINCT — columns used in ORDER BY must also appear in the SELECT list when using DISTINCT; otherwise Snowflake raises is not a valid order by expression.

Deep Links

include_links: true required when users wants a direct link to the app. It adds a _links entry to each row for supported entity UUID columns:

include_links adds a _links entry to each row for supported entity UUID columns. Supported fields and their requirements:

Always include the resolver column(s) in every SELECT — _links is silently empty without them:

• Include fund_uuid whenever the result contains journal_entry_gluuid, journal_entry_line_id, asset_id, or partner_interest_group_id
• Include fund_uuid or firm_carta_id whenever the result contains entity_link_id or issuer_entity_link_id
• Include these columns even when you don't display them to the user

Using _links: when a row has a _links entry, hyperlink the entity's display name (fund name, company name, LP name) to row["_links"][field]["web_url"]. Use the value verbatim — never reconstruct or guess URLs.

General Presentation Rules

Each semantic file's ## Presentation section is the source of truth for its domain. When a semantic file does not specify, fall back to these defaults:

• Render results as a markdown table with clear column headers
• Use names, never raw UUIDs as row identifiers — fund name, company name, LP name
• Currency — $X,XXX with commas; negatives/outflows in parentheses ($X,XXX); bold totals **$X,XXX**
• Percentages — X.XX%
• Multiples — X.XXx (e.g. MOIC, TVPI, DPI)
• Missing values — show — rather than 0 or null to avoid implying a real zero
• Use Carta voice — "your fund's NAV", "your portfolio", not "query results"

Terms