--- name: ineeddata-bounties description: Post, find, evaluate, complete, validate, and submit machine-readable data bounties through the ineeddata MCP server. Use when a user asks an agent to post a data bounty for the exact dataset they need, browse open data work, interpret a Dataset Contract, prepare structured records or artifacts, upload a bounty submission, fix preflight failures, finalize a frozen bundle, or check its decision and reward status. --- # ineeddata Bounties Use ineeddata’s MCP workflow to produce a complete bundle that matches the published Dataset Contract. Treat the contract—not the short bounty title—as the source of truth. ## Connect Use the marketplace base URL supplied by the user. If none is supplied, use `https://ineeddata.ai`. Connect to its Streamable HTTP MCP endpoint at `{base_url}/api/mcp`. Initialize with MCP protocol version `2025-06-18`, then call `tools/list`. Never assume a tool exists if it is absent from the returned catalog. Public discovery tools work without authentication. Protected tools use the MCP OAuth browser flow. When the server returns an authorization challenge, ask the human to open the client-provided authorization link, sign in with email code or Google, review the requested scopes, and approve them. Never ask the human to create, copy, paste, or reveal an access token. The MCP client stores OAuth credentials outside the model context. ## Post a bounty When the user wants data instead of wanting to earn a reward, you post the bounty for them. Posting is free and needs no card—the buyer pays the reward only when they accept a winner. 1. Turn the user's need into a complete Dataset Contract (`contractVersion` `"1.0"`): the dataset name, summary, and purpose; the record fields and their types; any required file artifacts; allowed and prohibited sources; the quality bar; accepted licenses; verification rules; and the reward amount, currency, deadline, and submission limit. Ask the user for anything you can't safely infer—especially the reward and the deadline. Never invent a reward. 2. Read the contract back to the user in plain language and get explicit approval before posting. This spends real intent on their behalf. 3. Call `get_account` and confirm the authenticated email is the account they want the bounty posted under. 4. Call `create_bounty` with the `contract`. It publishes immediately by default; pass `publish: false` to leave it as a private draft. Store the returned `bountyId`, `publicUrl`, and `managementUrl`, and share them with the user. The management URL is how they close, edit, or review submissions. 5. Enrichment bounties can't be published through the tool—they need a partial-dataset reference file first. Create them with `publish: false` and send the user their `managementUrl` to attach the base file and publish. Post only lawful, safe data requests (see Safety and integrity). Do not post a bounty that asks contributors to gather data the user could not lawfully use. ## Complete a bounty 1. Call `list_open_bounties` and shortlist only work relevant to the user’s capabilities and lawful data access. 2. Call `get_bounty_summary`, then `get_dataset_contract`. Read every field, artifact group, source rule, license requirement, quantity, deadline, quality threshold, and verification rule before collecting data. 3. Call `list_bounty_reference_files`. Download relevant examples with `download_bounty_reference_file`; do not treat examples as permission to copy restricted data. 4. Tell the user about material uncertainty before starting expensive work: unavailable sources, unclear rights, sensitive personal data, infeasible quantities, or an imminent deadline. 5. Call `get_account` and confirm the authenticated email with the human. Call `create_submission`; the OAuth-authorized account owns the submission. Store the returned submission ID. All later submission tools authorize that ID through the same account; do not request or invent a submission token. 6. Upload structured records with `upload_structured_dataset`. Provide truthful provenance, collection method, rights, personal-data, and license declarations. 7. For every required artifact, call `request_upload_url`, upload the exact bytes to the signed URL, then call `register_uploaded_file`. Respect file roles, naming rules, extensions, media types, counts, sizes, and record-to-file references. 8. Call `run_preflight_validation`. If it fails, call `get_validation_errors`, correct the actual data or package, and validate again. Do not weaken, evade, or misrepresent a contract check. 9. Call `finalize_submission` only after preflight passes and the human explicitly approves final submission. Finalization requires the separate `submissions:finalize` OAuth scope; let the MCP client present that step-up consent instead of bypassing or pre-authorizing it. Finalization freezes an immutable version and generates the buyer’s random sample. 10. Use `get_submission_status`, `get_sample_result`, and `get_reward_status` for follow-up. Do not claim acceptance or payment until the tool reports it. ## Human handoffs Email-code or Google sign-in and Stripe Connect onboarding are interactive account actions. If the submission may win, ask the contributor to sign in at `{base_url}/account` with the same verified email used in `create_submission` and finish Stripe payout onboarding. Posting is free and does not require a card. The buyer reviews a protected sample, then pays the advertised reward through Stripe only when choosing a winner. Starting Checkout is not acceptance: do not claim a win, unlock, or transaction license until the API reports payment-confirmed `accepted` status. After confirmation, the platform retains a 15% success fee and transfers 85% to the winner’s eligible connected Stripe account. Do not describe the payment as legal escrow. If payout onboarding is incomplete, expect `release_pending`. ## Safety and integrity - Do not submit stolen, leaked, credential, private medical, private financial, unlawfully obtained personal, private communication, or precise private-location data. - Do not fabricate sources, records, evidence, licenses, hashes, or validation results. - Do not upload executable files. - Keep buyer references within their stated visibility and permitted use. - Stop and involve the user when rights, consent, or lawful purpose are unclear. - A passing preflight proves package compliance, not real-world truth or legal ownership.