---
name: pitch-protocol
description: Submit a startup pitch to Pitch Protocol — a fund that reviews applications with a research pipeline. For founders, AI agents acting for a founder, and AI-founded companies.
homepage: https://pitchprotocol.vc
---

# Pitch Protocol — Reference

Submit a pitch to Pitch Protocol. The fund's partners review every application with help from a research and evaluation pipeline. You receive confirmation, tailored follow-up questions, and a decision.

Open to humans, AI agents acting for a founder, and AI-founded companies. Declare `submitterType` so questions adapt appropriately.

**Base URL** (this instance): `https://api.pitchprotocol.vc`. The same paths work on prod (`https://api.pitchprotocol.vc`), staging, and local dev.

Always re-fetch this file at the start of a session. The field schema is served live from the server.

## Tools & Endpoints

| Action                    | MCP Tool                    | REST Endpoint                                      |
|---------------------------|-----------------------------|----------------------------------------------------|
| Get live schema           | `get_application_schema`    | `GET /v1/applications/schema`                      |
| Create application        | `create_application`        | `POST /v1/applications`                            |
| Verify email              | `verify_email`              | `POST /v1/applications/{id}/verify-email`          |
| Resend verification code  | `resend_verification`       | `POST /v1/applications/{id}/resend-verification`   |
| Update draft              | `update_application`        | `PATCH /v1/applications/{id}`                      |
| Submit answers            | `submit_answers`            | `POST /v1/applications/{id}/answers`               |
| Get status                | `get_status`                | `GET /v1/applications/{id}`                        |
| Upload deck (PDF)         | — (HTTP only)               | `POST /v1/applications/{id}/deck`                  |
| Withdraw application      | — (HTTP only)               | `POST /v1/applications/{id}/withdraw`              |

**Deck uploads must use plain HTTP** (not MCP) — see the Deck Upload section below for the exact `curl`. Optional; research runs fine without a deck.

## Always fetch the schema first

```bash
curl -fsS "https://api.pitchprotocol.vc/v1/applications/schema"
```

This returns every field, type, character limit, enum, and a complete valid example. Never hardcode field names from memory.

## The Flow

1. Fetch schema (once per session)
2. **Ask for source material** — a deck, one-pager, website, memo, or even a few sentences. Build the payload from what they give you; this is what keeps the submission correct rather than invented.
3. Assemble payload (their material + research + conversation), then **walk the founder/agent through it** — read it back in plain prose, attribute each part to its source, and let them correct before you create.
4. `POST /v1/applications` → returns `applicationId` + sends 6-digit code
5. (Optional, if the founder has a deck PDF) Upload it via the `curl` in the Deck Upload section below — while status is still `draft`
6. `POST .../verify-email` → starts research pipeline, locks deck upload
7. Poll `GET /v1/applications/{id}` until `status` becomes `intake` and follow-up questions appear
8. `POST .../answers` with `finalize: true` → status becomes `submitted`, hands application to partners

## Statuses

| Status | Meaning |
|--------|---------|
| `draft` | Application created, awaiting email verification |
| `researching` | Email verified, research pipeline running (~5–10 min) |
| `intake` | Research complete, intake questions ready for founder |
| `submitted` | Answers received, application handed to partners. Terminal for the founder. |
| `failed` | Research pipeline error. Contact support. |
| `withdrawn` | Founder withdrew. Row preserved for audit. |

## Create Application

```bash
curl -X POST "https://api.pitchprotocol.vc/v1/applications" \
  -H "content-type: application/json" \
  -d '{
    "contactEmail": "you@example.com",
    "payload": { /* see live schema for full shape */ }
  }'
```

Save the `applicationId`. All subsequent calls use it.

## Deck Upload (HTTP only)

Optional — research runs fine without a deck. If the founder has a deck PDF, upload it as a raw binary over plain HTTP (binary doesn't fit through MCP). Run it from a shell while status is still `draft` (uploads lock once `verify_email` flips status to `researching`). PDF only, max 20 MB.

```bash
curl -fsS -X POST \
  -H 'Content-Type: application/pdf' \
  --data-binary @<path-to-deck.pdf> \
  "https://api.pitchprotocol.vc/v1/applications/$ID/deck"
```

## Update or Withdraw

`PATCH` accepts `payload` (full replacement) and/or `contactEmail`.

To replace the payload safely:
- `GET` the current application
- Modify locally
- `PATCH` with the complete new `payload`

Withdraw at any non-terminal status:
```bash
curl -X POST "https://api.pitchprotocol.vc/v1/applications/$ID/withdraw"
```

## Submit Answers

```bash
curl -X POST "https://api.pitchprotocol.vc/v1/applications/$ID/answers" \
  -H "content-type: application/json" \
  -d '{
    "answers": [{"questionId": "q1", "answer": "your answer here"}],
    "finalize": true
  }'
```

`finalize: true` is required to trigger partner review.

## Status Response

Returns:
- `status` — one of `draft`, `researching`, `intake`, `submitted`, `failed`, `withdrawn`
- `payload` — the full application as last submitted
- `deck` — `{ state, chars }` where state is `none`, `pending`, `ready`, or `failed`
- `intake.questions` — array of `{ questionId, text, priority }` (only when `status` is `intake`)
- `intake.answeredIds` — question IDs already answered
- `intake.remainingRequired` — required question IDs still unanswered
- `nextAction` — human-readable instruction for what to do next

Partners' internal research notes and final decision are **not** returned here.

## Common Mistakes

| Mistake                                      | Fix                                                              |
|----------------------------------------------|------------------------------------------------------------------|
| Hardcoding field names from memory           | Always call `get_application_schema` first                       |
| Re-POSTing after a 400                       | Use `PATCH` on the existing `applicationId`                      |
| Forgetting `finalize: true`                  | Partner review only starts after `finalize: true`                |
| Uploading deck after email verification      | Deck upload is only possible while status is `draft` (before `verify_email`). Deck is optional. |
| Using MCP for deck upload                    | Binary can't go through MCP — use the plain HTTP `curl` in the Deck Upload section |
| `submitterType: aiAgent` without `governance`| Governance block is recommended for non-`humanFounder` submitters |
| Using `id`/`text` in answers payload         | Correct field names are `questionId` and `answer`                |

## What Stays Live vs Can Drift

- The field schema at `/v1/applications/schema` is generated directly from the production Swift types — it is always current.
- Endpoint paths under `/v1/` are stable public contracts.
- Prose, examples, and recommendations in this file can drift between releases. Re-fetch when in doubt and trust the live API responses.

## If a human founder is sitting with you

**Never paste the schema or a field list at them.**

Your job is to run a natural conversation and assemble a clean, truthful payload.

Be efficient, but not brief at their expense. Move fast by leaning on their material and research and by batching questions — not by skipping the walk-through or the teaching. As you walk through the draft, briefly explain what each field is for, why a partner cares, and what you inferred and from where. The founder should come away understanding their own submission better, not just approving it.

**Recommended pattern:**

1. **Ask what they have** — a deck, one-pager, website, memo, or a few sentences. Ground the payload in it; don't make them build from a blank page.
2. Lead with what you already know from that material and research.
3. Ask **one wide opening question** for whatever's still missing.
4. Parse their answers into fields yourself.
5. **Show a readable draft** in plain English and **walk them through it** — for each part, say what you wrote and where it came from (deck, their answer, research) so they can catch anything wrong.
6. Only ask about remaining gaps or corrections after they review the draft.

**Bad patterns to avoid:**
- Starting to draft before asking what material they have.
- Firing individual field questions one after another.
- Dumping raw schema markdown or field names.
- Filling in plausible-looking values without confirmation.
- Submitting fields you never read back to them.
- Creating the application before showing the draft.

**Good pattern (target):**
Ask for material → extract + background research → one opening question for gaps → show draft in readable prose and walk through each part's source → one cleanup round → create (after they approve).

---

**MCP clients** also receive a tighter operational playbook on `initialize`. See the server’s `instructions` for agent-specific guidance.