signals
Server Details
Deduplicated, entity-resolved funding rounds, acquisitions, and exec moves as MCP tools.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 3.9/5 across 5 of 5 tools scored.
Each tool targets a distinct entity type—companies, funding events, acquisitions, executive moves, and investors—with no overlapping purposes. The descriptions clearly distinguish their focuses.
All tool names follow a consistent pattern: lowercase, plural nouns, with underscores for multi-word terms (e.g., exec_moves, funding_events). No mixing of conventions.
With 5 tools covering core business signals, the count is well-scoped for the domain. Each tool provides meaningful filtering, and there is no bloat or deficiency.
The tool set covers major areas of company intelligence—company records, funding, M&A, executive changes, and investors. Minor gaps like news or partnerships exist but do not severely hinder common workflows.
Available Tools
5 toolsacquisitionsAInspect
List acquisition and merger events ordered by discovery time. Filter by payment type, deal amount range, merger flag, or a company that is the acquirer or target. Costs one credit per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records to return (1-100). Each returned record costs one credit. | |
| since | No | Return records discovered/announced on or after this date (YYYY-MM-DD) or ISO-8601 timestamp. | |
| cursor | No | Opaque pagination cursor returned as pagination.nextCursor on the previous page. | |
| isMerger | No | Filter to mergers (true) or acquisitions (false). | |
| companyId | No | Return only events where this company is the acquirer or target. | |
| paymentType | No | Payment type filters. Canonical values: cash, stock, mixed, undisclosed. | |
| maxAmountUsd | No | Maximum deal amount in USD. | |
| minAmountUsd | No | Minimum deal amount in USD. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It discloses credit cost per record and ordering by discovery time, but doesn't state idempotency or that it's a read-only operation. For a list tool, this is adequate but not fully transparent.
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?
Three sentences: purpose, filters, cost. No waste, information is front-loaded. Every sentence adds value.
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?
No output schema is provided, and the description does not explain the return format or pagination behavior (though cursor parameter implies it). For a complex tool with 8 parameters, this is a moderate gap.
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 all parameters have descriptions. The description adds value by summarizing filters and stating credit costs, which are not in the schema. This extra context justifies a score above baseline.
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 acquisition and merger events ordered by discovery time. It uses a specific verb 'List' and resource 'acquisition and merger events', which distinguishes it from sibling tools (companies, exec_moves, etc.).
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 lists available filters (payment type, deal amount range, merger flag, company ID), which guides usage. It doesn't explicitly contrast with siblings, but since siblings cover different domains, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
companiesAInspect
Search and filter company records by keyword, exact domain, HQ country, industry group, employee-count bucket, or founded-year range. Costs one credit per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records to return (1-100). Each returned record costs one credit. | |
| since | No | Return companies created/updated on or after this date (YYYY-MM-DD) or ISO-8601 timestamp. | |
| cursor | No | Opaque pagination cursor returned as pagination.nextCursor on the previous page. | |
| domain | No | Exact company domain. | |
| search | No | Keyword search over name, domain, and description. | |
| country | No | Headquarters country code (ISO alpha-2). | |
| industryGroup | No | Company industry group. | |
| foundedYearMax | No | Maximum founded year. | |
| foundedYearMin | No | Minimum founded year. | |
| employeeCountBucket | No | LinkedIn employee count bucket, e.g. 51-200. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It mentions the cost of one credit per returned record, which is a behavioral trait. However, it lacks disclosure of other behaviors like idempotency, rate limits, or whether the search is case-sensitive.
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, zero waste. The first sentence efficiently lists all filter options; the second adds the cost constraint. 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?
Despite many parameters and no output schema, the description does not explain return format, pagination behavior beyond the cursor, or default search behavior. For a tool of this complexity, more context is needed for an agent to invoke it correctly.
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 value by summarizing the filter types and introducing the credit cost per record, which is not in the schema. This extra context slightly elevates the score.
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 'Search and filter company records' and lists specific filters (keyword, domain, country, etc.), making the verb and resource highly specific. The sibling tools (acquisitions, exec_moves, etc.) are distinct, so no confusion arises.
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 finding companies, but does not explicitly state when to use this tool versus alternatives like funding_events or investors. There are no 'when not to use' indications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
exec_movesAInspect
List executive appointment, promotion, departure, and transition events ordered by discovery time. Filter by company, person, role seniority, move type, or a time window. Costs one credit per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records to return (1-100). Each returned record costs one credit. | |
| since | No | Return records discovered/announced on or after this date (YYYY-MM-DD) or ISO-8601 timestamp. | |
| until | No | Return events discovered/announced on or before this date (YYYY-MM-DD, inclusive) or ISO-8601 timestamp. | |
| cursor | No | Opaque pagination cursor returned as pagination.nextCursor on the previous page. | |
| moveType | No | Move type filters. Canonical values: appointment, promotion, departure, transition. | |
| personId | No | Filter by person id. | |
| companyId | No | Filter by company id. | |
| roleSeniority | No | Role seniority filters. Canonical values: c_level, vp_level, founder. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses credit cost and ordering by discovery time, but does not mention read-only nature, auth requirements, or any side effects. It is adequate but not comprehensive.
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 core purpose, then listing filters and cost. Every sentence adds value without waste.
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 8 parameters, no output schema, and no annotations, the description covers purpose, filters, cost, and ordering. It does not mention pagination or return format, which would be helpful, but is still fairly complete for a list 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 baseline is 3. The description summarizes filter parameters but adds no additional meaning beyond the schema. The schema already provides detailed descriptions for each 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?
The description clearly states the verb 'List' with specific resources: executive appointment, promotion, departure, and transition events. It orders by discovery time and mentions filtering, distinguishing it from sibling tools like acquisitions or 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 implies usage for listing executive move events with various filters, but does not explicitly state when to use this tool versus alternatives or provide when-not guidance. Sibling tool names are distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
funding_eventsAInspect
List funding events ordered by discovery time. Filter by round, amount range, company HQ country, industry group, or a specific company id. Costs one credit per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum records to return (1-100). Each returned record costs one credit. | |
| round | No | Funding round filters. Canonical values: pre-seed, seed, angel, series-a, series-b, series-c, series-d, series-e, series-f, series-g, series-h, series-i, growth, extension, bridge, convertible, safe, debt, grant, pre-ipo, secondary, pipe, other. | |
| since | No | Return records discovered/announced on or after this date (YYYY-MM-DD) or ISO-8601 timestamp. | |
| cursor | No | Opaque pagination cursor returned as pagination.nextCursor on the previous page. | |
| country | No | Company headquarters country code (ISO alpha-2). | |
| companyId | No | Return only events for this entity-resolved company id. | |
| maxAmountUsd | No | Maximum funding amount in USD. | |
| minAmountUsd | No | Minimum funding amount in USD. | |
| industryGroup | No | Company industry group. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must cover behavioral traits. It adds 'ordered by discovery time' and 'costs one credit per returned record', which are useful. However, it does not disclose whether the operation is read-only, idempotent, or any side effects, leaving some gaps.
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: first states primary function and ordering, second lists filters and cost. It is concise, front-loaded, and contains no redundant information.
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 no output schema and 9 parameters, the description covers primary action, ordering, filters, and cost. It lacks details about pagination behavior (though cursor parameter is in schema) and return values, but is fairly complete for a list 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 baseline is 3. The description summarizes filterable parameters but adds no additional semantics beyond a high-level grouping. It does not provide new details that the schema lacks.
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 'List funding events ordered by discovery time', using a specific verb (list) and resource (funding events). The mention of various filters distinguishes it from sibling tools like acquisitions or companies, which deal with different entities.
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 lists available filters, implying when to use the tool (e.g., filtering by round or amount). However, it does not explicitly compare to sibling tools or provide when-not-to-use guidance, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
investorsAInspect
Search and filter investor records by keyword, type, HQ country, or exact domain. Costs one credit per returned record.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Investor type filters. Canonical values: vc, angel, cvc, pe, growth, accelerator, family_office, syndicate, unknown. | |
| limit | No | Maximum records to return (1-100). Each returned record costs one credit. | |
| since | No | Return investors created/updated on or after this date (YYYY-MM-DD) or ISO-8601 timestamp. | |
| cursor | No | Opaque pagination cursor returned as pagination.nextCursor on the previous page. | |
| domain | No | Exact investor domain. | |
| search | No | Keyword search over investor name and domain. | |
| country | No | Headquarters country code (ISO alpha-2). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the credit cost per returned record, which is behavioral. However, without annotations, it does not mention read-only nature, authentication requirements, or other side effects. The description provides some transparency but lacks completeness.
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 with no wasted words. The first sentence states the core purpose, and the second adds crucial cost information. Highly concise and front-loaded.
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?
No output schema is provided, so the description should ideally mention return format or fields. The current description focuses on input filtering and cost but omits output structure, leaving some incompleteness for a 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 coverage is 100%, so the baseline is 3. The description adds a summary of filter dimensions (keyword, type, country, domain) but does not significantly augment the parameter descriptions already in 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 explicitly states 'Search and filter investor records' and lists the filtering dimensions (keyword, type, HQ country, domain). This clearly distinguishes the tool from siblings like companies or funding_events.
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 explicit guidance on when to use or when not to use. The description only states functionality, leaving the agent to infer usage context from the tool name and siblings.
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.
Discussions
No comments yet. Be the first to start the discussion!