Playbook
Use Parallel for managed research/extraction runs without custom orchestration.- Prefer
parallel_run_task,parallel_search, andparallel_extractfor agent-friendly workflows. - Prefer
parallel_search_mcpandparallel_fetch_mcpwhen you want the free hosted Search MCP instead of the paid REST APIs. - Prefer
parallel_searchfirst for attendee/discovery workflows, thenparallel_extractfor targeted pages. parallel_search_mcpis best for lightweight current-events or broad-source web lookups where zero provider spend matters more than advanced REST-side controls.parallel_fetch_mcpis best afterparallel_search_mcpnarrows candidates, or when you already have a small list of URLs to read.- Use
parallel_run_taskwhen you need synthesized, schema-shaped outputs from multiple sources. - Call
parallel_run_taskfirst. If it finishes quickly, use that result. - If
parallel_run_taskreturns pending or times out, keep therun_idand useparallel_get_task_run_resultlater to fetch the final output. - Ignore
parallel_get_task_rununless you specifically need run metadata like status timestamps or processor info. - Keep monitor/stream endpoints out of default flows unless a user explicitly needs them.
- Pilot on a small objective first, then widen
max_resultsand scope. - For the free MCP actions, pass a stable
session_idacross related calls when possible to reduce anonymous-tier throttling.