TLDR
Model Context Protocol (MCP) lets an MCP-compatible application such as Claude or ChatGPT request data from a connected portfolio platform instead of relying on an uploaded file.
You connect in one of two ways: pick a listed connector from an application's directory, or add the platform's server URL as a custom connector and sign in with your existing platform credentials.
Before approval, ask any vendor four things: whether queries are retained, whether the model can write back to source data, whether your data trains the model, and whether access follows each user's existing role.
Once connected, an analyst can ask about covenant headroom, EBITDA versus plan, cash runway, or borrowing base movement and review an answer against the source data returned.
Lumonic's MCP connector works this way across private equity, private credit, and venture portfolios.
What MCP is, in plain terms
Model Context Protocol (MCP) is a standard that lets a compatible application request information from a connected data source. The application can then use that information to answer your question. Think about how you work today when a partner asks for covenant headroom on a position. You open the monitoring platform, find the borrower, read the latest figures, and do the math. With an MCP connection, you can ask Claude or ChatGPT to retrieve records from your monitoring platform instead of relying on a snapshot you saved earlier.
An MCP request can retrieve platform records that an uploaded file does not contain. When you paste a quarterly report into a chatbot, you hand the model one frozen document. It can only reason over what sits in that file, and a later compliance certificate will not appear in that upload. It also has no way to reach related data the report never contained, so the file cannot supply records for a borrower it does not cover.
An MCP connection removes that ceiling. Rather than working from a document you exported, the model asks your platform a question in real time and reads whatever the platform returns, drawn from the same current data you would see on screen. Ask about EBITDA against plan and it pulls the latest actuals. Ask a follow-up about cash runway on a second position and it runs a fresh lookup, because it is querying the source rather than a copy.
For a firm running the Lumonic MCP against its monitoring data, that means an analyst can ask questions in plain language and receive answers tied to live portfolio data, without exporting a single spreadsheet. Every number Lumonic returns through the connector carries a traceback to its source document, so the answer can be checked against the page it came from. The protocol is the plumbing. Your existing data and permissions stay where they are.
Why portfolio monitoring teams are adopting it
An analyst monitoring a portfolio today spends much of the work getting to the data before analyzing it. You open the platform, run a report, export it to a spreadsheet, wait for the numbers to reconcile, and only then start thinking. By the time the covenant summary or cash position lands in a PDF, it reflects the moment the report ran, not the current state of the borrower. That lag is the problem MCP removes.
With a live connection, you ask the question in plain English and the connected application requests the data available in your monitoring platform. Instead of pulling a covenant report and recalculating headroom by hand, you ask whether any borrower is within ten percent of a leverage limit and read the answer against the latest reported financials.
The connection can serve different monitoring questions across asset classes. A private credit manager may check covenant headroom, while a private equity investor may compare a portfolio company's results with plan. A venture debt investor may ask for its latest reported cash balance before calculating runway.
Lumonic exposes its portfolio data through an MCP connector for private equity, private credit, and venture portfolio questions. The underlying data differs by asset class, but the query pattern does not. Firms already using Lumonic for private credit monitoring or private equity monitoring can connect to records already available in Lumonic rather than build a separate data feed for those records.
Two ways to connect an AI model to your portfolio data
You can select a listed connector or enter your monitoring platform's MCP server URL as a custom connector. The available path depends on the application, your plan, and your firm's settings. In either case, check the sign-in method the platform provides before connecting your account.
Adding a built-in connector from the model's directory
The directory path is the faster of the two, and it requires no engineering involvement, which matters for firms that run lean or have no dedicated developers. AI models like Claude keep a directory of pre-listed connectors, each one a data source the model already knows how to talk to. An analyst or IT admin opens that directory, finds the connector for their monitoring platform, and clicks to add it (on Claude Team and Enterprise plans, an Owner adds it for the organization first, and members then connect with their own account). The model then asks the user to sign in using the credentials they already have for that platform. No API keys, no configuration files, and no code.
Authentication is the part worth understanding, because it is what keeps access properly bounded. When you sign in through the directory, you authorize the model to query the platform as you, with exactly the permissions your account already holds. You are not creating a new login or a shared service account. Your existing role governs what the model can see, which means a junior analyst connecting through the directory sees the same data they would see logging in directly, and no more.
For Lumonic, the concrete step is short. In Claude, open the connector directory, find Lumonic, and sign in with your existing Lumonic credentials. No engineering required. Claude handles the rest of the connection once you authenticate.
Adding a custom connector by server URL
Use a custom connector when your application supports server URLs and the platform is not available in its directory. Your monitoring platform supplies the address of its MCP server. Enter that URL in the application's connector settings, then complete the authentication method the platform requires.
Nothing about the custom path changes how permissions or authentication work when the URL points to the same vendor server. You are configuring the same connection by hand rather than picking it from a list. Directory listings are subject to the model provider's own directory policy and review labels, so check how your provider treats custom connectors before approving one. The URL simply tells the model where to send its questions, and your login still governs what comes back.
For Lumonic, the step is direct. In ChatGPT (where your plan and workspace settings allow custom connectors) or any other MCP client, add a custom connector pointed at mcp.lumonic.com/mcp and sign in with your existing Lumonic credentials. Lumonic customers manage the connector from their own MCP settings inside the platform, and a firm administrator enables it before individual analysts link it to their model of choice.
What compliance and IT will ask before approving this
Before your security review signs off on connecting an AI model to portfolio data, it will ask four questions. Any MCP implementation you evaluate, including Lumonic's, should answer each one directly. Ask for Lumonic's security documentation and written answers that cover both the monitoring platform and the application you plan to connect.
Are queries retained, and where?
Ask whether the questions your analysts type and the answers returned are stored, and by whom. The AI model provider (Anthropic, OpenAI) may log conversations under its own terms, and that is a separate decision from what the data platform retains. A clear implementation tells you exactly what the connector logs on its side, typically an access record for audit rather than the content of every query. Lumonic's MCP layer retains nothing: queries pass through and are not stored. What the AI model provider keeps from your conversations is governed by your firm's agreement with that provider.
Can the AI model write back to source data?
The answer you want is usually no. A monitoring connector should be read-only, meaning the model can retrieve covenant figures, cash balances, and EBITDA, but cannot alter a single value in the source platform. Write access turns a query tool into an operational risk, since a malformed instruction could change a covenant threshold or a reported figure. Lumonic's connector is currently read-only, so an analyst querying a borrowing base cannot modify the underlying record.
Does our data train the underlying model?
Confirm in writing that your portfolio data is not used to train the model that answers your questions. Consumer AI plans sometimes reserve the right to train on inputs, while enterprise and business tiers from Anthropic and OpenAI generally exclude API and business traffic from training. The platform connecting to the model should not add its own data-sharing on top. Lumonic does not use client data to train any model, and its MCP layer retains nothing. Whether the AI provider trains on your conversations is governed by your firm's own agreement with that provider.
How does access map to a user's existing role?
The connector should respect the permissions a user already holds in the source platform, not create a new, broader level of access. If an analyst can only see three funds inside your monitoring platform, the AI model should return data for only those three funds when that analyst queries it. A senior partner with portfolio-wide access sees the full picture, and a junior analyst sees their subset. Lumonic maps each MCP query to the requesting user's existing role, so the model inherits the same permission boundaries your team already administers. That mapping is what lets compliance approve this without redrawing the entire access model.
Example queries once you're connected
Once the connector is live, you stop pulling reports and start asking questions in plain language. The AI model reads the query, calls the right data through the connector, and returns an answer with the underlying figures attached. Below are four queries an analyst runs regularly, each hitting a different part of the portfolio data.
Covenant headroom is often the first thing credit teams check. You ask "How much headroom does Company A have on its leverage covenant this quarter?" The model pulls the covenant definition, the reported metric, and the threshold, then returns the cushion along with the period it covers. You see the number and the inputs that produced it, so you can verify it against the compliance certificate without opening a separate file.
EBITDA versus plan works the same way but draws on budget data instead of covenant terms. Ask "How is Company B tracking against its EBITDA plan year to date?" and the model compares reported actuals to the plan figures loaded for that company, then shows the variance in dollars and percent. Because the answer cites the source periods, you know whether you are looking at a trailing twelve-month figure or a single quarter.
Cash runway pulls from the same reporting but applies a forward calculation. You ask "At the current burn rate, how many months of runway does Company C have?" The model takes the latest cash balance and recent monthly burn, then returns the runway estimate. For a venture debt or venture-backed position, that answer changes the urgency of a conversation, and having it in seconds instead of a spreadsheet rebuild matters.
Borrowing base movement is the fourth, and it draws on collateral reporting rather than the income statement. Ask "How has Company D's borrowing base changed over the last three reporting periods?" and the model returns the trend across periods with the eligible collateral figures behind each point.
Every number Lumonic returns behind these answers carries a traceback to its source document, so an analyst can check it against the report it came from. The work shifts from calculating to reviewing, and the audit trail stays intact because the figures were never exported to a separate spreadsheet.
Getting started
Before you ask an engineer to build anything, check whether your existing monitoring platform already ships an MCP connector. If you run Lumonic, the connector is available today, and connecting it takes the built-in directory path or a server URL rather than a custom integration project. Firms often assume MCP requires development. For Lumonic, it does not.
Start with one model your firm already uses, connect it against a small set of portfolio companies, and run a few of the queries above to confirm the answers trace back to source data. Lumonic customers can pull ready-made starting points from the MCP library, which has proven prompts organized by asset class, including a quarterly portfolio review, a portfolio company tear sheet, and a valuation workbook that writes live formulas into Excel. The same setup works whether you monitor private equity holdings, private credit facilities, or venture debt positions. Nothing about the connection changes across asset class, because the AI model queries the same underlying data your team already maintains.
FAQs
Does connecting an AI model through MCP replace our existing portfolio monitoring platform? No. MCP is a query layer that sits on top of a monitoring platform like Lumonic, not a substitute for it. Your platform still ingests financials, tracks covenants, and stores the underlying data, while MCP lets an AI model ask that platform live questions in plain language.
Does this work with ChatGPT as well as Claude? Yes. Claude and ChatGPT can connect when the relevant application, plan, and workspace settings support Lumonic's MCP server. Check whether your account offers a listed Lumonic connector or allows a custom server URL; setup steps may differ between applications.
Can multiple users connect with different permission levels? Yes. Each user authenticates with their own credentials, so an analyst covering three deals and a partner covering the whole book see different data through the same connector. Access maps to the role a user already holds in the source platform rather than granting a new, separate level of access.
Does the AI model see data a user isn't authorized to see? No. The AI model queries the platform as the authenticated user, so it can only return data that user could already open directly in Lumonic. If someone lacks access to a fund or a borrower, no query through the connected model will surface that fund or borrower, because the permission check happens at the source, not in the model.
Disclaimer
This article was written by Lumonic, a PitchBook company, and reflects Lumonic's views as of October 2026. Statements about third-party products and companies are based on publicly available information, including the vendors' own websites, press releases and documentation, and on the sources linked in the text. Lumonic has not independently tested third-party products, and their capabilities, pricing and positioning may have changed since this article was last updated. Statements about Lumonic's own product describe the platform at the time of writing, and customer outcomes are taken from the published customer stories linked in the text. Nothing here is a guarantee of results. Third-party names and trademarks belong to their respective owners and are used for identification only. If you represent a company named here and believe a statement is inaccurate, contact support@lumonic.com and we will review and correct it.
TLDR
Model Context Protocol (MCP) lets an MCP-compatible application such as Claude or ChatGPT request data from a connected portfolio platform instead of relying on an uploaded file.
You connect in one of two ways: pick a listed connector from an application's directory, or add the platform's server URL as a custom connector and sign in with your existing platform credentials.
Before approval, ask any vendor four things: whether queries are retained, whether the model can write back to source data, whether your data trains the model, and whether access follows each user's existing role.
Once connected, an analyst can ask about covenant headroom, EBITDA versus plan, cash runway, or borrowing base movement and review an answer against the source data returned.
Lumonic's MCP connector works this way across private equity, private credit, and venture portfolios.
What MCP is, in plain terms
Model Context Protocol (MCP) is a standard that lets a compatible application request information from a connected data source. The application can then use that information to answer your question. Think about how you work today when a partner asks for covenant headroom on a position. You open the monitoring platform, find the borrower, read the latest figures, and do the math. With an MCP connection, you can ask Claude or ChatGPT to retrieve records from your monitoring platform instead of relying on a snapshot you saved earlier.
An MCP request can retrieve platform records that an uploaded file does not contain. When you paste a quarterly report into a chatbot, you hand the model one frozen document. It can only reason over what sits in that file, and a later compliance certificate will not appear in that upload. It also has no way to reach related data the report never contained, so the file cannot supply records for a borrower it does not cover.
An MCP connection removes that ceiling. Rather than working from a document you exported, the model asks your platform a question in real time and reads whatever the platform returns, drawn from the same current data you would see on screen. Ask about EBITDA against plan and it pulls the latest actuals. Ask a follow-up about cash runway on a second position and it runs a fresh lookup, because it is querying the source rather than a copy.
For a firm running the Lumonic MCP against its monitoring data, that means an analyst can ask questions in plain language and receive answers tied to live portfolio data, without exporting a single spreadsheet. Every number Lumonic returns through the connector carries a traceback to its source document, so the answer can be checked against the page it came from. The protocol is the plumbing. Your existing data and permissions stay where they are.
Why portfolio monitoring teams are adopting it
An analyst monitoring a portfolio today spends much of the work getting to the data before analyzing it. You open the platform, run a report, export it to a spreadsheet, wait for the numbers to reconcile, and only then start thinking. By the time the covenant summary or cash position lands in a PDF, it reflects the moment the report ran, not the current state of the borrower. That lag is the problem MCP removes.
With a live connection, you ask the question in plain English and the connected application requests the data available in your monitoring platform. Instead of pulling a covenant report and recalculating headroom by hand, you ask whether any borrower is within ten percent of a leverage limit and read the answer against the latest reported financials.
The connection can serve different monitoring questions across asset classes. A private credit manager may check covenant headroom, while a private equity investor may compare a portfolio company's results with plan. A venture debt investor may ask for its latest reported cash balance before calculating runway.
Lumonic exposes its portfolio data through an MCP connector for private equity, private credit, and venture portfolio questions. The underlying data differs by asset class, but the query pattern does not. Firms already using Lumonic for private credit monitoring or private equity monitoring can connect to records already available in Lumonic rather than build a separate data feed for those records.
Two ways to connect an AI model to your portfolio data
You can select a listed connector or enter your monitoring platform's MCP server URL as a custom connector. The available path depends on the application, your plan, and your firm's settings. In either case, check the sign-in method the platform provides before connecting your account.
Adding a built-in connector from the model's directory
The directory path is the faster of the two, and it requires no engineering involvement, which matters for firms that run lean or have no dedicated developers. AI models like Claude keep a directory of pre-listed connectors, each one a data source the model already knows how to talk to. An analyst or IT admin opens that directory, finds the connector for their monitoring platform, and clicks to add it (on Claude Team and Enterprise plans, an Owner adds it for the organization first, and members then connect with their own account). The model then asks the user to sign in using the credentials they already have for that platform. No API keys, no configuration files, and no code.
Authentication is the part worth understanding, because it is what keeps access properly bounded. When you sign in through the directory, you authorize the model to query the platform as you, with exactly the permissions your account already holds. You are not creating a new login or a shared service account. Your existing role governs what the model can see, which means a junior analyst connecting through the directory sees the same data they would see logging in directly, and no more.
For Lumonic, the concrete step is short. In Claude, open the connector directory, find Lumonic, and sign in with your existing Lumonic credentials. No engineering required. Claude handles the rest of the connection once you authenticate.
Adding a custom connector by server URL
Use a custom connector when your application supports server URLs and the platform is not available in its directory. Your monitoring platform supplies the address of its MCP server. Enter that URL in the application's connector settings, then complete the authentication method the platform requires.
Nothing about the custom path changes how permissions or authentication work when the URL points to the same vendor server. You are configuring the same connection by hand rather than picking it from a list. Directory listings are subject to the model provider's own directory policy and review labels, so check how your provider treats custom connectors before approving one. The URL simply tells the model where to send its questions, and your login still governs what comes back.
For Lumonic, the step is direct. In ChatGPT (where your plan and workspace settings allow custom connectors) or any other MCP client, add a custom connector pointed at mcp.lumonic.com/mcp and sign in with your existing Lumonic credentials. Lumonic customers manage the connector from their own MCP settings inside the platform, and a firm administrator enables it before individual analysts link it to their model of choice.
What compliance and IT will ask before approving this
Before your security review signs off on connecting an AI model to portfolio data, it will ask four questions. Any MCP implementation you evaluate, including Lumonic's, should answer each one directly. Ask for Lumonic's security documentation and written answers that cover both the monitoring platform and the application you plan to connect.
Are queries retained, and where?
Ask whether the questions your analysts type and the answers returned are stored, and by whom. The AI model provider (Anthropic, OpenAI) may log conversations under its own terms, and that is a separate decision from what the data platform retains. A clear implementation tells you exactly what the connector logs on its side, typically an access record for audit rather than the content of every query. Lumonic's MCP layer retains nothing: queries pass through and are not stored. What the AI model provider keeps from your conversations is governed by your firm's agreement with that provider.
Can the AI model write back to source data?
The answer you want is usually no. A monitoring connector should be read-only, meaning the model can retrieve covenant figures, cash balances, and EBITDA, but cannot alter a single value in the source platform. Write access turns a query tool into an operational risk, since a malformed instruction could change a covenant threshold or a reported figure. Lumonic's connector is currently read-only, so an analyst querying a borrowing base cannot modify the underlying record.
Does our data train the underlying model?
Confirm in writing that your portfolio data is not used to train the model that answers your questions. Consumer AI plans sometimes reserve the right to train on inputs, while enterprise and business tiers from Anthropic and OpenAI generally exclude API and business traffic from training. The platform connecting to the model should not add its own data-sharing on top. Lumonic does not use client data to train any model, and its MCP layer retains nothing. Whether the AI provider trains on your conversations is governed by your firm's own agreement with that provider.
How does access map to a user's existing role?
The connector should respect the permissions a user already holds in the source platform, not create a new, broader level of access. If an analyst can only see three funds inside your monitoring platform, the AI model should return data for only those three funds when that analyst queries it. A senior partner with portfolio-wide access sees the full picture, and a junior analyst sees their subset. Lumonic maps each MCP query to the requesting user's existing role, so the model inherits the same permission boundaries your team already administers. That mapping is what lets compliance approve this without redrawing the entire access model.
Example queries once you're connected
Once the connector is live, you stop pulling reports and start asking questions in plain language. The AI model reads the query, calls the right data through the connector, and returns an answer with the underlying figures attached. Below are four queries an analyst runs regularly, each hitting a different part of the portfolio data.
Covenant headroom is often the first thing credit teams check. You ask "How much headroom does Company A have on its leverage covenant this quarter?" The model pulls the covenant definition, the reported metric, and the threshold, then returns the cushion along with the period it covers. You see the number and the inputs that produced it, so you can verify it against the compliance certificate without opening a separate file.
EBITDA versus plan works the same way but draws on budget data instead of covenant terms. Ask "How is Company B tracking against its EBITDA plan year to date?" and the model compares reported actuals to the plan figures loaded for that company, then shows the variance in dollars and percent. Because the answer cites the source periods, you know whether you are looking at a trailing twelve-month figure or a single quarter.
Cash runway pulls from the same reporting but applies a forward calculation. You ask "At the current burn rate, how many months of runway does Company C have?" The model takes the latest cash balance and recent monthly burn, then returns the runway estimate. For a venture debt or venture-backed position, that answer changes the urgency of a conversation, and having it in seconds instead of a spreadsheet rebuild matters.
Borrowing base movement is the fourth, and it draws on collateral reporting rather than the income statement. Ask "How has Company D's borrowing base changed over the last three reporting periods?" and the model returns the trend across periods with the eligible collateral figures behind each point.
Every number Lumonic returns behind these answers carries a traceback to its source document, so an analyst can check it against the report it came from. The work shifts from calculating to reviewing, and the audit trail stays intact because the figures were never exported to a separate spreadsheet.
Getting started
Before you ask an engineer to build anything, check whether your existing monitoring platform already ships an MCP connector. If you run Lumonic, the connector is available today, and connecting it takes the built-in directory path or a server URL rather than a custom integration project. Firms often assume MCP requires development. For Lumonic, it does not.
Start with one model your firm already uses, connect it against a small set of portfolio companies, and run a few of the queries above to confirm the answers trace back to source data. Lumonic customers can pull ready-made starting points from the MCP library, which has proven prompts organized by asset class, including a quarterly portfolio review, a portfolio company tear sheet, and a valuation workbook that writes live formulas into Excel. The same setup works whether you monitor private equity holdings, private credit facilities, or venture debt positions. Nothing about the connection changes across asset class, because the AI model queries the same underlying data your team already maintains.
FAQs
Does connecting an AI model through MCP replace our existing portfolio monitoring platform? No. MCP is a query layer that sits on top of a monitoring platform like Lumonic, not a substitute for it. Your platform still ingests financials, tracks covenants, and stores the underlying data, while MCP lets an AI model ask that platform live questions in plain language.
Does this work with ChatGPT as well as Claude? Yes. Claude and ChatGPT can connect when the relevant application, plan, and workspace settings support Lumonic's MCP server. Check whether your account offers a listed Lumonic connector or allows a custom server URL; setup steps may differ between applications.
Can multiple users connect with different permission levels? Yes. Each user authenticates with their own credentials, so an analyst covering three deals and a partner covering the whole book see different data through the same connector. Access maps to the role a user already holds in the source platform rather than granting a new, separate level of access.
Does the AI model see data a user isn't authorized to see? No. The AI model queries the platform as the authenticated user, so it can only return data that user could already open directly in Lumonic. If someone lacks access to a fund or a borrower, no query through the connected model will surface that fund or borrower, because the permission check happens at the source, not in the model.
Disclaimer
This article was written by Lumonic, a PitchBook company, and reflects Lumonic's views as of October 2026. Statements about third-party products and companies are based on publicly available information, including the vendors' own websites, press releases and documentation, and on the sources linked in the text. Lumonic has not independently tested third-party products, and their capabilities, pricing and positioning may have changed since this article was last updated. Statements about Lumonic's own product describe the platform at the time of writing, and customer outcomes are taken from the published customer stories linked in the text. Nothing here is a guarantee of results. Third-party names and trademarks belong to their respective owners and are used for identification only. If you represent a company named here and believe a statement is inaccurate, contact support@lumonic.com and we will review and correct it.
