prep_and_submit_hackathon_entry

Tool of io.github.butterbase-ai/mcp

Prep and submit your project to a Butterbase hackathon. Two-step flow. The tool resolves which hackathon you mean from your submission_code (or, if you've already submitted before, your existing binding). You do NOT pass a slug — that's figured out for you. If resolution is ambiguous (no code, not yet bound, and multiple hackathons are open), the tool returns the list of open hackathons; ask the user which one they mean and re-run with a code. STEP 1 — action: "prep" Resolves the hackathon and returns its field_schema if exactly one is identified. Pass submission_code when you have it. Otherwise the tool will fall back to "user already bound" or "only one hackathon open". Use the schema to: • Show the user every field's "label" and "description" (never the internal "key"). • Propose a value for each field and wait for the user's explicit confirmation before STEP 2. Do NOT auto-fill values from guesses, prior context, or app metadata without showing the user every field value first. If resolution returns multiple open hackathons with no match, present "open_hackathons" to the user and ask them to provide the submission_code. STEP 2 — action: "submit" Submits the confirmed "data" object. Pass hackathon_slug = matched.slug from the prep response so submit always targets the same hackathon prep resolved (matters when multiple are open). Re-running updates the existing submission and bumps version. Closes after the hackathon's submission_deadline. App scoring: Always pass app_id on submit when you can. Hackathon scoring awards up to 50 points for a demo URL on butterbase.dev and up to 50 additional points for Butterbase features measured on that specific app (database, functions, deployed frontend, auth users, storage, OAuth, realtime, integrations, etc.). Without app_id only the demo URL is scored, so entries without it almost always rank lower. Including app_id also ties the submission to a real app, which is much better for human judges. Submission code: On the FIRST submission you must include the submission_code provided by the hackathon organizers. The same code is used to identify the hackathon during prep, so pass it on prep too. After the first successful submission the code is no longer required (the user is bound by user_id). Recommended flow: 1. Get the submission_code from the user (skip if they've already submitted before). 2. Call with action: "prep", submission_code to resolve + retrieve the schema. • If matched is null and open_hackathons has multiple entries, ask the user which one and re-run with a code. 3. Show the user each field's label / description, propose values, and wait for confirmation. 4. Call with action: "submit", hackathon_slug = matched.slug from prep, data: {...confirmed values}, app_id, and submission_code (if provided in step 1). Returns: prep → { matched: { slug, name, submission_deadline, ends_at, field_schema } | null, match_reason, open_hackathons, next_call?: { tool, arguments, instructions } } When matched is non-null, next_call contains a fully-formed example submit invocation with placeholders for each field. Use it as the literal shape for STEP 2: replace each placeholder in arguments.data with the user-confirmed value, then call this tool with those args. submit → { submission: { id, hackathon_slug, version, data, app_id, ... }, participant_created }