Quido MCP: private company data inside AI

Quido's data on private companies is now available directly inside AI assistants. With Quido MCP, a professional can ask, in natural language, for a company search, a set of financials or an ownership structure without leaving the conversation with their assistant.

Quido MCP connects Quido to assistants that support the Model Context Protocol, the standard that lets an AI assistant read from external data sources. Instead of opening the platform, looking up a figure and carrying it elsewhere, you ask the assistant and the answer comes back with Quido's data already in it.

Through Quido MCP the same information as the platform is reachable: company profiles and research, financials and balance sheets, ownership and private equity investors, people profiles with their roles and the deals they took part in, news and M&A activity. Access is read-only: the assistant reads the data, it does not change it.

Access follows the same rules as the platform. Every request is restricted to enabled client organisations: the assistant sees only what the organisation is allowed to see.

Quido MCP is available today to all client organisations.

The problem this addresses

Analytical work on private companies carries a hidden cost that nobody budgets for: moving the data. Not finding it, not interpreting it — moving it.

It is the step in which a professional finds a figure in one tool, copies it, pastes it into another document, checks the formatting, and starts again with the next figure. Each individual step takes seconds. Repeated across an afternoon of diligence, it becomes a meaningful share of the day. And every step is a point at which a number can change by accident.

In recent years a growing share of this work has moved inside an AI assistant: the memo draft gets written there, the summary of a document gets asked for there, the shape of an analysis gets thought through there. But an assistant, by its nature, knows neither confidential material nor the data of Italian private companies. The result is the same relay as before, with one more participant.

Quido MCP removes the transport. The assistant queries Quido's data directly and returns the answer where the work is already happening.

What the Model Context Protocol is, in practical terms

The Model Context Protocol is a standard describing how an AI assistant can read from an external data source. For assistants it is the equivalent of a power socket: it defines the shape of the connection, so that a compatible source and a compatible assistant can talk to each other without bespoke integration work.

For the person using it, what matters is that this is neither an add-on to install for every single piece of information nor a file upload. The assistant does not receive a copy of Quido's data: it queries Quido at the moment it is needed, and gets an answer current as of that moment.

That has a practical consequence worth spelling out. A document uploaded into an assistant starts ageing the instant it is uploaded. A request made through Quido MCP does not: it reads the data when the question is asked.

What can be asked

Through Quido MCP the assistant reaches the same information as the platform. In terms of concrete requests:

• Company profiles and research — identifying companies that match defined criteria, or opening the profile of a specific company.
• Financials and balance sheets — the company's economic and balance sheet figures, in the form the platform exposes them.
• Ownership and private equity investors — who controls a company and which investors sit in its capital.
• People profiles — the roles held and the deals taken part in.
• News — the news items linked to a company.
• M&A activity — the transactions on record.

Questions take the natural form of a conversation: there is no syntax to learn and no list of commands to remember. The assistant translates the request into a query against the data.

Which assistants it works with

Quido MCP works with assistants that support the Model Context Protocol, among them Claude and ChatGPT, through Quido's native MCP server.

The operative word in that sentence is "standard". A connection built for one specific assistant ties whoever adopts it to today's choice: change the tool, and the connection has to be rebuilt. A standard moves the constraint from the assistant to the protocol — what is compatible today stays reachable tomorrow, and what becomes compatible later does so without dedicated work on the data side.

For whoever has to approve the decision, that is the relevant point: adoption is not a bet on which assistant will prevail.

Read-only: a choice, not a limitation

Access through Quido MCP is read-only. The assistant reads the data, it does not change it.

This is a design choice, and it is worth explaining, because in a professional setting it is exactly what is required. An AI assistant is an excellent tool for reading, comparing and summarising. An assistant that could also write into the shared information estate would introduce a new category of risk: an unintended change, made autonomously, inside data on which somebody else then builds a decision.

Separating reading from writing keeps a clean line. What the assistant produces — a summary, a list, a comparison — remains a piece of work the professional assesses and, if they see fit, takes forward. The data estate stays governed by the platform.

Access rules remain the platform's own

Access follows the same rules as the platform. Every request is restricted to enabled client organisations, and the assistant sees only what the organisation is allowed to see.

In practice this is where the questions of whoever has to authorise adoption concentrate. It is worth stating plainly: Quido MCP does not create a second permissions perimeter alongside the existing one. There is no configuration in which the assistant can reach something the organisation cannot already reach from the platform.

The general data handling conditions are unchanged as well: European infrastructure, data encrypted at rest and in transit, GDPR compliance, and no use of client data for model training.

Use cases, by phase of the work

The most useful way to assess this is to place it in the phases where the work actually happens.

Origination

Building a target list starts from criteria: sector, size, geography, financial profile. With Quido MCP the request is made in the same conversation in which the list is then discussed — ask for the set, discuss it, narrow it, without changing tool at every step.

Screening

On a list already drawn up, the recurring question is one of summary: how large is this company, what does its ownership look like, who has invested in it. These are the questions the assistant can answer straight from Quido's data, one company after another, without opening and closing tabs.

Due diligence

In diligence the work moves to depth: accounts, ownership, people, past transactions, news. The value of conversational access here is not the speed of any single answer, but the ability to frame the next question from the previous one without rebuilding the context each time.

Drafting a memo

The memo is where the relay between tools weighs most, because every figure in it comes from another window. Drafting in the same conversation the data is read from removes the manual step, and with it the class of errors that step introduces: the half-copied figure, the wrong financial year, the number updated in one document and not the other. What remains is the part a memo actually calls for — deciding what is worth writing in it.

Portfolio monitoring

Across a portfolio, frequency matters more than depth: knowing whether something has changed, and what. A question put to the assistant is a light way to keep watch even when the pipeline is crowded.

Preparing for a meeting

Before a meeting a quick, reliable picture is needed: who the counterparty is, who controls it, what has happened recently. It is perhaps the situation with the most immediate gain, because it is the one with the least time available.

What Quido MCP is not

An announcement involving AI and data is easily read as more than it says. Some boundaries.

It is not a model trained on Quido's data. The assistant does not "know" the data: it reads it at the time of the request. Client data is not used to train models.

It is not a new data perimeter. The information reachable is the same as the platform's, no more and no less.

It is not a write channel. Access is read-only, for the reasons described above.

It is not an advisory tool. The assistant returns data and summaries; assessment and decision remain with the professional, as with any other diligence material.

It does not replace the platform. The capabilities that live in the interface — the shared deal flow board, reports in the firm's format, visual peer comparison — remain where that work is done best.

How it fits with the rest of the product

Quido MCP is one of several ways to reach the platform's data, and it should be read alongside the others.

The web interface remains the place for structured work: multi-criteria search, the full company profile, the team's shared deal flow, and generating reports in the firm's format.

The mobile app for iOS and Android takes the same analysis out of the office, and is covered in the article on the mobile app launch.

The AI agent inside the platform reasons over Quido's data and returns structured, sourced answers.

Quido MCP brings the same data into the assistant a professional already uses. It is not an alternative to the other channels: it is the one that matters when the work is happening elsewhere and breaking the flow would cost more than the figure being looked for.

All of these channels are included in the fee: Quido's commercial model is a fixed annual charge with unlimited users, unlimited searches and reports, and MCP, mobile and API access included. No credit consumption turns one more question into a line of cost.

Why a general assistant is not enough on private companies

Anyone who has asked a general assistant about an Italian SME already knows the problem, and it is worth naming precisely, because it is the reason this connection exists.

An assistant trained on public material has three structural limits when the question concerns a private company.

The first is coverage. The information published about a mid-sized private company is sparse and discontinuous. What does exist systematically — filed accounts, registry information — is not material a general model can be relied on to hold.

The second is currency. A model reflects the material it was trained on, with the date that material carries. Recently filed accounts or a change in the shareholder base do not enter that knowledge merely by having happened.

The third, and the most treacherous, is provenance. Even when the answer is correct, there is no way to trace it to a verifiable source. Where a figure will have to be defended in an investment committee, an answer without provenance is unusable, however plausible it looks.

Connecting to a data source resolves all three the same way: the assistant stops answering from memory and starts reading. The answer that comes back is Quido's data, read at the moment the question is asked, with the same traceability that applies on the platform.

A working sequence, start to finish

An example of how the steps fit together, without leaving the conversation.

It starts from a perimeter — a sector, a size band, a geography — and a request for the set of companies that fall inside it. The answer is a list, built from Quido's data rather than reconstructed from memory.

The list then gets narrowed. Questions become more specific: which of these have ownership running through a holding company, which already have a private equity investor in their capital, which have recorded transactions in recent years. Each question starts from the previous answer, which is exactly what a conversation allows and a series of separate searches does not.

The names that survive are examined in depth: accounts, movement in the economic and balance sheet figures, news, relevant individuals and the roles they have held.

The last step is the summary. It is where the assistant contributes most, because summarising is its craft — and it is now summarising real, traceable data rather than an approximate reconstruction.

What the professional does across that sequence does not change: assess, choose, decide. What changes is the time spent moving information from one window to another.

What to check before adopting it in a firm

In almost every firm, adopting a data access channel goes through an internal review. The questions that matter are few.

Who can use it? Access is restricted to enabled client organisations, and the assistant sees only what the organisation is allowed to see. There is no parallel permissions perimeter to govern separately.

What can it do? Read only. Read-only is a property of the channel, not a setting to be maintained.

Where does confidential data go? The infrastructure is European, data is encrypted at rest and in transit, processing is GDPR compliant, and client data does not feed model training.

How is an answer verified? The reachable information is the platform's, and on the platform every figure remains traceable to its source: an answer received in conversation can always be checked there.

What changes in cost? Nothing. MCP is included in the annual fee, along with the mobile app and API access, and there is no credit consumption.

What stays with the person reading the answer

One point deserves saying explicitly, because it concerns using this well.

An assistant connected to a data source sharply reduces the risk of an invented answer, but it does not turn a summary into a diligence document. A summary remains a summary: it chooses what to foreground, and that choice is already an interpretation. When the output is going into material that will be discussed, checking against the underlying data remains part of the craft, not a formality.

It is the same caution one applies to the work of a capable junior colleague: the material is useful and it gets checked. Quido MCP shortens the path to a draft; responsibility for what gets signed stays where it has always been.

A note on natural language

A final point of method, about how a request is framed.

Querying data in natural language does not mean any sentence produces a useful result. It means no syntax has to be learned: the precision required is that of the thinking, not that of the command. A vague question produces a vague answer, exactly as it would with a colleague.

In practice the most effective way to work is the familiar one: state the perimeter before asking for the figure, be explicit about the financial year or period where it matters, and narrow in steps rather than framing a single question containing everything. It is the method an analyst already applies when briefing a piece of research; only the recipient changes.

Who benefits most, and who does not

Not every role gains the same amount from this, and being straightforward about it is more useful than a general claim.

The clearest gain goes to whoever spends the day between an assistant and a data source: analysts and associates drafting screening notes and memos, and anyone handling the preparatory work before a meeting. For them the saving is direct, because the relay between windows is the bulk of the friction.

There is a second, quieter gain for people who use the platform occasionally — a partner who wants one figure before a call, a professional in an adjacent team who needs to know who controls a company. Occasional use is the case in which opening a tool, remembering where the information sits and navigating to it costs more than the answer is worth. A question asked inside a conversation removes that barrier entirely.

The gain is smallest for structured work that lives in the interface by design: comparing a set of companies visually, running the shared deal flow board, producing the final report in the firm's format. Those tasks are better served where they already are, and that is why nothing about them changes here.

Frequently asked questions

What is the Model Context Protocol?

It is the standard that lets an AI assistant read from external data sources. Quido MCP uses that standard to make the platform's data reachable from compatible assistants.

What information is reachable?

The same as the platform's: company profiles and research, financials and balance sheets, ownership and private equity investors, people profiles with roles and deals, news and M&A activity.

Can the assistant change the data?

No. Access is read-only: the assistant reads the data, it does not change it.

Who can use it?

Enabled client organisations. The assistant sees only what the organisation is allowed to see on the platform.

Is data used to train models?

No. The infrastructure is European, data is encrypted at rest and in transit, processing is GDPR compliant, and client data does not feed model training.

Does it replace the platform or the mobile app?

No. It is an additional access channel, made for the moment when the work is happening inside an assistant. Structured work — shared deal flow, reports in the firm's format, peer comparison — stays on the platform.

Which assistants does it work with?

Assistants that support the Model Context Protocol, among them Claude and ChatGPT, through Quido's native MCP server.

Does it cost extra?

No. MCP is included in the annual fee, along with the mobile app and API access.

When is it available?

Today, for all client organisations.

In summary

With Quido MCP, Quido's data on private companies — company research, financials, ownership, people profiles, news and M&A activity — is reachable directly from AI assistants that support the Model Context Protocol. Access is read-only and follows the same rules as the platform: every request is restricted to enabled client organisations.

Quido MCP is available today to all client organisations. For background on the company and its investors: the €1.6 million funding round. Questions on sources, security, pricing and integrations are answered on the FAQ page.