Brina Gap valuation, supply chains, screener and market score for US stocks. SEC data, free, no key.
Scored across 7 tools
Each tool targets a clearly distinct scope: custom DCF arithmetic, stored company valuation, supply chain relationships, whole-market valuation, published monthly lists, custom screening, and portfolio simulation. The potentially overlapping pairs are explicitly separated in the descriptions, especially calculate_dcf_value vs get_stock_valuation and screen_stocks vs list_flagged_stocks.
All names use consistent snake_case and a verb_noun pattern. Retrieval tools use get_, list/screen/simulate/calculate actions are predictable, and the DCF acronym is the only minor readability variation.
Seven tools is well within the appropriate range and each one covers a distinct analytical function. There is no obvious redundancy or thin coverage.
The surface covers the core valuation workflows: individual company valuation, custom DCF, market-level valuation, screening, published flags, supply chain context, and portfolio outcome simulation. Minor gaps exist around direct multi-ticker comparison and historical valuation time series, but agents can largely work around them.
Runs a two-stage discounted cash flow on numbers you provide and returns the fair value per share, the margin of safety against the price you gave, and how much of the value sits in the terminal stage. Cash flow grows at your growth rate for the stage-one years, then forever at your terminal rate, with the terminal value from the Gordon Growth Model discounted back over the stage-one years.
Use when the user wants to value a company under their own assumptions, test how sensitive a valuation is to the discount or growth rate, or check the arithmetic of a DCF they are building. Do not use it to look up what a company is worth on Zyberno's own assumptions, which is get_stock_valuation and uses a different, fade-based model; the two will not agree and are not meant to.
This computes your assumptions, it does not endorse them. The output is arithmetic, and a two-stage DCF is highly sensitive to the discount and terminal rates, so treat a single result as one point rather than an answer.
| Name | Required | Description | Default |
|---|---|---|---|
| growth_rate | Yes | Annual cash flow growth during the first stage, in percent. Pass 8 for 8 percent. Range -20 to 100. | |
| growth_years | Yes | Length of the high-growth first stage, in years. | |
| discount_rate | Yes | Discount rate (required return or WACC) in percent. Pass 10 for 10 percent. Must be greater than the terminal growth rate. | |
| cash_flow_per_share | Yes | Starting free cash flow or owner earnings PER SHARE, not the company total. This is the base the projection grows from. | |
| current_stock_price | Yes | Current share price, used only to compute the margin of safety against the fair value. | |
| terminal_growth_rate | Yes | Perpetual growth rate after the first stage, in percent. Pass 2.5 for 2.5 percent. Range -5 to 15, and must be below the discount rate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world, non-destructive), and the description adds genuine behavioral context on top: the two-stage mechanics, the Gordon Growth terminal, and the warning that results are highly sensitive to discount and terminal rates and should be treated as a single point rather than an answer. It also discloses that outputs will not reconcile with the internal model, preventing a false-cross-check failure.
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 what the tool computes, then routing, then caveats — a sensible order with no filler. The third paragraph's framing ('This computes your assumptions, it does not endorse them') is slightly rhetorical but conveys a real limitation about interpreting a single result.
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, and the description compensates by naming all three returned values. Combined with the units-and-range detail in the schema and the safety annotations, an agent has everything needed to call this correctly and interpret the result.
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 per-parameter units, ranges and the discount-rate-above-terminal-rate constraint already documented, so the schema carries most of the load. The description still adds relational meaning the schema cannot: growth_rate applies over growth_years and then handsoff to terminal_growth_rate in perpetuity, which clarifies how two parameters interact.
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 first sentence names a specific verb (runs a two-stage DCF), the exact inputs it operates on (numbers you provide), and the three outputs (fair value per share, margin of safety, terminal-stage share of value). It also explicitly distinguishes itself from get_stock_valuation and its fade-based model, so an agent can separate the two without opening either 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?
Gives three concrete use cases (value under user assumptions, sensitivity testing, checking a DCF's arithmetic) and an explicit exclusion: do not use to look up Zyberno's own valuation. The alternative tool is named and the reason for divergence is explained, which is exactly the routing information an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns Zyberno's stored valuation record for a single US-listed company: Margin of Safety against a discounted cash flow estimate, the Brina Gap (the growth rate the business can fund from its own returns minus the growth rate its current price implies), the Brina Matrix quadrant those two produce together, the Zyberno quality score, and trailing twelve month fundamentals from SEC filings.
Use when the user names a company or ticker and wants to know how it is valued. This is also the tool for questions phrased without the framework's vocabulary: what growth rate is priced into a stock, what the market expects from a company, what a reverse DCF on it implies, whether its growth expectations look too high or too low, or whether a cheap-looking stock is actually a value trap. Do not use it to find or rank companies (use screen_stocks), to retrieve the published monthly lists (use list_flagged_stocks), or for price quotes, charts, news, analyst ratings, earnings dates, or non-US listings, none of which this server holds.
Records refresh on a rolling cycle of roughly two weeks per company, so figures can lag a company's newest filing for part of that cycle. Every response states the date its data was computed.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker symbol of a US-listed company, for example AAPL, MSFT, or BRK.B. Case insensitive. Non-US listings and most OTC ADRs are not covered and return no data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered; the description adds genuinely new behavior: a ~two-week rolling refresh cycle that can lag the newest filing, and the guarantee that every response states its computation date. That staleness disclosure is exactly the kind of context annotations cannot carry. It stops short of describing response shape or error behavior beyond the schema's 'returns no data' note, so not 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?
Well structured and front-loaded: what it returns first, when to use second, when not to use third, freshness caveat last. Slightly long – the interpretability examples ('what growth rate is priced into a stock', 'value trap') are useful routing signal but push length; still, no sentence 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?
No output schema exists, and the description compensates by enumerating the returned fields and the freshness caveat, which is the main risk an agent needs to communicate. Combined with the exhaustive use/do-not-use routing against five siblings, nothing an agent needs to call this 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?
Only one parameter and schema coverage is 100%, with the schema already documenting case insensitivity, BRK.B-style tickers, and the non-US/OTC exclusion. The description reinforces 'single US-listed company' but adds no syntax or format meaning beyond the schema. Baseline 3 is correct when the schema does the work.
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 ('Returns Zyberno's stored valuation record for a single US-listed company') and then enumerates exactly which computed fields come back (Margin of Safety, Brina Gap, Brina Matrix quadrant, quality score, TTM fundamentals). It names the sibling tools it is not (screen_stocks, list_flagged_stocks), so an agent can route without opening any 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?
Explicit positive trigger ('when the user names a company or ticker'), an unusually valuable paraphrase list covering how users actually phrase valuation questions (priced-in growth, reverse DCF, value trap), and explicit exclusions with the correct alternatives for each (screen_stocks, list_flagged_stocks). It even states what this server does not hold at all: quotes, charts, news, ratings, earnings dates, non-US listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a company's supply chain as the SEC annual reports state it: the suppliers it names and the customers that name it, each graded sole source, primary supplier or named, with the year the link was first reported, the share of revenue or of the input where a filing discloses one, and the sentence from the report with a link to it on SEC EDGAR. Also returns how many large companies name it as a supplier, how much of their market value depends on it, and links the reports stopped naming.
Use when the user asks who supplies a company, who its customers are, which companies depend on it, how concentrated its suppliers or customers are, or what is exposed if it stops supplying. Do not use it for valuation (use get_stock_valuation) or to search across companies (use screen_stocks).
Covers about 1,250 US-listed companies, from annual reports (10-K, 20-F) since 2013, updated nightly. Companies do not have to name their suppliers, so a missing link is not proof there is none. In Zyberno's tests these links did not predict share prices well enough to trade on: they describe a company and its risks.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker symbol of a US-listed company, for example NVDA or TSM. Case insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, and the description goes well beyond them: coverage universe (~1,250 US-listed companies), source documents (10-K, 20-F since 2013, updated nightly), a crucial null-semantics caveat that a missing link is not proof no link exists, and an explicit statement that the links are descriptive risk data rather than predictive signals. That is exactly the kind of expectation-setting an agent cannot get from structured fields.
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?
Well front-loaded: what it returns, then when to use it, then coverage and caveats. The third paragraph's note about Zyberno's backtests is mildly promotional but still carries behavioral value by forestalling misuse as a signal. Slightly long, but nearly every sentence does work.
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 still fully specifies the return shape (grades, years, disclosed shares, source sentences with EDGAR links, aggregate dependency metrics, discontinued links). Coverage limits, freshness, and interpretation caveats are all present, so an agent has everything needed to call it and read the result 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?
Only one parameter and schema description coverage is 100%, so the schema already explains the ticker format, case insensitivity, and example values. The description adds nothing parameter-specific beyond reinforcing the 'US-listed company' scope, 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 opening sentence gives a specific verb (returns) and a precisely bounded resource (a company's SEC-reported supply chain), then enumerates the constituent parts: named suppliers, customers that name it, link grades, first-reported year, disclosed shares, and cited filing sentences. An agent can distinguish this from valuation or screening siblings without opening any 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?
Explicit positive triggers are listed ('who supplies a company, who its customers are, which companies depend on it, how concentrated... what is exposed if it stops supplying') and explicit exclusions name the alternatives: get_stock_valuation for valuation and screen_stocks for cross-company search. Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the Zyberno Market Valuation Score, a single 0 to 100 reading of how expensive the US equity market is relative to its own history, combining the Buffett Indicator, the Shiller PE, the 10 year minus 2 year Treasury curve and the Baa credit spread.
Use for questions about the market as a whole, overall valuation levels, or whether US stocks broadly look expensive or cheap right now. Do not use it for any individual company, sector, or index price level, none of which it measures.
The score measures present valuation against history. It is not a forecast and not a market timing signal.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds important behavioral context beyond the annotations: the score is present valuation versus history, not a forecast or timing signal. Annotations already cover safety and idempotency; the remaining gap is minor because the return value is described at a high level.
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-loads the core definition, then usage boundaries, then limitations. Three short paragraphs with no wasted text, and each sentence contributes to correct invocation.
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?
Complete for a zero-parameter, read-only valuation tool: it defines the returned score, scale, inputs, intended scope, exclusions, and interpretation caveats. No output schema is present, but the description sufficiently explains what comes back.
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 no parameter semantics to clarify. Baseline is 4 under the scoring rules for zero-parameter tools.
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: returns the Zyberno Market Valuation Score, a 0–100 reading of US equity market valuation relative to history. It also names the underlying components and explicitly distinguishes the tool from individual-company, sector, or index-level valuation 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?
Gives clear positive usage guidance (market-wide valuation questions) and explicit exclusions (not individual companies, sectors, or index price levels). It does not name the specific sibling tools to use instead, so it stops short of fully explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the two lists Zyberno publishes each month from one fixed screen. The first holds companies where the Margin of Safety and the Brina Gap both read as undervalued, labelled Double Discount. The second holds companies that look cheap on trailing earnings power while the Brina Gap reads negative, labelled value trap. Takes no parameters: the thresholds, sector exclusions and ranking are fixed and match the published page.
Use when the user asks what the framework currently flags, or asks about the Double Discount or value trap lists by name. Do not use it for custom criteria (use screen_stocks) or for one named company (use get_stock_valuation).
Both labels describe where a company sits on two valuation measures at one moment. They are screen output, not recommendations, and neither label forecasts a return.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotent, closed-world), but the description adds genuine context beyond them: the screen is fixed, thresholds and sector exclusions are not adjustable, and results match a published page. It also disclaims interpretation ('screen output, not recommendations, and neither label forecasts a return'), which helps an agent relay results responsibly.
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 core action, then definitions, then routing, then caveats — a sensible order with no repetition. Slightly longer than needed; the final caveat sentence could be tighter, but each sentence carries distinct information.
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 burden of explaining results, and it does name and characterize both returned lists. It stops short of describing the record shape (fields per company, ordering, count), which is the remaining gap for a parameterless list 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?
Zero parameters gives a baseline of 4, and the description justifies the empty schema rather than ignoring it ('Takes no parameters: the thresholds, sector exclusions and ranking are fixed'), pre-empting an agent's attempt to pass filter arguments.
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 ('Returns the two lists Zyberno publishes each month from one fixed screen') and then defines the contents of both lists by name and criteria. An agent can distinguish this from screen_stocks or get_stock_valuation purely from the description.
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 enumerates the triggering user intents ('what the framework currently flags', asking for the Double Discount or value trap lists by name) and explicitly names the exclusion cases with the correct alternative for each (screen_stocks for custom criteria, get_stock_valuation for a single company). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches Zyberno's database of roughly 10,000 US-listed companies and returns those matching the numeric criteria you supply, ranked by a field you choose. All metrics are computed from SEC filings.
Use when the user wants to find, filter, rank, or count companies by their characteristics rather than asking about one company by name. Omit any filter you do not want applied; omitting all of them ranks the whole covered universe. Do not use it for a single known ticker (use get_stock_valuation), and do not use it to reconstruct the published monthly lists, which apply their own fixed thresholds, sector exclusions and curation (use list_flagged_stocks).
Filters combine with AND: a company must meet every one you supply, and a company missing a filtered metric is left out. Returns at most 25 companies plus the total number that matched, so a query that is too broad or too narrow reports its own breadth. Each result gives the ticker, name, market cap, margin of safety, Brina Gap, Zyberno Score and ROIC, with a link to the company's report.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many companies to return, 1 to 25. Defaults to 10. The total number that matched is reported regardless. | |
| sector | No | Restrict to one sector, from the SEC industry code. Media and internet platforms are Consumer Discretionary or Technology (there is no Communication Services sector). | |
| roe_min | No | Minimum return on equity in percent. | |
| sort_by | No | Field to rank the matches by, largest first. Defaults to market_cap. | |
| exchange | No | Restrict to one listing venue. | |
| roic_min | No | Minimum return on invested capital in percent. Pass 15 for 15 percent. | |
| eps_sue_max | No | Maximum standardised earnings surprise (SUE), range -4 to +4. | |
| eps_sue_min | No | Minimum standardised earnings surprise (SUE), a winsorized z-score bounded to the range -4 to +4. Positive means the latest reported earnings beat the trend-based expectation. Pass 1 for a one standard deviation beat. | |
| pb_ratio_max | No | Maximum price to book ratio. | |
| pe_ratio_max | No | Maximum trailing price to earnings ratio. Companies with no meaningful P/E, including loss makers, are excluded when this is set. | |
| brina_gap_max | No | Maximum Brina Gap in percentage points. Use a negative value to isolate companies whose price implies more growth than fundamentals support. | |
| brina_gap_min | No | Minimum Brina Gap in percentage points. Positive means the growth the business can fund exceeds the growth its price implies; negative means the price implies faster growth than the fundamentals support. Pass 3 for 3 percentage points. | |
| fcf_yield_min | No | Minimum free cash flow yield in percent. Pass 5 for 5 percent. | |
| peg_ratio_max | No | Maximum PEG ratio, price to earnings divided by growth. | |
| market_cap_max | No | Maximum market capitalisation in US dollars. | |
| market_cap_min | No | Minimum market capitalisation in US dollars, for example 2000000000 for 2 billion. | |
| eps_cagr_3yr_min | No | Minimum 3 year diluted EPS compound annual growth rate in percent. | |
| current_ratio_min | No | Minimum current ratio. Pass 1.5 for 1.5x. | |
| momentum_12_1_max | No | Maximum 12 minus 1 price momentum in percent. Pass a negative value to isolate fallers. | |
| momentum_12_1_min | No | Minimum 12 minus 1 price momentum in percent: total return including dividends over the last 12 months, skipping the most recent month. Pass 20 for 20 percent, or -30 for a 30 percent fall. Values are unbounded above, and the strongest names in the universe can read in the hundreds of percent. Companies listed under 13 months have no window and are excluded whenever any momentum filter is set. | |
| zyberno_score_min | No | Minimum Zyberno business-quality score, 0 to 100, from 13 weighted measures of profitability, cash-flow quality, stability and growth. 70 is the cut-off the Zyberno Strategy uses. | |
| debt_to_equity_max | No | Maximum debt to equity ratio, as a ratio not a percent. Pass 1.5 for 1.5x. | |
| earnings_yield_min | No | Minimum earnings yield in percent, the inverse of P/E. Pass 8 for 8 percent. | |
| net_margin_ttm_min | No | Minimum trailing twelve month net margin in percent. | |
| ev_ebitda_ratio_max | No | Maximum enterprise value to EBITDA ratio. | |
| market_cap_category | No | Restrict by size band, as an alternative to explicit market cap bounds. Bands are micro under $300M, small $300M to $2B, mid $2B to $10B, large $10B to $200B, mega $200B and above. Note that large excludes mega, so for the very largest companies use mega, and to cover both give market_cap_min instead. | |
| gross_margin_ttm_min | No | Minimum trailing twelve month gross margin in percent. | |
| margin_of_safety_max | No | Maximum Margin of Safety in percentage points. Pass 10 for 10 percent. | |
| margin_of_safety_min | No | Minimum Margin of Safety in percentage points, where positive means the price sits below the discounted cash flow estimate. Pass 10 for 10 percent, not 0.1. Negative values are allowed. | |
| revenue_cagr_3yr_min | No | Minimum 3 year revenue compound annual growth rate in percent. | |
| momentum_12_1_pct_max | No | Maximum cross-sectional momentum percentile, 0 to 100. | |
| momentum_12_1_pct_min | No | Minimum cross-sectional momentum percentile, 0 to 100, where 100 is the strongest momentum in the covered universe. Prefer this over the raw percentage when the user asks for strong or weak momentum in relative terms. Percentiles refresh on a monthly recompute, so they can lag the raw figure. | |
| price_to_52w_high_max | No | Maximum ratio of current price to the 52 week high. Pass 0.7 to find stocks at least 30 percent below their high. | |
| price_to_52w_high_min | No | Minimum ratio of current price to the 52 week high, where 1.0 means the stock is sitting at its high. Pass 0.95 for within 5 percent of the high. | |
| revenue_yoy_growth_min | No | Minimum year over year revenue growth in percent. | |
| operating_margin_ttm_min | No | Minimum trailing twelve month operating margin in percent. | |
| owner_earnings_yield_min | No | Minimum owner earnings yield in percent. Owner earnings is the cash figure the discounted cash flow behind Margin of Safety is built on. | |
| fundamental_growth_rate_max | No | Maximum fundamentally fundable growth rate in percent. | |
| fundamental_growth_rate_min | No | Minimum fundamentally fundable growth rate in percent, defined as ROIC times reinvestment rate. This is the first half of the Brina Gap on its own. | |
| interest_coverage_ratio_min | No | Minimum interest coverage ratio, operating income over interest expense. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/closed-world, but the description adds substantive behavior the annotations cannot: filters AND together, companies missing a filtered metric are silently dropped, results are capped at 25 with the true match count reported, and ranking is largest-first. That last point is the only real gap territory, and it is covered; the 4 rather than 5 reflects that the silent-exclusion rule is stated once without enumerating which metrics are commonly sparse.
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 what it does, then when to use it, then the AND/cap mechanics, then the return shape — a sensible order with almost no filler. Slightly dense in the final sentence where the returned field list is packed in, but every clause carries information an agent needs given there is no output schema.
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 40-parameter, zero-required, no-output-schema tool, the description covers the pieces that matter: universe size and data provenance, combination semantics, silent-exclusion edge case, result cap plus total-match count, and a list of returned fields. Nothing an agent needs to call this 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?
With 100% schema coverage the schema carries per-parameter meaning, so the baseline is 3; the description earns a bump by explaining cross-parameter semantics the schema cannot express — AND combination, omission behavior, and the consequence that a broad or narrow query reports its own breadth via the match total. It does not add per-parameter detail beyond the already thorough 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?
States a specific verb and resource ('Searches Zyberno's database of roughly 10,000 US-listed companies'), plus the exact operation contract: match numeric criteria, rank by a chosen field, metrics from SEC filings. It also names the two sibling tools it is not (get_stock_valuation, list_flagged_stocks), so an agent can route 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?
Explicit when-to-use ('find, filter, rank, or count companies by their characteristics rather than asking about one company by name') and two explicit when-not-to-use cases with the correct alternative for each. Also states the empty-filter default behavior, so the agent knows what omitting everything does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a Monte Carlo simulation over a portfolio balance and returns the distribution of possible end values: percentiles, mean, median, and if you give a goal amount, the share of simulated paths that reached it. Returns are drawn from a normal distribution using the expected return and volatility you supply.
Use when the user asks about the range or probability of outcomes rather than a single projected number, for example the odds of reaching a target, or how much volatility widens the spread. Do not use it to value a company (use calculate_dcf_value or get_stock_valuation), and do not use it for retirement withdrawal, tax, or drawdown-sequencing questions, which it does not model.
The simulation propagates the assumptions you give it. Normally distributed returns understate real market tail risk, and the output is a property of the inputs, not a prediction about any real portfolio.
| Name | Required | Description | Default |
|---|---|---|---|
| years | Yes | How many years to simulate forward. | |
| goal_amount | No | Optional target end value. When set, the result reports the share of simulated paths that finished at or above it. | |
| simulations | No | Number of simulated paths. Defaults to 10000. More paths stabilise the tails and cost more time. | |
| fee_rate_pct | No | Annual fee drag in percent, for example a fund expense ratio. Defaults to 0. | |
| current_balance | Yes | Starting portfolio value in currency units. | |
| inflation_rate_pct | No | Annual inflation in percent. When set above 0, results are expressed in today's purchasing power. Defaults to 0. | |
| monthly_contribution | No | Amount added every month. Defaults to 0. | |
| annual_volatility_pct | Yes | Annual standard deviation of returns in percent. Pass 15 for 15 percent. Broad equity indices have historically run in the mid teens. | |
| expected_annual_return_pct | Yes | Expected average annual return in percent. Pass 7 for 7 percent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it discloses the normal-distribution assumption, warns that this understates tail risk, and frames the output as a property of inputs rather than a prediction. Those caveats are exactly the context an agent needs to avoid over-claiming results.
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 tight paragraphs in a deliberate order: what it does and returns, when to use it versus alternatives, then modeling caveats. Every sentence carries routing or behavioral 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?
There is no output schema, yet the description enumerates the return contents (percentiles, mean, median, goal-hit share), the distributional assumption, and the tool's limits. For a 9-parameter simulation tool, an agent has everything needed to call it and to report results honestly.
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 adds cross-parameter meaning by stating that returns are drawn from a normal distribution using the supplied expected return and volatility, and that goal_amount conditionally produces a hit-rate. It doesn't add detail on simulations, fee drag, or inflation beyond what the schema already documents.
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 ('Runs a Monte Carlo simulation over a portfolio balance') and immediately names the output shape: percentiles, mean, median, and goal-hit share. It explicitly distinguishes itself from calculate_dcf_value and get_stock_valuation by naming them as the wrong tool for valuation questions.
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 an explicit trigger ('when the user asks about the range or probability of outcomes rather than a single projected number') with concrete examples (odds of reaching a target, volatility widening the spread). It also lists explicit exclusions — company valuation with named alternatives, plus retirement withdrawal, tax, and drawdown sequencing — which the tool does not model.
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.
get_supply_chainscreen_stocks2 fields changedInput schema / properties / sector / descriptionPrevious value: -"Restrict to one sector, spelled as Zyberno stores it, for example Technology, Healthcare, Industrials, Energy, Consumer Cyclical, Financial Services, Real Estate, Utilities, Basic Materials, Communication Services, Consumer Defensive."New value: +"Restrict to one sector, from the SEC industry code. Media and internet platforms are Consumer Discretionary or Technology (there is no Communication Services sector)."Input schema / properties / sector / enumAdded value: +[
+ "Technology",
+ "Healthcare",
+ "Financial Services",
+ "Consumer Discretionary",
+ "Consumer Staples",
+ "Industrial",
+ "Energy",
+ "Materials",
+ "Utilities",
+ "Real Estate"
+]screen_stocks1 field changedInput schema / properties / zyberno_score_min / descriptionPrevious value: -"Minimum Zyberno quality score, on a 0 to 100 scale combining profitability, balance sheet strength and earnings consistency."New value: +"Minimum Zyberno business-quality score, 0 to 100, from 13 weighted measures of profitability, cash-flow quality, stability and growth. 70 is the cut-off the Zyberno Strategy uses."screen_stocks2 fields changedInput schema / properties / momentum_12_1_max / descriptionPrevious value: -"Maximum 12 minus 1 price momentum in percent. Use to isolate laggards."New value: +"Maximum 12 minus 1 price momentum in percent. Pass a negative value to isolate fallers."Input schema / properties / momentum_12_1_min / descriptionPrevious value: -"Minimum 12 minus 1 price momentum in percent: total return including dividends over the last 12 months, skipping the most recent month. Pass 20 for 20 percent. Companies listed under 13 months have no window and are excluded whenever any momentum filter is set."New value: +"Minimum 12 minus 1 price momentum in percent: total return including dividends over the last 12 months, skipping the most recent month. Pass 20 for 20 percent, or -30 for a 30 percent fall. Values are unbounded above, and the strongest names in the universe can read in the hundreds of percent. Companies listed under 13 months have no window and are excluded whenever any momentum filter is set."analyze_stockcalculate_dcf_valueget_brina_gap_moversget_market_valuationget_stock_valuationget_us_market_valuationlist_flagged_stocksscreen_stockssimulate_portfolio_outcomesanalyze_stockget_brina_gap_moversget_market_valuationIntrinsic stock value from SEC filings: DCF, EPV, Graham, moat signals. Deterministic, not guessed.
Value investing for US stocks: SEC filings, 13F guru holdings, intrinsic value, AI briefings.
Free US stock research from SEC filings: five plain answers on 3,000+ stocks. No API key.
Normalized SEC EDGAR fundamentals. 3 of 6 tools free; the rest $0.04-$0.10 per call in USDC.
Add one secure layer between your agents and this server.