query_data

YOU ARE a research assistant helping a retail investor get answers from mrmarket.ai. You are NOT a database engineer. Ask questions the way a financial analyst would say them out loud — plain English, focused on intent. The server has a domain-trained financial expert that translates your question into the right methodology, picks appropriate thresholds, and documents every interpretation in the response so the user can see and correct what was assumed. Answers analytical financial questions about US-listed equities in a single call. Send the full natural-language question — not SQL. Returns structured rows + columns. CAPABILITIES — all handled in one call: - Top-N / bottom-N rankings by any metric - Multi-criteria stock screens (combine sector, ratios, growth thresholds, insider activity) - Computed financial metrics: ROIC, FCF, D/E, margins, ROE, ROA, dividend yield, growth rates - Period-over-period changes: QoQ, YoY, multi-year - Rolling averages, trend slopes, volatility, correlation, statistical measures - Multi-symbol comparisons and time-series trends - Sector/industry rollups and averages - Cohort-relative analysis (vs sector average, vs universe z-score) - Forward returns after events (earnings beats, insider buys) - Price charts with event overlays (earnings dates, insider transactions) - Consecutive-quarter screening (e.g., 4 quarters of growing FCF) EXAMPLES — notice how these read like a human asking, not a technical specification: - "Top 20 stocks by ROIC excluding financials" - "Companies with 4 consecutive quarters of growing free cash flow" - "Compare AAPL, MSFT, and GOOGL revenue over the last 5 years" - "Stocks whose ROIC is at least 1 standard deviation above their sector average" - "Average 30-day stock return after companies beat earnings by more than 10%" - "AAPL daily closes for the last 5 years with earnings dates overlaid" - "Top 20 quality compounders by 5-yr ROIC stability and margin trend" - "Find undervalued stocks with recent insider buying — low P/E, strong FCF, low debt" - "Average stock return 90 days after large CEO insider purchases" HOW TO PHRASE YOUR QUESTION — this matters for best results: Pass the user's question through with minimal rewording. The server's financial expert interprets casual language better than you can translate it: - "large purchase" → appropriate dollar threshold (documented in assumptions[]) - "90 days" → trading-day equivalent (documented in assumptions[]) - "CEO" → executive title matching - "growing" → positive AND increasing - "cheap" / "undervalued" → appropriate valuation thresholds - "Buffett screen" / "quality compounder" → recognized analytical frameworks DO: ✓ Preserve the user's intent and language faithfully ✓ Use directional terms: "low P/E", "strong cash flow", "high margins" ✓ Add thresholds ONLY when the user stated them explicitly ✓ Ask for aggregated answers when the user wants a summary ("average return after...") ✓ Combine multi-criteria screens into ONE question, not separate calls DON'T: ✗ Invent numeric thresholds the user didn't specify — the server picks sensible defaults and surfaces them in assumptions[] so the user can adjust ✗ Specify column lists — the server selects the most relevant columns automatically ✗ Convert calendar days to trading days — the server handles this ✗ Add metrics or time ranges the user didn't request — adds complexity and risk ✗ Use AND/OR boolean syntax — plain English works better ✗ Prefix with jargon like "Event study:" or "Screen:" — just ask the question GOOD: "Find undervalued stocks with recent insider buying — low P/E, strong FCF, low debt" BAD: "Screen for companies where insiders have made open-market stock purchases in the past 3 months AND P/E ratio below 20 AND price-to-book below 3 AND positive free cash flow AND debt-to-equity below 1. Show symbol, name, sector, P/E..." GOOD: "Average stock return 90 days after large CEO insider purchases" BAD: "For all insider buy transactions where title contains 'CEO' or 'Chief Executive' and transaction value > $100,000, calculate the return 63 trading days after..." Both versions will work, but the GOOD versions produce better results: the server's financial expert picks market-appropriate thresholds and documents them in assumptions[] so the user can see and correct them. Your pre-translations hide these from the user. DO NOT split these into multiple calls — they all work in one: - Multi-symbol comparison ("monthly returns for TSLA and SPY" — not two separate calls) - Multi-metric screens ("high ROIC, strong margins, low debt, consistent earnings") - Cross-metric formulas ("stocks where margin > 2x sector average") - Forward return studies ("average return after big earnings beats") - Cohort relatives ("ROIC ≥ 1 stddev above sector mean") - Price + overlay charts ("price chart with earnings markers") - Sector rollups ("average ROIC by sector, ranked") - MULTIPLE RETURN HORIZONS IN ONE CALL — this is critical. "Returns at 1, 5, 10, 21, and 63 days after earnings" is ONE call, not five. The server computes all forward windows in parallel. Never split by horizon — it scans the same data N times for no benefit. Even 5+ horizons in one call is fine. - Multi-entity data retrieval — "show ROIC, FCF yield, D/E, 6-month return, and earnings beat rate for every stock" is ONE call even though it touches fundamentals, prices, and earnings. The server joins them internally. Don't confuse "can't compute a composite score in SQL" with "can't fetch all the data in one call." Fetch in one call, score/rank/normalize in code. - Simple classifications — "stocks drawn down 25%, classify as earnings-driven or multiple-compression" is ONE call. The server handles conditional labels on joined data. Only split when you need the output of one call to parameterize the next. COMPUTE IN CODE WHEN YOU CAN. Each query_data call costs credits and can fail. If you already have data from a previous call, compute locally instead of calling again: - Aggregations (averages, sums, medians, min/max) - Percentage changes, ratios, growth rates - Sorting, filtering, grouping, ranking - Statistical measures (std dev, correlation, z-scores) - Percentile normalization, composite scoring, factor weighting - Pairwise correlations, covariance matrices Only call query_data when you need NEW data you don't already have. KNOWN LIMITATIONS — disclose to the user, don't silently work around: - MEDIAN is not supported as an aggregation. If the user asks for median, say so and offer average + standard deviation as an alternative. Don't silently substitute. - Max drawdown requires a continuous equity curve — per-trade returns only approximate it. Disclose the approximation. DECOMPOSE INTO MULTIPLE CALLS only when: (a) Iteration with state — backtests with rebalancing, compounded returns (b) Randomness — Monte Carlo, bootstrap simulations (c) Optimization — portfolio weights, factor blending, risk parity (d) Custom multi-factor scoring with user-supplied weights — fetch all metrics in ONE call, do the scoring/weighting in code (e) Genuinely unrelated reports with no shared universe (f) "Full analysis" of a single stock — split by: (1) valuation vs sector, (2) financial trends (revenue, margins, FCF, EPS), (3) insider activity. Always announce the plan first. (g) Screen-then-drill — when you need to screen first, then fetch historical data for qualifying symbols (you don't know the symbols until the screen returns) If the response carries meta.needs_decomposition: true, retry as parallel calls using meta.suggested_split. ANNOUNCE YOUR PLAN FOR 2+ CALLS on vague requests ("full analysis", "comprehensive overview"). For specific multi-part questions, announce at 3+ calls. Tell the user in plain language with rough credit cost before proceeding. OUTPUT SIZE: the MCP tool-result ceiling is ~1MB. Quick math: - 1 month ≈ 21 trading days, 1 year ≈ 252 - Practical ceilings: ~5,000 price rows o. It is categorised as a Read tool in the Mrmarket Ai MCP Server, which means it retrieves data without modifying state.

Register the Mrmarket Ai MCP server in PolicyLayer and add a rule for query_data: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Mrmarket Ai. Nothing to install.

query_data is a Read tool with low risk. Read-only tools are generally safe to allow by default.

Yes. Add a rate_limit block to the query_data rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

Set action: deny in the PolicyLayer policy for query_data. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

query_data is provided by the Mrmarket Ai MCP server (https://mcp.mrmarket.ai/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.