Primary tool. Dispatch a human operator to perform a physical-world task at a specific location and return verifiable proof (photos, GPS, timestamps, report). Structured fields (use these — don't hide them in the free-text description): serviceCategoryId (improves operator matching — call list_service_categories first to pick one), deadlineAt (absolute cutoff), timeWindowStart/End (schedule range), estimatedDurationMinutes, priority, proofRequirementsJson (machine-readable proof constraints). Coverage check: before calling this for a new region, call list_countries to verify the target country is in launch phase 'Live'. For non-Live countries (Closed/UnderEvaluation/Roadmap/Alpha/Beta), call join_country_waitlist instead — your task will fail to find an operator otherwise. Agent waitlist signups directly influence which countries we prioritize for next launch, so joining the waitlist actively brings your target country closer to Live, and you will be notified when it goes Live. Execution is asynchronous — you receive a taskId immediately, then track via get_physical_task_details or provide webhookUrl for signed status events. Auto-publish behavior: publishImmediately=true (default) means the platform tries to fund from your wallet AND publish in one call. If wallet balance is sufficient → task goes straight to Published. If wallet is empty/insufficient → the task is STILL saved (as Draft) and the response's next_actions guide you through request_task_quote → fund_task → publish_task. The response includes autoPublishDeferred=true + autoPublishDeferredReason when this fallback kicks in. You never lose the task to a wallet-balance error. Scheduling: 4 execution modes control timing. 'asap' (default) = execute immediately. 'time_window' = operator picks when within your window. 'scheduled' = exact time ± tolerance (e.g. delivery at 13:00 ±15min). 'operator_schedule' = operator commits to a time within your broad window. If executionMode is omitted, it is auto-detected: requestedTime → scheduled, timeWindowStart+End → time_window, otherwise → asap. All times are yyyyMMddHHmmss (e.g. 20260321130000 = 21 Mar 2026 13:00). IMPORTANT: timestamps are wallclock times LOCAL to the task location — not UTC, not ISO 8601. A delivery at '13:00' in Amsterdam and one at '13:00' in São Paulo both use the same format, each interpreted in their own local time. Do not convert to UTC; do not render in a different timezone. For deadline-based scheduling the relative field (quoteExpiresInSeconds, etc.) is timezone-safe and preferred. Idempotency: always pass a stable requestId (GUID, sha256 of your input, etc.) for safe retries. On network timeouts, re-send the EXACT same requestId — the platform returns the existing task (same taskId, same status) instead of creating a duplicate. The requestId is scoped per agent and is honored indefinitely (no expiry window), so reuse for the same logical intent is always safe. Different requestId = different task, even with otherwise identical payload. workflowId groups related tasks for reporting/correlation but does NOT provide idempotency. Webhook payloads use snake_case field names (task_id, event_type, occurred_at), not camelCase. Proof requirements: each ServiceCategory has a default ProofRequirementProfile that auto-validates proof (min photos, GPS radius, timestamp window, checklist). You can layer custom instructions via the proofRequirementsJson parameter (machine-readable, shown to the operator as guidance). Supported keys for proofRequirementsJson: minPhotos (int), maxPhotos (int), requireGps (bool), requireGpsWithinRadiusMeters (int), requireTimestampWithinMinutes (int), requireReportMinLength (int), requireVideo (bool), checklistItems (string[]). Send as a JSON-encoded string. Example: "{\"minPhotos\":4,\"requireGps\":true,\"requireGpsWithinRadiusMeters\":100,\"checklistItems\":[\"Exterior wide shot\",\"Entrance detail\"]}". The full schema reference is in /.well-known/molt2meet.json under proof_package.proof_requirements_schema. Use get_task_proofs to review submitted proof with thumbnails. Requires: API key from register_agent. Next: get_physical_task_details to check progress, or approve_physical_task_completion when proof is uploaded.