SEC & institutional filings — Form 4, 8-K, 13F, Schedule 13D, Form D, IPO & earnings calendars.
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 17 of 17 tools scored. Lowest: 3.4/5.
Each tool targets a distinct regulatory filing or financial data type with clear, non-overlapping descriptions. Even similar concepts like 13F holdings vs. delta are well-differentiated.
Most tools follow a consistent 'get_<noun>' pattern, with a single exception 'detect_insider_cluster'. Overall naming is predictable and readable.
17 tools is slightly above the ideal 3-15 range but justified by the broad domain of regulatory filings and financial data. Each tool serves a clear purpose.
The server covers a comprehensive set of regulatory filings (13F, Form 4, 8K, etc.) and additional financial data (analyst targets, options, short interest). Minor gaps like Form 144 are acceptable given the scope.
detect_insider_clusterADetect insider buying clusters — multiple officers/directors buying the same stock inside a window. The smart-money signal hedge funds pay $200+/mo for. Returns one row per stock with cluster strength.
Args: ticker: Optional ticker to filter days_window: Cluster detection window in days (default 30 — 30/60/90 supported) min_insiders: Minimum distinct insiders to qualify as a cluster (default 3)
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | ||
| days_window | No | ||
| min_insiders | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, which the description does not contradict. The description adds return format ('one row per stock with cluster strength') but does not disclose additional behavioral traits like rate limits or data freshness. With annotations handling safety, the description provides moderate added value.
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 concise with two paragraphs: first explaining purpose and value, second listing parameters. It is front-loaded with the main idea. No redundant sentences, but could slightly tighten the marketing phrase to save space.
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 tool with three optional parameters and no output schema, the description covers purpose, parameter details, and return format. It does not cover error handling or edge cases, but given the simplicity and annotations (read-only, open-world), it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully explains all three parameters: ticker (optional filter), days_window (default 30, supported values 30/60/90), and min_insiders (default 3). This adds complete meaning beyond the raw schema, fully compensating for the lack of inline 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 uses a specific verb 'Detect' and clearly defines the resource: 'insider buying clusters'. It explains that it identifies multiple officers/directors buying the same stock within a window, which distinguishes it from siblings like 'get_form_4_insider_trades' that list individual trades.
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 mentions it as a 'smart-money signal hedge funds pay $200+/mo for', implying premium value, but does not explicitly state when to use it versus alternatives like raw insider trade tools. It provides some implicit guidance by describing output, but lacks clear when-not or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_13f_deltaACompute the position delta between a 13F filer's two most recent filings. Returns new positions, increased stakes, reduced stakes, and full exits per CUSIP — the actionable signal WhaleWisdom Premium charges $999/yr for.
Args: filer_cik: Filer CIK (e.g. "0001067983" for Berkshire) or fund name days_back: Lookback window for filings comparison (default 90 — informational)
| Name | Required | Description | Default |
|---|---|---|---|
| days_back | No | ||
| filer_cik | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, and the description confirms a read-only computation. It adds context about the return structure (per CUSIP) and mentions the days_back lookback parameter behavior.
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 concise paragraphs, with the purpose and output in the first and parameter details in the second. No redundant or filler sentences.
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 having no output schema, the description fully explains the tool's output (delta types per CUSIP) and parameters. For a 2-parameter tool with clear purpose, it covers all necessary context.
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 0% schema description coverage, the description compensates by explaining filer_cik (accepts CIK or name) and days_back (default 90, informational). This adds significant meaning beyond the raw schema types.
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 computes the position delta between two most recent 13F filings, which is a specific verb and resource. It distinguishes from sibling tools like get_form_13f_holdings, which likely returns raw holdings rather than delta.
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 explains the tool's output (new positions, increased stakes, etc.) and highlights its unique value as a premium signal. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_analyst_targetsBRetrieve Wall Street analyst price targets for a ticker — high, low, mean, latest changes by firm.
Args: ticker: Required ticker symbol
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, indicating safe reading and varied output. The description adds that it returns high, low, mean, and latest changes by firm, which is helpful but does not disclose rate limits, authentication needs, or data source frequency. With annotations covering safety, a score of 3 is appropriate.
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 concise with two sentences: the first defines the tool's action and output, the second specifies the parameter. No wasted words, and critical information is 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 exists, so the description should explain return values comprehensively. It mentions key fields but omits context like time range, data source, or update frequency. Given the tool's simplicity (1 param), completeness is partial.
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 0%, so the description must compensate. It states 'ticker: Required ticker symbol', which adds basic meaning but lacks details like format, exchange, or case sensitivity. For a single required parameter, this is minimal improvement.
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 retrieves Wall Street analyst price targets, listing specific data points (high, low, mean, latest changes by firm). The verb 'Retrieve' and resource 'analyst price targets' are specific, and the tool is distinct from siblings like get_earnings_estimates or get_short_interest.
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 tool versus alternatives. The description does not mention prerequisites, context, or when not to use it. For a data retrieval tool among many siblings, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dividend_aristocratsARetrieve S&P 500 Dividend Aristocrats — companies with 25+ consecutive years of dividend increases.
Args: min_years: Minimum consecutive years of dividend increases (default 25)
| Name | Required | Description | Default |
|---|---|---|---|
| min_years | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so description adds minimal behavioral context. It does not elaborate on rate limits or auth, but is consistent and non-contradictory.
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?
Extremely concise: two sentences with purpose and parameter detail. No fluff, front-loaded with the core function.
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 simple tool (one optional param, no output schema), description is largely complete. Could mention return format (e.g., list of tickers) but not critical.
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 0%, but the description explains the parameter 'min_years' with meaning (minimum consecutive years) and default, adding value beyond the schema's type definition.
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 clearly states 'Retrieve S&P 500 Dividend Aristocrats' with a specific verb and resource, and distinguishes from sibling tools which are other financial data tools but none with identical purpose.
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 this tool vs alternatives, nor any exclusions. The purpose is implied, but lacking in-depth usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_earnings_calendarARetrieve upcoming earnings calendar — report dates, EPS estimates, revenue estimates.
Args: days_forward: Calendar horizon in days (default 14) ticker: Optional ticker filter (post-filtered)
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | ||
| days_forward | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and openWorldHint. Description adds that ticker is 'post-filtered', which is a behavioral trait. However, it does not elaborate on potential pitfalls or limitations given openWorldHint.
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 concise: one line captures purpose, then an Args block. Front-loaded, no unnecessary words, and well-structured.
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 has two optional params, no output schema, and annotations covering safety, the description sufficiently covers what to expect. Could mention potential absence of data or pagination, but not critical for this simple read 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 0%, but the description compensates by explaining 'days_forward' as calendar horizon with default 14, and 'ticker' as optional post-filter. This adds meaningful context beyond parameter names and defaults.
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 retrieves an upcoming earnings calendar with report dates, EPS estimates, and revenue estimates. It differentiates from sibling 'get_earnings_estimates' by including report dates, but does not explicitly distinguish from all siblings.
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 tool instead of siblings like 'get_analyst_targets' or 'get_earnings_estimates'. No exclusions or alternative recommendations provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_earnings_estimatesARetrieve analyst earnings estimate revisions — EPS upgrades/downgrades over the lookback window.
Args: ticker: Required ticker symbol days_back: Lookback window — maps to 30d / 60d / 90d
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| days_back | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnly and openWorld hints. The description adds that the days_back parameter maps to specific windows (30d/60d/90d), providing useful behavioral context 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?
Description is concise (two sentences plus argument list) and front-loaded. Every sentence adds value 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?
For a simple two-parameter tool without output schema, the description covers purpose and parameter meaning adequately. The days_back mapping discrepancy slightly reduces completeness, but overall it is sufficient.
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?
Description adds meaning to both parameters: ticker as required symbol and days_back mapping to 30/60/90 days. However, the schema default is 14, creating inconsistency with the described mapping. This could mislead an agent.
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 clearly states it retrieves analyst earnings estimate revisions (EPS upgrades/downgrades) over a lookback window. This distinguishes it from siblings like get_analyst_targets (target prices) and get_earnings_calendar (dates).
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 defines what the tool returns but does not explicitly specify when to use it over alternatives. However, the context provided (revisions) implicitly guides an agent away from related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_form_13f_holdingsARetrieve SEC Form 13F-HR holdings — institutional investor positions ($100M+ AUM funds). Pull Berkshire Hathaway, Renaissance, Citadel, Two Sigma quarterly position disclosures.
Args: filer_cik: Filer CIK number (e.g. "0001067983" for Berkshire) or fund name (passed as query) quarter: Quarter in YYYY-QN format (e.g. "2025-Q4")
| Name | Required | Description | Default |
|---|---|---|---|
| quarter | No | ||
| filer_cik | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds limited behavioral context beyond explaining the data source and format. No additional behavioral traits like rate limits or authentication needs are mentioned.
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 concise with two clear paragraphs, including a one-sentence purpose statement and structured parameter documentation. No unnecessary 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?
The description provides adequate context for a read-only tool with well-documented parameters. However, without an output schema, it does not describe the return format or fields, which would be helpful for complex holdings data.
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 0% schema description coverage, the description fully explains both parameters: filer_cik can be a CIK number or fund name, and quarter uses YYYY-QN format. This adds substantial 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 retrieves SEC Form 13F-HR holdings for institutional investors, providing examples of filers and distinguishing it from sibling tools like get_form_4_insider_trades or get_schedule_13d_activist.
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 specifies the tool is for institutional investor positions with $100M+ AUM and gives quarterly disclosure context. It implies when to use it but does not explicitly state when not to use or compare with alternatives, though sibling tool list provides some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_form_4_insider_tradesARetrieve SEC Form 4 insider trades (officers/directors buying or selling their own stock). Replaces a WhaleWisdom Insider feed subscription. Returns transaction date, insider name & role, shares, price, value.
Args: ticker: Optional ticker filter (e.g. "NVDA") days_back: Lookback window in days (default 30) min_value_usd: Optional minimum transaction value filter (post-filtered)
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | ||
| days_back | No | ||
| min_value_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true. The description adds context by noting it replaces a WhaleWisdom Insider feed subscription, implying a specific data source. No contradictions; additional behavioral details (e.g., data freshness) could be added.
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 concise (3 sentences plus bulleted args), front-loaded with the main purpose, and well-structured. 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?
For a tool with 3 optional parameters and no output schema, the description provides sufficient context: what it returns, how to filter, and its relation to a subscription service. Minor gaps like sorting order or pagination could be included but are not critical.
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 has no descriptions (0% coverage), but the description explains each parameter: ticker as optional filter with example 'NVDA', days_back as lookback window with default 30, min_value_usd as post-filtered minimum value. This adds essential 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 explicitly states it retrieves SEC Form 4 insider trades, specifies the data fields returned (transaction date, insider name & role, shares, price, value), and distinguishes from siblings like get_form_13f_holdings by focusing on insider transactions.
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 clearly indicates the tool is for insider trading data, listing optional filters (ticker, days_back, min_value_usd). However, it does not explicitly guide when to use this tool over siblings or mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_form_8k_material_eventsARetrieve SEC Form 8-K material event filings — M&A, executive changes, bankruptcy, earnings, going concerns. Replaces an 8-K Push subscription. Real-time material event monitoring for any public company.
Args: ticker: Optional ticker filter event_type: Optional 8-K item filter (e.g. "1.01", "2.01", "5.02") days_back: Lookback window in days (default 14)
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | ||
| days_back | No | ||
| event_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, confirming a safe read operation with possibly open-world results. The description adds 'Real-time material event monitoring' but does not elaborate on data freshness, update frequency, consistency guarantees, or any side effects. 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?
The description is concise: one sentence for purpose, one for value proposition, and a structured Args list. No excessive text; front-loaded with the core verb 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 retrieval tool with 3 optional parameters and no output schema, the description covers purpose, parameters, and real-time aspect. Output format is not described, which is a gap but acceptable given lack of output schema. Overall adequately complete.
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 0%, so the description carries the full burden. It explains each parameter: ticker (optional filter), event_type (with example values like '1.01', '2.01', '5.02'), and days_back (lookback window, default 14). This adds meaningful context beyond the schema's type/defaults.
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 states 'Retrieve SEC Form 8-K material event filings' with specific event types (M&A, executive changes, bankruptcy, earnings, going concerns). It clearly distinguishes from sibling tools like get_form_13f_holdings and get_form_4_insider_trades, making its unique purpose immediately obvious.
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 8-K monitoring ('Replaces an 8-K Push subscription', 'Real-time material event monitoring') but lacks explicit guidance on when to use this tool versus alternative form tools (e.g., get_form_13f_holdings). No when-not-to-use or prerequisite conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_form_d_private_fundingARetrieve SEC Form D private offerings — private rounds, hedge fund launches, exempt securities filings. VC and private equity intel for tracking who's raising and how much.
Args: state: Optional state filter (e.g. "CA", "NY") — passed as a query keyword days_back: Lookback window in days (default 30) min_amount: Optional minimum offering amount filter (post-filtered)
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| days_back | No | ||
| min_amount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that results are 'private offerings' but does not elaborate on behavior like pagination, error handling, or rate limits. It does not contradict 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?
Two concise paragraphs: purpose with examples, then args list. Front-loaded with clear action and examples. 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?
Given the tool's simplicity (3 params, no output schema), the description covers purpose, examples, and parameter details. Missing output format or error behavior, but adequate for a read-only query 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 0%, so the description must compensate. It explains each parameter: state as a query keyword, days_back as a lookback window, min_amount as a post-filter. The 'post-filtered' note adds value, though slightly ambiguous. Overall, provides 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 uses a specific verb ('Retrieve') and clearly identifies the resource ('SEC Form D private offerings'). It provides examples (private rounds, hedge fund launches) and distinguishes it from sibling financial data 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 context ('VC and private equity intel') which implies usage, but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ipo_calendarARetrieve upcoming IPO calendar — pricing date, shares offered, price range, lead underwriters.
Args: days_forward: Calendar horizon in days (default 30) — passed via the upstream date_range enum
| Name | Required | Description | Default |
|---|---|---|---|
| days_forward | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the tool is safe to invoke. The description adds that it returns specific IPO calendar fields, but does not disclose rate limits, authentication requirements, or any other behavioral traits beyond what annotations provide.
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 brief: one sentence describing the tool's purpose and one line for the parameter. It is front-loaded and contains no filler. Every part 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?
For a simple tool with one parameter and no output schema, the description adequately explains the tool's purpose and the parameter's meaning. It also lists the key return fields (pricing date, shares offered, etc.), though it lacks details on potential limitations or data scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds an explanation for the 'days_forward' parameter: it is a calendar horizon in days with a default of 30, and mentions an 'upstream date_range enum'. This adds semantic meaning beyond the raw schema, though it remains somewhat ambiguous.
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 'Retrieve' and resource 'upcoming IPO calendar', listing specific data points (pricing date, shares offered, price range, lead underwriters). This distinguishes it from sibling tools which focus on other financial events (earnings, insider trades, 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 provides no guidance on when to use this tool versus alternatives like get_earnings_calendar. No exclusion criteria or prerequisites are mentioned, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_options_unusual_activityARetrieve unusual options activity — volume vs open-interest spikes, large block trades, suspected smart-money positioning.
Args: ticker: Optional ticker filter min_volume_ratio: Minimum volume / open-interest ratio (default 2.0)
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | ||
| min_volume_ratio | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds retrieval of unusual activity patterns and parameter options, but does not disclose additional behavioral traits such as data freshness, pagination, or response structure. With annotations present, the description provides marginal extra 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?
The description is front-loaded with the purpose and uses a clear Args section. Each sentence contributes necessary information without redundancy, making it efficient and easy to parse.
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 optional params, no output schema), the description covers the core functionality and parameter details. It lacks mention of return format or data structure, but this is acceptable given the absence of an output schema. Overall, it provides sufficient context for a minimal viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description's brief parameter explanations (ticker as optional filter, min_volume_ratio as minimum volume/oi ratio with default 2.0) add meaningful semantics beyond the schema alone. While concise, they adequately explain each parameter's role.
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 'Retrieve unusual options activity' and provides specific examples (volume vs open-interest spikes, large block trades, suspected smart-money positioning), which defines the tool's purpose distinctly from siblings like detect_insider_cluster or get_short_interest.
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 unusual options activity but does not explicitly state when to use this tool versus alternatives like get_short_interest or get_form_4_insider_trades. No exclusions or alternative mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pre_ipo_secondaryARetrieve pre-IPO secondary market valuations — Forge, EquityZen, Hiive prices for SpaceX, Stripe, OpenAI tier names.
Args: company: Optional company name filter (e.g. "SpaceX", "Stripe")
| Name | Required | Description | Default |
|---|---|---|---|
| company | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's statement about 'retrieving valuations' is consistent and adds specific context about data sources (Forge, EquityZen, Hiive) and example companies. This adds value beyond annotations without 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?
The description is extremely concise—one sentence for purpose plus a brief parameter explanation. It is front-loaded with the main action and avoids extraneous details. Every sentence is necessary and sufficient.
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 retrieval tool with one optional parameter and no output schema, the description adequately covers the purpose, the single parameter, and provides context (marketplaces, example companies). It does not describe the output format, but given the openWorldHint, this is acceptable. A small gap exists in not specifying what exactly the valuations include.
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 0% (no description in schema for the parameter 'company'). The description compensates by explaining it as an optional company name filter with concrete examples (SpaceX, Stripe). This fully clarifies the parameter's meaning and usage.
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 retrieves pre-IPO secondary market valuations, specifying marketplaces (Forge, EquityZen, Hiive) and example companies (SpaceX, Stripe, OpenAI). This is a specific verb+resource that distinguishes it from sibling tools like get_13f_delta or get_form_4_insider_trades, which cover different domains.
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 does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for pre-IPO valuation data with an optional company filter, but lacks 'when not to use' or references to sibling tools. Given the clear domain, it earns a baseline 'adequate' score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_schedule_13d_activistARetrieve SEC Schedule 13D / 13G activist & beneficial-ownership filings (>5% stake). Track Carl Icahn, Elliott Management, Pershing Square, Trian moves — the activist signal.
Args: target_ticker: Optional ticker of target company filer: Optional activist filer name (post-filtered) days_back: Lookback window in days (default 90)
| Name | Required | Description | Default |
|---|---|---|---|
| filer | No | ||
| days_back | No | ||
| target_ticker | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds no additional behavioral context. It does not mention data freshness, pagination, rate limits, or any side effects beyond the read-only nature.
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 concise, front-loaded with the main purpose, and follows a clear structure: purpose statement, example use, then parameter list. No extraneous text.
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 explains the tool's function and parameters but omits the output structure (e.g., fields in each filing) and whether results are paginated. Given the absence of an output schema, more detail would improve completeness.
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?
Despite schema having no descriptions, the description includes an 'Args' section explaining each parameter (target_ticker, filer, days_back) with defaults. This adds meaning beyond the raw schema, though 'post-filtered' is vague.
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 it retrieves SEC Schedule 13D/13G activist filings, with a specific threshold (>5% stake). It distinguishes from siblings like get_form_13f_holdings (institutional holdings) and get_form_4_insider_trades (insider trades) by focusing on activist ownership filings.
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 tracking activist investors (e.g., Carl Icahn) but lacks explicit guidance on when to use this tool versus alternatives like get_form_13f_holdings or get_13f_delta. No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_short_interestARetrieve short interest data — short ratio, days-to-cover, % of float short, changes vs prior period.
Args: ticker: Optional ticker filter days_back: Informational; actor returns latest reported short interest snapshot
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | ||
| days_back | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so safety is clear. The description adds behavioral context: returns latest snapshot, days_back is informational, and includes changes vs prior period. This goes beyond annotations, though no mention of rate limits or authentication is needed given read-only nature.
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 concise, front-loading the purpose, and uses a clear args list. It avoids verbosity, though the args section could be slightly more integrated. 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?
For a read-only tool with two parameters and no output schema, the description covers key aspects: data returned, parameter meanings, and behavioral trait (latest snapshot). Minor gaps exist (e.g., default behavior when ticker is empty), but overall complete enough.
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 0%, so the description compensates by explaining ticker as an optional filter and days_back as informational (does not affect result). This provides meaningful guidance beyond schema, though formatting details are absent.
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 retrieves short interest data and lists specific metrics (short ratio, days-to-cover, etc.), with a clear verb-resource pair. It is distinct from sibling tools, which deal with insider trades, filings, and other financial data.
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 obtaining short interest data but does not explicitly state when to use it versus alternatives or any prerequisites. No exclusions or when-not-to-use guidance is provided, though siblings are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stock_splits_corporate_actionsARetrieve upcoming stock splits, spinoffs, mergers, special dividends, and other corporate actions.
Args: days_forward: Calendar horizon in days (default 60)
| Name | Required | Description | Default |
|---|---|---|---|
| days_forward | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description's 'Retrieve upcoming' is consistent with the readOnlyHint annotation. It adds minimal behavioral context beyond annotations, such as the 'upcoming' temporal scope. No additional traits like pagination or rate limits are disclosed.
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 succinct sentences for the main functionality and a clear one-line parameter description. Every part is necessary and front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without output schema, the description adequately covers what the tool does and the parameter. However, it could be more complete by mentioning result ordering, coverage scope, or data freshness, but it is minimally sufficient.
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 0% schema description coverage, the description fully compensates by explaining 'days_forward' as 'Calendar horizon in days (default 60),' adding semantic meaning that the schema alone (type and default) does not provide.
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 retrieves 'upcoming stock splits, spinoffs, mergers, special dividends, and other corporate actions,' providing a specific verb and resource. It distinguishes from sibling tools like get_dividend_aristocrats and get_earnings_calendar by focusing on corporate actions.
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 getting corporate actions but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. Usage is implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_swf_holdingsARetrieve sovereign wealth fund (SWF) US equity holdings — Norway GPFG, GIC Singapore, ADIA, PIF. Tracks position changes for the world's largest state-backed investors.
Args: fund: Optional SWF name filter (e.g. "Norway", "GIC", "ADIA") quarter: Informational; the actor returns the most recently reported quarter per fund.
| Name | Required | Description | Default |
|---|---|---|---|
| fund | No | ||
| quarter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful context: it is for state-backed investors, tracks position changes, and quarter parameter returns most recent quarter per fund. No contradictions 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: first sentence states purpose with examples, second adds context, third details parameters. No wasted words, front-loaded with key 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?
No output schema exists, so description should document return structure. It mentions retrieving holdings and tracking changes, but does not specify return fields, format, or pagination. For a retrieval tool, this is incomplete.
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 0%, so description must compensate. It explains 'fund' is an optional SWF name filter with examples, and 'quarter' is informational returning the most recent quarter. This adds meaning beyond the bare schema, though acceptable values for fund could be more exhaustive.
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 'retrieve' and the resource 'sovereign wealth fund (SWF) US equity holdings', listing specific funds (Norway GPFG, GIC Singapore, ADIA, PIF). It distinguishes itself from sibling tools that deal with other financial data types like insider trades or 13F filings.
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 mentions optional parameters and explains the quarter parameter is informational, but does not provide explicit guidance on when to use this tool versus alternatives like get_form_13f_holdings. No when-not-to-use or alternative tool comparisons are given.
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!