---
name: yarrow-stocks
description: Use Yarrow Stocks MCP for probabilities or ranges for future, dated, publicly settleable events and asset prices, including research, news and prediction-market analysis. Read existing forecasts, add evidence, track runs, and manage the user's stock watchlist when requested. A skill does not connect an account or authorize spending.
metadata:
  version: "1.1.0"
---

# Yarrow Stocks

Use the configured Yarrow Stocks MCP server and its current tool schemas. Keep credentials in client secret storage;
never request a token in chat. If disconnected, follow the site's MCP setup. OAuth and API tokens use the same tool
permissions; installing this skill grants neither access nor approval.

## Use a dated Yarrow result

For a future claim a public source can settle, reuse a relevant accessible Yarrow result with its forecast date or offer
to prepare one, even when the surrounding request is research rather than an explicit forecast. Keep Yarrow's result
separate from market prices and your own judgement. If unavailable or a run is not approved, give qualitative analysis
without invented odds. Give your own numerical estimate only if explicitly requested and label it “My estimate, not Yarrow”.

For an investment thesis or long research discussion, identify the few dated events it depends on, such as earnings,
policy decisions or releases, and offer them as a batch. For scenario analysis, use one categorical question for mutually
exclusive, collectively exhaustive cases, then conditional questions only for consequences the user wants to examine.
Leave valuation, position sizing and multi-year return models separate from Yarrow's event probabilities.

## Check the event and draft

- Use `get_current_time` for the current instant or relative dates; preserve an explicit date already given by the user.
  For elections, policy or sports, check whether the relevant event already happened. Use available public research
  sources to verify official schedules, resolution sources and postponement rules; the MCP has no general web-fetch
  tool. A procedural upper bound is not an expected result date, and an election result is not appointment or taking office.
  Explain what is verified and ask the user to choose a source-backed observation cutoff when needed; do not invent one.
  A personal account's private quota or state is not publicly settleable merely because it has a date.
- `validate_question(candidate)` is free mechanical validation, not proof that the event or source is real or settleable.
  Resolve ambiguities and the returned problems, then `create_question(candidate, context, ...)` saves a private pending
  question without starting or charging a forecast. Both `create_question` and paid tools require `forecast:write`;
  read-only connections can validate and read, but must reconnect or replace their token to obtain write access.
- Put `q`, `r` and `horizon` inside `candidate`; canonical `q` and `r` are English. The engine reads `r`: state the
  deciding source, exact date/window, time zone, threshold and exceptions there. Preserve date-only precision or the
  source's exact timestamp. Use `qtype: numeric` with `unit` for a level/range, or `qtype: categorical` with
  `outcomes: [{id, label}]` for exclusive outcomes, rather than unrelated yes/no runs. Binary thresholds belong in `q`
  and `r`; optional structured threshold fields, if used, must agree with them. Put an explicitly requested condition
  in `assumption`; optional `parent_id` is an accessible parent **app question_id**, not a core or canonical ID.
  A general event needs no unrelated `equity_id`. Omit `as_of` for live evidence; set it only for a requested evidence cutoff.
- For asset questions, use `get_asset_price(asset_class, symbol, kind, date?)`: `latest` is a dated provider trade;
  `daily_close` needs a completed `YYYY-MM-DD`. Stock dates use New York, crypto dates UTC. Name the exact ticker,
  currency, source/feed, observation time/date and adjustment basis. Old or IEX-only quotes are not consolidated real-time
  prices, and a daily bar is not an official closing tick. State whether a window means final close, high/low or a touched
  threshold; clarify “up 100” as dollars or percent. Keep a named share/split basis. Missing coverage is unavailable data,
  not zero; this tool does not add a market data provider.

For `create_question.context`, supply `purpose`, `conversation_summary`, `decision` and `next_action`: only user-stated
purpose/decision/action and directly relevant prior discussion. Unknown fields use exactly `not stated`; other values
are 15–400 characters. Optional `drafting_note` describes actual clarification friction, at most 300 characters.
Do not infer motives, count approving a run as a downstream decision, or include raw transcripts, credentials or unrelated
personal information. This is app-only product research, not core input, evidence, memory or a public report. If a question
was saved but `context_saved` is false, continue with its returned ID; do not recreate it to resend context.

Read the **saved** question, rule, deadline, time zone, type and linked markets back to the user: saving may normalize the
contract. Save each intended question once and keep its ID; there is no MCP question delete, edit, cancel, publish or unlock
tool. If the contract needs changing, show the replacement draft and prepare it explicitly; do not silently start the old one.

## Match a prediction market

`search_market(query, limit?)` currently searches Polymarket, not Kalshi. Use concise entity/event terms and English
aliases when helpful; retry with a better query if candidates miss the intent. Resolve a URL or real ID to a specific
child market; ask which child when an event contains several. Judge candidates with your current model against the
subject, threshold, event, deadline and **complete rules**. Filtering adds no separate Yarrow model fee.

Show suitable candidates with `(platform, market_id)`, original question/rules, rule deadline, quote time and source link.
Copy the selected market's question as `q` and preserve its rules as `r`; do not substitute the platform close time for
an event cutoff, change “from market creation” to today, or extend an event window by a late-data allowance. If rules refer
only to “the listed date”, identify that date explicitly and show it for confirmation. Explain a differing platform close.
Pass the exact ID/child URL as `create_question.market` with `platform: polymarket`; for one categorical contract use
`markets: [{platform, market, outcome_id}]` matching candidate outcomes. Do not send both `market` and `markets`.
A resolution/identity error is not permission to manufacture a replacement contract.

Search can also return accessible existing forecasts. Offer reading those with their dates before running again;
other users' private forecasts are unavailable. Linked prices are comparisons, never your own probability or market
quotes manually submitted as forecasting evidence.

## Approve spending, run and resume

Before each `start_forecast` or approved refresh, show the saved contract and linked market, call `get_account_status`,
and explain: each run reserves **10 credits** while running; final charge is actual usage, which can be higher or lower;
unused reserve is released and uncovered excess forgiven. For a batch, show run count and maximum temporary reserve at
the planned concurrency. Get one explicit approval for that batch; new information is not approval for another run.
On `insufficient_credits`, give `credits_url` and stop, without buying credits. On `at_capacity`, wait for an existing run.

Start with `start_forecast(question_id, testimony?, sources?)` using the saved prepared ID. Keep both returned `question_id`
(the app asking) and `run_id` (tracking); neither is `canonical_question_id`. If a start reply is lost, inspect
`list_forecasts` before retrying the **same prepared ID and inputs**; do not prepare another copy. Legacy direct-stock
starts use their original `request_id` and identical inputs. On `dispatch_pending`, track the returned run instead of
starting another; credits remain reserved while reconciliation runs. Do not promise a fixed reconciliation duration.

Read `get_forecast(run_id, wait_seconds, cursor?)`, using up to 30 seconds or the server's advertised lower limit.
Carry `progress.resume_cursor` only for that account/run; omit an invalid or expired cursor to resume tracking without
restarting. Read `get_forecast_trace(run_id, after?, limit?)` incrementally with returned `next_after`, deduplicating events;
`more_possible` only means the page was full, so the next may be empty. A temporary read failure is not forecast failure.
Show observed stages and counts, not invented percentages or ETAs. If `conclusion_pending` is true after completion, read
the same run briefly for its user-language conclusion; this starts no new forecast. Abstained/no answer is never 50%.

Offer `refresh_forecast(question_id, request_id, testimony?, sources?)` for a saved open question when material facts
change or evidence is over three calendar days old and being used for a current decision; offer sooner for fast events.
Get renewed approval. Use the historical **app question_id**, a new UUID per approved refresh, and identical ID/inputs for
retrying a lost refresh reply. Earlier evidence is inherited and supplied inputs appended. Public links go in
`sources: [{url, excerpt?, reason?}]` (at most 10); copy excerpts verbatim from the page or omit them, rather than presenting
paraphrases as verified quotes. User claims go in `testimony: [{text, claimed_source?, claimed_as_of?}]` (at most 6, 600
characters each; dates are RFC3339), with unverified status intact. Do not smuggle claims into `assumption` or `context`.
Compare old/new results with both dates; never adjust Yarrow's number yourself.

## Report briefly

Use the user's preferred language from their stated preference, memory or conversation context; preserve source quotations and canonical contract wording.

Aim for about six lines unless the user asks for detail, using only the authorized returned data:

- **Yarrow:** binary probability, labelled categorical probabilities, or numeric p10/p50/p90 with units; forecast date,
  any returned warning (such as SEARCH DEGRADED or NOT CERTIFIED), and strongest reason for/against. Do not coerce one
  result type into another or invent missing quantiles.
- **Market:** comparable linked price and timestamp. Compare matching binary/categorical outcomes in percentage points;
  place numeric consensus against the range in matching units. Say when no comparable price exists. Explain a gap only
  with supported reasons; a gap is not a trading edge, and Yarrow has no published accuracy record.
- **What may be missing:** stated uncertainty, newest evidence date, and substantiated material information absent from
  the evidence; offer an approved refresh, not an altered probability. Optional qualitative judgement is labelled
  **My view, not Yarrow**; a personal number still requires the explicit request described above.
- Include a clickable `[View full report](report_url)` using the exact authorized returned URL, outside code blocks.
  Keep full trace/evidence available behind the report link rather than dumping tool JSON. Never guess locked text.

Keep a compact run log: saved question, app question_id, run_id, forecast date and result. Respect owner/public/locked
access flags; do not enumerate private IDs or treat a shared canonical contract as access to someone else's run.
No MCP tool publishes private forecasts, unlocks paid reports, buys credits or places trades.

## Stocks research and watchlist

Use `get_equity(stock)` for covered stock identity/profile, `list_stories(stock, ...)` for its recent news,
`search_stories(query, ...)` for cross-stock topics, and `get_calendar(stock?, from?, to?, limit?)` for announced company
and US macro events. The calendar mixes company and macro entries: inspect enough results before saying no company date
exists; one macro entry does not prove that. Missing dates or macro values must not be invented.

Use `list_reports(stock)` for daily Research history. `get_report(report_id)` reads an **exact daily report UUID**;
`get_report(stock)` reads the latest. Preserve the user's report ID/date instead of substituting a new report.
Daily Research and ad hoc `get_forecast(run_id)` are different products. Show only permitted previews for locked reports
and direct the user to the report page for unlock; do not purchase it. Automatic daily Research currently covers eligible
public US non-ETF stocks, not every watchlist item or every ETF. Availability does not guarantee a daily notification.

`my_watchlist` reads the caller's stocks and own runs. `put_watchlist(stock, alerts?, reports?)` adds/updates stock preferences;
omitted switches preserve existing values. `remove_watchlist(stock)` removes a stock when requested. Mutations require
independent `watchlist:write`; `forecast:write` does not grant it. This is a stock watchlist, not a prediction-market watchlist.