Verified European PE ownership: who owns a company, GP portfolios, exits by year. Hand-checked.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 7 tools
The gp_ tools (per-firm exits/portfolio) and search_ tools (cross-firm deals/exits) overlap in subject matter, but descriptions explicitly draw the line ('Cross-firm exit search the per-firm tools cannot do'), which mostly resolves potential misselection.
Names use a predictable prefix pattern where gp_ denotes per-firm queries and search_ denotes cross-firm queries, with who_owns as a single small deviation. Mostly consistent and readable.
Seven tools is well-scoped for a PE intelligence database, with each tool covering a distinct query dimension (firms, portfolio, exits, deals, ownership, name search).
The surface covers firms, portfolio holdings, exits, cross-firm deals, name search and ownership history, which is strong lifecycle coverage. Minor gaps like fund-level or financing-round detail exist but aren't obvious dead ends for the stated domain.
List the exits (realised divestments) of a private equity firm, optionally for a specific year. The query AI search cannot answer reliably: 'what did GP X sell in YEAR'. Returns company, exit year, exit route, hold period.
| Name | Required | Description | Default |
|---|---|---|---|
| gp | Yes | PE firm name | |
| year | No | Exit year filter, e.g. 2024 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds return fields (company, exit year, exit route, hold period) and reliability hint. Annotations already declare readOnlyHint=true, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficient: purpose, optional parameter, usage hint, return fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage scenario, and return values. Lacks mention of pagination or error handling but sufficient for a simple list tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers both parameters with descriptions (100% coverage). Description adds only context of optionality, not new semantic meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'list', resource 'exits', and context 'PE firm' with optional year. Distinguished from siblings like 'search_exits' by focusing on a specific GP.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes when to use (when AI search cannot answer reliably for GP and year). Could be more explicit about alternatives (e.g., use search_exits for cross-firm queries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the portfolio companies of a private equity firm (GP), optionally filtered to active holdings or exited positions. Returns company, sector, geography, entry year, exit year/type, fund and vintage.
| Name | Required | Description | Default |
|---|---|---|---|
| gp | Yes | PE firm name, e.g. 'Ardian' or 'PAI Partners' | |
| status | No | Filter: only active holdings or only exited positions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's job is to add context. It lists the returned data fields, which is helpful, but does not disclose any behavioral traits beyond what annotations and schema provide (e.g., about filtering behavior or performance).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and key options. Every sentence adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, good annotations), the description is fairly complete. It lists return fields and states filtering capability, leaving little ambiguity. Minor omission: no mention of pagination or data freshness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds example values for 'gp' and clarifies the 'status' enum, but this is marginal added value over the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists portfolio companies of a PE firm, with optional filtering by status. It uses specific verb and resource, but does not explicitly distinguish from sibling tool gp_exits which might overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing portfolio companies and mentions returned fields, but provides no guidance on when to use this tool versus siblings like gp_exits or search_companies. No exclusions or conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the 34,000+ PE-backed companies tracked on GP Intel by name.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Company name or fragment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered without the description. The description usefully adds that the searchable corpus is a specific curated set of 34,000+ PE-backed companies (implying bounded, curated results), but says nothing about match semantics, ranking, or how many results come back. Adds some value beyond annotations, hence a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no waste: verb first, then corpus scope, then the match dimension. Nothing redundant with the title beyond the unavoidable resource name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only search tool this is close to adequate, and annotations carry the safety profile. However, with no output schema the description should say what a result looks like and whether the result set is capped by limit, which it omits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: query is documented in the schema and the description reinforces name/fragment matching via 'by name'. The limit parameter is undocumented in both places, so the description does not compensate for the coverage gap. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (PE-backed companies) with useful scope qualifiers: the 34,000+ dataset and GP Intel as the source, and that matching is by name. An agent can distinguish this from search_gps and search_deals by domain. It stops short of explicitly naming a sibling or contrasting conditions, so it is clear but not maximally differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, no conditions that select this tool over search_gps/who_owns, and no prerequisites such as exact-match vs fuzzy behavior. Usage must be fully inferred from the name and dataset qualifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-firm investment search across ALL European PE firms: filter portfolio companies by entry year (or range), sector, geography and status (active/exited). Set group_by to count instead of list, e.g. answers 'how many French healthcare companies were PE-backed in 2024 across all firms'. Buyer names and MOIC are included.
| Name | Required | Description | Default |
|---|---|---|---|
| gp | No | Optional: restrict to one PE firm by name | |
| geo | No | Company geography filter, e.g. 'France' (exact, case-insensitive) | |
| year | No | Exact entry year, e.g. 2024 | |
| limit | No | Page size for list mode (max 50) | |
| offset | No | Pagination offset for list mode | |
| sector | No | Sector filter, e.g. 'Healthcare' (exact, case-insensitive) | |
| status | No | Filter: only active holdings or only exited positions | |
| year_to | No | Entry year range end (ignored if year is set) | |
| group_by | No | Return counts grouped by this dimension instead of a list of deals | |
| year_from | No | Entry year range start (ignored if year is set) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: group_by switches from listing to counting, and buyer names and MOIC are included in results. Pagination limits and output shape are not discussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the scope and primary filters front-loaded, followed by the mode-switching group_by detail and one concrete example. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter read-only tool with no output schema, the description covers the main modes, filters, and returned fields well. Minor gaps remain around pagination behavior and the optional gp restriction, but nothing essential to correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented in the schema. The description adds a little meaning by explaining entry-year ranges and group_by counts, but does not clarify the gp restriction or year/year_from/year_to precedence beyond what the schema already states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (PE investments/deals) with an explicit scope (cross-firm, ALL European PE firms). The capitalized 'ALL' clearly distinguishes it from single-firm siblings like gp_portfolio and gp_exits, letting an agent tell it apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context: use it for cross-firm investment search and counting via group_by, with a concrete example question. It does not explicitly name alternatives like search_companies or state when not to use it, but the scope is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-firm exit search the per-firm tools cannot do: filter REALISED exits across ALL European PE firms by year (or range), exit route, sector and geography. Set group_by to count instead of list, e.g. group_by='exit_type' with year=2026 answers 'how many continuation-vehicle exits in 2026 across Europe'. exit_type 'Continuation Vehicle' covers continuation funds, strip sales and GP-led tender offers. Buyer names and MOIC are included.
| Name | Required | Description | Default |
|---|---|---|---|
| gp | No | Optional: restrict to one PE firm by name | |
| geo | No | Company geography filter, e.g. 'France' (exact, case-insensitive) | |
| year | No | Exact exit year, e.g. 2026 | |
| buyer | No | Filter exits to a specific buyer (acquirer), e.g. 'RadNet'. | |
| limit | No | Page size for list mode (max 50) | |
| offset | No | Pagination offset for list mode | |
| sector | No | Sector filter, e.g. 'Healthcare' (exact, case-insensitive) | |
| year_to | No | Exit year range end (ignored if year is set) | |
| group_by | No | Return counts grouped by this dimension instead of a list of exits | |
| exit_type | No | Exit route. 'Continuation Vehicle' = continuation funds / strip sales / GP-led tender offers | |
| year_from | No | Exit year range start (ignored if year is set) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior: what the result set contains (buyer names and MOIC included) and what the 'Continuation Vehicle' route actually covers (continuation funds, strip sales, GP-led tender offers). Pagination limits are left to the schema rather than the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with the distinguishing capability before the parameter guidance and enum clarification. No filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the right thing by stating what fields come back (buyer names, MOIC) and how counts differ from lists. Only marginal gaps remain, such as pagination behavior in list mode, which the schema's limit/offset handle adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes beyond it by showing how group_by interacts with year and exit_type to produce counts, and by explaining the range vs exact-year relationship implicitly through the example, though the exit_type definition largely repeats the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (cross-firm exit search) plus the scope that distinguishes it: 'across ALL European PE firms', explicitly contrasting with 'the per-firm tools'. An agent can immediately separate this from gp_exits without reading either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use ('the per-firm tools cannot do') and a concrete alternative mode selection: set group_by to count instead of list, with a worked example answering 'how many continuation-vehicle exits in 2026 across Europe'. Nothing about mode choice is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the 1,200+ European private equity firms (GPs) tracked on GP Intel by name. Returns country, AUM and strategies.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | GP name or fragment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful context by naming the returned fields (country, AUM, strategies) and corpus coverage, but omits result-count/pagination behavior tied to the limit parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the resource and scope front-loaded and no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only search with no output schema, telling the agent what comes back (country, AUM, strategies) is genuinely helpful. However, nothing explains the limit parameter or result ordering, which is the main remaining gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: 'query' is documented as 'GP name or fragment' while 'limit' (1-25) is undocumented anywhere. The description reinforces the name-based query but adds no syntax, matching, or cap details, so it does not compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (European private equity firms / GPs) and even quantifies the corpus (1,200+). The parenthetical '(GPs)' subtly differentiates it from the sibling search_companies, but the distinction is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says search is 'by name' but gives no when-to-use guidance, no prerequisites, and never names an alternative among siblings (search_companies, search_deals, who_owns). The agent must infer that this is the GP-lookup route rather than the company/deal route.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find who owns a company: its current private equity owner(s) and the full ownership history (entry years, exits with year and route). Covers 34,000+ companies held by European PE firms, hand-verified. Use for questions like 'who owns X' or 'X parent company'.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company name or gp-intel.com company slug, e.g. 'Bark.com' or 'bark-com' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and closed-world, but the description adds useful behavioral context: the data covers 34,000+ European PE-backed companies, is hand-verified, and returns both current owners and historical ownership details including entry years and exit routes. It does not describe authentication or rate limits, but adds meaningful domain scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is three concise sentences, front-loaded with the core purpose and return scope, followed by dataset coverage and usage examples. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup with no output schema, the description adequately explains what is returned, the data coverage, and example usage scenarios. Nothing essential for correct invocation appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'company' parameter, including a name-or-slug example. The description adds no additional parameter semantics beyond implying the company should be within the covered European PE-backed dataset, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: finding who owns a company, with detail on returning current private equity owners and full ownership history. It is clear and concrete, but it does not explicitly differentiate this tool from siblings such as search_companies or gp_portfolio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states intended use cases with example queries: 'who owns X' and 'X parent company'. This gives clear context for when to use the tool, though it does not name alternatives or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_exits1 field changedInput schema / properties / buyer / descriptionPrevious value: -"Pro only: filter exits to a specific buyer (acquirer). Ignored for anonymous callers."New value: +"Filter exits to a specific buyer (acquirer), e.g. 'RadNet'."search_exits2 fields changedInput schema / properties / exit_type / descriptionPrevious value: -"Exit route. 'GP-led' = continuation funds / strip sales / GP-led tender offers"New value: +"Exit route. 'Continuation Vehicle' = continuation funds / strip sales / GP-led tender offers"Input schema / properties / exit_type / enumPrevious value: -[
- "Trade Sale",
- "Secondary",
- "IPO",
- "MBO",
- "GP-led",
- "Write-off",
- "Liquidation",
- "Unknown"
-]New value: +[
+ "Trade Sale",
+ "Secondary",
+ "IPO",
+ "MBO",
+ "Continuation Vehicle",
+ "Recapitalization"
+]search_dealssearch_exitsgp_exitsgp_portfoliosearch_companiessearch_gpswho_ownsKYB data from 23 European business registries — company briefs, financials, ownership, AML screening
Company, KYB, VAT, sanctions, LEI and address data for 15 EU countries.
Curated investor database: 10,469 VC, angel, PE, and family office firms with contacts, via MCP.
Search European tech funding rounds, companies, investors and exits — sourced, EUR-normalized.
Add one secure layer between your agents and this server.
