Search InvestorMatch's public directory of VC investors and fundraising guides. No sign-in needed.
Scored across 4 tools
Each tool has a clearly distinct role: search_investors searches the firm directory, get_investor fetches a single firm's detail, list_investor_filters enumerates accepted filter values, and search_fundraising_guides searches articles. The search-vs-detail boundary between search_investors and get_investor is explicit and reinforced by cross-references in the descriptions.
All four names follow a clean verb_noun pattern (get_investor, list_investor_filters, search_fundraising_guides, search_investors) with consistent snake_case. The verbs get/list/search map predictably to the operation type.
Four tools is lean but fits a read-only public directory lookup service. Each tool earns its place, though the surface is small enough that it borders on thin.
The read-only lifecycle is well covered: filter discovery, directory search with pagination, full firm detail, and fundraising content. Since it is a public no-sign-in server, the absence of write/shortlist operations is expected, though a comparison or list-all capability could round it out.
Get a venture capital firm's full public InvestorMatch profile by its slug (from search_investors): thesis, stages, sectors, check size, partners and their focus, recent portfolio companies, funds and how the firm prefers to be approached. Contact emails are never included.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The firm's slug, e.g. "sequoia-capital". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the profile is 'full public' and contact emails are deliberately excluded, which tells the agent what it will and won't get without an output schema.
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?
One front-loaded sentence that puts the verb, resource and key first, then enumerates the payload. The enumeration is long but earns its place because there is no output schema; no filler sentences.
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 describe the return payload, and it does so thoroughly (thesis, stages, sectors, check size, partners, portfolio, funds, approach preferences) plus an explicit exclusion. It stops short of covering error behavior for an unknown slug.
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% with a single, fully documented slug parameter (including an example), so the schema carries the semantics. The description adds only the provenance of the slug, which is usage context rather than parameter meaning; 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 (get) and resource (a VC firm's full public InvestorMatch profile), keyed by slug, and enumerates the profile's contents so the agent knows exactly what comes back. It also distinguishes itself from search_investors by naming it as the source of the slug.
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 tells the agent where the slug comes from ('from search_investors'), which implies the correct two-step flow. It also sets a boundary ('Contact emails are never included'). It does not, however, state explicit when-not conditions or contrast the use case against list_investor_filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the exact stage, sector and location values search_investors accepts as filters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and non-open-world behavior, so the safety profile is covered. The description adds that these are the exact accepted values, but does not explain output format, ordering, or other behavioral details beyond what the annotations provide.
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 front-loaded sentence states exactly what the tool returns and for which sibling it matters. There is no filler or redundant restatement of the tool name.
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?
For a zero-parameter listing tool with no output schema, the description is complete enough: it identifies the kinds of values returned and the consuming tool. An agent has everything needed to decide whether to call it and what to expect.
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, so the baseline score is 4 per the rubric. The description correctly implies no input is required and focuses on the values returned rather than parameter meanings.
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 description states a specific verb and resource: listing the stage, sector, and location values that search_investors accepts. It clearly distinguishes this enumeration tool from the sibling search_investors tool, which consumes those values.
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?
By naming search_investors and the exact filter values it accepts, the description strongly implies this tool is used to discover valid inputs before searching. It does not explicitly state when not to use it or spell out an imperative workflow, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search InvestorMatch's published fundraising guides and articles (pitch decks, investor outreach, valuations, term sheets and more). Returns up to 10 articles with a title, excerpt and link. Leave query empty for the latest articles.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Topic keywords, e.g. "cold email to investors". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds behavior the annotations do not: a hard result cap of 10 items and the shape of each result (title, excerpt, link), which matters because there is no output schema. It does not discuss ranking or relevance behavior, keeping it below 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?
Two sentences, zero waste: scope and domain first, then the return contract and the empty-query rule. Front-loaded and appropriately sized for a one-parameter search tool.
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 return contract itself and does so adequately (up to 10 items, each with title, excerpt, link), plus the empty-query fallback. Nothing an agent needs 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% with a single well-documented parameter, so the baseline is 3. The description earns an extra point by defining the semantics of the empty/omitted value (returns latest articles), which the schema does not state.
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 (search) and resource (InvestorMatch's published fundraising guides and articles), and the parenthetical topic list (pitch decks, investor outreach, valuations, term sheets) pins down the content domain. This is unmistakably distinct from the sibling investor-lookup tools, so an agent can route correctly 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?
"Leave query empty for the latest articles" gives a concrete invocation rule for the zero-argument case, which is genuinely useful since the parameter is optional. It stops short of stating when to prefer this over alternatives or what kinds of queries it handles poorly, but the sibling tools occupy a clearly different domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search InvestorMatch's public directory of venture capital firms. Filter by firm name (query), stage, sector and HQ location; results are sorted alphabetically, 25 per page (up to page 20). Each result has the firm's stages, sectors, check size, a thesis summary and a link to its InvestorMatch profile. The accepted stage, sector and location values are listed by list_investor_filters, and a firm's full profile is in get_investor.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 1-20 (default 1). | |
| query | No | Part of the firm's name, e.g. "sequoia". | |
| stage | No | A stage from list_investor_filters, e.g. "Seed". | |
| sector | No | A sector from list_investor_filters. | |
| location | No | A location slug from list_investor_filters, e.g. "london". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds real behavior beyond them: alphabetical sort order, 25 results per page, and a hard cap of page 20, plus the field set returned per result. No contradiction with annotations.
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 sentences, front-loaded with the resource and directory scope, then filtering, then pagination, then cross-references. Every clause carries information; nothing is restated from the title.
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 compensates by enumerating the returned fields (stages, sectors, check size, thesis summary, profile link) and the pagination envelope. An agent has everything needed to call it and interpret results.
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 all five parameters are already documented in the schema, including the query-as-firm-name and the list_investor_filters dependency. The description reinforces the same mapping but adds no new syntax, format, or defaulting detail beyond the schema, which is the baseline-3 case.
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 ('Search InvestorMatch's public directory of venture capital firms') and scopes it as the public directory rather than the full profile, which distinguishes it from get_investor. An agent can tell what it retrieves 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 routes the agent to list_investor_filters for accepted stage/sector/location values and to get_investor for a full profile, which is strong sibling guidance. It stops short of stating when-not to use this tool (e.g. when you already know the firm), so it is clear context rather than a complete when/when-not rule set.
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_investorlist_investor_filterssearch_fundraising_guidessearch_investorsSearch VC investors and read your InvestorMatch campaigns, matches, outreach drafts and teardowns.
Search Signed's public angel investor directory by sector, check size, or keyword. No login needed.
VC and startup intelligence: AI VC Finder, deal sourcing, deck analysis and market data.
Search startups, look up scores, request research memos and read public startup research.
Add one secure layer between your agents and this server.