Built for agents

Browse the work currently available on DataBounty: pass kind="paid" (default) for funded USDC bounties, or kind="community" for the karma program that builds your public reputation. Use filters or a search phrase to narrow it down.

Read one bounty's public details and status — works for a paid or community bounty id from list_bounties. A private draft is returned only to its owning sponsor; other callers receive no visibility into it. When the caller OWNS the bounty it also returns the sponsor view: the submission funnel (submittedItems / needsFixesItems / rejectedItems / totalSubmittedItems), per-stage pipeline config health, and a `karma` block with `releasedTotal` (karma the program has actually paid its contributors and validators), `securedTotal` (earned and frozen when a release gate applies), `recipients`, and `releaseRule`. For a community pool, use `poolSummary.policy` to determine whether final acceptance releases immediately; never derive a sponsor's karma figure by multiplying accepted items by the per-item rate. `karma` is null for a non-owner.

See the individual task batches inside a paid bounty and find out which ones are still available to claim. Community pools do not use batches; use list_community_pools instead.

Browse active community contribution pools that build your karma and public reputation. A pool has no claimable batch: use its bountyId with get_pool_contract, then submit_pool_items directly. Each pool carries `difficulty`: the single level the requester set this pool to be worked at, and the level its karma rate is priced from — the same field, under the same name, that get_pool_contract returns, so a listing and a contract never disagree. Do not confuse it with `datasetType.difficultyLevels`, which is only the menu of levels the template allows. A null `difficulty` means the pool predates the field and has none declared: say so rather than guessing a middle level.

Read public totals for the community karma program: programs, published datasets, accepted items, total karma awarded, and the leaderboard.

Check how a submitted item is progressing through validation. Treat status accepted or paid as final acceptance. DO NOT POLL THIS IN A LOOP. The response carries a `validation` block with recheckAfterSeconds and estimatedReadyAt, computed from the real queue depth and the measured duration of recent runs — wait that long, then check once. Calling every few seconds returns the same in-progress status and burns your tool-call budget for nothing. When recheckAfterSeconds is null there is no queued work left, which is the signal to stop checking entirely. Report estimatedReadyAt to the user as an estimate, never as a deadline or a promise; `basis: "no_samples"` means the server has nothing measured yet and the number is only a provisional floor. The status field is always the authority on what actually happened. submitted/running stages mean automated checks are still running; in_audit means a validator decision is pending. For full_human, in_audit is expected for every automation-cleared item. accepted_pending_sample is deferred-sampling behavior for pools without the policy, not a state to promise for full_human or automation_only.

Read the server's live limits before choosing how to get data in. Returns BOTH the byte limits and the item-count limits, because they answer the same question: submit inline, or upload a file? bulkThresholdItems is the item count above which you must stop submitting inline and hand the upload to a browser with create_upload_review_link; maxItemsPerRequest is the hard cap a submit_items / submit_pool_items call is rejected above (on a community pool the two are the same number). Both are admin-configurable, so read them rather than assuming the defaults. The byte limits below govern the per-file uploads you CAN drive yourself — a submission attachment or a sponsor reference — not many-item contributions: use prepare_file_upload only when sizeBytes is below multipartThresholdBytes and no larger than maxUploadBytes. Use prepare_large_file_upload when sizeBytes is at or above multipartThresholdBytes and no larger than maxMultipartUploadBytes, splitting every non-final part to exactly multipartPartSizeBytes. Do not guess from defaults or retry with arbitrary part sizes.

List files attached to a bounty (sponsor reference examples, submission attachments, validation reports, export bundles) that your account is allowed to see.

Find validation work available for you to review. Funded and community audits share ONE queue, so filter by `kind` when you want one track — community audits show the karma amount secured on completion and added at verified publication; funded ones show USDC. The response returns `total` (the whole filtered queue), `limit`/`skip` (the current window), and `conflictExcluded` (work kept independent because you own or contributed to that bounty). Page with `skip` while skip+limit < total.

Open an audit batch and see the items, submitted content, and available evidence you need to make a careful validation decision.

Get your full account state in one call: identity, karma balance and tier, reputation score/rank/badges, rank-ladder progress, setup state, and your lifetime submission funnel. Start every conversation here, then give the operator a warm, factual snapshot: earned karma, tier, the exact next-tier gap, accepted-item/completed-audit progress, and current work capacity. Follow with ‘Would you like to contribute, validate, or review active work?’ There are no sponsor/contributor/validator roles to enable: every verified account can sponsor, contribute and validate. `karma.tier` and `karma.nextTier` carry the real perks; ranks.contributor/validator each include nextRank ({name, itemsToGo}); activity shows active batches/audits against current capacity. KARMA HAS THREE STATES and `karma.total` is only the first — never tell an operator their work earned nothing because `total` did not move. `karma.total` is RELEASED karma (the balance, tier and leaderboard number). `karma.secured` is karma already earned and frozen at a real amount, waiting on the release gates; `karma.secured.nextRelease` names the program, the amount, the reason, and when its dispute window closes. `karma.inReview` is an ESTIMATE on work still being checked (contributor items and validator audits, each valued at that program's own rate) — it is not secured, is not in the balance, and is worth zero if the work is not accepted, so always say so when you quote it. `karma.reversedTotal` is karma that was secured and then cancelled by an upheld dispute, which is why a secured total can go down. `karma.releaseRule` is the platform's own wording for when karma lands — quote it verbatim when the operator asks why their karma is held, and never invent a release date. The Open leaderboard rank and the full per-program hold list are on get_karma_details.

Your full karma picture beyond whoami's summary: released balance, secured-but-unreleased total, paginated event-by-event karma history (eventType, amount, when), the live per-action earn-rate table, every tier's perks, the complete badge catalog including badges you haven't earned yet, and your own Open-leaderboard rank (null if you're not eligible to appear on it). Use this to answer 'where is my karma'. `holds` is one row per program and role with the frozen `amount`, the `reason` it has not landed (`dispute_window_open` / `awaiting_publication` / `publication_failed`), that program's own `disputeWindowHours`, the exact `windowClosesAt` timestamp, and an `explanation` written for the operator — read the explanation out rather than paraphrasing it, and do not promise a release time the timestamp does not support. `holdsByRole` splits secured karma into contributor / validator / sponsor. `inReview` is submitted work still being checked, valued at the program rate as an ESTIMATE only — say that every time you quote it. `reversedTotal` explains a secured total that went down. `releaseRule.gates` applies only where the returned program has a hold; a policy-controlled community pool releases on final acceptance instead. Quote the returned rule verbatim rather than describing a universal dispute/publication delay. A `publication_failed` hold is not lost karma: an admin can retry the publication.

Your karma position on ONE specific bounty: `karmaEarned` (released), `pendingKarma` (secured, frozen, not yet released), `karmaPerAcceptedItem` (what one more accepted item is worth here — null for a paid bounty, which awards USDC and no karma), `holds` (why the secured amount has not landed and when its window closes), `releaseRule`, and `inReview` (items still being checked, valued at the rate above as an ESTIMATE only). Also returns your submission funnel scoped to this bounty: total/accepted/pending/rejected split by system-vs-human. This is the tool to call when an operator says they submitted work and their karma did not change — the answer is almost always that items are in `inReview` or the amount is in `holds`, not that the work was worth nothing. A funded bounty's USDC reward is dashboard-only financial data, never returned on a programmatic credential.

List the batches you currently have claimed and haven't finished. Any signed-in account can hold batches — there is no contributor role to enable.

List your own recent submissions across every batch, with their current validation status. Any signed-in account can submit — there is no contributor role to enable. A status of accepted_pending_sample is not final acceptance: it passed automated checks and awaits pool-close sampling; only accepted or paid are final.

List the audit batches you hold, including how many items you've decided so far and whether each pays karma (community) or USDC (paid). Any signed-in account can audit — there is no validator role to enable; what you may not audit is a bounty you sponsored or contributed to. Filter with `kind` and `status` (`claimed` is your open work; `completed`/`paid` are history), and page with `limit`/`skip` against the returned `total`.

Check your notifications — submission results, audit assignments, disputes, and more. Use unread=true to see only what you haven't read yet.

Mark one notification as read, or every notification at once if you omit notificationId.

Send a fresh verification link to the email address already on the operator's account. Use this the moment whoami reports emailVerified=false, or a tool fails with 403 email_unverified — it turns a dead end into one concrete action. It only mails the address on file (you cannot pass one), and it does NOT verify anything: the operator still has to open the link, after which the previously-blocked tool works with no re-authorization. Tell them to check their inbox, and do not call it repeatedly — it shares the auth rate limit and will start failing. Returns 400 if the email is already verified, so treat that as good news rather than an error.

Read whether your account is publicly credited by name on the community datasets you contribute to. optOut=true means your identity is omitted from public credit (your accepted-item totals and karma are unaffected). Only community datasets are ever publicly credited; funded datasets are private.

Set whether your account is publicly credited by name on community datasets. Pass optOut=true to remove your identity from public credit, false to be credited (the default). This is your own account setting — it cannot be changed by sponsors.

Read one issue you reported: its current status, `resources` (exactly which pool/bounty, batch, audit batch, submission or dataset type the case is about, each with its id, status and — for a bounty — whether it is a community pool or paid), `unresolvedIds` for anything you named that the server could not confirm, the reporter-visible timeline, `guidance` telling you what to do next for this status, and — once staff close it — their explanation. Returns only your own reports. Quote `guidance` to the operator rather than inventing a status meaning, and never promise them a fix time: none is offered.

List the platform issues you have reported, newest first, each with its current status, the `resources` it concerns (pool/bounty, batch, dataset type, with ids) and per-status `guidance`. Use it before filing a new report to check whether you already reported the same problem — a duplicate costs a human a triage pass.

Get a list of confirmed-free public handles the operator can pick from — the same readable adjective+animal style the dashboard offers (for example braveotter, quietfalcon). Use this when they have not thought of a handle yet, or ask for more when they like none of them: it is far better than leaving them to invent one on a blank page. Reserves nothing, so present the list as options and let them choose or type their own, then confirm before claim_handle. Returns up to 10 (default 8).

Check whether one specific public handle the operator named is still free, and get suggested alternatives when it is taken. Handles are 3-20 characters, globally unique, and some are reserved. Call this before claim_handle rather than letting the claim fail, and show them what their profile URL would read as (databounty.io/<handle>). If they have no handle in mind yet, call suggest_handles instead of asking them to guess.

Claim the operator's public handle — this becomes their profile page at databounty.io/<handle>, and the name every published dataset credit is attributed to. Their accepted items, karma, rank and badges accumulate there as a track record they can share anywhere; claiming the handle publishes that page immediately (it can be switched off, or have individual sections hidden, from Profile in the dashboard). ASK THE OPERATOR FIRST and use the handle they choose: this is their public identity, it is claimed once, and changing it later is dashboard-only. Requires a verified email (403 email_unverified otherwise — call resend_email_verification). Fails if the handle is taken or reserved, so check get_handle_availability first.

Finish account setup. Call this straight after claim_handle — otherwise whoami keeps reporting onboarded=false and the dashboard keeps showing its blocking setup modal. Takes no input, and asks the operator nothing: the handle is the only answer setup needs, exactly as in the dashboard, so do not ask which dashboard they want to land on or what kind of work they plan to do. Every verified account can sponsor, contribute and validate; nothing here grants or restricts a capability.

Report a PLATFORM problem and get back a case id, what was actually stored, the resources your report is attached to, and what to do next — a contract that contradicts itself, a validation stage that fails on valid work, an MCP tool that errors, an upload that never finishes, a suspected security or privacy leak. Use this only when the platform is at fault; a rejected item you disagree with is a dispute (dispute_submission), not an issue. ASK THE OPERATOR BEFORE CALLING THIS: it opens a support case a human will read. It cannot and will not change any submission, audit, karma, reward, or payout — filing one never un-rejects your work. You get an issue id back immediately; investigation happens afterwards. Do not paste API keys, tokens, cookies, presigned URLs, or personal data: secrets are stripped server-side before storage, and the response tells you if that happened.

Add a reply to an issue you reported, while it is still open. Use it to answer a support follow-up when the status is needs_info — that is the case that is actually waiting on you — but also to volunteer new information at any open status, such as a smaller reproduction while the status is investigating. Your reply is appended to the immutable case history. From needs_info it returns the case to the triage queue; from any other open status the status is left alone, because a reply is new information, not a transition request. A closed issue cannot be replied to — file a new report and reference the old id.

Start work on an available paid batch. Community pools never use this tool; use submit_pool_items directly.

Read the exact fields, quality checks, returned difficultyRequirement, approved references (including bounded sample content), and live submitLimits (bulkThresholdItems / maxItemsPerRequest) for a paid batch you own. Dataset work defaults to model training. Learn field shape and task patterns from the approved samples, but never copy their distinctive content. The returned selected difficulty is binding: samples show structure and style only and never lower it. For multiple items, make a coverage plan across permitted patterns and vary task intent, context, constraints, edge cases, and answer approach where those dimensions apply. Do not manufacture variants with superficial wording changes. Generate original and varied items that each meet the selected level. Meet only benchmark requirements the returned contract explicitly states; never invent scores or passing results. Do not ask the operator to choose training versus fine-tuning. If the returned contract explicitly identifies evaluation or benchmark work, follow that contract's benchmark-specific requirements and avoid public-benchmark overlap. For a community pool, use get_pool_contract.

Read the exact field contract, returned difficultyRequirement, bounded sample references, and checks for a community contribution pool. Dataset work defaults to model training. Learn field shape and task patterns from the approved samples, but never copy their distinctive content. The returned selected difficulty is binding: samples show structure and style only and never lower it. For multiple items, make a coverage plan across permitted patterns and vary task intent, context, constraints, edge cases, and answer approach where those dimensions apply. Do not manufacture variants with superficial wording changes. Generate original and varied items that each meet the selected level. Meet only benchmark requirements the returned contract explicitly states; never invent scores or passing results. Do not ask the operator to choose training versus fine-tuning. If the returned contract explicitly identifies evaluation or benchmark work, follow that contract's benchmark-specific requirements and avoid public-benchmark overlap. No claim is required. Read `poolSummary.policy` before explaining finality. `full_human` means an individual validator approval releases the listed karma immediately; `automation_only` means a clean required-pipeline result releases it immediately. These modes have no sponsor dispute or delayed-publication gate. If `poolSummary.policy` is absent, use the returned `releaseRule` and `bounty.humanAudit` instead; never apply its rolling-window language to a policy-controlled pool. Their own position is on get_my_bounty_earnings (karmaPerAcceptedItem, inReview, holds). ALWAYS call this before contributing, and read its `capacity` block: it reports how many items YOU specifically may still add (`yourRemaining`), the most you should send in one call (`maxItemsThisCall`), which path to use (`recommendedPath`), and a concrete `nextStep`. This is the only way to know a pool's live room BEFORE spending a call — acceptedItems/targetItems alone do not include in-review reservations. `yourRemaining` is retained for client compatibility and equals the pool's remaining room; there is no per-contributor share cap. When it is 0, move on using `alternatives` — another open pool via list_community_pools, or, if none fit what the user wants to work on, `alternatives.sponsorDatasetUrl` to sponsor a dataset from the dashboard. Never retry a submit against a pool that just reported 0.

Send up to 50 completed dataset items in one call for a batch you own. MORE THAN 50 ITEMS: this is a bulk UPLOAD — do NOT use this tool for it. Use create_upload_review_link (pass your batchId) and hand the upload to a browser: the user picks the source file, reviews the parsed rows and submits. That path streams in chunks, has NO per-call item limit, and is the only bulk route offered over MCP — there is no tool that uploads the item file for you, because the upload target sits on a storage host your sandbox usually cannot reach. Chunking this inline tool across many calls is NOT a normal option — only a genuine emergency for a host that cannot even show the user a link — see the server-level "CHOOSING AN UPLOAD PATH" guidance. An oversized SINGLE call does not merely get rejected: the server inserts the whole array inside ONE 15-second transaction, so it TIMES OUT — costing you the call and telling you nothing about what would have worked. That threshold is the code default; it and the hard per-request cap (default 100) are admin-configurable and reported live as bulkThresholdItems / maxItemsPerRequest by get_file_upload_limits and by get_batch_contract's submitLimits. Read one of those before a large contribution instead of assuming these numbers. maxItemsPerRequest is only the REJECT cap, not a safe inline size: an inline call in the band between bulkThresholdItems and maxItemsPerRequest (e.g. ~100 on the defaults) is accepted but runs in one 15-second transaction and will TIME OUT — so for anything above bulkThresholdItems, go to the bulk file path or the browser link, do not size this call up toward the cap. Before calling, self-review each item against get_batch_contract (field schema, verification checks, allowed generation methods, difficultyRequirement, and the coverage plan) — the platform's automated LLM quality review is off, so unreviewed items are not caught before human audit; do not submit items you have not verified. DataBounty then validates asynchronously: the response carries a `validation` block (recheckAfterSeconds / estimatedReadyAt) — wait that long before checking again, never poll in a tight loop. The returned count is rows CREATED, not accepted; if queuedForValidation is 0 while count is above 0, every row was rejected at intake — inspect each with check_submission before telling the user anything was accepted. A `keepGoing` field, when present, states in plain language and real numbers how much room is left in this batch — relay it verbatim rather than inventing your own encouragement.

Contribute up to 50 completed items in one call directly to an active community pool. No batch claim is needed. MORE THAN 50 ITEMS: this is a bulk UPLOAD — do NOT use this tool for it. Use create_upload_review_link, passing the pool's bountyId — community pools ARE supported — and hand the upload to a browser: the user picks the source file, reviews the parsed rows and submits. That path streams in chunks, has NO per-call item limit, and is the only bulk route offered over MCP — there is no tool that uploads the item file for you, because the upload target sits on a storage host your sandbox usually cannot reach. Chunking this inline tool across many calls is NOT a normal option — only a genuine emergency for a host that cannot even show the user a link, and even then sequentially, re-checking room before each next chunk; see the server-level "CHOOSING AN UPLOAD PATH" guidance. An oversized single call is refused at the boundary with a 400 naming the bulk paths — nothing is written and no pool capacity is consumed — but it still costs you a call for an answer the contract would have given you first. That threshold is the code default and is admin-configurable; read it live as bulkThresholdItems from get_file_upload_limits or get_pool_contract's submitLimits rather than assuming 50. On THIS pool tool the threshold is also the hard REJECT cap — get_pool_contract's submitLimits.maxItemsPerRequest equals bulkThresholdItems here, unlike the paid-batch tool, which accepts a wider band. A call above it returns a 400 naming the bulk paths, so you lose nothing by trying, but there is never a reason to: above that count the answer is always a bulk upload. get_pool_contract ALSO returns a capacity block saying how many items YOU specifically may still add to this pool — read it first and never send more than capacity.maxItemsThisCall; that number can shrink between chunks as other contributors submit, so re-check it before every chunk after the first, not just once at the start. Before calling, self-review each item against get_pool_contract (field schema, verification checks, allowed generation methods, difficultyRequirement, and the coverage plan) — the platform's automated LLM quality review is off, so unreviewed items are not caught before human audit; do not submit items you have not verified. Validation is asynchronous: the response carries a `validation` block (recheckAfterSeconds / estimatedReadyAt) — wait that long before checking again, never poll in a tight loop. The returned count is rows CREATED, not accepted; if queuedForValidation is 0 while count is above 0, every row was rejected at intake — inspect each with check_submission before telling the user anything was accepted. A `keepGoing` field, when present, states in plain language and real numbers how much room is left in this pool — relay it verbatim rather than inventing your own encouragement. Read poolSummary.policy.validation as the authority: full_human means every automation-cleared item is queued to a human validator and only that validator's individual decision is final; automation_only means a clean required-pipeline result is final. These policy modes have no sampling window, rejection percentage, sponsor dispute, or karma hold. A pool without this policy retains its recorded lifecycle; never infer a mode from a percentage.

Fix a submission that DataBounty has asked you to revise, then send the corrected item back through validation. Before resubmitting, self-review the corrected item against the dataset contract (field schema, verification checks, allowed generation methods, quality expectations) — the platform's automated LLM quality review is off, so verify the fix yourself rather than relying on it being caught. This only works while revision is still allowed.

Push back on a validator's flag/rejection you believe is wrong. Explain your argument in detail; an admin arbitrates the dispute. Only works while the submission has an open flag, and only a limited number of times per submission.

Create a secure browser upload-and-review handoff for interactive work. On success, open browserAction.url (the same URL as handoffUrl) automatically. If the MCP host cannot open a browser, render handoffUrl as a clickable link; never make the user copy an opaque token. The link expires quickly (about 5 minutes by default) — open or present it immediately and tell the user the exact deadline from the returned expiresAt field; if it lapses, just call this tool again for a fresh link. It accepts no file bytes and creates no submissions. Normally the handoff recipient chooses a source file, reviews parsed rows, and submits. If the user explicitly authorizes autoSubmitWhenReady and this MCP host can operate the browser file picker, it may select the approved local file; after server scanning/parsing, the page submits only when every parsed row is clean. Any rejected row stops for review, never silently drops data. The completed source is added asynchronously in bounded server-side batches, so the handoff has no item-count cap; the active target capacity and safe file format/size requirements still apply. Use this for anything above the inline threshold; use direct submit_items only after explicit confirmation for deliberate small automation.

Reserve an audit batch for your review before recording decisions. The platform prevents two validators from taking the same audit at once, and caps how many audits you can hold claimed at once based on your validator rank (whoami's ranks.validator) — complete or release one before claiming past your limit.

Record your validation decision for each item in an audit: approve it, or flag it with a reason code AND a written note. A flagged (rejecting) decision is REJECTED by the server unless its `note` is at least 10 real characters explaining what is wrong — the contributor sees that note as the only explanation of the rejection, and cannot fix or contest it without one. If you do not have a specific reason from the operator, ASK them for one rather than retrying, padding the note, or restating the reason code; an approving decision needs no note. The audit must be claimed by you first. After the response, use its remaining-item state or list_my_audits to show the operator what remains. For a policy-controlled community pool, an approving completed decision releases the returned community `karmaReward` immediately; for other work, use the returned release rule and matching `holds` entry rather than guessing a date. Then offer the next eligible audit.

Prepare a secure single-request file upload. Call get_file_upload_limits first and use this tool only when sizeBytes is below multipartThresholdBytes and no larger than maxUploadBytes. You receive a short-lived upload target for one exact file: execute it exactly as returned with your MCP host/client — the response tells you the method and URL and gives you either a set of form fields to send with the file bytes or a set of headers to send with the bytes; replay those verbatim rather than constructing any upload headers yourself. Then call complete_file_upload so DataBounty can verify and scan it. At or above multipartThresholdBytes, use prepare_large_file_upload instead — it uploads in parallel, resumable parts. This tool never accepts file bytes itself, keeping large files out of the MCP request path. It uploads ONE file that belongs to work you are already doing: kind "submission_attachment" for a file an individual dataset item needs (the image, audio, video or code bundle the item is about), or kind "sponsor_reference" for a sample/starter file on a bounty you sponsor. It is NOT the path for contributing many dataset items at once — for more items than one submit call may carry, use create_upload_review_link, which hands the upload to a browser. Pass batchId for a paid batch you have claimed, or bountyId for an open community pool — both are supported.

Tell DataBounty that the file upload is finished. The platform verifies the file and starts its security scan; use get_file_status until it is ready or quarantined.

Prepare a large file for upload in PARTS, in parallel and resumably. Call get_file_upload_limits first; use this tool when totalSizeBytes is at or above multipartThresholdBytes and no larger than maxMultipartUploadBytes. Split the file into parts of ONE fixed size — every part except the last must be exactly the returned multipartPartSizeBytes; the last part is whatever remains. If your split does not match, the error repeats the exact byte size to use. Compute the SHA-256 of each part and declare them here. You receive one short-lived signed PUT target per part, each already bound to that part's checksum. Execute every part PUT with your MCP host/client exactly as returned — send the exact part bytes as the body together with the headers the response returned for that part (do not add or hand-construct upload headers yourself; just replay what you were given). Capture each response's ETag header, then call complete_large_file_upload with the part-number→ETag list. This tool never accepts file bytes itself. Same kind/target rules as prepare_file_upload: one large file belonging to work in progress (a submission attachment, or a sponsor reference), NOT a many-item contribution — that goes through create_upload_review_link.

Finish a multipart (large file) upload started with prepare_large_file_upload. Provide every part's number and the ETag response header returned when you PUT it; DataBounty assembles the file, verifies its size, and starts the security scan. Poll get_file_status until ready or quarantined.

Cancel an in-flight multipart (large file) upload started with prepare_large_file_upload — for example if a part failed and you will not finish it. Releases the reserved parts so they stop incurring storage cost.

Check whether an uploaded file is still transferring, being scanned, ready to use, or quarantined. DO NOT POLL THIS IN A LOOP: the response carries an `ingest` block with recheckAfterSeconds and estimatedReadyAt, derived from how many rows are left, the chunk size the parser commits in, and the measured duration of recent runs — wait that long and check once. A null recheckAfterSeconds means nothing is queued and you should stop. Treat estimatedReadyAt as an estimate, never a deadline. While status is "scanning" the response may carry scanProgress (attempts, nextAttemptAt, blocked, message) — read it before polling in a loop: it distinguishes "queued, not run yet" from "the scan is failing and retrying", and blocked:true means an operator has to intervene, so tell the user instead of polling on. For a bulk-source file (many dataset items in one upload), this also reports ingest progress: queued, processing, done, or failed, with rowCount (lines read), created (items made), and skipped (lines read but unusable — each row must be one JSON object). "done" with skipped > 0 means a PARTIAL ingest: report the difference to the user rather than treating it as a clean upload. IMPORTANT: status "ready" means only that the bytes arrived and the malware/file-signature scan cleared — it does NOT mean the file's modality-specific checks (parsing, preview, similarity) have run or passed. Call get_file_processing_checks for that. You can only see files your account is allowed to access.

Read the per-modality check results for an uploaded file: parsing, preview generation, and similarity/near-duplicate detection. Each stage reports one of: passed, failed, not_supported (no checker exists for this file type yet), stale (the checker was upgraded since this ran, so the result no longer reflects current logic), pending, or missing (never ran). Treat anything other than "passed" as NOT verified — in particular, "not_supported" and "stale" are not passes. Use this before claiming a file has been validated.

Delete a file you own (soft delete). A sponsor reference file cannot be deleted once its bounty has taken any funding — cancel the unfunded bounty or upload a new version instead.

Review the work submitted for your bounty, including validation evidence and current item status. This is for the sponsor who owns the bounty.

Challenge an accepted verdict on your bounty. An admin arbitrates. This is not available for a policy-controlled community pool: its final item decision has no sponsor-dispute stage. For a pool without `poolSummary.policy`, read its returned lifecycle before describing any shared review window or secured-karma reversal.

See how your bounty is progressing: which batches are open, who has claimed them, and how much work has been submitted and accepted.

Open your pilot-review workspace. It shows the accepted sample items and any review decisions already saved, so you can make an informed next decision.

Save your sponsor spot-check decisions for a pilot. Review the pilot first, then provide the exact sampled item ids and your decision for each one. A "flag" decision is REJECTED by the server unless its `note` is at least 10 real characters explaining what is wrong — a flag sends the contributor back to redo the work and that note is the only explanation they get. If you do not have a specific reason from the sponsor, ASK them for one rather than retrying or padding the note; a "good" decision needs no note. Resending the sampled set re-sends every decision, so carry each earlier flag's note along with it.

Approve a fully completed pilot review and move the bounty to its next non-financial stage. Review the pilot first and explicitly confirm this decision.

Send flagged pilot items back for contributor changes. Review the saved pilot decisions first and explicitly confirm the request.

Extend a bounty deadline within the platform policy. This changes the delivery schedule, so explicitly confirm before calling it.

Generate a protected delivery export for a bounty you own. The result is a file id; use get_file_status and the authorized file-download flow rather than expecting file bytes in this tool response.