Read-only value-investing fund, holdings, financial, options, and insider research.
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 3.9/5 across 8 of 8 tools scored.
Most tools target distinct resources (funds, stocks, investors, insider transactions, pages). Slight overlap between get_fund (latest filing + investors) and fund_history (filing history) could cause minor confusion, but descriptions clarify the difference.
Tool names mix styles: some use verb_noun (get_fund, fetch_page), some are noun phrases (fund_history, fund_holdings), and one is a bare verb (search). No consistent pattern or prefix.
Eight tools is a well-scoped set for a financial data API, covering funds, holdings, investors, stocks, insider transactions, and site content without redundancy or bloat.
The surface covers the core lifecycle for a read-only investment data API: fund details, historical filings, current holdings, investor links, stock holders, insider feed, and cross-domain search. No obvious dead ends or missing operations for the stated domain.
compare_stocksCompare stocks side by sideAAligned multi-stock comparison: valuation, latest financial point, fund conviction, and insider activity. Requires FolioFact Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | Comma-separated tickers (2–6, dots allowed). | |
| insider_window | No | Insider activity window. |
| Name | Required | Description |
|---|---|---|
| columns | Yes | |
| tickers | Yes | |
| provenance | Yes | |
| insider_window | Yes | |
| unknown_tickers | Yes | |
| submitted_tickers | Yes | |
| insider_window_label | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the description only needs to add extra context. It adds the significant requirement 'Requires FolioFact Pro' and notes the 'Aligned' presentation style, which goes beyond the annotated safety profile.
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: two tight sentences. The first sentence front-loads the action and scope, while the second sentence states the key requirement. 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 modest complexity, full parameter descriptions in the schema, rich annotations, and an output schema, the description sufficiently covers purpose, scope, and the critical Pro requirement. No major gaps remain.
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 100% description coverage, clearly defining tickers and insider_window with examples and enums. The description lists comparison categories that relate to the parameters but doesn't add new parameter-specific details, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an 'Aligned multi-stock comparison' and lists specific dimensions (valuation, latest financial point, fund conviction, insider activity), distinguishing it from single-stock tools like get_stock and specialized tools like stock_insiders. It uses a specific verb and resource.
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 conveys when to use this tool: for multi-stock comparison across the listed dimensions. It does not explicitly mention alternatives or exclusions, but the context is clear. The note 'Requires FolioFact Pro' adds a prerequisite, which is useful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_pageFetch a public pageAFetches an allowlisted public page as markdown/text: published blog posts (/blog/:slug), static pages (e.g. /agents, /api-docs, /about), and the agent discovery doc (/llms.txt).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Public path, e.g. /blog/how-to-read-a-13f-without-overreading-it, /agents, or /llms.txt. |
| Name | Required | Description |
|---|---|---|
| path | Yes | |
| text | Yes | |
| title | No | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the 'allowlisted' constraint and the output format (markdown/text), providing useful behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence that front-loads the purpose and lists examples. No unnecessary words or repetition.
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 1-parameter schema, strong annotations, and output schema, the description covers the tool's scope, constraints, and output format sufficiently. It is complete for a simple fetch 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?
The schema fully documents the single 'path' parameter with examples. The description also lists path patterns like /blog/:slug, but this largely overlaps with the schema. Since schema coverage is 100%, the description adds marginal value 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 the tool fetches public pages, specifies the output format (markdown/text), and enumerates the types of allowlisted pages (blog posts, static pages, /llms.txt). This distinguishes it from the finance-focused sibling 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 implies usage by enumerating specific page types and the 'allowlisted' constraint, which tells the agent when this tool is appropriate. It does not explicitly list alternatives or exclusions, but the scope is clear and distinct from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fund_historyFund filing historyAQuarter-by-quarter filing history and a summary (turnover, concentration, favorites).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Fund slug (URL identifier). |
| Name | Required | Description |
|---|---|---|
| fund | Yes | |
| summary | Yes | |
| quarters | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety and side-effect profile. The description adds useful context about the data granularity (quarter-by-quarter) and summary metrics, but does not disclose additional behavioral traits such as authentication requirements or potential limitations. 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?
The description is a single, concise sentence that conveys the core content efficiently. No redundant phrases or irrelevant details are present, and it is front-loaded with the primary purpose.
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 one-parameter schema, rich annotations, and presence of an output schema, the description is complete enough. It provides the key information needed to understand the tool's role without needing to elaborate on return formats or parameters, which are covered by structured fields.
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 100% description coverage for the single 'slug' parameter, explicitly defining it as 'Fund slug (URL identifier).' The description does not add any parameter detail, but the schema fully compensates, so a baseline of 3 is appropriate.
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 specifies the resource ('fund filing history') and the content ('quarter-by-quarter history' with 'turnover, concentration, favorites'). This distinguishes it from sibling tools like fund_holdings and get_fund, which focus on different aspects. The verb is implied but the scope is unambiguous.
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 usage context is implied: use this when you need a fund's filing history and summary metrics. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions. Sibling tools like fund_holdings exist, but no differentiation guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fund_holdingsFund portfolio holdingsBA fund's current portfolio positions with quarter-over-quarter change.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Fund slug (URL identifier). |
| Name | Required | Description |
|---|---|---|
| fund | Yes | |
| quarter | Yes | |
| holdings | Yes | |
| provenance | Yes | |
| total_value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds context that the output includes quarter-over-quarter change, but it does not disclose data freshness, limitations, or edge cases. This is acceptable but not rich 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?
The description is a single, compact sentence that directly states the tool's purpose and key differentiator. There is no redundant or filler content, making it highly scannable 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?
Given the tool has one well-specified parameter, strong safety annotations, and an output schema, the description is largely complete for its simplicity. However, it omits any cross-referencing to sibling tools or usage context, which would elevate it further.
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 sole parameter 'slug' is fully described in the input schema as 'Fund slug (URL identifier).' with 100% coverage. The tool description adds no additional parameter context, but the schema already provides sufficient meaning, so baseline 3 applies.
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 identifies the resource as a fund's current portfolio positions and adds the differentiator of quarter-over-quarter change, distinguishing it from siblings like fund_history. The verb is implicit (retrieve/list) but the meaning is unambiguous.
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 is provided on when to use this tool versus alternatives such as fund_history, get_fund, or search. There are no explicit exclusions, prerequisites, or context hints, so the agent must infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fundGet a tracked fundBOne fund's latest filing and its investors.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Fund slug (URL identifier). |
| Name | Required | Description |
|---|---|---|
| fund | Yes | |
| filing | Yes | |
| investors | Yes | |
| portfolio | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that the tool returns 'latest filing and its investors,' which is useful context, but it does not disclose any additional behavior such as pagination, rate limits, or relationship to other resources.
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 a single, short phrase with no filler or redundant information. Every word contributes to specifying what the tool returns, making it highly concise 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?
For a simple single-parameter retrieval tool with an output schema and strong annotations, the description is largely sufficient. It clearly states the core return data, but it could be slightly more complete by explaining what constitutes 'latest filing' or what investor details are included, though the output schema likely covers these.
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%: the single parameter 'slug' is fully described with examples and a clear definition. The description adds no extra parameter meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
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 'One fund's latest filing and its investors' clearly identifies the resource and what data is returned, distinguishing it from sibling tools like fund_history and fund_holdings. However, it lacks a explicit verb (e.g., 'retrieves'), relying on the title and name for the action.
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. Sibling tools such as fund_history and fund_holdings likely overlap in functionality, but no comparison or exclusions are mentioned. The only implied usage is that this tool focuses on a single fund's latest filing and investors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_investorGet an investorAOne investor's portfolio links (funds they run or back) and featured fund.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Investor slug (URL identifier). |
| Name | Required | Description |
|---|---|---|
| investor | Yes | |
| portfolios | Yes | |
| provenance | Yes | |
| featured_fund | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety coverage is well established. The description adds the specific return subjects (portfolio links, featured fund) but does not disclose additional behavioral traits such as error handling, ordering, or authorization requirements.
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 a single, tightly written sentence that conveys the essential output of the tool without repetition. It is front-loaded with the resource type and adds clarifying parenthetical detail, earning its place with minimal 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 (one required parameter, strong annotations, and an existing output schema), the description is sufficient for an agent to understand what the tool does. It could be slightly more explicit about the scope (e.g., 'by slug'), but that is already captured by the schema.
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 100% coverage for the single 'slug' parameter, including examples and a description of it as an 'Investor slug (URL identifier).' The tool description adds no further parameter-level meaning, so the schema itself carries the full semantic weight.
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 identifies the resource (an investor) and the specific payload (portfolio links and featured fund), distinguishing it from sibling tools like get_fund and get_stock. However, it is phrased as a noun phrase rather than a clear imperative verb like 'Returns' or 'Lists,' relying on the title for the verb.
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?
Usage context is implied: the description indicates this tool provides a single investor's portfolio links and featured fund, so an agent can infer it is for investor-specific lookups. It does not explicitly contrast with alternatives or state when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stockGet a held stockAOne company as held by tracked funds: holders, values, and last-quarter moves.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker (dots allowed, e.g. BRK.A). |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| ticker | Yes | |
| positions | Yes | |
| provenance | Yes | |
| total_value | Yes | |
| single_class | Yes | |
| latest_earnings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to cover safety. The description adds useful context about the response content (holders, values, moves), but doesn't disclose additional behavioral traits like rate limits or permissions. This is adequate given 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence fragment that packs all essential information: the resource (one company), the context (held by tracked funds), and the data returned (holders, values, moves). No wasted words, and it is front-loaded with the core subject.
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 only one parameter, full schema coverage, an output schema present, and strong annotations, the description is sufficient for an agent to select and invoke the tool. It clearly conveys the tool's scope without needing to explain return values, since the output schema handles that.
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 covers the single parameter 'ticker' with a clear description and examples, providing 100% coverage. The description does not add any additional parameter semantics, so a baseline score of 3 is appropriate.
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 identifies the tool as returning information about a single company as held by tracked funds, specifying the data areas (holders, values, last-quarter moves). This distinguishes it from sibling tools like compare_stocks or fund_holdings, making its purpose unambiguous.
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 usage context is implied through the phrase 'as held by tracked funds' and the data fields listed, but there is no explicit guidance on when to choose this over alternatives like compare_stocks or stock_financials. The tool would benefit from stating exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
insider_feedInsider transaction feedARecent Form 4/5 insider transactions across all held stocks, newest first. Filterable by transaction type and owner. Page 2+ requires FolioFact Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Owner name query. | |
| dir | No | Sort direction. | |
| page | No | Page number (deep pages require Pro). | |
| sort | No | Sort column. | |
| filter | No | Transaction type filter. | |
| per_page | No | Rows per page. |
| Name | Required | Description |
|---|---|---|
| dir | Yes | |
| sort | Yes | |
| query | Yes | |
| filter | Yes | |
| pagination | Yes | |
| provenance | Yes | |
| coverage_on | Yes | |
| transactions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive; the description adds valuable context such as default ordering ('newest first'), the pagination paywall ('Page 2+ requires FolioFact Pro'), and the universe of stocks ('all held stocks'). These go beyond the structured annotations to inform the agent of constraints.
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-loads the primary purpose, and includes only high-value constraints (newest first, Pro requirement, filterability). Every phrase earns its place with no fluff or repetition.
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 moderate complexity (6 optional parameters), strong annotations, and an existing output schema, the description covers the core semantics, scope, ordering, filtering, and a key limitation (Pro paywall). The output schema handles return value details, so the description is sufficient for an agent to select and invoke this tool 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 coverage is 100%, so the baseline is 3. The description reinforces that the tool is filterable by transaction type and owner, which maps to parameters, and its pagination note aligns with the 'page' parameter already explained in the schema. However, it adds no new parameter-level detail beyond what the schema provides.
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 a specific resource ('Form 4/5 insider transactions') and action/scope ('across all held stocks, newest first'), which clearly distinguishes it from sibling tools like fund_holdings or get_stock. It also mentions filterability, making the tool's function unmistakable.
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 clear context for when to use the tool (viewing recent insider transactions for held stocks) and implicitly excludes other uses by naming its specific scope. It does not explicitly name alternatives or when-not-to-use, but the domain is sufficiently distinct from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch funds, stocks, and insidersABounded cross-domain search: funds by name, stocks by ticker/name, and insider transactions by owner. The same scopes the web search uses. A blank or missing query returns empty buckets, mirroring GET /api/v1/search.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search query (fund names, tickers, insider names). |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable behavioral details: blank/missing queries return empty buckets, and the search scopes mirror web search. This goes beyond annotations without contradicting them. It does not describe pagination or sorting, but those are likely in the output schema.
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, immediately stating the tool's purpose and scope, followed by a concise edge-case behavior. No redundant information or filler; every sentence adds value. The structure is front-loaded and easy to scan.
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 an output schema present, return values need not be described. The description covers scope, matching criteria, and blank-query behavior. For a bounded search tool, this is largely complete. It might ideally mention result count or pagination, but those are likely in the output schema. Overall, the description is sufficient for an agent to invoke the tool 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 coverage is 100%, with the 'query' parameter already described as 'Search query (fund names, tickers, insider names).' The description reinforces this by listing matching fields but does not add significant new parameter-level semantics. The blank-query behavior is useful but is more behavioral than parameter semantics. Baseline of 3 is appropriate given full schema coverage.
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 identifies the tool as a cross-domain search covering funds, stocks, and insiders, with specific fields (name, ticker/name, owner). This distinguishes it from sibling getters like get_fund, get_stock, and get_investor, which target single entities. The phrase 'Bounded cross-domain search' further clarifies its scope.
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 when to use this tool: when searching across domains by name/ticker/owner, rather than retrieving a specific known entity via sibling tools. It does not explicitly name alternatives or state when not to use it, but the cross-domain scope and reference to web search scopes provide clear situational context. A minor gap is the absence of explicit exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stock_earningsStock earnings analysisAThe latest cited earnings report for one stock. Teasers are public. Set include_full=true for the complete evidence-linked report; that content requires FolioFact Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Optional stable report slug, for example 2026-03-31-quarter. | |
| ticker | Yes | Stock ticker (dots allowed). | |
| include_full | No | Request full Pro analysis. Defaults to true for Pro callers and false otherwise. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| access | Yes | |
| report | Yes | |
| ticker | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds valuable behavioral context: teasers are public, full content requires FolioFact Pro, and the report is 'evidence-linked.' This goes beyond the annotations by clarifying access levels and content characteristics.
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 primary purpose, and every sentence contributes useful information. It avoids redundancy with the schema and annotations.
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, output schema present, read-only annotations), the description covers the essential behavior: fetching a single earnings report, teaser vs. Pro full version, and the access requirement. It does not explain 'period' in detail, but the schema covers that, and the description is adequate for an agent to decide whether to invoke it.
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 already has 100% parameter documentation, so the baseline is 3. The description adds meaningful semantics for 'include_full' by explaining that it provides the 'complete evidence-linked report' and that this requires Pro access. This clarifies the difference between teaser and full content, which is not fully explicit in the schema alone.
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 'the latest cited earnings report for one stock,' which is specific about the resource (earnings report) and scope (one stock). It does not explicitly distinguish it from sibling tools like 'stock_financials' or 'get_stock,' but the focus on 'earnings' is clear enough to infer its primary use.
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 implicit usage context: it is for fetching earnings reports, with teasers publicly accessible and full reports requiring Pro. However, it does not explicitly guide when to choose this tool over alternatives such as 'stock_financials' or 'compare_stocks.' The conditional about 'include_full=true' is more about output depth than tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stock_financialsStock financial statements and valuationAFinancial statements (yearly and quarterly) and the valuation summary (enterprise value, FCF/EV and OCF/EV yields). Requires FolioFact Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker (dots allowed). |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| series | Yes | |
| ticker | Yes | |
| summary | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the FolioFact Pro requirement, which is not present in the annotations, and lists specific data returned (e.g., FCF/EV and OCF/EV yields). This adds meaningful behavioral context beyond the readOnly and idempotent hints without contradicting them.
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 a single, well-structured sentence that concisely covers the tool's output and access requirement. Every phrase adds value, with no redundancy or filler.
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 one parameter, an output schema, and clear annotations, the description sufficiently explains what the tool returns and its access requirement. No critical selection or invocation information is missing.
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 fully documents the single ticker parameter with its description, so the baseline is 3. The description does not add any additional parameter-level semantics beyond what the schema already provides.
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 provides financial statements (yearly and quarterly) and a valuation summary including enterprise value, FCF/EV, and OCF/EV yields. This specific and distinct scope differentiates it from sibling tools like stock_earnings and stock_options.
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 when financial statements or valuation data are needed, but does not explicitly state when to use this tool versus alternatives. The noted 'Requires FolioFact Pro' is a prerequisite, not a use-case guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stock_insidersStock insider transactionsARecent Form 4/5 insider transactions for one company. Requires FolioFact Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker (dots allowed). |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| ticker | Yes | |
| provenance | Yes | |
| coverage_on | Yes | |
| transactions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat these. It adds valuable context by stating 'Requires FolioFact Pro' (an access restriction) and specifying 'Form 4/5' (the exact regulatory filing type). This goes beyond the structured fields without contradicting them, earning a 4.
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 short sentences: 'Recent Form 4/5 insider transactions for one company. Requires FolioFact Pro.' Every piece of information (content type, scope, access requirement) earns its place. It is front-loaded and free of any irrelevant detail, making it highly concise 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's simplicity (one parameter, output schema present, annotations cover safety), the description is largely complete. It states the data type (Form 4/5), the granularity (one company), and a key prerequisite (Pro subscription). Minor details like how 'recent' is defined or pagination are not mentioned, but the output schema likely covers return structure. Overall, it provides sufficient context for a straightforward 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?
The input schema provides 100% coverage for the single parameter 'ticker' with a description ('Stock ticker (dots allowed).'). The description adds no additional parameter semantics or examples. With full schema coverage, the baseline is 3, and there is nothing extra to justify a higher 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 the tool's function: 'Recent Form 4/5 insider transactions for one company.' It uses a specific verb ('transactions') and resource ('insider transactions'), and explicitly limits scope to 'one company,' distinguishing it from broader tools like insider_feed. This is a precise and unambiguous purpose statement.
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 context (single company vs. a feed) but does not explicitly mention alternatives or when not to use this tool. The phrase 'for one company' suggests it is for a single ticker, but no exclusions or sibling tool comparisons are provided. This is clear context without explicit guidance, so a 3 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stock_optionsStock options-market snapshotADaily 30-day implied volatility history for one company. Requires FolioFact Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker (dots allowed). |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| stale | Yes | |
| latest | Yes | |
| ticker | Yes | |
| history | Yes | |
| provenance | Yes | |
| expected_reading_date | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent behavior, so the description adds value by disclosing the FolioFact Pro subscription requirement and the specific daily 30-day history scope. No contradictions with annotations; the tool is read-only and the description reinforces that.
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?
One sentence, front-loaded with the core purpose and immediately followed by the critical access requirement. Every word earns its place; no redundancy or unnecessary detail.
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 tool has rich annotations, a simple one-parameter schema, and an output schema, so the description does not need to explain return values. It covers the essential behavioral constraint (Pro requirement) and scope. Minor gap: does not mention that the data is historical series, but output schema likely covers this.
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% with the ticker parameter well described ('Stock ticker (dots allowed)'). The tool description adds 'for one company,' clarifying single-ticker usage, but does not introduce format details beyond what the schema already provides. Baseline 3 is appropriate.
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 identifies the resource (daily 30-day implied volatility history) and scope (one company), distinguishing it from siblings like stock_earnings or get_stock. It lacks an explicit verb but the noun phrase is specific and unambiguous.
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 'for one company,' implying single-stock usage, and 'Requires FolioFact Pro' sets a clear prerequisite. However, it does not explicitly state when to use this tool instead of alternatives or mention any exclusions, though sibling names suggest differentiation from general stock data tools.
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!