F4 Raise

Find VC firms

find_vc_firms

Use this when a founder asks which venture capital investors to pitch, wants an investor list for a fundraise, or asks which VC firms back a kind of startup. Not for fundraising mechanics such as SAFEs, valuation or dilution, or for investor contact details. Ranks up to 20 public VC firms for a startup from a plain-language description of 10 to 500 characters. Each firm comes with up to three public companies it backed that resemble the startup, and a link to its F4 page. The result also carries one link to a free, longer report on f4.fund built from the company's pitch deck, which ranks about 100 firms. The optional stage removes firms whose stated stages are all two or more steps away from it, so a firm one stage away can remain. The optional round size removes firms whose smallest cheque is more than twice the round. The optional location lists firms whose stated geography excludes it after the firms that invest there. These are applied only when given. The optional website is used for its domain, and its home page may be read. F4 stores the description, website domain, stage and round size to fill in the report form and count how the plugin is used. Each call saves a new search and prefilled report link. It sends no email and contacts no firm, and it returns no contact details.

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": {
      "description": "<description>"
    },
    "name": "find_vc_firms"
  }
}

Input Schema

Name	Required	Description
`stage`	No	The funding stage of the round, only if the founder stated it. Firms whose stated stages are all two or more steps away from it are removed, so a firm one stage away can remain.
`website`	No	The startup's website, only if the founder stated it. Only the domain is used.
`location`	No	Where the startup is based, only if the founder stated it. Firms whose stated geography excludes it are listed after the firms that invest there.
`description`	Yes	What the startup does and for whom, in plain language, in the founder's words. 10 to 500 characters.
`roundSizeUsd`	No	The size of the round in US dollars, only if the founder stated it. Firms whose smallest cheque is more than twice the round are removed.

Output Schema

Name	Required	Description	Default
`code`	No
`count`	No
`firms`	No
`issues`	No
`method`	No
`status`	Yes
`applied`	No
`message`	No
`missing`	No
`reportUrl`	No
`emailOffered`	No
`retryAfterSeconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: it discloses that F4 persists the description, domain, stage and round size, that each call creates a new saved search and prefilled report link (consistent with idempotentHint=false and readOnlyHint=false), and that it sends no email, contacts no firm and returns no contact details. It also explains the ranking and filtering semantics rather than just asserting a list is returned.

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

Conciseness3/5

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

Front-loaded correctly with usage first and behavior second, and most sentences carry real information. However, it runs long and re-litigates parameter rules that already live in the schema descriptions, which is wasted space for an agent that reads both.

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?

Covers everything an agent needs for a tool with five params, side effects and an output schema: what it ranks, what each result contains, how filters behave, what is stored, and what it deliberately does not do. Return-value explanation is arguably redundant given the output schema, but nothing material is missing.

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 100%, so the schema already documents all five parameters, and the description largely restates those same rules (stage distance, cheque-vs-round ratio, location ordering). It does add one point of meaning the schema lacks — that the optional filters 'are applied only when given' — but otherwise the value-add over the schema is marginal.

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 ('Ranks up to 20 public VC firms') plus concrete triggering intents ('which venture capital investors to pitch', 'an investor list for a fundraise'), and explicitly carves out what it is not ('fundraising mechanics such as SAFEs, valuation or dilution, or investor contact details'). An agent can distinguish it from get_vc_firm_details and email_report_link 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.

Usage Guidelines4/5

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

Gives clear when-to-use triggers and explicit exclusions, which is more than most definitions. It does not name the sibling tools it should route to instead (get_vc_firm_details for firm detail, email_report_link for sending), leaving that inference to the agent.

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

All F4 Raise 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?