rentahuman-mcp 2.3.0 → 3.1.0

package/README.md

@@ -159,8 +159,8 @@ These tools sign payments locally; the private key never leaves your machine, an
 - **create_escrow_checkout**: Fund an accepted bounty application or conversation payment offer. Accepts optional `idempotencyKey` and returns a deterministic `status`. `requires_payment` includes `checkoutTotal` next to `checkoutUrl` (what checkout charges; it includes a platform fee).
 - **get_escrow**: Inspect a specific escrow, including status, amounts, fees, parties, and audit history.
 - **list_escrows**: List escrows you created as the poster. Filter by `applicationId`, `bountyId`, optional `humanId`, or status.
-- **confirm_delivery**: Confirm work was delivered so payment can be completed or released.
-- **release_payment**: Release active funded escrow to the worker and complete the task after explicit user payment direction. A prior worker completion or evidence review is not required. Accepts optional `applicationId` binding check.
+- **confirm_delivery**: Confirm work was delivered so payment can be completed or released. Refused unless the escrow is bound to an accepted application or a live booking.
+- **release_payment**: Release active funded escrow to the worker and complete the task after explicit user payment direction. For ordinary bounty jobs, review the evidence first and pass `acknowledgeRelease: true`; without it HTTP 409 `release_acknowledgement_required` returns `amountCents`, `workerPayoutCents` and `worker`. Accepts optional `applicationId` binding check.
 - **cancel_escrow**: Cancel an unfunded or funded escrow and refund the payer.
 - **open_dispute**: Freeze an eligible escrow for admin review.
 - **get_earnings_balance**: Check withdrawable, held, disputed, and withdrawn earnings for the authenticated account.
@@ -198,14 +198,14 @@ worker (`escrow_recipient_mismatch`).
 - **get_bounty**: Get detailed bounty information including spots filled/remaining
 - **update_bounty**: Modify an ordinary one-shot bounty or close it while unassigned. Work Completed and Paid are synchronized from escrow evidence and cannot be set directly. Figure ongoing-operator-only bounty settings are intentionally omitted from MCP.
 - **cancel_bounty**: Cancel one of your bounties by ID with a required canonical reason and `details` only when the reason is `other`; this feedback is private and never shown to workers
-- **get_bounty_applications**: View applications for your bounty, including uploaded media URLs (`imageUrls`, `videoUrls`, `documentUrls`) on upload-collection bounties
+- **get_bounty_applications**: View applications for your bounty, including uploaded media URLs (`imageUrls`, `videoUrls`, `documentUrls`) on upload-collection bounties. Each application carries `isBlockedByOwner` and `isPreferredByOwner`; call `prefer_human` / `block_human` with the application's `humanId` to favorite or block an applicant while reviewing (blocking is future-only and never removes an accepted worker). Each application also carries `reviewSummary` (`averageRating` 1-5 or `null`, `reviewCount`, up to 3 `recentReviews` with `rating`, `comment`, `escrowVerified`, `reviewerName`, `createdAt`); `averageRating: null` with `reviewCount: 0` means no review history yet, not a low score
 - **get_bounty_dataset**: List download URLs for every accepted upload on one of your upload-collection bounties
 - **accept_application**: Accept a human's application (supports accepting multiple for multi-person bounties). Accepts optional `idempotencyKey`.
 - **reject_application**: Reject an application
-- **pay_enterprise_bounty**: Pay a completed legacy enterprise bounty from the owner wallet after explicit user payment direction. Applies only to older bounties created under the retired enterprise deferred-billing tier; new bounties are always escrow-funded and use release_payment instead.
+- **pay_enterprise_bounty**: Pay a completed legacy enterprise bounty from the owner wallet after explicit user payment direction. Applies only to older bounties created under the retired enterprise deferred-billing tier; new bounties are always escrow-funded and use release_payment instead. Same approval and `acknowledgeRelease` rules as `release_payment`.
 - **get_bounty_submissions**: List evidence submissions for one of your bounties. Automated findings are advisory.
 - **get_submission**: Get one evidence submission, including uploaded files and the advisory check report.
-- **review_submission**: Approve, reject, or request a redo. Returns `nextAction`; does not release payment.
+- **review_submission**: Approve, reject, or request a redo while the job is `evidence_in_review`. Returns `jobState`, `nextAction` and the redo `attempt` counter; does not release payment. Redo is capped at 3 cycles per job; reject is terminal and files a dispute.
 
 To target every eligible worker in one country, pass `location` with the ISO
 country code and `isRemoteAllowed: false`, omitting `city` and `state`. The
@@ -215,16 +215,30 @@ same shape works with `update_bounty`. Platform-blocked countries are rejected.
 location: { country: "US", isRemoteAllowed: false }
 ```
 
-For ordinary accepted one-shot bounties, workers must finalize post-acceptance
-photo/video evidence before marking the task complete. To review it, the agent
-loads the bounty criteria with `get_bounty`, lists and opens the canonical
-submission, and inspects every uploaded file before calling
-`review_submission`. Automated `recommendation` values stay advisory. If the
-agent cannot inspect a file, it must report that limitation instead of deciding.
-Review decisions require explicit user choice or explicit criteria-based
-delegation and do not move money. Conversely, an explicit `release_payment` or
-`pay_enterprise_bounty` instruction can pay before completion or evidence
-approval. Platform admins cannot authorize payment.
+For ordinary accepted one-shot bounties, the worker marks the task complete by
+submitting post-acceptance evidence, which opens the poster's four-day review
+window (`jobState: evidence_in_review`). To review it, the agent loads the
+bounty criteria with `get_bounty`, lists and opens the canonical submission,
+and inspects every uploaded file before calling `review_submission`. Automated
+`recommendation` values stay advisory. If the agent cannot inspect a file, it
+must report that limitation instead of deciding. Review decisions require
+explicit user choice or explicit criteria-based delegation and do not move
+money.
+
+- `approve` moves the job to `approved_awaiting_release`; `release_payment`
+  (or `pay_enterprise_bounty`) then needs `acknowledgeRelease: true`.
+- `request_redo` (reason required) moves it to `changes_requested` and the
+  worker resubmits; at most 3 redo cycles per job, then only approve or reject
+  remain (`redo_limit_reached`).
+- `reject` (reason required) is terminal for the evidence loop: a dispute is
+  filed immediately (`rejected_disputed`) and the worker cannot resubmit.
+
+Releasing escrow without the acknowledgement returns HTTP 409
+`release_acknowledgement_required` with `amountCents`, `workerPayoutCents` and
+`worker`. The owner may release escrow before the review is closed; the
+seven-day auto-release and `pay_enterprise_bounty` require an approved
+submission (`evidence_approval_required` otherwise). Platform admins cannot
+authorize payment.
 
 ### Human-written text
 
@@ -284,13 +298,20 @@ the listing leaves discovery and rejects new applications and direct uploads;
 it does not create a per-worker completion timer. Use `completionWindowHours`
 for accepted work:
 
-`create_bounty` and `update_bounty` accept `completionWindowHours` (number,
-1-720; `update_bounty` also accepts `null` to disable). When set, a worker who
+`create_bounty` and `update_bounty` accept `completionWindowHours` as any whole
+number of hours from 1 to 720 (30 days), e.g. `36` for a day and a half;
+`update_bounty` also accepts `null` to disable. Presets are a UI convenience
+only: the API and MCP take any value in that range. When set, a worker who
 confirms their seat must complete the task within that many hours. They get an
 in-chat + email reminder at the half-way point; past the deadline the seat is
 automatically released, the application is expired, escrow returns to your
 funding source, and the listing reopens for other applicants.
 
+Omit `completionWindowHours` for work anchored to a specific future event,
+shift, or appointment. The clock starts when the worker confirms their seat,
+not at the scheduled start time, so a shorter window could release the worker
+before the work can begin.
+
 Workers may request more time. Pending requests appear on
 `get_bounty_applications` as `completionExtension` with `status: "requested"`
 (an open request pauses the auto-release for up to 24 hours). Answer with the