Valuein — SEC EDGAR Fundamentals & Smart-Money Data

Run Bounded Factor Backtest

run_backtest

Read-onlyIdempotent

A SMALL, BOUNDED, in-Worker sanity-check backtest — NOT a full-universe backtesting engine. Answers a quick question like 'does this factor actually work on these 5 names over the last year' inline, mid-conversation, without leaving MCP. Composes two existing tools (get_pit_universe + get_pit_valuation_ratios) across up to 10 tickers x 12 rebalance dates (120 cells): for each rebalance date, checks which requested tickers were in the survivorship-free PIT universe on that date (dropping — never erroring on — a ticker not yet listed or already delisted), then pulls each surviving ticker's point-in-time valuation multiples and computes the forward return to the NEXT rebalance date from the raw (unadjusted) close. Returns a flat {rebalance_date, ticker, factor_values, forward_return_pct} grid plus a small factor<->forward-return correlation per requested factor — a quick cross-sectional signal check, NOT a transaction-cost-aware portfolio simulation or a statistically validated backtest result. If the requested grid exceeds 120 cells, this tool does NOT silently truncate — it returns a stream_fallback response (signed Parquet download URLs, same shape as get_compute_ready_stream) and tells you to use those URLs. For a REAL full-universe, multi-date, survivorship-free backtest, use the Python SDK's AlphaEngine (pip install valuein-sdk) looped over as_of dates client-side — this tool is explicitly the small complement to that, not a replacement for it. Available on every plan; coverage follows your plan tier same as the two tools it composes.

Input Schema

TableJSON Schema

Name	Required	Description
`factors`	No	Which of get_pit_valuation_ratios's own output fields to include as factor_values. One or more of: pe_ratio, ps_ratio, pb_ratio, ev_ebitda, ev_revenue, fcf_yield_pct, gross_margin_pct, operating_margin_pct, net_margin_pct. Omit to include all of them.
`tickers`	Yes	1-10 stock ticker symbols, e.g. ["AAPL","MSFT"].
`rebalance_dates`	Yes	1-12 historical dates (YYYY-MM-DD) to snapshot valuation multiples on. Order does not matter — the tool sorts them chronologically. Forward return is computed from each date to the NEXT one in the sorted list.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	Yes
`_meta`	Yes	Provenance envelope — data lineage for every MCP response
`cells`	No
`capped`	Yes
`method`	Yes
`caveats`	Yes
`dropped`	Yes
`factors`	Yes
`streams`	No
`summary`	No
`tickers`	Yes
`pit_safe`	Yes
`next_step`	No
`grid_cells`	Yes
`cells_computed`	Yes
`rebalance_dates`	Yes
`source_tools_used`	Yes

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds rich behavioral context: it composes two tools, drops tickers not in the PIT universe (never errors), computes forward return to the next rebalance date, returns a flat grid and factor-return correlations, and provides a stream_fallback for large grids. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively long but well-structured, with clear sentences and logical flow. Every sentence adds necessary context (scope, behavior, fallback, alternative). It could be slightly more concise, but it effectively communicates all critical information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (composing two tools, handling streaming, explaining limitations), the description covers all critical aspects: scope, behavior on missing tickers, forward return computation, output format, fallback mechanism, and comparison to alternatives. The output schema exists and the description explains the return shape, so no gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema: it explains that factors come from get_pit_valuation_ratios, that tickers and rebalance_dates follow specific patterns, that rebalance_dates are sorted automatically, and that forward return is computed to the next date. This provides meaningful additional guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies the tool as a 'SMALL, BOUNDED, in-Worker sanity-check backtest,' clearly distinguishing it from a full-universe backtesting engine. It states the exact scope (up to 10 tickers x 12 dates) and the composed tools (get_pit_universe + get_pit_valuation_ratios), providing a precise verb+resource+scope definition that differentiates it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('quick question mid-conversation') and when not to ('REAL full-universe... backtest'), naming the alternative (Python SDK's AlphaEngine). It also explains what happens if the grid exceeds 120 cells (stream_fallback response with download URLs).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Valuein — SEC EDGAR Fundamentals & Smart-Money Data tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation5/5

Each tool has a distinct purpose with detailed descriptions that clarify differences. Overlaps like get_peer_comparables vs screen_universe are well-differentiated by scope (single company vs cross-sectional). Similarly, get_insider_sentiment vs get_smart_money_flow are clearly distinguished by data sources and methodology.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., create_report, get_financial_ratios, delete_alert). No mixing of conventions or inconsistent verbs.

Tool Count2/5

With 69 tools, the count far exceeds the 25+ threshold for 'too many'. While the domain is broad, the sheer volume likely overwhelms agents and increases selection complexity.

Completeness4/5

The tool set covers a wide range of SEC filings, ratios, smart-money data, alerts, reports, and more. Minor gaps exist (e.g., no options or detailed debt data), but most analyst workflows are supported.

Run Bounded Factor Backtest

Input Schema

Output Schema

TDQS

Glama MCP Gateway

TDQS

Resources