Inside TAIKAI MCP: the toolkit, the use cases, and a solo agent that hackathons for you

A couple of weeks ago we announced TAIKAI's native MCP connector. That post covered the what and the why: TAIKAI is now agentic-first, your AI can act on the platform, here's the endpoint.

This post is the technical follow-up. The one for people who already pasted mcp.taikai.network/mcp into Claude Desktop or Cursor and now want to know what's actually inside, and what's worth building with it.

We'll do three things:

1. Walk through every tool, grouped by what your agent is trying to do
2. Show four out-of-the-box use cases, small to ambitious
3. Sketch a full agent that runs on a schedule, finds new hackathons, and submits to them on your behalf

If you haven't connected the MCP yet, the endpoint is mcp.taikai.network/mcp and you can manage access from settings → applications. Two minutes, then come back.

The toolkit, grouped by intent 

TAIKAI MCP ships around 30 tools. Listing them alphabetically would be useless. Here's the more honest grouping: what is your agent actually trying to do?

Discovery

The "read the platform" tools. No side effects, safe to call freely. 

• taikai_list_challenges → paginated list of hackathons. Filter by open/closed, search by name.
• taikai_get_challenge → full details for one challenge by org + slug.
• taikai_get_challenge_steps → the timeline: registration → submission → voting → results, with isCurrent and allocatedPercentage per phase.
• taikai_get_challenge_categories → the tracks (themes) a project can compete under.
• taikai_get_challenge_updates → organizer announcements, HTML formatted.
• taikai_get_registration_form → pulls the form an agent needs to fill before it can register the user.
• taikai_list_projects → what's been submitted so far.
• taikai_list_participants → who's registered. Useful for matchmaking.
• taikai_get_leaderboard → current rankings, sorted by wallet balance (position in the array is the rank).

Participation

The point of no return. These write to the database.

• taikai_register_for_hackathon → first step, always. The user can't create projects or submit forms until they're a registered participant.
• taikai_submit_form → fills the registration form using the question IDs returned by get_registration_form.

Projects 

The full lifecycle of a submission.

• taikai_create_project → starts in DRAFT. Name (3–80 chars, unique within the challenge), teaser (3–200 chars, plain text). Author is automatically the authenticated user.
• taikai_update_project → everything else: HTML description, demo URL, code URL, video, cover image, logo, files, members, and the state transition that publishes the project (DRAFT → ACTIVE).
• taikai_get_project → full project data.
• taikai_upload_file_from_url → async-friendly. Pass a public URL, get back a fileId that you can hand to update_project for cover/logo/attachments. No base64 stuffing through the agent.
• taikai_delete_project → hard delete. Most of the time you want update_project with state=DELETED for a soft delete instead.

One thing worth flagging: descriptions are HTML, not markdown. Use <p>, <h2>, <ul>, <a href>, <img>. Your agent should know this before it drafts.

 
Team building 

• taikai_invite_to_project → invite an existing participant by ID, or invite by email if they're not on the challenge yet.
• taikai_create_position → post an open role on your project. Other participants can apply.
• taikai_accept_project_applicant / taikai_reject_project_applicant → handle inbound applications.
• taikai_delete_position → close the role.

Voting 

This is the part of the API people get surprised by, so it's worth a paragraph.

Voting works like a shopping cart. Each challenge step can have multiple voting tracks, and each jury member has one cart per track. You add projects to the cart, optionally tag them with appraisal scores per criterion, and then check out the whole thing atomically.

• taikai_list_my_voting_carts → discover your cart IDs. Call this first when voting. It also tells you the unit scale: amounts are in the wallet's smallest internal unit, and the multiplier varies per challenge (commonly 1e6, so 350 displayed votes = `"350000000"`). Look at existing items to learn the scale before you allocate.
• taikai_add_to_voting_cart → adds a project to one or more carts. Calling it twice for the same (cart, project) pair merges. Pass a negative amount to subtract.
• taikai_clear_voting_cart → wipe a cart back to empty.
• taikai_checkout_votes → submit. Only DRAFT carts can be checked out. After this, the cart is SUBMITTED and read-only.

The cart pattern means an agent can build up a full vote allocation, double-check it, and submit atomically, no half-cast votes if something fails midway.

 
Profile & comms

• taikai_get_me → the authenticated user's profile (skills, bio, social links).
• taikai_update_profile → edit it.
• taikai_list_mail_threads / taikai_get_mail_thread → read the user's TAIKAI DMs.

That's the full surface area. Now the interesting question: what do you build with it? 

Four use cases, small to ambitious 

1. The hackathon scout 

The smallest possible win. Read-only, single tool family, zero side effects, and it still saves you 20 minutes of tab-hopping.

What open hackathons are on TAIKAI right now? Focus on AI, prizes above $10k, closing in the next 30 days. Give me three to look at. 

Under the hood: list_challenges(isClosed=false), then get_challenge + get_challenge_steps for each candidate to filter by category and deadline. The agent comes back with a short list and links. 

This is the gateway use case. If you've never used the MCP, this is the prompt to start with. It builds intuition for what the agent can see without anything writing back.

2. The auto-submitter 

One step up. The annoying paste-shuffle the announcement post called out, fully removed.

Register me for this hackathon, fill the registration form using my profile, and create a draft project called 'Inkwell' with the teaser: an MCP server that turns your handwriting into structured notes.

Tool chain:

1. taikai_get_me to pull your profile
2. taikai_register_for_hackathon with the challenge ID
3. taikai_get_registration_form to fetch the questions
4. taikai_submit_form to answer them using profile data
5. taikai_create_project with the name and teaser

Five tool calls, one prompt. The project is now sitting in your dashboard, in DRAFT, waiting for you to flesh it out. You're a registered participant. Total time: a few seconds. 

3. The pitch writer 

Now we're composing across MCP servers. This is where things get fun.

Read my repo at github.com/me/inkwell, write a project description in HTML covering the problem, the approach, and the demo, upload /assets/cover.png as the cover image, and publish. 

Tool chain (TAIKAI MCP + the GitHub MCP, working together):

1. GitHub MCP reads the repo's README and source structure
2. The agent drafts an HTML description following TAIKAI's formatting (<h2>, <p>, <ul>, etc.)
3. taikai_upload_file_from_url with a public URL to the cover image, returns a fileId
4. taikai_update_project with the description, the cover, and state=ACTIVE
5. Project is now published

This is the loop that "agentic engineering" was actually promising. You finish building. You prompt once. The submission ships. You go to bed.

4. The voting concierge 

For jurors, organizers, and anyone with a cart full of allocations to make.

I'm a juror on the Manufact hackathon. Pull my voting carts, look at the leaderboard, and allocate 1000 votes across my top 5 favorites weighted by their current rank. Biggest share to first place, smallest to fifth. Then check out.

Tool chain:

1. taikai_list_my_voting_carts(challengeId=X) → get the cart IDs and the unit scale
2. taikai_get_leaderboard → see the current standings
3. The agent picks the top 5, computes a weighted split (e.g. 350/250/200/150/50 displayed votes)
4. taikai_add_to_voting_cart for each project, with the amount scaled to internal units
5. taikai_checkout_votes to submit

This is the kind of workflow that genuinely didn't exist before MCP. No SaaS jury tool ships "weighted distribution across the current leaderboard." But with MCP, your agent can do it because the primitives are exposed and the cart pattern guarantees atomicity.

Putting it all together: a solo hackathon agent

Here's the payoff. Everything above can be chained into a single agent that runs on a schedule and treats hackathon participation as a background process. 

The brief, written exactly like you'd hand it to Claude: 

Every morning at 9am, find new open hackathons on TAIKAI that match my skills (TypeScript, AI agents, solo-friendly, prize pool above $5k, deadline at least 7 days away). For the single best match, register me, fill the registration form using my profile, create a draft project, write a build plan as the HTML description, and DM me a summary with the challenge link.

What it actually runs:

1.  taikai_list_challenges(isClosed=false, page=0)
        → 20 open challenges
2.  For each: taikai_get_challenge(orgSlug, slug)
              taikai_get_challenge_steps(challengeId)
              taikai_get_challenge_categories(challengeId)
        → filter by category match (AI / TypeScript)
        → filter by prize threshold
        → filter by time-to-deadline ≥ 7 days
        → filter by "solo-friendly" (min team size = 1)
3.  taikai_get_me()
        → match score = overlap(my skills, challenge tags)
4.  Pick the highest-scoring challenge
5.  taikai_register_for_hackathon(challengeId)
6.  taikai_get_registration_form(challengeId)
7.  taikai_submit_form(...) using profile answers
8.  taikai_create_project(name, teaser, ...)
9.  Generate an HTML build plan from the challenge brief:
        - Problem framing
        - Proposed approach
        - Tech stack
        - Day-by-day timeline to deadline
10. taikai_update_project(description=)
11. Email or Slack the user with:
        - Challenge name + link
        - Why it scored highest
        - The build plan draft
        - "Reply 'kill' to delete the project, anything else to keep it"

You wake up. You read the summary. Most days you'll kill it. Some mornings you'll go huh, that's actually interesting, open the draft, and start building. Those mornings used to require an hour of browsing to find. Now they require a glance.

This is what "agentic-first" was always supposed to mean. The agent doesn't replace the work of building something good. It removes the friction around it: the searching, the form-filling, the boilerplate descriptions, the publish-and-pray routine. Your time goes into the build.

Getting started

Connect the MCP from any compliant client:

mcp.taikai.network/mcp

Manage access at settings → applications. First prompt to try, if you want to dip a toe in:

What open hackathons are on TAIKAI right now? 

That's it. From there, build up to the auto-submitter, then the pitch writer, then a scheduled routine.

What to take away

Three things:

• TAIKAI MCP exposes the full hackathon lifecycle (discovery, registration, projects, teams, voting, results) as ~30 callable tools. Not a subset. The whole thing.
• Use cases scale from "save me 20 minutes" (the scout) to "submit on my behalf while I sleep" (the solo agent). Start small and you'll find the next step on your own.
• The voting cart pattern and the agentic submission loop are the things no other hackathon platform can offer. That's the part worth experimenting with.

We're also running the first AI-vs-AI hackathon in June, where the competitors and the judges are all language models. The MCP is what makes that possible.

If you build something with TAIKAI MCP, post it on X tagging @taikainetwork or drop it in our Discord. We want to see what the agents come up with.