@Pitch Protocol
Basic information
Transport
Streamable HTTP
Authentication
Check provider docs
Category
Finance & Commerce
Author
Pitch Protocol
Submitted by
Josh May
Founder-side MCP server for Pitch Protocol, agent-native venture capital. A founder's agent submits one application (about ten minutes, no web form, deck optional) and it is reviewed and matched against the theses of 15+ partner venture funds, who reach out directly. Free for founders, any geography, pre-seed and seed.
https://api.pitchprotocol.vc/mcp/founderclaude mcp add pitch-protocol --transport http https://api.pitchprotocol.vc/mcp/founderIssue a fresh 6-digit verification code. Supersedes any prior unconsumed code. **When:** founder didn't receive the first code, the code expired, or too many wrong attempts invalidated it. **Before you call:** nothing. Safe to call multiple times (rate-limited). **Returns:** confirmation the new code was emailed (in dev: the code itself). **On error:** - Rate-limited — the error tells you how many seconds to wait. Don't spam. - Already verified — status already past `draft`. Nothing to resend. Call `get_status` to confirm the current state.
Update an application's payload and/or contact email while it's still in `draft`. **When:** founder caught something wrong after `create_application` but before `verify_email`. Also when changing the email address. **Before you call:** - Full-replace on payload: send the WHOLE `PitchApplication` object, not a patch. Read current values from `get_status` if you don't have them. - Email change resets verification: `emailVerified` goes back to false and a fresh code is sent to the NEW address. Let the founder know. **Returns:** the fresh `StatusView` — markdown by default, JSON if `responseFormat: "json"`. Same shape as `get_status`. **On error:** - `notEditable` — status is past `draft`. Nothing to update; state is locked. Read `get_status` to understand where you are. - Validation failed — payload doesn't satisfy the schema. Fix per the error message and retry.
The primary status endpoint. Returns the full current state of an application: status, email verification, deck state, intake questions (when ready), and a `nextAction` string. **While research runs (`status == "researching"`) — read this:** This call WAITS server-side. It holds for up to ~45 seconds and returns the instant research finishes (or after ~45s if nothing has changed yet). You do NOT sleep or set timers yourself — you just call it again. Research usually completes within a handful of these blocking calls (~5–10 min total). Between calls, give the founder a short "still researching…" note so they're not left wondering — but do NOT ask permission to keep checking, and do NOT hand control back as if it failed. Keep calling until `status` leaves `researching`. In all other states (`draft`, `intake`, `submitted`, `failed`, `withdrawn`) this returns immediately and `nextAction` is the founder-facing instruction — read it to them verbatim and act on their reply. **When to call:** - After `verify_email` — call again and again until status leaves `researching`. - When the founder asks for an update. - To read intake questions when `status == "intake"`. **Before you call:** nothing. **Returns:** markdown by default. Use `responseFormat: "json"` when you need to branch programmatically on `status` / `deck.state`. **On error:** `notFound` if the applicationId is wrong. Otherwise safe to call repeatedly.
Save the founder's answers to the intake questions. Upsert semantics with an explicit commit flag. **When:** `status == "intake"`, after research generates the questions. Read them from `get_status` → `intake.questions`. **Before you call:** - READ the questions to the founder verbatim. Ask only the question `text` — do not volunteer or invent any internal rationale for why we ask. - Collect answers conversationally; don't make them answer all five at once if they'd rather talk through them. - If `finalize: true`: show every answer back to the founder for confirmation first. This is one-way — after finalize they can't edit. - If `finalize: false` (autosave): no confirmation needed. **Answers shape:** array of `{questionId, answer}` objects. Only include question ids that were in the `get_status` response — other ids are rejected. **Upsert rules:** - Answers with matching `questionId` overwrite. - Prior answers for ids NOT in this batch are KEPT. - So you can save Q1 + Q2 in one call, Q3-Q5 in another, then commit with `finalize: true` + empty `answers: []` at the end. **On error:** - `unknown questionIds` — check spelling / the id list from `get_status`. - `missing required` — on `finalize: true`, every `priority=required` must have an answer. Error lists which are missing. - `alreadyAnswered` — you called finalize twice. Status is `submitted`; no more edits. - Wrong status — not in `intake` yet (still researching) or already past it.
Consume the 6-digit code the founder received and start the research pipeline. **When:** after `create_application`, and ideally after the deck has been uploaded over plain HTTP (see the `curl` printed by `create_application`). Founder has read the code from their inbox. **Before you call:** - CONFIRM you have the right code from the founder (not guessing, not stale). Once this succeeds, research starts and is irreversible. - If deck parsing is still pending, that's fine — research auto-defers and dispatches when the deck resolves. Don't wait, don't re-verify. **Returns:** `status: researching` + whether research was dispatched now or deferred on the deck. **On error:** - `wrong code` — response includes attempts-remaining. Ask the founder to check their inbox again. If the error says the code is invalidated, call `resend_verification` for a new one. - `no active code` — they never received one, or it expired. Call `resend_verification`. - Already verified — idempotent success; returns current status. Don't retry in a loop.
Create a new pitch application draft and send a 6-digit verification code to `contactEmail`. **When:** once you have a complete payload (research + deck + founder confirmed). One per conversation with a given founder. **Before you call:** 1. `get_application_schema` — know the fields, limits, enums. 2. Get the founder's source material — deck, memo, one-pager, website, or even a few sentences — and READ/parse it yourself (plus web search) to fill the payload. The deck is an input you read, not a file to upload. 3. Ask the founder for anything you can't find or confirm. Don't fabricate — leave gaps and ask. 4. Show the assembled payload to the founder for review before submitting. **Returns:** `applicationId` — required for every subsequent tool call — plus `codeSent` and (in dev) `devCode`. **Next:** ask the founder for the 6-digit code and call `verify_email`.
The authoritative field reference for the `PitchApplication` payload. **When:** call this FIRST in every session. Cache the response. **Before you call:** nothing — no inputs. **Returns:** markdown listing every field, type, limit, enum, plus a complete valid example. With this in context, you can assemble a payload that validates on the first `create_application`.
Pitch Protocol is agent-native venture capital infrastructure. Instead of a web form, a founder's own AI agent (Claude, Cursor, ChatGPT, or any agent that can read a URL and make HTTP calls) connects to this server and submits the application on the founder's behalf. One submission is reviewed and matched against the theses of 15+ partner venture funds; funds that are interested reach out to the founder directly.
Founders raising a pre-seed or seed round, anywhere in the world. Applying is free and a deck is optional.
Either connect the remote server at https://api.pitchprotocol.vc/mcp/founder, or tell your agent: Read https://api.pitchprotocol.vc/skill.md and submit my company to Pitch Protocol. The agent packages the pitch, submits it, and you verify by email. Takes about ten minutes.
The Pitch Protocol remote MCP server is a hosted Model Context Protocol endpoint at https://api.pitchprotocol.vc/mcp/founder, so AI assistants can connect to it without installing or running anything locally.
Add the endpoint https://api.pitchprotocol.vc/mcp/founder to any MCP-compatible client such as Claude Code, Cursor, or VS Code. The setup snippets on this page configure each client in one step.
Authentication requirements for Pitch Protocol have not been confirmed in this listing. Check the provider’s documentation before connecting.
Pitch Protocol exposes a Streamable HTTP endpoint, the transport used by remote MCP servers and supported by all major MCP clients.
AdaptlyPost: Schedule and publish social posts to Instagram, TikTok, YouTube, X, Facebook, LinkedIn, Pinterest, Threads, and Bluesky from any MCP client.
Search and read current AWS documentation, check regional availability and load AWS agent skills, with no AWS account needed.
Pharmaceutical drug & clinical trial intelligence
AOI is a commercial environmental-intelligence gateway that gives AI agents programmatic access to 38 real-world intelligence capabilities — climate risk, satellite monitoring, methane detection, water & soil, vegetation
Discover, evaluate, and buy solutions for the cloud
Comments