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_se...
Risk signalsHandles credentials or secrets (apiKey) · High parameter count (38 properties)
Part of the Molt2Meet server.
Free to start. No card required.
AI agents invoke dispatch_physical_task to trigger processes or run actions in Molt2Meet. Execute operations can have side effects beyond the immediate call -- triggering builds, sending notifications, or starting workflows. Rate limits and argument validation are essential to prevent runaway execution.
dispatch_physical_task can trigger processes with real-world consequences. An uncontrolled agent might start dozens of builds, send mass notifications, or kick off expensive compute jobs. PolicyLayer enforces rate limits and validates arguments to keep execution within safe bounds.
Execute tools trigger processes. Rate-limit and validate arguments to prevent unintended side effects.
{
"version": "1",
"default": "deny",
"tools": {
"dispatch_physical_task": {
"limits": [
{
"counter": "dispatch_physical_task_rate",
"window": "minute",
"max": 10,
"scope": "grant"
}
]
}
}
}See the full Molt2Meet policy for all 54 tools.
These attack patterns abuse exactly the kind of access dispatch_physical_task gives an agent. Each links to the full case and the policy that stops it:
Other execute tools across the catalogue. The same approach applies to each: rate-limit and validate the arguments.
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.. It is categorised as a Execute tool in the Molt2Meet MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
Register the Molt2Meet MCP server in PolicyLayer and add a rule for dispatch_physical_task: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Molt2Meet. Nothing to install.
dispatch_physical_task is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the dispatch_physical_task rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for dispatch_physical_task. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
dispatch_physical_task is provided by the Molt2Meet MCP server (https://molt.molt2meet.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 54 Molt2Meet tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.