Read-only value-investing fund, holdings, financial, options, and insider research.
Scored across 13 tools
Most tools have clear boundaries: fund_* covers fund-specific data, stock_* covers single-stock metrics, and get_* returns entity snapshots. The closest pairs (stock_insiders vs insider_feed, get_fund vs fund_holdings, get_stock vs compare_stocks) differ by scope or aggregation, so an agent can generally tell them apart with the descriptions, though a couple require careful reading.
Names are readable and domain-prefixed, but conventions are mixed: get_fund/get_stock/get_investor use verb-object while fund_history/stock_* use noun-noun, with one-off verbs like compare_stocks, fetch_page, and search. This makes the set predictable within subgroups but not globally consistent.
13 tools is within the ideal range, and each tool covers a meaningful slice of fund, investor, stock, insider, or discovery functionality. No tool feels redundant or padding, and the count matches the breadth of a financial data server.
The server covers the core read-only lifecycle for the domain: fund profiles/history/holdings, investor links, stock-level financials/earnings/insiders/options, cross-domain search, and a global insider feed. Minor gaps exist—such as no bulk list-all endpoint for funds/stocks and no direct fund-to-fund comparison—but agents can work around them with search and the current tools.
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 the tool read-only, idempotent, and non-destructive. The description adds valuable context beyond those annotations: it notes the 'Requires FolioFact Pro' access constraint and describes the 'aligned' output arrangement, giving the agent useful behavioral expectations without contradicting any annotation.
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 front-loaded sentence that delivers the core message, lists the comparison scope compactly, and ends with the critical Pro requirement. There is no filler or redundant restatement of the title.
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 two-parameter schema, rich output schema, and safety annotations, the description covers the essential information: what is compared, how results are aligned, and a required entitlement. It leaves minor nuances like default insider_window values to the schema, which is acceptable here.
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 both parameters fully documented using examples and an enum, so the description doesn't need to re-explain them. The dimension list loosely maps to the kind of data returned, but it adds no extra meaning about how tickers or insider_window behave 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 opens with 'Aligned multi-stock comparison,' a specific verb-plus-resource phrase that clearly defines the tool's job. It lists concrete comparison dimensions (valuation, latest financial point, fund conviction, insider activity) and inherently distinguishes itself from single-stock sibling tools like get_stock, stock_financials, and stock_insiders.
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 emphasizing 'multi-stock comparison,' but it never explicitly states when to prefer this tool over single-stock alternatives or how to choose between related tools. There is no 'use when' guidance or named alternative, so the agent must infer the use case from context.
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 declare readOnly, idempotent, and non-destructive behavior. The description adds no behavioral details but is consistent with annotations, so the lower bar is met and no contradictions exist.
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 with no extraneous words. It efficiently conveys the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool and the presence of an output schema, the description is complete. It does not need to explain return values, and it provides enough context for callers.
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 single parameter 'slug' is described as 'Fund slug (URL identifier)', which is clear and covers the schema fully. Though minimal, it provides sufficient meaning for a unique identifier.
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 current portfolio positions with quarter-over-quarter change. It distinguishes from siblings like fund_history (historical data) and get_fund (general fund info) by focusing on holdings and their changes.
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 offers no explicit guidance on when to use this tool versus alternatives. It implies usage for current holdings but does not contrast with siblings or state conditions for selection.
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 | |
| listing | 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 carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), lowering the disclosure burden. The description adds useful context by scoping the data to 'tracked funds' and previewing the returned content, but it does not clarify semantics like how 'last-quarter moves' are computed or as-of what date the values are.
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 efficient line with the topic front-loaded before a colon-separated content list; there is zero filler. It loses a point for being a verbless fragment, which makes it slightly less self-contained as a description.
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 one-parameter, fully-annotated, read-only tool with an output schema present, the description covers the essentials: what entity it addresses and what data it returns. The remaining gaps — no sibling distinction from fund_holdings and no definition of 'last-quarter moves' — are real but minor for this simple 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%: the ticker parameter already includes a type, examples (AAPL, BRK.A), and a description noting dots are allowed. With the schema carrying the full burden, the baseline of 3 applies; the description adds nothing about parameters.
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 names a specific resource ('One company as held by tracked funds') and enumerates the data content (holders, values, last-quarter moves), which distinguishes it from siblings like stock_earnings, stock_financials, and stock_insiders. It stops short of a 5 because it is a noun phrase with no explicit verb — 'get' appears only in the title — and it does not clearly differentiate itself from fund_holdings, which could plausibly cover the same data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to call this tool versus alternatives; it never mentions siblings or exclusions. The closest rival, fund_holdings, is not addressed, leaving the agent to guess whether to use this tool or fund_holdings for a holdings query.
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 establish read-only, idempotent, and non-destructive behavior; the description adds the important edge-case behavior that blank or missing queries return empty buckets. It also states the bounded scope, echoing the closed-world annotation, and contains no contradiction with 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?
Three sentences deliver scope, domain mapping, and empty-query behavior with no filler. The most important differentiator, bounded cross-domain search, 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 one-optional-parameter search tool with a rich output schema and strong annotations, the description covers purpose, scope, domain mapping, and the edge case. There is no essential context missing for correct invocation, though sibling-selection guidance could be stronger.
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 documents the single query parameter with examples, and the description goes further by mapping query forms to each domain: funds by name, stocks by ticker/name, and insider transactions by owner. It also clarifies the optional-parameter case with the empty-bucket behavior, so parameter semantics are fully covered.
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 names the search verb, enumerates the three resources (funds, stocks, and insider transactions), and states the fields each can be queried by. This makes it easy to distinguish from sibling getters like get_fund, get_stock, and insider_feed.
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?
It clearly identifies the tool as a cross-domain search entry point with the same scopes as web search, so an agent can infer when a broad query is intended. However, it never says when to prefer the specific sibling tools instead, leaving exclusion guidance implicit.
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.
compare_stocks2 fields changedOutput schema / properties / columns / items / properties / listingAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "disclosure_note": {
+ "type": "string"
+ },
+ "event_type": {
+ "enum": [
+ "ipo",
+ "direct_listing",
+ "spin_off"
+ ],
+ "type": "string"
+ },
+ "listed_on": {
+ "format": "date",
+ "type": "string"
+ },
+ "recently_listed": {
+ "type": "boolean"
+ },
+ "source_url": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "listed_on",
+ "event_type",
+ "recently_listed",
+ "source_url",
+ "disclosure_note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / columns / items / requiredPrevious 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"
-]New value: +[
+ "ticker",
+ "name",
+ "listing",
+ "market_cap",
+ "enterprise_value",
+ "ocf_ev_yield",
+ "fcf_ev_yield",
+ "price_basis_kind",
+ "valuation_observed_at",
+ "financial_point",
+ "fund_summary",
+ "insider_summary"
+]fund_holdings2 fields changedOutput schema / properties / holdings / items / properties / security / properties / listingAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "disclosure_note": {
+ "type": "string"
+ },
+ "event_type": {
+ "enum": [
+ "ipo",
+ "direct_listing",
+ "spin_off"
+ ],
+ "type": "string"
+ },
+ "listed_on": {
+ "format": "date",
+ "type": "string"
+ },
+ "recently_listed": {
+ "type": "boolean"
+ },
+ "source_url": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "listed_on",
+ "event_type",
+ "recently_listed",
+ "source_url",
+ "disclosure_note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / holdings / items / properties / security / requiredPrevious value: -[
- "ticker",
- "name"
-]New value: +[
+ "ticker",
+ "name",
+ "listing"
+]get_stock2 fields changedOutput schema / properties / listingAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "disclosure_note": {
+ "type": "string"
+ },
+ "event_type": {
+ "enum": [
+ "ipo",
+ "direct_listing",
+ "spin_off"
+ ],
+ "type": "string"
+ },
+ "listed_on": {
+ "format": "date",
+ "type": "string"
+ },
+ "recently_listed": {
+ "type": "boolean"
+ },
+ "source_url": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "listed_on",
+ "event_type",
+ "recently_listed",
+ "source_url",
+ "disclosure_note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / requiredPrevious value: -[
- "ticker",
- "name",
- "total_value",
- "single_class",
- "latest_earnings",
- "positions",
- "provenance"
-]New value: +[
+ "ticker",
+ "name",
+ "listing",
+ "total_value",
+ "single_class",
+ "latest_earnings",
+ "positions",
+ "provenance"
+]search2 fields changedOutput schema / properties / results / properties / stocks / items / properties / listingAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "disclosure_note": {
+ "type": "string"
+ },
+ "event_type": {
+ "enum": [
+ "ipo",
+ "direct_listing",
+ "spin_off"
+ ],
+ "type": "string"
+ },
+ "listed_on": {
+ "format": "date",
+ "type": "string"
+ },
+ "recently_listed": {
+ "type": "boolean"
+ },
+ "source_url": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "listed_on",
+ "event_type",
+ "recently_listed",
+ "source_url",
+ "disclosure_note"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / results / properties / stocks / items / requiredPrevious value: -[
- "ticker",
- "name"
-]New value: +[
+ "ticker",
+ "name",
+ "listing"
+]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_feedsearchRead-only public-company financials, KPIs, benchmarks, filings, and insider activity.
Read-only impersonal market research: portfolio rankings, ticker scores, signals, daily briefs.
Value-investing research: fair values, valuation verdicts, quality scores and 13F portfolios
Indian NSE/BSE research data and mechanically-computed ratios; read-only market tools.
Add one secure layer between your agents and this server.
