rentahuman-mcp 3.0.0 → 3.2.0

package/README.md

@@ -105,8 +105,9 @@ webhooks.
 
 ### Conversations
 
-- **start_conversation**: Start a conversation with a human when the account is eligible for direct messaging. Prefer `create_bounty` for first contact.
-- **send_message**: Send messages in an existing conversation. Accepts optional `idempotencyKey`.
+Direct messaging is no longer available. Use `create_bounty` for first contact. Existing direct threads remain readable but read-only; messaging is available for bounty, service-booking, feedback, dispute, and platform-support conversations. `start_conversation` is deprecated and hidden from the tool catalog, and cached calls return an error directing clients to `create_bounty`.
+
+- **send_message**: Send messages in an existing supported conversation. Accepts optional `idempotencyKey`.
 - **get_conversation**: Get conversation history with all messages
 - **list_conversations**: List all your conversations with humans
 
@@ -193,10 +194,10 @@ worker (`escrow_recipient_mismatch`).
 
 ### Bounties (Task Postings)
 
-- **create_bounty**: Post a one-shot task bounty for humans to apply to (supports multi-person and country-wide bounties). Accepts optional `idempotencyKey`. Dry-run `preview.fundingTotal` is the total funding requirement before existing wallet balance is applied. Live `pending_deposit` `checkout_total` is the exact hosted charge after wallet balance is applied. Ongoing data-collection bounties (`bountyKind: "ongoing"`) are Figure ongoing-operator-only REST resources and are intentionally not exposed through MCP.
+- **create_bounty**: Post a one-shot task bounty for humans to apply to (supports multi-person and country-wide bounties). Accepts optional `idempotencyKey`. Dry-run `preview.fundingTotal` is the total funding requirement before existing wallet balance is applied. Live `pending_deposit` `checkout_total` is the exact hosted charge after wallet balance is applied.
 - **list_bounties**: Browse available bounties (includes partially filled bounties by default)
 - **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.
+- **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.
 - **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. 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
@@ -242,14 +243,15 @@ authorize payment.
 
 ### Human-written text
 
-- **create_humanization**: Hire one human for a private text rewrite with a fixed worker price and exact turnaround. Requires a stable `idempotencyKey`. Optional applicant screening takes caller-supplied AI-generated text, sizes it by percentage with a 500-word cap, and requires the same document, continuous recording, attestation, and advisory Pangram analysis before acceptance. A private resume upload can also be required.
-- **get_humanization**: Poll the owned order, applicant screening evidence/results, current worker deadline, attempts, submission links, review state, and advisory Pangram results.
+- **create_humanization**: Hire one human for a private text rewrite with a fixed worker price and exact turnaround. Requires a stable `idempotencyKey`. Optional applicant screening takes caller-supplied AI-generated text, sizes it by percentage with a 500-word cap, and requires the same document, continuous recording, attestation, and Pangram analysis before acceptance. A valid AI fraction below 50% approves the screening; 50% or greater rejects it. Missing or invalid scores remain in manual review. A private resume upload can also be required.
+- **get_humanization**: Poll the owned order, applicant screening evidence/results and automatic review state, current worker deadline, attempts, submission links, final review state, and Pangram results.
 
 Humanization source text and private instructions are never included in the
 public bounty. Detector scores and screen recordings are review evidence, not
-proof of authorship; the tools never average scores or make an automatic
-payment/rejection decision. Use the existing submission-review tool to approve,
-request a redo, or reject after analysis becomes terminal. Requests that seek
+proof of authorship. The platform applies the 50% AI-fraction threshold to
+screening samples and managed delivery review, but it never releases payment by
+score alone. Use the existing submission-review tool for any manual approve,
+redo, or reject decision after analysis becomes terminal. Requests that seek
 credential falsification, recommender impersonation, academic-integrity
 violations, or required-disclosure evasion are rejected.
 
@@ -272,6 +274,20 @@ payout is confirmed. Agents cannot set `completed` or `paid` through
 
 `create_bounty` and `update_bounty` accept `identityRequired` (boolean, default false). When true, applicants must pass an identity check (government ID) before they can apply. Identity is verified once per account and reused across every bounty that requires it, so a returning worker who is already verified applies without re-checking. Recommended for in-person tasks.
 
+#### Excluding previous participants
+
+`create_bounty` and `update_bounty` accept `excludedParticipantSourceBountyIds`
+(up to 1,000 ids of your own earlier bounties). Any worker who was ever accepted
+on one of those bounties cannot see or apply to the bounty, which is how repeat
+surveys and fresh-panel studies keep prior participants out. `update_bounty`
+replaces the whole list: pass the full new list, or an empty array to clear it.
+Exclusion is evaluated live, so a source added later hides the bounty from its
+ever-accepted workers and blocks accepting them; pending applications are not
+auto-rejected. Sources must be your own regular bounties that were funded at
+least once, and never the bounty itself: AI-managed, QA, and taste run
+bounties, archived program records, never-funded drafts, and a self-reference are
+rejected with a 400 whose `error` names the problem.
+
 #### Country targeting
 
 `create_bounty` and `update_bounty` accept a country-only `location` when a
@@ -298,8 +314,10 @@ 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
@@ -335,10 +353,13 @@ review and accept every application yourself. Ignored on `aiManaged` bounties,
 whose managed engine owns applicant review.
 
 On `micCheckRequired` bounties the deterministic gate scores the applicant's
-mic recording: auto-accept requires an overall DNSMOS score of at least
-`autoAcceptMinMicScore` (1-5, default 3.0 — the platform's pass boundary).
-Set it at creation or change it later via `update_bounty` (`null` resets to
-the default). Below the floor, applications wait for your manual review.
+mic recording by its overall DNSMOS score (1-5). Set `autoAcceptMinMicScore`
+to make that score a hard cutoff: applications below it are auto-rejected
+with a reason, and applications at or above it proceed toward acceptance
+(unscored recordings always wait for manual review). Set it at creation or
+change it later via `update_bounty` (`null` resets to the platform default of
+3.0, below which applications only wait for your manual review — nobody is
+rejected for audio quality by default).
 
 #### Microphone quality requirement
 
@@ -419,7 +440,20 @@ Create bounties that hire multiple humans (e.g., "10 people to hold signs in Tim
 - Bounty status transitions: `open` → `partially_filled` → `assigned` →
   `completed` (**Work Completed**) → `paid`; every accepted seat must satisfy
   the release/payout condition before the aggregate advances.
-- Other applications are only auto-rejected when all spots are filled
+- Recruiting continues while spots are merely filled (a seat can still be
+  released and refilled): new applications keep arriving as pending, existing
+  pending applications are kept, and platform outreach keeps running. The pool
+  is only auto-rejected — and recruiting only stops — once every seat's escrow
+  is settled (released/paid). Accepting more workers than funded seats stays
+  impossible.
+- Staffed bounties that are still recruiting appear in `list_bounties`'
+  default recruiting list (they carry `spotsRemaining: 0`). Pause one with
+  `update_bounty` (status `paused`) to stop applications and outreach while
+  accepted workers keep working; resuming with status `open` returns it to the
+  seat-derived status (`open`, `partially_filled`, or `assigned`).
+- With `autoAccept`, applicants who arrive while every seat is taken wait as
+  pending and are re-reviewed automatically, oldest first, whenever a seat is
+  released.
 
 ### Upload-Collection Bounties (photos, videos, documents)
 
@@ -449,10 +483,6 @@ Collect media or documents directly instead of standard applications — e.g. "u
 
 3. **Retrieve the dataset** of everything you accepted with `get_bounty_dataset(bountyId)` — returns download URLs for all accepted files grouped by applicant. For a bulk zip archive, `GET https://rentahuman.ai/api/bounties/{bountyId}/applications/dataset` with your `X-API-Key` header.
 
-### Ongoing Data-Collection Bounties
-
-Ongoing bounties are specialized partner programs created with `bountyKind: "ongoing"` and an `ongoing` configuration block. They require the server-derived Figure ongoing-operator capability in the REST API and are not agent-facing MCP tools. Human contributors join those programs through the web data-collection intake flow, not through `create_bounty` or `update_bounty`.
-
 ## Usage
 
 ### TypeScript Types