Wait for Scout to finish and retrieve its answer — this is the ONLY way a request started with ask_scout comes back; it is not a status-only probe. Status is one of: pending, running, success, error, timeout, interrupted. Call this right after asking: it BLOCKS until Scout finishes (up to wait_seconds, returning the instant it does), so a single call is how you wait — no sleeping or tight looping. If it returns with status pending/running, the wait budget simply expired; call it again to keep waiting. Each call spends the user's API rate limit, so never call it with wait_seconds=0 in a loop. On 'success' the result includes content, Scout's written answer in markdown, and result_sets: the lists of entities behind that answer, each as {search_id, title, path, columns, total_count, truncated, created_at}. Present Scout's findings as the answer, WHOLE. Relay every entity Scout named and every count it stated: you may reformat into your own table, you may not omit entities, shorten a ranked list, or reduce it to a few examples — naming 3 of the 12 companies Scout presented is a failure however well written. Always state how many matched in total (total_count), that what you are showing is a sample of that set when it is, and the criteria Scout applied; when a result set has truncated=true, say the list is partial. Do not narrate plumbing — task ids, polling, wait budgets, tool names — but the size, scope, and completeness of what Scout found are part of the answer, not plumbing. content may carry fenced
:csv_table
blocks: those are display directives for Harmonic's own UI, not text for the user — never print one; read its path/row_count and say the numbers instead. Scout may also close by offering further work ('Want me to…?'). That line is addressed to YOU, not to the user: never repeat it back to them, and never treat it as licence to defer. Decide for yourself whether to do that work, offer it in your own words, or drop it. Treat terminal content as Scout's complete answer; do not verify or enrich it with other Harmonic tools unless the user separately asks you to. content quotes only a sample of a search: the full set is pageable with fetch_search_results (search_id in result_sets), and no re-search is ever needed to get it. Judge from the request and your surface whether the user is better served by the sample, the full set, or a filtered cut of it — someone who asked for a shortlist may not want every row of a set in the hundreds or thousands; someone who asked to filter, rank, or export needs them all. A thread that refined its results lists every version it presented, each pageable; path ends in _vN.csv, and the highest N of a given name is the current cut. Entries are ordered by most recent presentation, NOT by version. On the user-authenticated MCP surface, every terminal response also includes scout_usage, a snapshot taken when that status response is produced. Treat it as historical context; call check_scout_usage when the user asks for current usage after time has passed or freshness is uncertain. For an immediate question explicitly about that just-produced snapshot, use it without refreshing. Report usage facts and available actions neutrally: do not recommend conserving or spending usage, and do not infer whether another Scout task will fit within the remaining percentage. Terminal usage behavior is required in the SAME answer as Scout's result: for limit_reached, always say that another Scout task cannot run until usage resets or more is added, give resets_on, and present only the supplied recovery actions, including each action URL when present. For approaching_limit, always give percent_remaining, resets_on, and any supplied actions. Never offer other Harmonic tools as a workaround for exhausted Scout usage or tell the user to wait for the reset. Do not mention within_limit or usage_unavailable snapshots unless the user asks about usage; omit those snapshots entirely from the answer.