Skip to main content
Human guide: work with your agent → Inspect one Parallel action before starting provider-backed work. Your first result is a verified input and output contract.

Provider-specific requirements

Use Parallel for managed research/extraction runs without custom orchestration.
  • Use parallel_run_task, parallel_search, and parallel_extract for agent-friendly workflows.
  • Use the paid REST actions parallel_search and parallel_extract for every Play, enrich, map, dataset, batch, repeated, unattended, or production workload.
  • The free anonymous parallel_search_mcp and parallel_fetch_mcp actions 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_search or parallel_extract instead.
  • Prefer parallel_search first for attendee/discovery workflows, then parallel_extract for targeted pages.
  • parallel_search_mcp is only for an explicitly requested lightweight lookup where zero provider spend matters more than reliability or REST-side controls.
  • parallel_fetch_mcp is only for directly reading a small set of URLs during that same exploratory session.
  • Use parallel_run_task when you need synthesized, schema-shaped outputs from multiple sources.
  • Call parallel_run_task first. If it finishes quickly, use that result.
  • If parallel_run_task returns pending or times out, keep the run_id and use parallel_get_task_run_result later to fetch the final output.
  • Ignore parallel_get_task_run unless 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.
  • For larger or uncertain authorized research, pilot on a small objective before widening max_results and scope. Do not add a pilot or repeat approval for a small supplied Play. Inspect existing task results by run_id. inspection does not authorize a new paid research run or repair. The REST-only policy for Plays and scale still applies.
  • For a direct exploratory MCP call, pass a stable session_id across related calls when possible to reduce anonymous-tier throttling. A session id does not make MCP suitable for scale.

Find an applicable action

Confirm your effective workspace, then search the live catalog:
Search returns candidates. Check the returned provider and operation rather than selecting a similar title automatically.

Inspect the selected contract

Replace <returned-tool-id> with the identifier returned by discovery:
These commands do not execute the selected provider action. Read its required inputs, supported access mode, pricing unit, outputs, and limits. A connection does not establish that every action supports BYOK. Follow the provider-specific requirements above and the live action contract.

Prepare one reviewed input

Use one authorized record that matches the inspected schema. Preserve its source identity and define the result you will accept. Open the action reference for its payload and response shape. Provider-backed execution can incur usage or external effects. For reusable logic, follow Write Plays. For direct-call recovery, use Tool execution recovery.
Continue only when the workspace, provider, required fields, acceptance rule, and applicable price are understood. Keep unavailable access separate from no-result evidence.