Verified European PE ownership: who owns a company, GP portfolios, exits by year. Hand-checked.
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 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.
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 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.
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 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. '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, so the description only needs to add extra context. It does so by noting 'Buyer names and MOIC stay locked unless authenticated as Pro' and clarifies the 'Continuation Vehicle' exit_type scope. No contradiction with 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?
The description is three sentences long: the first defines scope, the second provides a usage example, and the third clarifies a nuanced terminology. Every sentence earns its place with no 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?
The description covers the main filtering dimensions, aggregation mode, access restrictions, and a key terminology nuance. Although it does not describe the exact return format, the schema thoroughly documents parameters, and pagination is handled in schema descriptions. This is nearly complete for a read-only search 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 description coverage is 100%, so the baseline is 3. The description adds extra value by demonstrating group_by with a concrete example and explaining the 'Continuation Vehicle' exit_type, which goes beyond the schema's parameter 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's purpose: 'Cross-firm exit search the per-firm tools cannot do' and specifies filtering 'REALISED exits across ALL European PE firms by year (or range), exit route, sector and geography.' This is a specific verb-plus-resource and explicitly distinguishes it from sibling per-firm tools.
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 clear usage context by contrasting with per-firm tools and provides a concrete example with group_by and year to answer a specific question. It does not explicitly name alternative sibling tools or give exclusions, but the context is sufficiently clear for when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 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.
Find 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.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
1000+ actively deploying VC funds and 399 disclosed LPs, with live investor signals
Company, KYB, VAT, sanctions, LEI and address data for 15 EU countries.
European hosting & domain market intelligence: M&A tracking, operator dossiers, screening.
Curated investor database: 10,469 VC, angel, PE, and family office firms with contacts, via MCP.
Add one secure layer between your agents and this server.
Each tool has a unique purpose: gp_exits and gp_portfolio are per-firm, while search_exits and search_deals are cross-firm, clearly differentiated by scope. search_companies, search_gps, and who_owns cover distinct entity types and actions, leaving no ambiguity.
Tool names use a consistent verb_noun pattern for search_* tools and a gp_* prefix for per-firm tools, but who_owns breaks the convention with a question phrase. The inconsistency is noticeable but does not severely impair usability.
With 7 tools, the server is well-scoped for its domain, covering per-firm and cross-firm queries, entity searches, and ownership history without redundancy or bloat.
The toolset covers the core private equity data needs: searching firms and companies, viewing portfolios and exits for a specific GP, cross-firm deal and exit searches, and ownership lookup. Minor gaps like detailed company financials are outside the apparent scope.
