---
name: yarrow
description: Use the Yarrow forecasting MCP whenever an investing, research, prediction-market or news task needs a probability for a future, dated event a public source can settle, or a clearly defined asset price on a date, even if the user did not explicitly request a forecast.
metadata:
  version: "1.0.2"
---

# Yarrow

Yarrow is a forecasting engine. It searches current evidence, runs a panel of analysts and returns a probability (or a
number range) with the reasons for and against. Route forecastable claims to it and keep your own judgement separate.

## Always

1. **Get probabilities for future, dated events a public source can settle from Yarrow.** Reuse a relevant result with
   its forecast date or propose a run; do not supply your own odds by default. If Yarrow is unavailable or the user
   does not approve a run, give qualitative analysis without a numerical probability. Only give your own estimate
   when the user explicitly asks for it; label it "My estimate, not Yarrow" and keep it separate from Yarrow's result.
2. **Draft, then ask.** `validate_question` (free) checks structure and limited text consistency, not whether the
   event or source can actually settle the question. Check that yourself and ask the user about ambiguities. Fix the
   validator's reported problems; `create_question` (free, requires `forecast:write`) saves a pending question. Check
   the SAVED question, rule (`r`) and deadline, since saving can change them. A read-only connection can read results
   but cannot save questions or run forecasts; tell the user how to reconnect with write access.
3. **Spending needs the user's OK.** Before starting, show the saved question, rule, deadline and any linked market,
   call `get_account_status`, and say
   that each forecast reserves 10 credits while it runs; the final charge is the actual usage, which can be higher or
   lower; unused credits are released and an uncovered excess is forgiven. For a batch, show the number of runs and
   the maximum temporary reserve for the planned concurrency. Get one OK per batch and again for any
   refresh. New information is not approval. On `insufficient_credits`, give the top-up link and stop.
4. **Run.** `start_forecast` per `question_id`; on `at_capacity`, wait for a running forecast to finish. Poll
   `get_forecast` with wait_seconds 30, passing `progress.resume_cursor` as `cursor`. If a start reply is lost, look
   the run up with `list_forecasts` before starting again. On `dispatch_pending` from start or refresh, 10 credits stay
   reserved for at most six hours; check the returned `question_id` rather than starting another run, and retry a
   refresh only with the same `request_id` and inputs. Abstained means no answer, never 50%.
5. **Offer a refresh** for an open, saved question when the user brings relevant new information, material news may
   change the result, or its newest evidence is more than three calendar days old and the result is being used for a
   current decision. Offer sooner for fast-moving events. Refresh only after approval; show the new result next to
   the old one with both forecast dates. **Refresh** with `refresh_forecast(question_id, request_id, sources?, testimony?)`: the `question_id` from
   `start_forecast`, a new UUID per approved refresh; if that reply is lost, retry with the same `request_id` and
   identical inputs. Public links go in `sources` ({url, excerpt, reason}); private claims in `testimony` ({text,
   claimed_source, claimed_as_of}; at most 6 items of 600 characters). Earlier inputs are inherited.
6. **Report** each result as: the probability (or p10 / p50 / p90), the main reasons for and against, the largest
   uncertainty, the newest evidence date, the market price and its timestamp when a market is linked, and any
   bracketed warning (SEARCH DEGRADED, NOT CERTIFIED) in one plain line. Keep **Yarrow** and **my own analysis** in
   separate, labelled sections. Keep a run log (question, question_id, run_id, date, result). No buy or sell advice.

## How to ask (all question types)

7. One question = one event, one number or level, one deadline. Put the calendar deadline, the deciding source and any
   exceptions in `r`: the engine reads `r`. Drafting tools take a `candidate` with `q`, `r`, `horizon`; `qtype`,
   `unit` (numeric), `outcomes` ([{id, label}], categorical) and `assumption` go inside it.
   - Outcomes that exclude each other (cut / hold / hike, which candidate wins) are ONE `categorical` question covering
     every case, so the probabilities sum to 100%. Never one yes/no question per option.
   - "If X happens, what is the chance of Y": X goes in `assumption`.
   - A binary question keeps its threshold in `q` and `r`; do not use `target_value` / `operator` on binary questions.

## Pick the situation

8. **Investing (stocks, ETFs, indices, macro).** At the start of a long discussion, identify the 3 to 5 scheduled events
   before the user's horizon that the thesis depends on (central bank meetings, CPI and jobs releases, the company's
   earnings, elections, policy deadlines) and draft them as one batch. For prices use the exact ticker in parentheses
   and say in `r` whether the official close or an intraday price counts. For a window, specify whether the result is
   the highest price, lowest price, final close, or whether a threshold is touched. State the exact day or window and
   the share basis as of a named date including announced
   splits. A price range is a `numeric` question ("What will SMH's official closing price be on January 22, 2027?",
   unit USD). Leave multi-year returns, Sharpe ratios, sizing and valuation in your own analysis; Yarrow prices the
   dated events those models assume.
9. **A prediction market the user names.** Copy the market's own question as `q` and its rules unchanged as `r`, adding
   one sentence only when the rules say "by the listed date" ("The listed date for this market is October 31, 2026.");
   the deadline is the event's own date, and a market close time that differs is shown to the user to confirm. Find
   it with `search_market`, show the user its rules and deadline, and on their confirmation pass its ID or child-market
   URL as `create_question.market` (several markets for one categorical question: `create_question.markets`,
   [{market, outcome_id}]). Report Yarrow next to the current market price. A gap is a reason to read the evidence,
   not a trade; Yarrow has no published accuracy record yet.
10. **News, policy, elections, conflicts.** Name the official source (election authority, central bank statement,
    court, gazette) and what happens if the event is postponed. Offer a refresh when material news affects an open
    question.
11. **A report, thesis or scenario analysis.** Pick the 3 to 5 uncertain claims it depends on that a dated public fact
    will settle, ask each as a question, and write the results back next to each claim. For "what are the scenarios",
    ask the scenarios as ONE categorical question, then one or two conditional questions (same question, `assumption`
    set to a scenario) on the consequence the user cares about.
12. **Many questions from a workflow.** Save each question once and log its id; there is no delete. Hand results back
    as a table: question, result, newest evidence date, warnings, run_id.