Agent-to-agent fundraising for pre-seed and seed founders: a founder's AI agent submits one structured application, Pitch Protocol runs research and thesis matching and routes the company to venture funds, with a decision in about 48 hours. Free, no web form. Skill: https://www.pitchprotocol.vc/skill.md
Score is being calculated.
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:
get_application_schema — know the fields, limits, enums.
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.
Ask the founder for anything you can't find or confirm. Don't fabricate — leave gaps and ask.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Full PitchApplication JSON payload. Call `get_application_schema` for field list + limits. | |
| submittedBy | Yes | Identifier for the agent/client submitting on the founder's behalf (e.g. your client name or ID). Required — every application must record who submitted it. | |
| contactEmail | Yes | Email where the 6-digit verification code will be sent. Must be the founder's real address. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-readonly, non-idempotent, non-destructive, open-world. The description adds the concrete side effect (an email is dispatched to contactEmail), a per-founder rate-like constraint ('one per conversation with a given founder'), and the dev-only devCode. It does not spell out failure/rejection behavior, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and the side effect, then organized into bold-labeled When/Before/Returns/Next blocks. The length is justified by a multi-step, multi-tool workflow rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, the return value (applicationId) needed downstream, and the next tool (verify_email). With an output schema present the description needn't explain return shape, yet it still surfaces the fields that drive subsequent calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents all three parameters, so the baseline is 3. The description reinforces that payload must be assembled from source material and that contactEmail must be the founder's real address, but adds little syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Create a new pitch application draft') and an immediate side effect ('send a 6-digit verification code to contactEmail'). It names the sibling tools it interacts with (get_application_schema, verify_email), so an agent can place it in the flow without opening sibling schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When' clause (complete payload, one per conversation per founder) plus a four-step prerequisite list including 'don't fabricate — leave gaps and ask' and 'show the assembled payload for review'. It distinguishes the path from sibling read tools and tells the agent exactly what must precede the call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond them: the return is markdown, it should be cached, and it guarantees a validating payload. It stops short of stating stability guarantees across sessions, so not a full 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Bold-labeled sections (When / Before / Returns) front-load the actionable guidance, and every sentence contributes: timing, absence of inputs, return shape, and the payoff. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and zero parameters, the remaining burden is guidance, and the description supplies timing, caching advice, return format, and the reason to call it. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4; schema coverage is 100% and the description confirms 'nothing — no inputs,' which removes any ambiguity about a call signature that is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ('the authoritative field reference for the PitchApplication payload') with a clear function, and distinguishes itself from siblings like create_application by positioning itself as the schema source those tools consume. An agent can tell exactly what it gets without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'call this FIRST in every session. Cache the response,' giving both timing and a reuse policy. It also names the downstream sibling (create_application) whose success depends on this call, routing usage unambiguously.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| applicationId | Yes | Application id from `create_application`. | |
| responseFormat | No | `markdown` (default) or `json`. JSON returns the raw StatusView for programmatic use. | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds behavior the annotations cannot express: the call blocks server-side for up to ~45s and returns early when research finishes, so the agent must not sleep on its own. It also documents the expected duration (~5-10 min of repeated calls) and the specific error code (notFound on a bad applicationId). This is exactly the extra context the annotations bar leaves room for.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the return payload, then bulked out with the polling contract, and it uses headers to make the branching states scannable. It runs long and repeats the keep-calling instruction several ways ('call it again', 'keep calling', 'do NOT hand control back'), but that emphasis is arguably load-bearing for a tool whose main failure mode is premature abandonment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the branch-relevant state machine, the polling contract, the response format choice, and the error case; an output schema exists, so return-value detail needn't be restated. Nothing an agent needs in order to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents both parameters, including that json returns the raw StatusView. The description's responseFormat note ('use json when you need to branch programmatically on status / deck.state') adds only a small amount of selection guidance beyond the schema, so it sits at the baseline rather than above it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a concrete verb+resource ('The primary status endpoint. Returns the full current state of an application') and enumerates exactly what that state contains (status, email verification, deck state, intake questions, nextAction). This clearly distinguishes it from the mutation-oriented siblings (create_application, verify_email, submit_answers, update_application) without the agent needing to open a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call (after verify_email, on founder request, to read intake questions at status == intake) and, critically, how to behave in the polling loop versus the terminal states. It names the sibling verify_email as the preceding step and gives an explicit stop condition ('keep calling until status leaves researching'), leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue 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.
| Name | Required | Description | Default |
|---|---|---|---|
| applicationId | Yes | Application id from `create_application`. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations: it discloses the supersede/invalidation side effect, rate limiting with a wait-time hint and 'don't spam' guidance, dev-environment return of the raw code, and the 'already verified' failure mode keyed to status past `draft`. This is behavior an agent could not infer from readOnlyHint=false and idempotentHint=false alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded one-line purpose, then headed blocks (When / Before you call / Returns / On error) that let an agent scan to the relevant part. No filler sentences; every line carries operational meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the full lifecycle for a simple one-param mutation: trigger conditions, prerequisites, side effects, success confirmation, and both documented error branches. Output schema exists, so return-value detail is appropriately brief.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema coverage is 100%, with the schema itself linking applicationId back to create_application. The description adds no syntax, format, or sourcing detail beyond what the schema already states, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Issue a fresh 6-digit verification code,' plus the key differentiator 'supersedes any prior unconsumed code,' which separates it from verify_email and create_application in the sibling set. An agent can pick this tool without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When' block enumerates the three triggering conditions (no code received, code expired, locked out by wrong attempts) and 'Before you call: nothing' pre-empts prerequisite hunting. Error paths explicitly route to get_status when the application is already verified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | Array of `{questionId, answer}` objects. Can be empty when finalize is true. | |
| finalize | No | If true, commits the answers and flips status to submitted. One-way — confirm with founder first. | |
| applicationId | Yes | Application id from `create_application`. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false; the description goes well beyond them by spelling out upsert rules (matching ids overwrite, unmatched prior answers are KEPT), that finalize is one-way and irreversible, and a full error taxonomy (unknown questionIds, missing required, alreadyAnswered, wrong status). Nothing contradicts the annotations, and the irreversibility disclosure adds real value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded (purpose, then When, then pre-call steps, then upsert rules, then errors), so each block is scannable and earns its place for a mutation tool with real protocol. It is at the edge of verbose for a 3-parameter tool, keeping it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value explanation is unnecessary, and the description covers the remaining gaps: status preconditions, confirmation requirements, upsert behavior, and error recovery. An agent has everything needed to call this correctly and recover from failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it clarifies that `answers` is an array of `{questionId, answer}` limited to ids returned by `get_status`, that empty answers are valid on finalize, and how questionId matching drives the upsert. It stops short of a full 5 only because most field-level documentation is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb+resource ('Save the founder's answers to the intake questions') and immediately characterizes the operation as 'Upsert semantics with an explicit commit flag.' It explicitly ties itself to the sibling `get_status` for reading questions, so an agent can distinguish it from siblings like `update_application` without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'When' precondition (`status == "intake"`, after research generates questions), a pre-call checklist, and a distinction between finalize=true (confirm first, one-way) and finalize=false (autosave, no confirmation). This covers when-to-use, when-not, and the semantics that select each mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | Full PitchApplication JSON (optional). Replaces the current payload wholesale. | |
| contactEmail | No | New contact email (optional). Resets verification and issues a new code. | |
| applicationId | Yes | Application id from `create_application`. | |
| responseFormat | No | `markdown` (default) or `json`. JSON returns the raw StatusView for programmatic use. | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations covering safety (idempotent, non-destructive), the description adds material behavior: the payload is a full replace (not a patch), an email change resets `emailVerified` to false and re-sends a code to the NEW address, and the terminal `notEditable` state past `draft`. It also discloses the return shape and how to request JSON.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose followed by clearly labeled When / Before you call / Returns / On error sections. Every block carries distinct decision-relevant content with no filler, and the format guidance is compressed into one clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still notes the return is a `StatusView` matching `get_status` and how to get JSON. With mutation semantics, an irreversible verification reset, and multiple enumerated error states all covered, nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already states 'replaces the current payload wholesale' and 'resets verification and issues a new code,' so the description largely restates those. It does add operational value the schema lacks: read current values from `get_status` before sending a full payload, and warn the founder about the email change.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence gives a specific verb (update), resource (application), and scope constraint (payload and/or contact email, only while in `draft`). It further pins the boundary by referencing the siblings it sits between (`create_application`, `verify_email`), so an agent can distinguish it from them without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit '**When:**' section names the two triggering situations (fixing a mistake after `create_application`, changing the email) and the lifecycle window (before `verify_email`). Alternatives are routed by name (`get_status` for reading, `create_application` for the initial write), and failure-mode guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The 6-digit numeric code from the founder's inbox. | |
| applicationId | Yes | Application id from `create_application`. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare non-read-only, idempotent, non-destructive and open-world; the description adds far more: the operation is irreversible once it succeeds, research auto-defers when deck parsing is pending, wrong-code errors return attempts-remaining, and re-verification is an idempotent success rather than an error. This is exactly the behavioral context annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Bold-labeled sections (When, Before you call, Returns, On error) make it scannable and front-loaded, with the irreversible consequence stated before the call. Despite its length, every line carries actionable content for a stateful, error-prone operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, side effects, deferral behavior, idempotency, and a full error taxonomy. An output schema exists, yet the description still summarizes the return shape, so an agent has everything needed to call it and interpret both success and failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are documented, so the baseline is 3. The description still adds real meaning: the code must be the founder's current, non-stale, non-guessed code, and the applicationId traces back to create_application, which goes slightly beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('consume the 6-digit code') and the consequential effect ('start the research pipeline'), which cleanly separates it from resend_verification and get_status. An agent can identify the tool's role without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit ordering ('after create_application, and ideally after the deck has been uploaded'), explicit exclusions ('Don't wait, don't re-verify'), and named alternatives for each failure mode ('call resend_verification for a new one'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_applicationget_application_schemaget_statusresend_verificationsubmit_answersupdate_applicationverify_email
Add one secure layer between your agents and this server.