A
license-
qualityB
maintenanceHosted MCP server that gives AI agents real-time access to SEC EDGAR filings search, 10-K/8-K reading, XBRL financial facts, and insider-trade (Form 4) alerts.
10
1
MIT
IPOGrid IPO Calendar & Filing Research
by com.ipogrid
Server Details
IPO calendar, SEC filings, deal terms, and IPO news research via the IPOGrid MCP server.
- 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.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.4/5.0
Tool DescriptionsA
Average 4.4/5 across 4 of 4 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool targets a distinct function: charts, company details, company discovery, and news. No overlap in purpose.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with 'get' for retrieval and 'list' for discovery.
Tool Count5/5
Four tools cover the core IPO research workflow without being excessive or insufficient.
Completeness4/5
Covers company discovery, details, charts, and news. Missing a dedicated IPO calendar tool, but existing tools handle date ranges and filters.
Available Tools
4 toolsget_chartGet ChartARead-onlyIdempotentInspect
Build an aggregated IPO chart and return its data plus canonical embed, page, and API URLs. Use this instead of hand-building chart URLs. Anonymous requests are quota-limited and may clamp a 52-week range to 26 weeks or a daily bucket to weekly unless the explicit date window is at most 31 days.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Dimension used to split chart series. Defaults to sector for proceeds/returns and form_family for filing counts. | |
| range | No | Trailing window when explicit dates are omitted. Defaults to 26w; anonymous 52w requests are clamped to 26w. | |
| scope | No | Include all matching records or only active offerings. Defaults to active. | |
| bucket | No | Time interval. Defaults to week; anonymous daily requests require an explicit window of at most 31 days or are clamped to week. | |
| issuer | No | Include every issuer or exclude SPACs. Defaults to all. | |
| metric | No | Value to aggregate. Defaults to gross_proceeds. | |
| date_to | No | Inclusive YYYY-MM-DD upper bound. Use with date_from for a custom window instead of range. | |
| date_from | No | Inclusive YYYY-MM-DD lower bound. Use with date_to for a custom window instead of range. | |
| materiality | No | Include all filing forms or only major IPO forms. Defaults to all. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| links | Yes |
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by disclosing quota limits and clamping behavior for anonymous requests, which are not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The first sentence states core purpose and output, the second provides important usage guidance and limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 optional parameters and an output schema, the description covers the tool's purpose, output, and key behavioral notes. It could mention default parameter behaviors briefly, but overall it's sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully describes each parameter. The description does not add parameter-level details beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds an aggregated IPO chart and returns data plus URLs, using specific verbs and resource. It distinguishes itself from sibling tools (get_company, list_companies, list_news) by focusing on chart generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool instead of hand-building chart URLs, and notes anonymous request limitations. While it doesn't exclude alternative tools among siblings, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_companyGet CompanyARead-onlyIdempotentInspect
Fetch one issuer by SEC CIK after discovery with list_companies. Optional enrichments add terms and research context; anonymous requests allow only latest_terms, classification, and news.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cik | Yes | SEC Central Index Key, with or without leading zeroes (for example 1907085 or 0001907085). | |
| include | No | Optional detail sections. Authenticated lockup_schedule includes normalized holder classes, numeric tranche quantities, resolved dates, anchors and offsets, exceptions, conditions, and evidence. Anonymous requests silently omit consensus, financial_snapshot, filings, comps, and lockup_schedule. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Issuer detail with the requested and permitted enrichment sections. |
Tool Definition Quality
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint false. The description adds significant behavioral detail: it explains that optional enrichments add terms and research context, and that anonymous requests are limited to certain sections. This is valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and detailed annotations, the description covers the key behavioral aspects: auth-dependent behavior, prerequisite, and optional enrichments. It is sufficiently complete for an AI agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (cik and include) with clear descriptions. The description adds context by explaining that include sections are optional and that anonymous requests silently omit some sections. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches one issuer by SEC CIK, includes a prerequisite (after discovery with list_companies), and distinguishes from sibling tools like list_companies that list multiple issuers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: it's used after discovery with list_companies. It also explains the difference between anonymous and authenticated requests regarding enrichments. However, it does not explicitly list alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_companiesList CompaniesARead-onlyIdempotentInspect
Discover IPOGrid companies and active deals with cursor pagination and market, issuer-kind, freshness, or proceeds filters. Use get_company after selecting an issuer. Anonymous requests return at most 10 rows and omit consensus enrichment.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Return only these issuer kinds. Omit to include every kind. | |
| limit | No | Maximum rows to return. Defaults to 50 when authenticated; anonymous requests are capped at 10. | |
| scope | No | Filter to IPO-only rows or all active deal rows. | |
| cursor | No | Opaque next_cursor from a previous response. Omit for the first page. | |
| market | No | Filter by normalized market family. | |
| include | No | Optional enrichments for each row. Anonymous requests silently omit consensus. | |
| updated_since | No | ISO-8601 lower bound on the company update timestamp. | |
| gross_proceeds_gt | No | Lower bound on gross proceeds, using stated gross proceeds or a midpoint estimate from price range times shares offered. | |
| gross_proceeds_lt | No | Upper bound on gross proceeds, using stated gross proceeds or a midpoint estimate from price range times shares offered. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Rows for the current page. |
| meta | Yes | |
| has_more | Yes | Whether another page is available. |
| next_cursor | Yes | Opaque cursor for the next page, or null when this is the last page. |
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, etc. Description adds context on anonymous request caps (10 rows) and omission of consensus enrichment, and mentions cursor pagination. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first covers purpose and filters, second guides usage and anonymous limits. No fluff, front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 9 parameters and output schema, the description covers purpose, pagination, filtering, and sibling guidance. Omits return format details, but output schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description summarizes filter categories (market, issuer-kind, freshness, proceeds) but does not add new meaning beyond the schema; baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Discover' and resource 'IPOGrid companies and active deals', and distinguishes from sibling tool 'get_company' by stating 'Use get_company after selecting an issuer.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using get_company for a specific company after listing, but does not address when to use alternatives like get_chart or list_news. Also mentions anonymous request limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_newsList NewsARead-onlyIdempotentInspect
List recent IPO-company news, optionally filtered by SEC CIK. Use this for a news feed; use get_company with news for broader issuer context. Anonymous requests return at most 10 rows and omit full content.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cik | No | Optional SEC CIK filter, with or without leading zeroes. | |
| limit | No | Maximum rows to return. Defaults to 50 when authenticated; anonymous requests are capped at 10. | |
| cursor | No | Opaque next_cursor from a previous response. Omit for the first page. | |
| include | No | Set to ["content"] for stored article body text. Anonymous requests omit content. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Rows for the current page. |
| meta | Yes | |
| has_more | Yes | Whether another page is available. |
| next_cursor | Yes | Opaque cursor for the next page, or null when this is the last page. |
Tool Definition Quality
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses anonymous behavior (capped at 10 rows, no content) beyond annotations. Annotations already mark it as read-only, idempotent, and non-destructive, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences covering purpose, usage guidance, and a behavioral quirk. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main behavior, filtering, pagination (cursor), and authentication differences. Output schema exists so return values are not needed. Could mention time range for 'recent', but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds little beyond what schema already provides (e.g., 'optionally filtered by SEC CIK' is redundant). Does not enhance parameter understanding significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List recent IPO-company news' with optional CIK filter. Explicitly distinguishes from sibling tools (get_company) by advising to use it for broader issuer context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides when-to-use ('for a news feed') and when-not-to-use ('use get_company with news for broader issuer context'). Also notes anonymous request limitations (10 rows, no content).
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!
Related MCP Servers
- Alicense-qualityAmaintenanceQuery SEC EDGAR filings, XBRL financials, and company data through MCP.3897Apache 2.0
shareseer-mcpofficial
Alicense-qualityBmaintenanceShareSeer provides: SEC filings data (10-K, 10-Q, 8-K forms) & related financials Insider trading transaction data per company Largest insider purchases & Sales in a day and week Integration: Remote MCP server (https://shareseer.com/mcp)9MIT- Alicense-qualityCmaintenanceMCP server for SEC EDGAR data, providing tools to look up companies, retrieve filings and documents, and access XBRL financial facts.227MIT