Search 3,650+ institutional venture capital firms and 13,000+ partners by stage, sector, and HQ.
Scored across 3 tools
search_investors (find many) and get_investor_details (retrieve one firm) are clearly distinct, and get_mode_vc_thesis_and_criteria targets Mode VC's own published parameters rather than the directory. The thesis tool is a slight outlier from the atlas theme but its scope is unambiguous.
All three follow a verb_noun snake_case pattern (get_*, search_*), which is readable and predictable. The only deviation is the unusually long get_mode_vc_thesis_and_criteria, but the convention itself is consistent.
Three tools is on the lean side for a directory of 3,650 firms and 13,000 partners, but each earns its place: search, detail retrieval, and thesis lookup. It is well-scoped rather than padded, just slightly thin.
The read-only lookup lifecycle (search by multiple filters, retrieve full firm details) is well covered for a directory. Minor gaps remain, such as no direct partner-level lookup or sector enumeration, but agents can work around these via search.
Returns one firm from the Investor Atlas: headquarters and locations, website and social links, latest fund as listed, reported entry stages, check size bands (lowest and highest the firm reports) and lead preference where known, sectors, and up to 12 partner names (the total partner count is also given). It does not include portfolio companies or investment theses.
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_name | Yes | Firm slug or name, e.g. "andreessen-horowitz", "sequoia-capital", "accel", "406-ventures" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety bar is low. The description adds real behavioral detail beyond that: the 12-partner cap, that the total partner count is still returned, and which data domains are out of scope — meaningful because there is no output schema to disclose the return shape.
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?
Two sentences, front-loaded with the action and return contents, with the limiting constraints (12 partners, no portfolio/theses) placed last where they belong. The field enumeration is dense but every item carries selection value.
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 no output schema, the description carries the full burden of describing return values and does so thoroughly, including caps and absences. Combined with 100%-covered parameters and read-only annotations, an agent has everything needed to call it correctly.
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 single parameter already carries a description with concrete slug/name examples. The description adds no lookup-format guidance (matching rules, ambiguity handling) beyond what the schema provides, so the 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?
States a specific verb and resource ('Returns one firm from the Investor Atlas') and then enumerates exactly what is returned: HQ/locations, links, latest fund, entry stages, check size bands, lead preference, sectors, partners. The closing exclusion of portfolio companies and investment theses implicitly separates it from get_mode_vc_thesis_and_criteria and from search_investors.
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 scope exclusions ('does not include portfolio companies or investment theses') hint that another tool covers theses, but neither sibling is named and no explicit when-to-use condition is stated. Usage is implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns Mode VC's published investment parameters as stated on https://modevc.com/thesis: ticket size, geography focus, stage, core conviction and how to pitch.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds meaningful non-annotation context: the data is published/firm-authored material sourced from a specific URL, implying a static snapshot rather than live deal data or personalized guidance. It does not state staleness or freshness guarantees.
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?
A single sentence that front-loads the verb and resource and then lists the returned content. No filler, no restatement of the title, nothing that fails to earn its place.
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 no output schema, the description must carry the return-value burden, and it does so by enumerating the fields returned (ticket size, geography, stage, conviction, how to pitch). Combined with annotations covering safety and zero params, this is nearly complete; only freshness/staleness of the published data is left unstated.
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?
The tool takes zero parameters (empty object, additionalProperties=false), so per the rubric the baseline is 4. There is nothing for the description to disambiguate on the input side, and it does not confuse the reader with any implied optional inputs.
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: 'Returns Mode VC's published investment parameters' followed by an explicit enumeration of the payload (ticket size, geography focus, stage, core conviction, how to pitch). An agent can immediately tell this is a firm-level thesis lookup. It does not explicitly contrast itself with get_investor_details or search_investors, so it stops short of a 5.
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?
Usage is only implied — the mention of 'how to pitch' hints at the fundraising/pitch-prep scenario, but there is no explicit when-to-use, when-not-to-use, or alternative routing (e.g. 'use get_investor_details for other firms, this only covers Mode VC'). Adequate but leaves the agent to infer the trigger condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the Mode VC Investor Atlas, a directory of venture capital firms and their partners compiled from public information (counts are in the response). Filter by firm or partner name, sector, entry stage, and headquarters or location. Stage and check size are as reported by each firm where available; it does not hold portfolio companies or fund performance.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum firms to return. Default 10. | |
| query | No | Firm or partner name, e.g. "a16z", "Benchmark", "Marc Andreessen", "Khosla" | |
| stage | No | Entry stage the firm reports investing at | |
| sector | No | Sector slug, e.g. "ai-and-data", "dev-tools-and-infra", "enterprise-software", "fintech", "crypto", "healthtech", "climate", "consumer" | |
| location | No | Geographic hub, e.g. "california", "new-york", "massachusetts", "toronto", "united-states" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely non-structured context: data provenance ('compiled from public information'), that counts appear in the response, and that stage/check size are self-reported and may be unavailable. No contradictions.
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?
Three compact sentences: purpose first, filters second, caveats last. Every clause carries information, and the parenthetical about counts is short. Slightly dense in the middle sentence but appropriately sized with 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 no output schema, the description does the necessary work: it names the data source, the filterable dimensions, the reliability caveat on self-reported fields, and notes that counts are returned. What is still missing is a hint at the shape of a result record (fields returned per firm/partner), which would help an agent chain into get_investor_details.
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 every parameter is already documented with examples and enums; the baseline is 3. The description's sentence 'Filter by firm or partner name, sector, entry stage, and headquarters or location' largely restates the schema, adding only the caveat that stage and check size are as reported by each firm.
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 and resource ('Searches the Mode VC Investor Atlas') and immediately defines scope: a directory of VC firms and their partners compiled from public info. It also draws negative boundaries ('does not hold portfolio companies or fund performance'), which lets an agent distinguish this from get_investor_details and the thesis tool at a glance.
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 description enumerates the filter dimensions, which implies how to narrow a search, but never states when to choose this tool over the sibling get_investor_details or get_mode_vc_thesis_and_criteria, nor any recommended sequence (search first, then fetch details). Usage is implied rather than guided.
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.
get_investor_details1 field changedInput schema / properties / slug_or_name / descriptionPrevious value: -"Firm slug or exact name (e.g. \"andreessen-horowitz\", \"sequoia-capital\", \"accel\", \"406-ventures\")"New value: +"Firm slug or name, e.g. \"andreessen-horowitz\", \"sequoia-capital\", \"accel\", \"406-ventures\""search_investors5 fields changedInput schema / properties / limit / defaultRemoved value: -10Input schema / properties / limit / descriptionPrevious value: -"Number of results to return (max 50)"New value: +"Maximum firms to return. Default 10."Input schema / properties / query / descriptionPrevious value: -"Name of the firm or individual partner (e.g. \"a16z\", \"Benchmark\", \"Marc Andreessen\", \"Khosla\")"New value: +"Firm or partner name, e.g. \"a16z\", \"Benchmark\", \"Marc Andreessen\", \"Khosla\""Input schema / properties / sector / descriptionPrevious value: -"Target sector, e.g. \"ai-and-data\", \"dev-tools-and-infra\", \"enterprise-software\", \"fintech\", \"crypto\", \"healthtech\", \"climate\", \"consumer\""New value: +"Sector slug, e.g. \"ai-and-data\", \"dev-tools-and-infra\", \"enterprise-software\", \"fintech\", \"crypto\", \"healthtech\", \"climate\", \"consumer\""Input schema / properties / stage / descriptionPrevious value: -"Target investment stage"New value: +"Entry stage the firm reports investing at"get_investor_detailsget_mode_vc_thesis_and_criteriasearch_investorsSearch institutional pre-seed venture capital firms, partner profiles, and valuation.
Search institutional seed venture capital firms, partner profiles, and valuation benchmarks on.
Search institutional series-a venture capital firms, partner profiles, and valuation.
Search 58,000+ angel investors and VCs by market and location, see portfolios, and reveal emails.
Add one secure layer between your agents and this server.