Playbook
Use Parallel for managed research/extraction runs without custom orchestration.- Use
parallel_run_task,parallel_search, andparallel_extractfor agent-friendly workflows. - Use the paid REST actions
parallel_searchandparallel_extractfor every Play, enrich, map, dataset, batch, repeated, unattended, or production workload. - The free anonymous
parallel_search_mcpandparallel_fetch_mcpactions are exact-name tools for small, direct, one-off exploration only. They are intentionally omitted from general tool discovery. - Never put a free MCP action in a Play or scale loop. Use
parallel_searchorparallel_extractinstead. - Prefer
parallel_searchfirst for attendee/discovery workflows, thenparallel_extractfor targeted pages. parallel_search_mcpis only for an explicitly requested lightweight lookup where zero provider spend matters more than reliability or REST-side controls.parallel_fetch_mcpis only for directly reading a small set of URLs during that same exploratory session.- 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 a direct exploratory MCP call, pass a stable
session_idacross related calls when possible to reduce anonymous-tier throttling. A session id does not make MCP suitable for scale.