Verified European PE ownership: who owns a company, GP portfolios, exits by year. Hand-checked.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 7 of 7 tools scored.
Most tools have distinct purposes, but gp_exits and gp_portfolio both cover exits for a firm, and search_exits and search_deals both allow cross-firm filtering on exits. Descriptions help disambiguate, but some overlap exists.
Tools use three naming patterns: gp_*, search_*, and who_owns. The gp_ and search_ prefixes are consistent within their subgroups, but the who_owns tool breaks the pattern, making the set inconsistent overall.
Seven tools cover per-firm portfolio and exits, cross-firm searches, company and GP lookup, and ownership. This is well-scoped for a PE data service, neither too few nor too many.
The tool set covers core queries: per-firm portfolio/exits, cross-firm searches, company/GP lookup, and ownership history. Missing are detailed company profiles or fund-level data, but the main use cases are addressed.
gp_exitsPE firm exits by yearAList 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.
gp_portfolioPE firm portfolioAList 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_companiesSearch PE-backed companiesASearch the 21,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 indicate readOnlyHint=true, so the read-only nature is known. Description adds that search is by name but no other behavioral traits (e.g., pagination, sorting, rate limits). Minimal extra value beyond annotations.
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?
Single sentence, to the point. No redundant words or filler. Front-loaded with action and resource.
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 search tool with 2 params and no output schema, description covers core purpose and scope. Lacks mention of result format, pagination, or sorting, but adequate given low complexity.
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% (only 'query' has a description). Description mirrors 'by name' for query but adds nothing for 'limit'. Does not compensate for undocumented limit parameter.
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?
Description states 'Search the 21,000+ PE-backed companies tracked on GP Intel by name.' It specifies verb (search), resource (PE-backed companies), and scope (by name, specific database). Clearly differentiates from siblings like search_gps and search_deals.
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?
No guidance on when to use this vs. alternatives (e.g., search_gps, who_owns). Does not mention exclusions, prerequisites, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_dealsSearch PE investments across all firmsACross-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 stay locked unless authenticated as Pro.
| 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, indicating safe read. Description adds that buyer names and MOIC are locked unless Pro authenticated, which is useful behavioral context beyond annotations. No contradictions found.
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, front-loaded with main purpose. No redundant words; every sentence adds value. Highly efficient.
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 main use cases, filtering options, and authentication caveat. Lacks explanation of return format (list of deals vs counts), but as there is no output schema, this is acceptable. For a complex 10-parameter tool, description is fairly comprehensive.
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 parameters are already documented. Description adds context for group_by usage and authentication locking, which extends schema meaning. Baseline 3 is appropriate; description does not significantly enhance param semantics.
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?
Description starts with 'Cross-firm investment search across ALL European PE firms', clearly stating the broad scope and distinguishing from sibling per-firm tools like gp_portfolio. It lists specific filters (entry year, sector, geography, status) and modes (list vs group_by).
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?
Provides explicit usage example with group_by ('how many French healthcare companies...') and mentions authentication requirements for buyer names and MOIC. However, it does not explicitly state when to avoid this tool or compare to siblings like search_exits or who_owns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_exitsSearch PE exits across all firmsACross-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 GP-led / continuation exits in 2026 across Europe'. exit_type 'GP-led' covers continuation funds, strip sales and GP-led tender offers. Buyer names and MOIC stay locked unless authenticated as Pro.
| 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 | Pro only: filter exits to a specific buyer (acquirer). Ignored for anonymous callers. | |
| 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. 'GP-led' = 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 declare readOnlyHint=true, consistent with a read operation. The description adds significant behavioral context: it notes that buyer names and MOIC are locked for non-Pro users, clarifies that exits are 'REALISED' (completed), and explains that exit_type 'GP-led' includes continuation funds and strip sales. This goes beyond annotations to inform the agent about access restrictions and data 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 description is extremely concise: 3 sentences covering purpose, differentiation, example, and a clarification. It is front-loaded with the core capability, followed by an illustrative example and an important caveat about authentication. No filler or redundant content.
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 complexity (11 params, no output schema), the description covers core functionality, differentiation from siblings, and authentication constraints. It explains group_by behavior well. However, it does not describe the return format for list mode beyond being a 'list', nor does it mention pagination details (though schema covers those). For a search tool, this is fairly complete, but the lack of output schema place a heavier burden on the description to hint at results structure.
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 baseline is 3. The description adds value by providing an example (group_by with year), clarifying that 'GP-led' covers multiple sub-types, and emphasizing that buyer filter is Pro-only. While schema descriptions already cover each parameter, the description enhances understanding of usage patterns and edge cases.
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 performs cross-firm exit search, explicitly distinguishing it from per-firm tools like gp_exits. It specifies filtering by year, exit route, sector, and geography, with a clear verb ('search') and resource ('REALISED exits across ALL European PE firms'). This differentiates it from siblings like search_deals (deals) and search_companies (companies).
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 implicitly says to use this tool when cross-firm exit data is needed, contrasting with per-firm tools. It provides a concrete example with group_by. However, it does not explicitly exclude alternatives or state when not to use it, such as for per-firm data (use gp_exits) or for deal data (use search_deals). The guidance is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_gpsSearch PE firmsASearch the 900+ 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; the description adds that it returns country, AUM, and strategies, providing some behavioral context beyond the annotation.
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?
Single sentence with no fluff, front-loaded with action and scope. Every word 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 search tool with 2 parameters and no output schema, the description sufficiently covers what it does and returns, though it lacks details on error handling or matching behavior.
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% (only query has a description). The tool description mentions 'by name' but does not elaborate on the limit parameter or add meaning beyond 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?
The description clearly states it searches European PE firms by name and returns country, AUM, and strategies, distinguishing it from sibling tools like gp_exits and 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?
The description implies use for name-based search but does not explicitly state when to use this tool versus alternatives or mention any conditions for not using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
who_ownsWho owns a companyAFind who owns a company: its current private equity owner(s) and the full ownership history (entry years, exits with year and route). Covers 21,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 indicate read-only; description adds that data covers 21,000+ hand-verified companies and includes comprehensive history, providing useful behavioral context.
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, no wasted words; front-loaded with core function, then scope and usage examples.
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?
Describes output (current owners + history) despite no output schema; covers scope and verification. Lacks error handling but adequate for a simple lookup tool.
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 describes the 'company' parameter fully (name or slug); description reinforces this but adds no new meaning beyond 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?
The description clearly states it finds current PE owners and full ownership history for a company, distinguishing it from sibling tools like gp_exits or search_companies.
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?
Explicit use cases are given ('who owns X' or 'X parent company'), but no explicit exclusions; however, the context from sibling tools makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.
