Read-only value-investing fund, holdings, financial, options, and insider research.
Aligned 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 declare readOnly, idempotent, and non-destructive. The description adds the access requirement 'Requires FolioFact Pro', which is valuable behavioral context beyond the annotations. It also clarifies the scope of the comparison, but doesn't elaborate on return behavior beyond what the output schema covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core purpose, lists specific comparison dimensions, and ends with the Pro requirement. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the presence of a rich output schema, and comprehensive annotations, the description is complete. It covers what the tool does, what data it compares, and a key prerequisite. There is no need to explain return values or parameter formats as those are already in 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific details; it only references categories (e.g., valuation, insider activity) that map loosely to the schema but provide no extra semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Aligned multi-stock comparison' with specific data categories (valuation, financial point, fund conviction, insider activity). The title 'Compare stocks side by side' reinforces the verb and resource, distinguishing it from single-stock tools like get_stock or stock_financials.
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 it through 'multi-stock comparison', which sets it apart from single-stock tools. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches 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.
Quarter-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.
A 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 establish that the operation is read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds 'current' and 'quarter-over-quarter change' as return-content context, but it does not disclose how the change is calculated, data lag, or any other behavioral nuance.
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 short sentence conveys the resource, time scope, and comparison metric with no filler. The key phrase 'current portfolio positions' 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?
For a single-parameter tool with an output schema and comprehensive annotations, this description is sufficient. It identifies the input type, the output concept, and the notable quarter-over-quarter change, leaving no critical ambiguity for invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: slug is already described as a fund URL identifier. The tool description reinforces that the input is a fund but adds no extra parameter semantics, so the 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 states exactly what the tool returns: a fund's current portfolio positions plus quarter-over-quarter change. It is semantically distinct from siblings like fund_history, but it does not explicitly name or contrast them.
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 word 'current' implies this tool is for the latest holdings snapshot rather than historical analysis, so some usage context is present. There is no explicit statement of when to prefer another sibling such as fund_history or get_fund, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One 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.
One 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.
One 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.
Recent 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.
Bounded 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.
The latest cited AI Earnings Report for one stock (or a stable period with period). 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 (always returned to Pro callers). |
| 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 behavior. The description adds meaningful context beyond that by disclosing the FolioFact Pro requirement and clarifying that the report is the latest cited one unless a stable period slug is supplied. This is useful behavioral information for an agent deciding whether it can invoke the tool.
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 with no filler. The core purpose is front-loaded, and the access requirement is stated separately and clearly. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with full schema coverage, annotations, and an output schema, the description is nearly complete. It covers purpose, scope, and an access restriction. The only gap is that it does not help an agent choose between this and closely related siblings like stock_financials, though the AI Earnings Report naming makes that distinction reasonably inferable.
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 already documents all three parameters and their exact meanings, so schema_description_coverage is 100%. The description adds a little extra framing by mentioning 'one stock' and the stable-period use of `period`, but it does not materially supplement the schema's parameter documentation.
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 clear resource and action: retrieving the latest cited AI Earnings Report for a single stock, with an optional stable period. It also names a required access condition (FolioFact Pro). It does not explicitly differentiate this from sibling tools like stock_financials or compare_stocks, so it stops short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use it for one stock or a stable period, and only with FolioFact Pro. It does not explicitly state when not to use it or point to alternatives such as compare_stocks for multi-stock comparisons, but the intended scope is apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Financial 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?
Annotations already declare the tool as read-only and idempotent, so safety is covered. The description adds valuable context by disclosing the FolioFact Pro requirement and specifying the exact data returned (enterprise value, FCF/EV, OCF/EV yields), which goes beyond the annotations and helps the agent judge suitability.
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 front-loads the core content (financial statements and valuation summary) and then notes the access requirement. Every phrase earns its place with no redundancy or fluff.
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), rich annotations (read-only, idempotent), presence of an output schema, and a description that lists both the data types and the Pro requirement, the description is fully sufficient for an agent to select and invoke the tool correctly. The output schema explains return values, so the description need not elaborate.
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 already covers 100% of parameter descriptions (ticker with 'dots allowed'). The description adds no additional parameter information, but since schema coverage is high, the baseline of 3 applies. The description's mention of data scope (yearly/quarterly) provides some contextual link to what the ticker parameter retrieves, but no new semantic detail.
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's function: providing financial statements (yearly and quarterly) and valuation summary metrics. This distinguishes it from sibling tools like stock_earnings (earnings data) and get_stock (basic stock info), making the purpose 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 implies usage when one needs financial statements or valuation metrics, but it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. The mention of 'Requires FolioFact Pro' is a prerequisite, not a usage guideline. No explicit alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent 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.
Daily 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
fund_holdings2 fields changedOutput schema / properties / holdings / items / properties / position_typeAdded value: +{
+ "enum": [
+ "direct",
+ "call",
+ "put"
+ ],
+ "type": "string"
+}Output schema / properties / holdings / items / requiredPrevious value: -[
- "security",
- "shares",
- "value",
- "percent_of_fund",
- "change",
- "change_percent"
-]New value: +[
+ "security",
+ "position_type",
+ "shares",
+ "value",
+ "percent_of_fund",
+ "change",
+ "change_percent"
+]stock_earnings1 field changedInput schema / properties / include_full / descriptionPrevious value: -"Request full Pro analysis. Defaults to true for Pro callers and false otherwise."New value: +"Request full Pro analysis (always returned to Pro callers)."compare_stocks3 fields changedOutput schema / properties / columns / items / properties / price_basis_kindAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "daily_close",
+ "intraday",
+ "implied_13f"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / columns / items / properties / valuation_observed_atAdded value: +{
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / columns / items / requiredPrevious value: -[
- "ticker",
- "name",
- "market_cap",
- "enterprise_value",
- "ocf_ev_yield",
- "fcf_ev_yield",
- "financial_point",
- "fund_summary",
- "insider_summary"
-]New value: +[
+ "ticker",
+ "name",
+ "market_cap",
+ "enterprise_value",
+ "ocf_ev_yield",
+ "fcf_ev_yield",
+ "price_basis_kind",
+ "valuation_observed_at",
+ "financial_point",
+ "fund_summary",
+ "insider_summary"
+]stock_financials5 fields changedOutput schema / properties / summary / properties / price / anyOfRemoved value: -[
- {
- "pattern": "^-?[0-9]+(?:\\.[0-9]+)?$",
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / summary / properties / price / typeAdded value: +"null"Output schema / properties / summary / properties / price_basis_kind / anyOfPrevious value: -[
- {
- "enum": [
- "daily_close",
- "implied_13f"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "daily_close",
+ "intraday",
+ "implied_13f"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / summary / properties / valuation_observed_atAdded value: +{
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / summary / requiredPrevious value: -[
- "market_cap",
- "enterprise_value",
- "fcf_ev_yield_ttm",
- "ocf_ev_yield_ttm",
- "fcf_ev_yield_year",
- "ocf_ev_yield_year",
- "price",
- "price_reported_on",
- "price_basis_kind",
- "valuation_label",
- "revenue_growth_quarter",
- "revenue_growth_year",
- "revenue_growth_three_year_cagr",
- "share_reduction_quarter",
- "share_reduction_year",
- "share_reduction_two_years",
- "share_reduction_three_years"
-]New value: +[
+ "market_cap",
+ "enterprise_value",
+ "fcf_ev_yield_ttm",
+ "ocf_ev_yield_ttm",
+ "fcf_ev_yield_year",
+ "ocf_ev_yield_year",
+ "price",
+ "price_reported_on",
+ "price_basis_kind",
+ "valuation_observed_at",
+ "valuation_label",
+ "revenue_growth_quarter",
+ "revenue_growth_year",
+ "revenue_growth_three_year_cagr",
+ "share_reduction_quarter",
+ "share_reduction_year",
+ "share_reduction_two_years",
+ "share_reduction_three_years"
+]compare_stocksget_stock2 fields changedOutput schema / properties / latest_earningsAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "period": {
+ "additionalProperties": false,
+ "properties": {
+ "end_on": {
+ "format": "date",
+ "type": "string"
+ },
+ "kind": {
+ "enum": [
+ "quarter",
+ "half_year",
+ "annual"
+ ],
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "label",
+ "kind",
+ "end_on"
+ ],
+ "type": "object"
+ },
+ "published_at": {
+ "format": "date-time",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "revision": {
+ "type": "integer"
+ },
+ "teaser": {
+ "additionalProperties": false,
+ "properties": {
+ "headline": {
+ "type": "string"
+ },
+ "highlights": {
+ "items": {
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 3,
+ "type": "array"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "headline",
+ "summary",
+ "highlights"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "period",
+ "revision",
+ "published_at",
+ "teaser"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / requiredPrevious value: -[
- "ticker",
- "name",
- "total_value",
- "single_class",
- "positions",
- "provenance"
-]New value: +[
+ "ticker",
+ "name",
+ "total_value",
+ "single_class",
+ "latest_earnings",
+ "positions",
+ "provenance"
+]stock_earningsstock_financialsstock_insidersstock_optionsfetch_pagefund_historyfund_holdingsget_fundget_investorget_stockinsider_feedsearchClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Indian NSE/BSE research data and mechanically-computed ratios; read-only market tools.
SEC filings, insider trades, and earnings data
Hosted SEC EDGAR filings: Form 4 insider trades, 8-K events, S-1/IPO registrations. Read-only.
Intrinsic stock value from SEC filings: DCF, EPV, Graham, moat signals. Deterministic, not guessed.
Add one secure layer between your agents and this server.
Most tools have clearly distinct scopes: fund tools cover funds, stock_* tools cover single-stock analytics, and get_stock covers holder positions. Minor overlap exists between compare_stocks and the individual stock/fund/insider tools, and insider_feed versus stock_insiders could require careful reading, but the descriptions are generally sufficient to avoid misselection.
Naming is readable and consistently snake_case, but conventions are mixed: get_* for entity lookups, fund_* for fund data, stock_* for stock analytics, plus standalone names like compare_stocks, insider_feed, fetch_page, and search. This is not chaotic, but it lacks a single predictable verb_noun pattern.
Thirteen tools is well-scoped for a financial data server covering funds, investors, stocks, insider activity, options, search, and documentation access. Each tool earns its place, and the count is firmly within the reasonable range for this domain.
The surface covers core read-only workflows: fund research, investor discovery, stock fundamentals, earnings, options volatility, insider transactions, and cross-domain search. Minor gaps exist, such as no direct price/quote endpoint and no option chain data, but agents can accomplish the apparent intended tasks without dead ends.
