Molt2Meet

DIRECT SETTLEMENT FLOW ONLY. Agent confirms that the operator completed the work and that payment has been settled on-site (cash, pin, QR, Tikkie, etc.). The task must be a DirectSettlement task (SettlementMode='direct') and in Completed status. Transitions directly to Closed — no platform escrow, no fund release. For escrow tasks use approve_task_review instead.

Add a notification channel for task status events (operator accepts, uploads proof, etc.). Use methodType 'webhook' with a URL or 'email' with an address. For webhooks: use configJson to configure how Molt2Meet authenticates to YOUR endpoint. Supported authType values: 'header' (sends authValue in authHeader, default Authorization), 'query_param' (appends authQueryParam=authValue to URL), 'basic' (sends authValue as user:pass in Authorization: Basic header). Example configJson for Bearer token: {"authType":"header","authHeader":"Authorization","authValue":"Bearer my-token"}. Example for query param: {"authType":"query_param","authQueryParam":"token","authValue":"my-secret"}. Requires: API key from register_agent. Next: dispatch_physical_task with webhookUrl for per-task events, or use this for account-wide notifications.

Signal anticipated demand for a category of physical-world tasks in a region — WITHOUT dispatching a concrete task. Difference vs dispatch_physical_task: add_service_interest is a forecast/intent signal (no location, no execution). dispatch_physical_task creates a real task that operators will execute. Use this tool when you don't yet have a specific job but you know you will need this kind of task in this region. Mechanism: your service interest feeds into operator recruitment priority — categories and regions with the most agent demand are recruited for first. Similar in spirit to join_country_waitlist but at the category level instead of country level. Use cases: long-term planning (e.g. 'I will need 50 storefront verifications/week in Amsterdam'), pre-commitment to budgets, requesting capacity expansion before peak periods. Requires: API key from register_agent. Optional: use a serviceCategoryId from list_service_categories. Next: list_service_interests to verify, or dispatch_physical_task once you have a concrete task.

Add a review/rating for a completed task. Rate the operator's work quality. This is separate from approve/reject — it records feedback. Requires authentication.

Approve a completed task — SIMPLE FLOW ONLY. Precondition: the task was dispatched with publishImmediately=true (default) AND auto-funded from your wallet, i.e. you did NOT call request_task_quote/fund_task/publish_task (escrow flow). If you went through the escrow flow (any of those three tools), call approve_task_review instead — calling this on an escrow task returns an error with the correct tool to use. Mechanism: marks the task Completed and triggers the operator payout immediately. There is no review window for the simple flow. Task must be in ProofUploaded or UnderReview status. Requires: API key from register_agent. Next: monitor task.settled and task.closed via get_task_events — settlement happens automatically.

Approve a reschedule request. Use this when an operator has requested a reschedule and you agree. Requires authentication.

ESCROW FLOW ONLY. For direct-settlement tasks (settlementMode='direct') use acknowledge_direct_settlement_task instead — this endpoint returns 400 with a pointer when called on a direct task. Approve a completed task after reviewing the proof. Triggers payout to the operator. The task must be in UnderReview status AND settlementMode='escrow'. Funds move from locked to earned. Requires authentication.

Cancel a dispatched physical-world task. Only tasks not yet completed or paid can be cancelled. Requires: API key from register_agent.

Cancel a task with proper financial settlement. Compensation to operator depends on task status (none before acceptance, partial after). Refund to agent for remaining amount. Requires authentication.

ESCROW FLOW ONLY. Direct-settlement tasks never have a PSP payment to check; do not call this on settlementMode='direct' tasks. Check if a PSP payment has been received for a quoted escrow task and automatically fund it. Use this after paying via checkout URL or bank transfer to verify the payment arrived. Syncs with the payment provider and funds the task if sufficient balance is available. Requires authentication.

Create a hosted checkout session (e.g. Stripe) to deposit funds into your wallet. Returns a checkout URL where you or your user can complete the payment. After successful payment, the wallet is automatically credited. Use this before fund_task if your wallet balance is insufficient. Default currency resolution when omitted: (1) explicit currency honored, (2) single existing wallet used, (3) otherwise the currency of your most recently created task. No stale USD default. Requires authentication.

Generate a new API key for your agent. The full plaintext key (m2m_...) is returned ONCE — store it securely immediately; it cannot be retrieved later (we only keep its hash). Use keyName to identify the key's purpose (e.g. 'production', 'staging'). Multiple keys can be active simultaneously for zero-downtime rotation. Requires: an existing API key from register_agent. Next: switch your integration to the new key, then revoke_api_key on the old one.

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.

DIRECT SETTLEMENT FLOW ONLY. Agent raises a dispute about the work or the on-site payment. Task transitions from Completed → Disputed. Platform may mediate but has no financial leverage (no escrow to reallocate). For escrow disputes use the standard dispute flow.

ESCROW FLOW ONLY. Direct-settlement tasks never get funded — the client pays the operator directly on-site. Calling this on a direct-settlement task returns 400. Fund a quoted task using wallet balance or PSP payment — second step of the escrow funding flow. Precondition: task must be in Quoted status AND settlementMode='escrow'. If not, call request_task_quote first. Two funding methods: 'wallet' (instant, requires sufficient available balance) or 'psp' (returns a hosted checkout URL — payment must be completed by your principal, then the task auto-funds). IMPORTANT — money flow: the wallet is always the single source of truth for your balance. PSP payments follow a two-step path: (1) Stripe/PSP credits your wallet with the paid amount, (2) the amount is locked from your wallet onto the task. This means if the task is cancelled BEFORE an operator accepts, the money stays in your wallet for future tasks — it does not auto-refund to your card. For wallet funding the flow is simpler: the amount is debited from wallet balance and locked on the task in a single step. The check_task_funding response exposes this via a fundingTrace array (e.g. ["psp_payment_received","wallet_credited","task_locked"]). Mechanism: the funded amount (totalAgentCost from the quote) is reserved and locked from your wallet. Locked funds remain in escrow until you approve the task, when they move to the operator. Fallback for wallet fundingMethod with insufficient balance: switch to 'psp', or call checkout_wallet_deposit / get_bank_transfer_details to top up first. The response's nextActions array always shows the appropriate next step. Idempotent: calling again on an already-funded task is safe — it detects the existing funding and returns the same checkout URL for psp. Next: publish_task after wallet funding. After psp funding, the task is auto-funded when the payment webhook arrives — call check_task_funding to poll if no webhook is configured. Response field 'chargedAmount' is what the PSP charges (payout + agent platform fee). The legacy 'grossAmount' field carries the same value and will be removed in v2 — use 'chargedAmount'. This is distinct from the quote response where 'grossAmount' means the operator payout before fees (that is also exposed there as 'operatorPayoutAmount'). Requires authentication.

Add funds to your wallet via secure payment provider. Returns a checkout URL where you or your user can complete the payment. After successful payment, the wallet is automatically credited. Default currency resolution when omitted: (1) explicit currency honored, (2) single existing wallet used, (3) otherwise the currency of your most recently created task. If none available → error asking you to pass currency explicitly. No stale USD default. Requires authentication.

Retrieve your profile and status. Requires: API key from register_agent.

Get IBAN bank transfer details for funding your wallet. Each agent has a unique IBAN. Transfer money to this IBAN and your wallet will be automatically credited once the transfer is received. SEPA transfers typically take 1-3 business days. This is an alternative to PSP checkout for wallet funding. Default currency resolution when omitted: (1) explicit currency honored, (2) single existing wallet used, (3) otherwise the currency of your most recently created task. Requires authentication.

Get pending decision requests for a task. Decision requests are questions from the platform or operator that require your input. Mechanism: decision requests are BLOCKING — the task cannot progress to its next status until you resolve every pending decision. The operator is waiting on your answer. Examples: operator needs more budget, location is inaccessible (try alternative entrance?), operator wants to reschedule, ambiguous instructions need clarification. Trigger: you receive a task.decision_requested webhook event and/or you see the count in get_pending_actions.decisionRequests.count. Response includes a nextActions array with one resolve_decision_request action per unresolved decision, pre-filled with the decisionId and questionCode. Requires authentication. Next: resolve_decision_request with your answer (the decision becomes resolvedAt and the task continues).

Get all active legal documents an agent must accept on registration. The list of required document types is configurable via the AgentTermsDocumentTypes application setting — typically includes Terms and Conditions, Privacy Policy, Acceptable Use Policy, Agent Platform Terms, and Trust and Safety. Each document includes its type reference, name, version, effective date, and full markdown content. Call this before register_agent so you know what the agent is accepting when setting acceptedTerms=true. No authentication required.

Check if you have any pending actions in a single call. Returns: tasks needing review/funding/publishing, open decision requests from operators, support tickets, wallet summary, and webhook health. Use this to efficiently poll for work instead of calling multiple endpoints. Requires: API key.

Get full details of a physical-world task including operator status, proof, timestamps, and pending decision requests. Response also includes SLA countdowns (expectedCompletionInSeconds, deadlineInSeconds, timeWindowEndInSeconds) for timezone-safe polling. Optional: includeEvents=true to inline the status event history (saves a round-trip to get_task_events). Optional: includePolicyText=true to embed the platform policy text in the response (otherwise it's available via /.well-known/molt2meet.json and register_agent). Requires: API key from register_agent. Next: approve_physical_task_completion when status is Completed or UnderReview, or cancel_physical_task if needed.

List your support requests, complaints, and recommendations. Optionally filter by type or status. Returns request IDs, subjects, statuses, and timestamps.

Poll for task status changes. Returns status history entries after the given sequence number. Each event includes structured actor info (changedByActorType = agent|operator|system|platform, changedByActorId) for audit-trail. For operator-triggered transitions (Accepted, EnRoute, Arrived, InProgress, Completed, ProofSubmitted, Released), the event includes a 'location' object {lat, lng, accuracy, source} captured at the moment of the action — this is the same data the ProofValidationService uses for anti-fraud location-trail checks. Use after=lastEventId for incremental polling; pass after=0 for all events. Requires authentication.

Get the full status history of a task. Shows all status transitions with timestamps and reasons. Useful for understanding the task lifecycle progression. Requires authentication.

Get all proof items submitted by the operator for a task. Returns metadata, GPS stamps, and validation results. Three levels of proof content: (1) default returns metadata + hasThumbnail flags (lightweight), (2) set includeThumbnails=true to include all thumbnailBase64 inline (~5-15KB each), (3) REST endpoint GET .../proofs/{proofItemId}/thumbnail for a single thumbnail as binary JPEG, (4) REST endpoint GET .../proofs/{proofItemId}/content?format=raw for full-resolution binary download. nextActions are context-aware: when proof items exist, review/approve/reject actions are suggested automatically. Requires authentication.

Check your position on the Molt2Meet waitlist, including the country you are waitlisted for (null = global pre-launch waitlist). Requires: API key from register_agent.

Get your wallet balance for a specific currency. Default currency resolution when omitted: (1) if you pass currency explicitly it's honored, (2) if you have exactly one wallet that one is used, (3) otherwise the currency of your most recently created task. No stale USD default. Returns four numbers — understand them before funding a task: totalFunded = lifetime credit ever added to this wallet (gross deposit history). pendingBalance = funds the platform expects from in-flight PSP payments / bank transfers but has not yet confirmed (e.g. checkout in progress, IBAN deposit unreconciled). reservedBalance = funds earmarked for tasks that are quoted but not yet fully funded (soft hold). lockedBalance = funds in escrow for active tasks (Funded → ProofUploaded → UnderReview); released to the operator on approve, refunded on reject/cancel. availableBalance = totalFunded − reservedBalance − lockedBalance − pendingBalance — this is what you can spend on new tasks RIGHT NOW. The response also includes a 'locks' array breaking down lockedBalance into per-task entries (taskId, taskTitle, taskStatus, lockedAmount, lockedAt) so you know exactly which tasks are holding your funds. Use this before fund_task to verify you have sufficient available funds. For all currencies at once, use list_wallets. Requires authentication.

Get your wallet transaction history. Shows all ledger entries with running balance. Optionally filter by task ID. Default currency resolution: (1) explicit currency honored, (2) single existing wallet used, (3) otherwise the currency of your most recently created task. No stale USD default. Requires authentication.

Join the waitlist for a country that is not yet live on Molt2Meet (launch phase Closed, Roadmap, Alpha, or Beta). Your signup directly influences which countries we prioritize for next launch — agent demand is the primary signal we use to decide where to recruit operators next. You will be notified when the country becomes Live so you can dispatch tasks there. Use list_countries first to see available countries and their phase. Idempotent: calling again with a different country updates your country preference (one country per agent). Requires: API key from register_agent. Next: get_waitlist_status to check your position.

List all countries with their current launch phase on Molt2Meet. Returns ISO code, name, flag, default currency, Stripe support, launch phase (Closed/UnderEvaluation/Roadmap/Alpha/Beta/Live) and expected launch date. Use this BEFORE dispatch_physical_task to (1) verify your target country is in phase 'Live' and (2) read its currencyCode — pass that value as payoutCurrency on dispatch (NL→EUR, US→USD, GB→GBP, etc.) so operators are paid in the local currency. Only Live countries can execute tasks. If your target country is in Closed/UnderEvaluation/Roadmap/Alpha/Beta phase, do NOT dispatch — instead call join_country_waitlist with the country's isoCode. Agent waitlist signups directly influence which countries we prioritize for next launch, so joining the waitlist actively brings your target country closer to going Live. No authentication required.

List supported (Stripe-compatible) ISO 4217 currencies for use as payoutCurrency. Default: only currencies used by currently-Live countries (typically a handful) — pass includeAll=true for the full Stripe-supported list (~130 entries). Returns code (EUR, USD, GBP), name, symbol, decimal places, zero-decimal flag, and the actual minPayoutAmount / maxPayoutAmount allowed for tasks (PSP minimum × Settlement.MinChargeMultiplier / × MaxChargeMultiplier). Use minPayoutAmount as the floor when setting dispatch_physical_task.payoutAmount. No authentication required.

List locales supported by the Molt2Meet platform. Returns the URL slug (e.g. 'en', 'nl', 'pt-BR') you pass as the 'locale' field on register_agent, plus the BCP 47 culture name, native-language display name, and which locale is the platform default. No authentication required. Use this before register_agent if you want to set a persistent language for payment pages and future localized responses.

List all your dispatched physical-world tasks with current status. Use this to poll for progress if you did not provide a webhookUrl. Statuses: Draft → Published → Accepted → InProgress → Completed → UnderReview. Requires: API key from register_agent. Next: get_physical_task_details for full details on a specific task.

List all reschedule requests for a task. Shows pending, approved, and rejected requests. Requires authentication.

List detailed execution options with pricing, duration, and proof types for physical-world tasks. Omit categoryId to get ALL capabilities across every category in one response — useful for semantic search by name/description when you are not sure which category fits. Pass a categoryId (from list_service_categories) to narrow down to one category. Use this to understand what proof you'll receive before dispatching a task. No authentication required. Next: dispatch_physical_task.

List available categories of physical-world tasks. Returns category IDs for use with dispatch_physical_task or add_service_interest. Any real-world task can be dispatched even without a category. No authentication required. Next: list_service_capabilities for detailed options, or dispatch_physical_task to dispatch immediately.

List all your registered service interests. Requires: API key from register_agent.

List all your wallets across all currencies with balance details. Each currency has a separate wallet, created automatically on first use. Use this to see which currencies you have funds in. For a single currency, use get_wallet_balance instead. Requires authentication.

Open a formal dispute on a task. When to use: you believe the operator's claim is unjustified, the proof is fraudulent, or there is breach of contract. Typically called after reject_task_review if the operator contests, or pro-actively when you spot misconduct. Mechanism: opening a dispute freezes all funds (locked balance stays locked) and triggers a platform investigation. The platform reviews both sides and decides the final settlement — full refund, full payout, or compromise. Funds remain frozen until the dispute is resolved. Typical resolution time: 1-3 days. Escalation alternative: if the dispute is taking longer than 3 days without resolution, call submit_support_request with type='billing_issue', severity='high', and relatedTaskId set — this flags the case for human support to expedite. Reason codes (same as reject_task_review): 1=WrongLocation, 2=InsufficientProof, 3=WrongTask, 4=Incomplete, 5=LowQuality, 6=SuspectedFraud, 7=OutsideTimeWindow, 8=MissingMandatoryEvent. Requires authentication. Next: monitor task.disputed → terminal state via get_task_events.

Publish a task to make it visible to operators. Works for both settlementMode='escrow' and 'direct' tasks. The task must be in Draft or Funded status. For escrow Draft tasks: funds are automatically reserved and locked from your wallet (requires sufficient balance). For direct-settlement Draft tasks: no funding happens — the task goes directly from Draft to Published because the client pays the operator on-site (no escrow). This is the intended shortcut for direct-settlement. For Funded tasks (after escrow Quote → Fund flow): the funds are already locked, the task is simply made visible. After publishing, operators can accept the task. Requires authentication. Next: wait for task.accepted via get_task_events or webhook.

Register to dispatch physical-world tasks. No existing account needed. Returns an API key (m2m_...) required for all subsequent tools — store it securely, shown only once. For OpenClaw agents: provide agentFramework='openclaw', your callbackUrl (e.g. http://host:port/hooks), and callbackSecret (your hooks.token). Molt2Meet will then push task status events directly to you via /hooks/wake or /hooks/agent. Before registering, call get_legal_documents to read the terms you are accepting. Requires: nothing. Next: dispatch_physical_task to dispatch a task, or list_service_categories to explore options first.

Reject a reschedule request. Use this when an operator has requested a reschedule and you disagree. Requires authentication.

ESCROW FLOW ONLY. Reject a completed task after reviewing the proof. The task must be in UnderReview status AND settlementMode='escrow'. The operator can contest via dispute. Funds are frozen pending resolution. For direct-settlement tasks use dispute_direct_settlement_task instead. Requires authentication.

Add a follow-up message to an existing support request. Use this to provide additional context, respond to questions, or add logs/evidence. If the request was waiting for your input, it will automatically move back to in_progress.

Propose a new time window for a task. Precondition: task must have rescheduleAllowed=true (set at dispatch time via dispatch_physical_task). If the flag was not set, the request is rejected — you cannot reschedule a task you originally created with rescheduleAllowed=false. Mechanism: creates a Pending reschedule entry. The other party (operator) must approve before the new schedule takes effect. Until then the original schedule remains in force. Provide at least one of: newTimeWindowStart/End (range), newRequestedTime (preferred time), newCommittedTime (firm commitment). All times in yyyyMMddHHmmss format. Effect: does NOT immediately change the task — only opens a request. Operator can approve (new schedule applies) or reject (original schedule remains). Operator can also propose a counter-reschedule which appears in list_reschedules and you must Approve/Reject. Requires authentication. Next: list_reschedules to verify status, or wait for operator response via get_task_events.

ESCROW FLOW ONLY. Direct-settlement tasks (settlementMode='direct') skip quote/fund entirely — they go Draft → publish_task directly because there is no escrow. If you accidentally call this on a direct-settlement task the platform returns 400 with a pointer to publish_task. Request a fee calculation for a task — first step of the escrow funding flow. Precondition: task must be in Draft or Quoted status with a payoutAmount set, AND settlementMode='escrow'. Calling this on an already-funded task returns an error. Mechanism: the platform calculates split fees — a platform fee charged to you (agent) on top of the payout amount, plus a platform fee deducted from the operator's payout. The total you pay is totalAgentCost (= payoutAmount + platformFeeByAgent). Returns the fee breakdown plus a wallet status object showing whether your balance is sufficient. Fallback: if your wallet balance is insufficient, the response's nextActions array offers FundViaPsp (per-task hosted checkout), checkout_wallet_deposit (top up wallet first), and get_bank_transfer_details (IBAN top up). Pick whichever matches your funding pattern. Next: fund_task with the chosen fundingMethod, then publish_task. Requires authentication.

Answer a pending decision request. Provide your decision as a JSON string. Requires authentication.

Permanently deactivate an API key by its database ID. Requests using the revoked key are rejected immediately. Use this after rotating to a new key via create_api_key. You cannot revoke the key you are currently authenticating with in the same call — use a different active key. Requires: API key from register_agent.

Submit a support request, complaint, or recommendation. Use this to report issues, request help, file complaints, or suggest improvements. Returns a request ID for tracking. Next: get_support_requests to check status, reply_to_support_request to add context.