Search 58,000+ angel investors and VCs by market and location, see portfolios, and reveal emails.
Scored across 5 tools
Most tools have clearly distinct purposes: get_investor (detail), reveal_investor_email (contact action), and recent_funding_rounds (funding events) are unambiguous. The one soft overlap is search_investors vs company_investors, since search can already filter by a company backed, but the descriptions frame company_investors as a focused, activity-sorted view, which mostly disambiguates them.
All names use consistent snake_case, which is a strong plus. However, only get_investor, search_investors, and reveal_investor_email follow a verb_noun pattern, while company_investors and recent_funding_rounds are bare noun phrases, a minor deviation.
Five tools is a reasonable, well-scoped set for an investor database: search, detail lookup, email reveal, a company-based investor view, and funding rounds. It is slightly lean but each tool earns its place.
The surface covers the core read-only workflow: find investors, inspect a profile, view a company's backers, browse recent rounds, and reveal contact emails. Gaps are minor (no firm-centric browsing, market/industry enumeration, or saved-list operations), but nothing blocks typical agent workflows.
Angel investors in AngelBacked who backed a named company (exact company name, case-insensitive), most active first, up to 50. Use it to find investors who already back companies like yours.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | Company name, e.g. "Notion". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does disclose real behavioral traits: exact company-name matching, case-insensitivity, 'most active first' ordering, and a hard cap of 50 results. It omits anything about pagination past 50, data freshness, or auth requirements, which keeps it from the top score.
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, both earning their place: the first front-loads scope, matching rule, ordering and cap; the second adds the use case. No padding or 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 single-parameter read lookup with no output schema and no annotations, the description covers scope, match semantics, ordering and result limit adequately. Only the truncation behavior at 50 results is left unexplained.
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, and the description adds meaningful matching semantics the schema lacks (exact match, case-insensitive) beyond the schema's bare "Company name, e.g. 'Notion'".
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?
Names a specific resource (angel investors), a specific filter (those who backed a named company) and the data source (AngelBacked), so an agent can tell it apart from the generic siblings like search_investors. It stops short of explicitly contrasting itself with those siblings, which keeps it from 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?
"Use it to find investors who already back companies like yours" gives one positive usage context, but there is no when-not guidance and no mention of search_investors as the alternative for non-portfolio lookups. Usage is implied rather than delimited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full profile for one investor by id or slug (from search results or an angelbacked.co/investor/ URL): title, firm, location, markets, social links and up to 100 portfolio companies. No email; use reveal_investor_email.
| Name | Required | Description | Default |
|---|---|---|---|
| investor | Yes | Investor id (uuid) or profile slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and largely meets it for a read tool: it discloses the field set returned, the 'up to 100 portfolio companies' cap, and the deliberate omission of email. It does not mention rate limits, auth/permission needs, or truncation/pagination behavior beyond the portfolio cap.
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 dense sentence plus one short routing clause; field scope and identifier sources are front-loaded before the email exclusion. 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?
For a one-parameter read tool with no output schema, the description adequately previews the returned fields and the inbox exclusion. Minor gaps remain around pagination of the 100-company portfolio list and error behavior for invalid slugs.
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 meaning the schema lacks: it clarifies the slug can be sourced from search results or scraped from an angelbacked.co/investor/<slug> URL, which tells the agent how to obtain a valid value.
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 ('Full profile for one investor') and pins the lookup key ('by id or slug'), which cleanly separates it from search_investors and company_investors. The enumeration of returned fields (title, firm, location, markets, social links, portfolios) further concretizes what 'full profile' means.
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?
It tells the agent where the identifier comes from ('from search results or an angelbacked.co/investor/<slug> URL') and routes one sub-use case to an alternative ('No email; use reveal_investor_email'). That is real when-to-use guidance, though it stops short of stating explicit exclusions or prerequisites for the general case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent startup funding rounds tracked by AngelBacked Signals: company, date, stage, amount and industry, newest first. Filter by days back (max 180), industry and stage (e.g. "Seed", "Series A", "Pre-Seed").
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback in days. Default 30. | |
| page | No | Page number (1-20). Default 1. | |
| stage | No | Exact round stage, case-insensitive (e.g. "Seed"). | |
| industry | No | Industry, partial match (e.g. "Health"). | |
| per_page | No | Results per page (max 25). Default 25. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose useful behavior: the data source, that results are sorted 'newest first', and the fields returned. It omits pagination behavior despite three pagination-related params, and says nothing about rate limits, auth, or result volume, leaving real gaps for a no-annotation tool.
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 front-loaded sentences that lead with what the tool returns before describing filters. It is efficient, though the 'max 180' detail duplicates the schema and the second sentence crams three filters 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?
Since there is no output schema, the description usefully enumerates the returned fields and sort order, which is exactly what an agent needs for a listing tool. It is slightly incomplete on pagination semantics (page/per_page behavior), but the essentials for correct invocation are present.
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%, so the schema already documents all five parameters including defaults and the 180-day cap. The description repeats the day cap and offers stage examples that the schema essentially already provides ('Seed'), adding little beyond the structured fields.
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 names a specific resource and verb: 'Recent startup funding rounds tracked by AngelBacked Signals', and enumerates the returned fields (company, date, stage, amount, industry). The resource is clearly distinct from the investor-oriented siblings, though no sibling is named to make the distinction explicit.
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?
It states the available filters ('days back (max 180), industry and stage') and gives stage examples, which implies intended usage. However, there is no explicit when-to-use guidance, no exclusions, and no routing to alternatives among the investor tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reveal one investor's email address. Uses the account's email reveal allowance (the same one as the Reveal button on angelbacked.co; Annual: 500 per day, 3,000 per 30 days). Revealing an investor the account has already revealed is free. Only reveal investors the user intends to contact.
| Name | Required | Description | Default |
|---|---|---|---|
| investor_id | Yes | Investor id (uuid) from search_investors or get_investor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses the shared account allowance, the concrete quota numbers (500/day, 3,000/30 days), and that re-revealing an already-revealed investor is free. It omits what happens when the allowance is exhausted and any error/auth behavior, which leaves a modest gap.
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 tight sentences, front-loaded with the action and immediately followed by cost mechanics and the usage caution. Every sentence earns its place; nothing is redundant with the name or 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?
For a single-param mutation with no output schema or annotations, the description covers the operation, its cost model, and idempotency behavior sufficiently. Only the failure mode on quota exhaustion is unaddressed.
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% for the single investor_id parameter, which the schema already documents as a uuid sourced from search_investors or get_investor. The description adds no parameter-level meaning beyond the schema, 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?
States a specific verb and resource — 'Reveal one investor's email address' — which is clearly distinct from the read-only siblings (get_investor, search_investors). An agent can tell this is the paywalled email-unmasking action, not a generic lookup.
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?
Gives an explicit usage constraint ('Only reveal investors the user intends to contact') and contextualizes the action as quota-consuming, which steers the agent away from casual calls. It does not name the upstream step (search_investors/get_investor) that should precede it, but the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 58,000+ angel investors and VCs in AngelBacked. Filter by free text (name, firm, title), market/sector, location, or a company they backed. Returns id, name, title, firm, city/state/country, markets, portfolio_count, LinkedIn/Twitter/website, profile_url and has_email. Emails are not included: call reveal_investor_email for the investors you actually want to contact. Sorted by portfolio size.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-20). Default 1. | |
| query | No | Free text matched against name, firm and title (e.g. "former founder", "Sequoia"). | |
| market | No | Market/sector, partial match (e.g. "FinTech", "Artificial Intelligence", "SaaS"). | |
| location | No | City, state or country, partial match (e.g. "Austin", "California", "United Kingdom"). | |
| per_page | No | Results per page (max 25). Default 25. | |
| min_portfolio | No | Minimum number of portfolio companies (activity filter). | |
| portfolio_company | No | Only investors who backed this company (partial match, e.g. "Stripe"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well: it discloses the returned field set, the sort order (portfolio size), and the critical constraint that emails are excluded. It omits auth requirements and pagination caps, though the latter are captured in the 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?
Purpose is front-loaded, filtering options follow, then the return contract and the email caveat. Every sentence earns its place; the return-field enumeration substitutes for a missing output schema 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?
For a search tool with no output schema and no annotations, the description covers the essential contract: what is searchable, what comes back, the sort order, and the email limitation. Only pagination behavior is left implicit, and that is handled in the schema.
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%, so all seven parameters are already documented with examples. The description restates the filterable dimensions (free text, market/sector, location, backed company) but adds no syntax or matching semantics beyond the schema, 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?
States a specific verb (Search) and resource (angel investors and VCs in AngelBacked) with a concrete scope of 58,000+. It is clearly distinguishable from siblings like get_investor and reveal_investor_email.
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?
Gives explicit context (use for broad investor discovery) and names the alternative with the precise condition that selects it: emails are not returned, so call reveal_investor_email for contacts you actually want. This is exactly the routing guidance an agent needs vs. siblings.
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.
company_investorsget_investorrecent_funding_roundsreveal_investor_emailsearch_investorsCurated investor database: 10,469 VC, angel, PE, and family office firms with contacts, via MCP.
VC and startup intelligence: AI VC Finder, deal sourcing, deck analysis and market data.
Search 3,650+ institutional venture capital firms and 13,000+ partners by stage, sector, and HQ.
Person-checked US VC firms and startup investors with verified work emails and LinkedIn profiles.
Add one secure layer between your agents and this server.