Value-investing research: fair values, valuation verdicts, quality scores and 13F portfolios
Scored across 7 tools
Most tools have clearly distinct purposes, but screen_stocks and stocks_of_the_week both return ranked valuation picks, and compare_stocks overlaps with get_stock_research for multi- vs single-ticker views. Descriptions mostly resolve the boundaries, yet an agent may hesitate when asked for 'top stocks' without a specific screen.
Six of seven tools follow a verb_noun snake_case pattern (compare_stocks, get_stock_research, list_superinvestors, screen_stocks, search_stocks), but stocks_of_the_week breaks the verb-first convention and get_stock_research mixes singular/plural naming.
Seven tools sit comfortably in the 3-15 sweet spot, and each maps to a distinct capability—search, single-stock research, comparison, screening, weekly picks, and investor lookup/list. No filler tools are present.
The surface covers discovery, detailed single-stock analysis, comparison, screening, curated picks, and superinvestor tracking well. Minor gaps include no explicit way to list the full coverage universe and no historical time-series beyond the latest snapshot or filed results.
Put two or more tickers side by side on verdict, fair value, upside and scores.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | Tickers to compare. |
| Name | Required | Description |
|---|---|---|
| companies | Yes | |
| not_covered | Yes | Tickers asked for that Talval does not cover. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered and the description carries less burden. The description adds the comparison dimensions as output context, but discloses no additional behavior such as result ordering, caching, or partial-failure handling for invalid tickers.
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 action and resource, and every clause (the compared dimensions) carries information. No filler or 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?
With an output schema present, the description needn't explain return values, and the sole parameter is fully covered by the schema. The only shortfall is the absence of routing guidance among the six siblings, which is a minor gap for such a 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 description coverage is 100% and the single 'tickers' parameter is documented in the schema with minItems/maxItems constraints. The description's 'two or more tickers' merely echoes the schema's minItems=2, adding no syntax or format detail beyond it.
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 verb+resource ('put two or more tickers side by side') and enumerates the compared dimensions (verdict, fair value, upside, scores), which makes it clearly a multi-ticker comparison rather than a single-entity lookup. It does not explicitly name or contrast any sibling, so it stops short of a 5.
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 is only implied: the phrase 'two or more tickers' suggests the tool is for multi-ticker comparison versus the single-ticker siblings like get_stock_research. There is no explicit when-to-use, when-not-to-use, or named alternative such as screen_stocks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Talval's valuation verdict, fair-value estimate, upside, quality/safety/value scores and latest filed results for one ticker. End-of-day snapshot with a date.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Exact ticker as Talval lists it, e.g. 'AAPL', 'RHM.DE', 'PRU.L'. |
| Name | Required | Description |
|---|---|---|
| url | No | |
| name | No | |
| as_of | No | Date of the verdict snapshot, YYYY-MM-DD. |
| price | No | |
| scores | No | 0-100, null where the inputs behind a score are missing. |
| sector | No | |
| ticker | Yes | |
| country | No | |
| covered | Yes | False when Talval does not cover this ticker; every other field is then null. |
| verdict | No | Undervalued, Fairly valued or Overvalued. |
| currency | No | Trading currency of price and fair value. |
| industry | No | |
| conviction | No | 1-10. |
| fair_value | No | Null when withheld — see fair_value_usable and withheld_reason. |
| market_cap | No | |
| risk_level | No | |
| upside_pct | No | Percent, not a fraction. |
| pe_trailing | No | |
| price_as_of | No | |
| latest_annual | No | As reported in the company's own filings — not estimates. |
| withheld_reason | No | Why fair_value is null, when it is. |
| fair_value_usable | No | False when the company reports in a different currency than it trades in, which makes every price-to-fundamentals figure cross-currency nonsense. A false here is a deliberate suppression, not missing data. |
| dividend_yield_pct | No | Forward yield as a PERCENT, e.g. 2.9 for 2.9%. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds a valuable behavioral trait not in annotations: the data is an 'End-of-day snapshot with a date,' signalling non-real-time freshness and a dated result. This is a clear addition beyond structured fields, though not a rich behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences: the first front-loads the returned fields, the second adds the snapshot timing. Every clause carries information and there is no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-ticker retrieval tool with a rich output schema and safety annotations, the description covers what is returned and the snapshot nature. It lacks explicit sibling routing, which would help an agent distinguish it from search_stocks and screen_stocks, but the core call context is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the ticker parameter's schema already documents the exact format with examples ('AAPL', 'RHM.DE', 'PRU.L'). The description only reinforces 'for one ticker,' adding no syntax or format detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific data returned (valuation verdict, fair-value estimate, upside, quality/safety/value scores, latest filed results) for a single ticker, making the tool's purpose clear. It implicitly distinguishes from siblings like screen_stocks and compare_stocks by stating 'for one ticker,' but never explicitly names alternatives.
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?
There is no explicit guidance on when to use this tool versus siblings such as search_stocks or screen_stocks, nor any prerequisites or exclusions. The single-ticker scope implies a narrow usage, but the description leaves the agent to infer this without confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One tracked investor's reported holdings and quarter-on-quarter activity. Call list_superinvestors first to get the slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug, e.g. 'berkshire'. |
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| found | Yes | False when no tracked investor has that slug. |
| person | No | |
| manager | No | |
| activity | No | Quarter on quarter. Null when there is no prior filing to compare against. |
| holdings | No | Largest first, capped at 30. |
| n_positions | No | |
| quarter_end | No | |
| portfolio_value_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds the quarter-on-quarter activity framing and the sibling dependency, but says nothing about rate limits or staleness despite the name 'reported holdings' implying a reporting lag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The resource description is front-loaded and the prerequisite call is the second sentence, which is the right order.
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?
Single-parameter read tool with a full annotation set and an output schema, so the agent has what it needs to call it correctly. The remaining gap is that 'reported holdings' and 'quarter-on-quarter activity' are not anchored to which quarter or what reporting lag to expect.
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% and the schema even gives an example slug ('berkshire'). The description adds no format or syntax detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: fetches one tracked investor's reported holdings and quarter-over-quarter activity. Distinguishes it from the sibling list_superinvestors by naming that tool as the prerequisite. Could be sharper about what 'activity' means, but the scope is clear.
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?
Explicitly tells the agent to call list_superinvestors first to obtain the slug, and the shared noun 'superinvestor' ties this tool to its sibling. The one condition that matters for correct invocation is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The investors Talval tracks through their quarterly 13F filings — portfolio size, position count and largest holdings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| investors | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond that — the data source and implied timeliness ('quarterly 13F filings') and the shape of what each entry carries (portfolio size, position count, largest holdings). It does not, however, mention freshness lag or coverage limits.
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?
A single sentence with no filler, and the datasource qualifier is front-loaded. It is efficient, though the missing verb is a structural omission rather than verbosity — the agent may, however, want to know this comes from a list operation rather than a lookup.
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?
A rich output schema exists (so return values need not be explained) and annotations carry the safety profile, so the burden on the description is light. Still, the absence of any stated operation or sibling routing leaves a gap around why an agent should pick this over get_superinvestor.
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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly avoids inventing optional filters.
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 is a noun phrase describing what a superinvestor is ('investors Talval tracks through their quarterly 13F filings'), but it never states the verb — that the tool returns a list. It partially restates the title and offers no differentiation from the sibling get_superinvestor, so the agent must infer the operation.
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?
There is no indication of when to call this versus get_superinvestor (single investor lookup) or the other screen_/search_ siblings. No prerequisites, no exclusions, and no context are given — usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one of Talval's stock screens over the covered universe and return the ranked results with fair value, upside and scores.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many ranked rows to return. The screen is already ranked, so a smaller number gives the strongest names rather than a sample. | |
| screen | Yes | Which screen to run. | |
| sector | No | Optional sector filter, e.g. 'Technology'. |
| Name | Required | Description |
|---|---|---|
| rows | Yes | Ranked. Empty when nothing clears the screen. |
| label | No | |
| screen | Yes | |
| sector | No | The sector filter applied, if any. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds that output is ranked and includes fair value, upside and scores, but with an output schema present even that is partly redundant. Modest added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One tight sentence that front-loads the verb, the source of the screens, and the shape of the result. Nothing extraneous.
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 full schema coverage, rich annotations and an output schema, the description only needs to orient the agent, which it does. It is slightly thin on how this differs from the other stock-listing siblings, but nothing required for a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters are already documented, including the important note that limit selects the strongest names rather than a sample. The description adds no syntax or semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (run) and resource (Talval's stock screens) and describes the returned payload (ranked results with fair value, upside and scores). It does not name a sibling to differentiate from search_stocks or get_stock_research, so it lands at 4 rather than 5.
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 is implied by the screen enum and the 'covered universe' framing, but there is no explicit when-to-use-this-vs-alternatives guidance, e.g. versus search_stocks for arbitrary lookups. A reader can infer intent but is not told the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a company in Talval's coverage by name or ticker. Typo tolerant. Use this first when you only have a company name.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many matches to return. Raise it when a name is ambiguous across listings — Shell and Unilever trade in more than one place. | |
| query | Yes | Company name or ticker, e.g. 'Rheinmetall' or 'RHM.DE'. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| matches | Yes | Empty when nothing in Talval's coverage matches. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds a genuine behavioral trait not present in structured data — "Typo tolerant" — which changes how an agent should phrase queries and trust near-matches.
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 short sentences, front-loaded with the purpose before the routing hint. Every sentence carries information; nothing is redundant.
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?
An output schema exists, so return values need not be explained. Combined with fully documented parameters and a complete safety annotation set, the description covers what an agent needs, though a note on ambiguous-match handling would round it out.
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 both parameters are already documented, including the disambiguation rationale for `limit`. The description only echoes the name-or-ticker semantics, adding nothing the schema does not already say.
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?
States a specific verb and resource ("Find a company") and a scope ("Talval's coverage") with the search key (name or ticker). It implicitly separates itself from screen_stocks and compare_stocks by positioning as the name-lookup entry point, but it never names those siblings explicitly.
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?
"Use this first when you only have a company name" gives a clear condition for selecting this tool over sibling lookups. It stops short of naming alternatives (e.g., screen_stocks for filtered discovery) or stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Talval's current weekly picks — the latest Undervalued verdict per ticker, refreshed weekly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | No | This week's written note, when there is one. |
| picks | Yes | Empty when nothing is published for this week yet. |
| week_start | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds that the data is refreshed weekly and represents an Undervalued verdict, which is useful context about data freshness and content, though no further behavioral traits like rate limits or auth are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that precisely conveys the tool's output. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the resource and its refresh cadence, which is sufficient given the rich annotations and the existence of an output schema. It could be slightly more complete by noting that the result is likely a list of stocks with associated verdicts, but the core information is present.
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 tool takes no parameters, so there is no schema parameter information to add. The description correctly does not discuss parameters. Baseline for zero parameters is 4.
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 a specific resource: Talval's weekly stock picks, defined as the latest Undervalued verdict per ticker. This is more than a tautology, but it doesn't explicitly distinguish itself from siblings like screen_stocks or get_stock_research beyond the weekly, curated framing.
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 phrase 'current weekly picks' implies when to use it—when the agent needs a ready-made weekly selection—but no explicit when/when-not or sibling comparison is provided. The usage context is inferable but not stated.
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_stocks1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "companies": {
+ "items": {
+ "properties": {
+ "conviction": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "currency": {
+ "description": "Trading currency of the price and fair value.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "dividend_yield_pct": {
+ "description": "Percent, e.g. 2.9.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fair_value": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fair_value_usable": {
+ "type": "boolean"
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "quality_score": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "safety_score": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ticker": {
+ "type": "string"
+ },
+ "upside_pct": {
+ "description": "Percent, not a fraction: 12.5 means +12.5%.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value_score": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "verdict": {
+ "description": "Undervalued, Fairly valued or Overvalued.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "ticker"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "not_covered": {
+ "description": "Tickers asked for that Talval does not cover.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "companies",
+ "not_covered"
+ ],
+ "type": "object"
+}get_stock_research1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "as_of": {
+ "description": "Date of the verdict snapshot, YYYY-MM-DD.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "conviction": {
+ "description": "1-10.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "country": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "covered": {
+ "description": "False when Talval does not cover this ticker; every other field is then null.",
+ "type": "boolean"
+ },
+ "currency": {
+ "description": "Trading currency of price and fair value.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "dividend_yield_pct": {
+ "description": "Forward yield as a PERCENT, e.g. 2.9 for 2.9%.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fair_value": {
+ "description": "Null when withheld — see fair_value_usable and withheld_reason.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fair_value_usable": {
+ "description": "False when the company reports in a different currency than it trades in, which makes every price-to-fundamentals figure cross-currency nonsense. A false here is a deliberate suppression, not missing data.",
+ "type": "boolean"
+ },
+ "industry": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "latest_annual": {
+ "description": "As reported in the company's own filings — not estimates.",
+ "properties": {
+ "eps_diluted": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "fiscal_year": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "free_cash_flow": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "net_income": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "revenue": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "market_cap": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "pe_trailing": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "price_as_of": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "risk_level": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "scores": {
+ "description": "0-100, null where the inputs behind a score are missing.",
+ "properties": {
+ "composite": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "dividend": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "piotroski_f_score": {
+ "description": "0-9.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "quality": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "safety": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "value": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "sector": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ticker": {
+ "type": "string"
+ },
+ "upside_pct": {
+ "description": "Percent, not a fraction.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "url": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "verdict": {
+ "description": "Undervalued, Fairly valued or Overvalued.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "withheld_reason": {
+ "description": "Why fair_value is null, when it is.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "ticker",
+ "covered"
+ ],
+ "type": "object"
+}get_superinvestor1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "activity": {
+ "description": "Quarter on quarter. Null when there is no prior filing to compare against.",
+ "properties": {
+ "added_to": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "new_buys": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "reduced": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "sold_out": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "type": [
+ "object",
+ "null"
+ ]
+ },
+ "found": {
+ "description": "False when no tracked investor has that slug.",
+ "type": "boolean"
+ },
+ "holdings": {
+ "description": "Largest first, capped at 30.",
+ "items": {
+ "properties": {
+ "activity": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "issuer": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "pct_of_portfolio": {
+ "description": "Percent, e.g. 12.4.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ticker": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "manager": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "n_positions": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "person": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "portfolio_value_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "quarter_end": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "found"
+ ],
+ "type": "object"
+}list_superinvestors1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "investors": {
+ "items": {
+ "properties": {
+ "manager": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "n_positions": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "person": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "portfolio_value_usd": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "quarter_end": {
+ "description": "The reported quarter, YYYY-MM-DD.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "slug": {
+ "description": "Pass this to get_superinvestor.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "investors"
+ ],
+ "type": "object"
+}screen_stocks2 fields changedInput schema / properties / limit / descriptionAdded value: +"How many ranked rows to return. The screen is already ranked, so a smaller number gives the strongest names rather than a sample."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "label": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rows": {
+ "description": "Ranked. Empty when nothing clears the screen.",
+ "items": {
+ "properties": {
+ "currency": {
+ "description": "Trading currency of the price and fair value.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "fair_value": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "price": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "quality_score": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "ticker": {
+ "type": "string"
+ },
+ "upside_pct": {
+ "description": "Percent, not a fraction: 12.5 means +12.5%.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "verdict": {
+ "description": "Undervalued, Fairly valued or Overvalued.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "ticker"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "screen": {
+ "type": "string"
+ },
+ "sector": {
+ "description": "The sector filter applied, if any.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "screen",
+ "rows"
+ ],
+ "type": "object"
+}search_stocks2 fields changedInput schema / properties / limit / descriptionAdded value: +"How many matches to return. Raise it when a name is ambiguous across listings — Shell and Unilever trade in more than one place."Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "matches": {
+ "description": "Empty when nothing in Talval's coverage matches.",
+ "items": {
+ "properties": {
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sector": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ticker": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ticker"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "query": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "query",
+ "matches"
+ ],
+ "type": "object"
+}stocks_of_the_week1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "note": {
+ "description": "This week's written note, when there is one.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "picks": {
+ "description": "Empty when nothing is published for this week yet.",
+ "items": {
+ "properties": {
+ "conviction": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "rank": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "sector": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "ticker": {
+ "type": "string"
+ },
+ "verdict": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "ticker"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "week_start": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "picks"
+ ],
+ "type": "object"
+}compare_stocksget_stock_researchget_superinvestorlist_superinvestorsscreen_stockssearch_stocksstocks_of_the_weekFair value, valuation status and quality score for 35,000+ stocks, plus your watchlist and alerts.
Intrinsic stock value from SEC filings: DCF, EPV, Graham, moat signals. Deterministic, not guessed.
US stock quotes, analyst targets, superinvestor 13F, insider buys and earnings from SEC filings
Value investing for US stocks: SEC filings, 13F guru holdings, intrinsic value, AI briefings.
Add one secure layer between your agents and this server.