getfund

Submit application

getfund_submit_application

Starts a hosted run of an application: getfund's own browser opens the program's form, fills it from the application's answers and stops at a review that waits for the founder's approval; nothing reaches the program without that approval. Returns the run in the shape of the submission status: runId, status (queued) and watchUrl, the run's page on getfund where the founder follows it live and steps in for a login, a CAPTCHA or a code. Refused while hosted apply is paused (hosted_paused) or not enabled for the account (hosted_not_enabled), below Autopilot (payment_required), once the billing period's hosted submissions or the day's runs are used (hosted_quota_exhausted, hosted_daily_cap_reached), for an application that is submitted, archived or has no form to open, on a site that blocks getfund's browser (hosted_unsupported: the getfund extension applies there), on a site where a run of the last 30 days found no application form (hosted_unsupported, its message naming the contact the site shows, if any) and while the application has a run that has not ended (conflict). Needs applications:write and the Autopilot plan.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "applicationId": "<applicationId>"
    },
    "name": "getfund_submit_application"
  }
}

Input Schema

Name	Required	Description	Default
`applicationId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Far exceeds the generic annotations: it discloses that nothing reaches the program without founder approval, that the browser may need human intervention for login/CAPTCHA/code, and it enumerates every error code with its meaning. It also documents the return payload (runId, status, watchUrl) and the required scopes and plan.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the approval guarantee are front-loaded, then the return shape, then the refusal taxonomy. The long run-on error enumeration is dense but every clause is load-bearing given there is no output schema; only the sheer length of the final sentence costs it a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no parameter documentation, the description compensates fully: return fields, authorization scopes, plan requirement, and the full failure surface are all covered. An agent has everything needed to decide whether to call and how to interpret a refusal.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the single applicationId parameter, and it only implicitly conveys that the id selects the application whose answers are used and whose form is opened. It adds useful constraints about which application states are rejected, but does not say where to obtain the id or reinforce the UUID format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Starts a hosted run of an application') and immediately defines the scope of that run: getfund's browser opens the form, fills it, and halts at a review. This distinguishes it cleanly from getfund_approve_submission and getfund_submission_status, since it clearly produces the run those tools then act on.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is well framed: the run only proceeds after the founder's approval, and the many refusal conditions (hosted_paused, payment_required, quota exhaustion, submitted/archived applications, active run conflict) tell an agent precisely when not to call it. It also names the alternative path for hosted_unsupported (the getfund extension), though it never explicitly points at sibling tools by name for the follow-up approval step.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All getfund tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?