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, no...
Risk signalsBulk/mass operation — affects multiple targets
Part of the Mcp server.
Free to start. No card required.
AI agents use prep_and_submit_hackathon_entry to create or modify resources in Mcp. Write operations carry medium risk because an autonomous agent could trigger bulk unintended modifications. Rate limits prevent a single agent session from making hundreds of changes in rapid succession. Argument validation ensures the agent passes expected values.
Without a policy, an AI agent could call prep_and_submit_hackathon_entry repeatedly, creating or modifying resources faster than any human could review. PolicyLayer's rate limiting ensures write operations happen at a controlled pace, and argument validation catches malformed or unexpected inputs before they reach Mcp.
Write tools can modify data. A rate limit prevents runaway bulk operations from AI agents.
{
"version": "1",
"default": "deny",
"tools": {
"prep_and_submit_hackathon_entry": {
"limits": [
{
"counter": "prep_and_submit_hackathon_entry_rate",
"window": "minute",
"max": 30,
"scope": "grant"
}
]
}
}
}See the full Mcp policy for all 47 tools.
These attack patterns abuse exactly the kind of access prep_and_submit_hackathon_entry gives an agent. Each links to the full case and the policy that stops it:
Other write tools across the catalogue. The same approach applies to each: rate-limit and validate the arguments.
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 }. It is categorised as a Write tool in the Mcp MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
Register the MCP server in PolicyLayer and add a rule for prep_and_submit_hackathon_entry: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Mcp. Nothing to install.
prep_and_submit_hackathon_entry is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the prep_and_submit_hackathon_entry rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for prep_and_submit_hackathon_entry. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
prep_and_submit_hackathon_entry is provided by the MCP server (@butterbase/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 47 Mcp tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.