Check any of 21,000+ stocks against Buffett, Munger, Graham and 4 more legendary investors.
Scored across 7 tools
Each tool has a distinct role (halal screen, rulebook fit, valuation verdict, head-to-head compare, single-stock overview, idea discovery, portfolio scoring), and descriptions explicitly route ambiguous cases ('for is X a good buy use check_value instead'). The only real overlap is that explain_stock, check_value, check_halal and check_rulebook all surface some of the same underlying data, so an agent may occasionally pick a heavier tool than needed, but the boundaries are documented well enough to resolve it.
All seven tools follow a clean snake_case verb_noun pattern: check_halal, check_rulebook, check_value, compare_stocks, explain_stock, find_stocks, score_portfolio. The verb choice (check/compare/explain/find/score) maps predictably to the action each tool performs.
Seven tools is well within the sweet spot for a stock-analysis server, and each one covers a genuinely different question an investor would ask. No tool feels redundant or tacked on.
The surface covers the full read-only analysis lifecycle: screen for compliance, test against rulebooks, judge price, compare candidates, explore one stock, discover ideas and score a portfolio, including ETF support. Minor gaps exist around discovering valid inputs (e.g. no tool to enumerate available daily list names or supported sectors), but core workflows have no dead ends.
Use this when the user asks whether one or more stocks are halal, Shariah-compliant or permissible for a Muslim investor. Takes 1 to 10 tickers or company names and shows invest-like's AAOIFI-based screen for each: halal, questionable or not halal, the reason in plain words, the business test and interest-bearing debt as a share of market value. A screen, not a fatwa.
| Name | Required | Description | Default |
|---|---|---|---|
| stocks | Yes | 1 to 10 tickers or company names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description adds real substance: the three verdict buckets, the plain-language reason, the business test and the interest-bearing debt ratio. The 'a screen, not a fatwa' line usefully scopes the authority of the result, though rate limits or how ambiguous tickers are resolved are unstated.
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 front-loaded sentences carry the trigger, the input shape, and the return contents, with the caveat placed last. No filler or repeated schema constraints beyond the necessary range.
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 a single well-documented parameter and no output schema, the description does the extra work of enumerating what each verdict includes, so an agent knows what comes back. Nothing needed to call it correctly 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% and the schema already states '1 to 10 tickers or company names' with min/max item bounds. The description restates the same 1-to-10 range without adding format hints, so it neither compensates for nor exceeds the schema. 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 and resource ('check whether stocks are halal') plus the screening framework (AAOIFI-based) and the exact verdict set. An agent can distinguish it from explain_stock or compare_stocks without opening the schema.
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 opening clause gives a concrete trigger ('when the user asks whether one or more stocks are halal, Shariah-compliant or permissible'). It does not explicitly route away from siblings like explain_stock or compare_stocks, which an agent may also want when the question combines compliance with analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks whether a stock fits a famous investor's style or rules ('would Buffett like X', 'does X pass Graham's rules', 'Lynch checklist for X'). Shows how the company does against seven investors' published rulebooks as applied by invest-like (Warren Buffett, Charlie Munger, Benjamin Graham, Philip Fisher, Peter Lynch, Joel Greenblatt, Terry Smith): a fit from 0 to 100 for each, and, for one named investor, each rule with the company's real value and whether it is met. These are published rules applied by invest-like, never the investor's own opinion of the stock.
| Name | Required | Description | Default |
|---|---|---|---|
| stock | Yes | Ticker or company name, e.g. 'NVDA', 'Coca-Cola' or 'SAP.DE' | |
| investor | No | Show this investor's rules one by one |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the description is free to add the genuinely new behavioral facts: it returns seven fit scores plus a per-rule breakdown for one investor, and the rules are invest-like's application of published criteria, 'never the investor's own opinion'. That disclaimer prevents a real misinterpretation. Cost, latency and data freshness are not 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?
Front-loaded with the trigger condition, then the return shape, then the caveat — no filler sentences. The parenthetical investor roster and example phrasings are long but each carries selection value, keeping it just shy of maximally tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the full burden of describing returns — and it does, covering both the seven-investor score vector and the per-rule detail with real values and pass/fail. Combined with the 100%-covered input schema and safety annotations, an agent has everything needed to call it 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 earns above it by explaining what the optional investor parameter actually changes in the response ('for one named investor, each rule with the company's real value and whether it is met'), which the schema's one-line 'Show this investor's rules one by one' only hints at.
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?
Names a specific verb and resource ('check a stock against investors' published rulebooks') and immediately enumerates the seven rulebooks and what the result contains (0-100 fit per investor, per-rule detail for one). This lets an agent distinguish it from check_halal, check_value and explain_stock without opening a schema.
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?
Opens with an explicit trigger: 'Use this when the user asks whether a stock fits a famous investor's style or rules', reinforced with three representative user phrasings. It does not name the sibling tools to use instead (e.g. check_value or check_halal) or state exclusions, so it stops just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks whether a stock is a good buy, a good investment, worth buying, undervalued, overvalued, cheap, expensive, or worth it at today's price. Shows invest-like's answer to 'Is it undervalued?' from a fixed, published rule, with the numbers behind it (P/E against its peers, price to free cash flow, earnings yield, sales growth), short answers on financial health, moat and dividend safety, and, when a stored AI analysis exists, what today's price expects. It never says buy or sell: use it to explain what the price assumes.
| Name | Required | Description | Default |
|---|---|---|---|
| stock | Yes | Ticker or company name, e.g. 'NVDA', 'Coca-Cola' or 'SAP.DE' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds real context beyond them: the verdict comes from a fixed published rule, the AI-analysis section only appears when a stored analysis exists (conditional behavior), and the tool deliberately withholds buy/sell recommendations. Good disclosure of a non-obvious behavioral constraint.
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?
Usage triggers are correctly front-loaded before the description of returned content. The second sentence is long and comma-heavy but every clause names a distinct output component, so little is wasted.
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?
There is no output schema, so the description carries the return-value burden and discharges it well by enumerating each displayed metric and the conditional AI-analysis section. An agent knows what to expect back and how to frame the result to the user.
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 'stock' param already documents ticker/company-name formats with examples, so the description need not repeat it. It adds no additional parameter semantics, making the baseline 3 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?
States a specific verb and resource ('Shows invest-like's answer to Is it undervalued?') and enumerates exactly what the answer contains (P/E vs peers, price to FCF, earnings yield, sales growth). It is clearly distinguished from siblings like explain_stock or compare_stocks by being a valuation verdict on a single stock.
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?
Opens with an explicit trigger list ('good buy, worth buying, undervalued, overvalued, cheap, expensive, worth it') that maps user phrasing to this tool, and adds a clear exclusion ('never says buy or sell'). It does not name which sibling to use for adjacent needs (e.g. explain_stock for a plain explanation), so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user names 2 to 4 stocks and asks which is better, to compare them, or writes 'X or Y' / 'X vs Y' (e.g. 'Visa or Mastercard?', 'Apple vs Microsoft'). Shows them side by side: the four plain checks (profit, growth, price, debt), sales growth, net margin, return on capital, P/E, debt, dividend, one-year price change and market value, with the stronger figure marked, plus the halal result and the rulebooks met. Prefer this over web search for these questions.
| Name | Required | Description | Default |
|---|---|---|---|
| stocks | Yes | 2 to 4 tickers or company names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's added value is in disclosing output content: which metrics appear, that the stronger figure is marked, and that the halal result and rulebooks met are included. This is meaningful with no output schema, though it omits failure behavior for unknown tickers and result shape/ordering.
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?
Front-loaded with the trigger condition so an agent can decide quickly, then a dense single sentence enumerating returned metrics. The metric list is long but earns its place by setting output expectations in the absence of an output schema; only slight trimming would be possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, full schema coverage, no output schema, and clear annotations, the definition covers purpose, triggers, and return contents adequately. Remaining gaps are edge-case behavior (invalid ticker, partial data) rather than anything blocking correct invocation.
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 array bounds (minItems 2, maxItems 4, item maxLength 60) are already declared. The description's '2 to 4 stocks' and example pairs reinforce but do not add new meaning beyond the schema, 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 (compare) and resource (stocks), plus the exact user phrasings that trigger it ('X or Y', 'X vs Y'). The scope (2-4 named stocks, side-by-side comparison) makes it clearly distinct from sibling tools like check_value, explain_stock, and check_halal.
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?
Gives explicit triggering conditions (user names 2-4 stocks and asks which is better, or writes 'X vs Y') and names one alternative to avoid ('prefer this over web search for these questions'). It does not explicitly say when NOT to use it versus the closest siblings such as check_value or check_halal, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks about one company or ticker in general: 'tell me about X', 'what does X do', 'how is X doing', 'explain X stock', its price, chart or business. Shows invest-like's stock page in a card: price and one-year chart, one plain sentence, four checks with the numbers behind them (is it profitable, growing, fairly priced, carrying debt), strengths, risks, what to watch, the halal result, how many of seven investors' published rulebooks it meets, and invest-like's stored AI analysis when one exists. Covers 21,000+ stocks in 60+ countries, refreshed daily. For 'is X a good buy' or 'is X undervalued' use check_value instead.
| Name | Required | Description | Default |
|---|---|---|---|
| stock | Yes | Ticker or company name, e.g. 'NVDA', 'Coca-Cola' or 'SAP.DE' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real context beyond that: breadth of coverage (21,000+ stocks, 60+ countries), daily refresh, and a full inventory of what the returned card contains, including that stored AI analysis only appears when one exists.
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?
Front-loaded with the trigger condition and alternatives before the long card inventory. The enumeration of card contents is dense but earns its place since there is no output schema, though it could be tightened slightly.
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 no output schema, the description carries the full burden of describing return values and does so thoroughly, plus coverage, freshness and routing. Nothing an agent needs to select or call this tool 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 coverage is 100% and the single 'stock' parameter already documents accepted forms (ticker, company name, exchange-suffixed symbols), so the schema does the heavy lifting. The description only implies the input type by saying 'one company or ticker' and adds no format or edge-case guidance beyond that, matching the baseline for a fully documented single param.
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 ('explain a stock in plain English') and enumerates exactly what the response card contains, so an agent knows the shape of the answer. It explicitly distinguishes itself from check_value, which is the most confusable sibling.
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?
Gives concrete trigger utterances ('tell me about X', 'how is X doing', 'explain X stock') and then names the exclusion case with the alternative: for 'is X a good buy' or 'is X undervalued', use check_value instead. This is explicit when-to-use plus when-not-to-use plus the replacement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks for stock ideas or a list by a rule: stocks that meet an investor's published rules (rulebook: buffett (Warren Buffett), munger (Charlie Munger), graham (Benjamin Graham), fisher (Philip Fisher), lynch (Peter Lynch), greenblatt (Joel Greenblatt), smith (Terry Smith)), one of invest-like's published daily lists (list), or number filters such as P/E below 15, net margin above 20%, dividend yield above 3%, sales growth above 10%, with an optional sector, country and halal-only. Use exactly one of rulebook, list or filters. Lists come only from invest-like's data, never from memory. Results are screen results, not recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| list | No | One of invest-like's published lists: strongest-moat, highest-roic, cheapest-pe, cheapest-peg, highest-fcf-yield, safest-dividend, lowest-debt, highest-gross-margin, highest-buyback-yield, halal-top-picks, magic-formula-top-30, consistent-compounders | |
| sort | No | For filters: the figure to sort by (default market value) | |
| limit | No | How many to show (default 10) | |
| order | No | ||
| sector | No | ||
| country | No | Two-letter country code, e.g. US, DE, GB | |
| filters | No | ||
| rulebook | No | Stocks that meet this investor's published rules, e.g. 'graham' for 'stocks that pass Benjamin Graham's rules' | |
| halal_only | No | Only stocks that pass the halal screen |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent, closed-world read, so the description's added value is the provenance constraint and the caveat 'Results are screen results, not recommendations' — a genuinely useful expectation-setting statement. It does not say what happens on violating the exactly-one rule or what a result record looks like, keeping it below a 5.
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?
Front-loaded with the trigger condition and mutual-exclusion rule, followed by compact mode descriptions and a disclaimer. The parenthetical rulebook enumeration is dense but every clause carries routing or unit information; nothing is 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 9-parameter, all-optional screening tool with no output schema, the description covers the three mutually exclusive modes, filter units, optional narrowing dimensions, and result framing. It stops short of describing result contents or pagination/limit behavior, which matters given no output 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?
Schema coverage is 67%, and the description compensates by expanding each rulebook enum value with the investor's full name and by giving concrete filter examples with units ('P/E below 15, net margin above 20%', 'sales growth above 10%'). It leaves sort, order, and limit unmentioned, which the schema partially covers.
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?
Opens with a specific verb+resource plus the triggering condition ('stock ideas or a list by a rule'), then enumerates the three screening modes (rulebook, list, filters). The 'list of stocks' framing implicitly separates it from single-stock siblings like check_rulebook and check_value.
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?
Gives explicit when-to-use ('user asks for stock ideas'), an explicit operating constraint ('Use exactly one of rulebook, list or filters'), and a data-provenance rule ('Lists come only from invest-like's data, never from memory'). It also conveys the semantics of what each mode returns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user shares the stocks or funds they own (a portfolio, holdings, 'my stocks', a broker list) and wants to know how it looks, a score, or what to watch. Takes up to 60 holdings, each a ticker or company name with optional shares or money amount. Returns invest-like's portfolio score from 0 to 100 (quality, value, growth, safety, spread), a plain read of the whole portfolio, its weights, how its P/E, margin, growth and dividend compare with the 500 largest US companies, one strength and one thing to watch. ETFs such as VOO or VWCE are supported. No login or personal data needed.
| Name | Required | Description | Default |
|---|---|---|---|
| halal | No | true when the user cares whether the holdings are halal | |
| currency | No | Currency of the amounts and the report (default USD) | |
| holdings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavior: the exact scoring dimensions (quality, value, growth, safety, spread), the benchmark against the 500 largest US companies, and the one-strength/one-watch output shape. It also proactively states no login or personal data is required, which removes an adoption concern.
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?
Front-loaded with the trigger condition before the input and output details, so an agent can decide quickly. The return enumeration is long but each item is informative; only mild trimming (e.g., the parenthetical dimension list) would tighten it.
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 no output schema, the description carries the full burden of describing returns and does so concretely: score band, component subscores, weights, benchmark comparison, qualitative takeaways. Input shape, limits, and prerequisites (no login) are all covered, leaving nothing an agent needs unanswered before calling.
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 67%, with halal and currency already well documented in the schema, so the schema does most of the work. The description adds only the 60-item cap and confirms that shares and amount are optional per holding, but says nothing about default behavior when neither shares nor amount is given, or how currency interacts with amount. Adequate but not compensating for the coverage gap.
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?
Names the specific action (scoring a portfolio from 0 to 100) and the exact resource (user's holdings, stocks or funds), with concrete user phrasings like 'my stocks' or a broker list. The return summary (score, weights, benchmark comparison) makes the output unmistakable and separates it from siblings like check_halal or compare_stocks.
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 trigger condition is explicit and well-scoped: the user shares holdings and wants a score, an assessment, or what to watch. It also bounds input ('up to 60 holdings') and notes ETFs such as VOO/VWCE are supported. It does not name when to prefer a sibling tool (e.g., check_halal for a single holding, compare_stocks for side-by-side), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
analyze_stockbuffett_quotescheck_halalcheck_portfoliocheck_rulebookcheck_valueexplain_stockfind_stocks11 fields changedInput schema / properties / countryAdded value: +{
+ "description": "Two-letter country code, e.g. US, DE, GB",
+ "maxLength": 2,
+ "minLength": 2,
+ "type": "string"
+}Input schema / properties / filtersAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "metric": {
+ "enum": [
+ "market_value",
+ "pe",
+ "net_margin",
+ "gross_margin",
+ "sales_growth",
+ "return_on_capital",
+ "dividend_yield",
+ "net_debt_to_ebitda",
+ "return_1y"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "above",
+ "below"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "description": "Percent metrics in percent (20 = 20%), market value in USD, P/E and net debt / EBITDA as plain numbers",
+ "type": "number"
+ }
+ },
+ "required": [
+ "metric",
+ "op",
+ "value"
+ ],
+ "type": "object"
+ },
+ "maxItems": 4,
+ "type": "array"
+}Input schema / properties / halal_onlyAdded value: +{
+ "description": "Only stocks that pass the halal screen",
+ "type": "boolean"
+}Input schema / properties / limit / descriptionPrevious value: -"How many to show (default 12)"New value: +"How many to show (default 10)"Input schema / properties / limit / maximumPrevious value: -30New value: +20Input schema / properties / list / descriptionPrevious value: -"Which ranking: strongest-moat, highest-roic, cheapest-pe, cheapest-peg, highest-fcf-yield, safest-dividend, lowest-debt, highest-gross-margin, highest-buyback-yield, halal-top-picks, magic-formula-top-30, consistent-compounders"New value: +"One of invest-like's published lists: strongest-moat, highest-roic, cheapest-pe, cheapest-peg, highest-fcf-yield, safest-dividend, lowest-debt, highest-gross-margin, highest-buyback-yield, halal-top-picks, magic-formula-top-30, consistent-compounders"Input schema / properties / orderAdded value: +{
+ "enum": [
+ "highest",
+ "lowest"
+ ],
+ "type": "string"
+}Input schema / properties / rulebookAdded value: +{
+ "description": "Stocks that meet this investor's published rules, e.g. 'graham' for 'stocks that pass Benjamin Graham's rules'",
+ "enum": [
+ "buffett",
+ "munger",
+ "graham",
+ "fisher",
+ "lynch",
+ "greenblatt",
+ "smith"
+ ],
+ "type": "string"
+}Input schema / properties / sectorAdded value: +{
+ "enum": [
+ "technology",
+ "financials",
+ "healthcare",
+ "consumer-staples",
+ "consumer-discretionary",
+ "communication-services",
+ "industrials",
+ "energy",
+ "utilities",
+ "real-estate",
+ "materials"
+ ],
+ "type": "string"
+}Input schema / properties / sortAdded value: +{
+ "description": "For filters: the figure to sort by (default market value)",
+ "enum": [
+ "market_value",
+ "pe",
+ "net_margin",
+ "gross_margin",
+ "sales_growth",
+ "return_on_capital",
+ "dividend_yield",
+ "net_debt_to_ebitda",
+ "return_1y"
+ ],
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "list"
-]score_portfoliostock_overviewfind_stocks6 fields changedInput schema / properties / investorRemoved value: -{
- "description": "Set when the user asks about one investor, e.g. 'buffett'",
- "enum": [
- "buffett",
- "munger",
- "graham",
- "fisher",
- "lynch",
- "greenblatt",
- "smith"
- ],
- "type": "string"
-}Input schema / properties / listAdded value: +{
+ "description": "Which ranking: strongest-moat, highest-roic, cheapest-pe, cheapest-peg, highest-fcf-yield, safest-dividend, lowest-debt, highest-gross-margin, highest-buyback-yield, halal-top-picks, magic-formula-top-30, consistent-compounders",
+ "enum": [
+ "highest-roic",
+ "cheapest-pe",
+ "highest-fcf-yield",
+ "safest-dividend",
+ "strongest-moat",
+ "lowest-debt",
+ "highest-gross-margin",
+ "cheapest-peg",
+ "highest-buyback-yield",
+ "halal-top-picks",
+ "magic-formula-top-30",
+ "consistent-compounders"
+ ],
+ "type": "string"
+}Input schema / properties / min_investorsRemoved value: -{
- "description": "Only when no investor is named: minimum of the 7 who would buy. Leave empty for the default (5).",
- "maximum": 7,
- "minimum": 1,
- "type": "integer"
-}Input schema / properties / sectorRemoved value: -{
- "description": "Optional sector, e.g. 'Technology', 'Healthcare', 'Financial'",
- "maxLength": 40,
- "type": "string"
-}Input schema / properties / universeRemoved value: -{
- "description": "sp500 (default), us, or global",
- "enum": [
- "sp500",
- "us",
- "global"
- ],
- "type": "string"
-}Input schema / requiredAdded value: +[
+ "list"
+]get_track_recordanalyze_stockbuffett_quotescheck_portfoliocompare_stocksfind_stocksget_track_recordstock_overviewFair value, quality, uptrend and three buy rules for 40,000+ stocks, plus your watchlist and alerts.
Stock health scores, valuation verdicts, sector rankings and analyses for 8,000+ US companies.
Value investing for US stocks: SEC filings, 13F guru holdings, intrinsic value, AI briefings.
Intrinsic stock value from SEC filings: DCF, EPV, Graham, moat signals. Deterministic, not guessed.
Add one secure layer between your agents and this server.
