Curated & traceable AI venture data: verified funding events, org & founder profiles, US + China
Scored across 9 tools
Each tool maps to a distinct resource/aggregation: profile lookups (organization vs person), search (organizations vs articles), funding events, sector aggregates, comparable companies, and investors-by-sector. The only mild overlaps are search_organizations vs get_organization_profile (list vs detail) and get_svtr_stats vs get_sector_landscape (both aggregate numbers), but descriptions make the boundaries clear.
Every tool follows a strict verb_noun snake_case pattern: get_* for retrieval/aggregation and search_* for lookups. get_svtr_stats is the only brand-specific name but still fits the get_ + noun convention.
Nine tools for a venture-database query surface is well within the ideal range, and each one covers a distinct query type (entity profiles, search, funding, sector stats, comparables, investors, articles, site stats). No tool appears redundant or wasteful.
Entity profiles, search, funding events, aggregates, and comparables are covered, but there is a notable gap: no way to query/filter companies by sector, stage, or geography (search_organizations is name/alias only), and funding events are capped to a 7-day window with no historical funding search. There is also no person search counterpart to search_organizations, making some discovery workflows dead ends.
哪些投资机构在投某个方向：按近 24 个月已确认出手笔数排名的活跃投资机构（如「投资 AI4S 的机构有哪些」）。sector 用 SVTR 标准赛道，tag 用行业主题标签（AI4S / 智能体 / 人形机器人 / 药物发现 等，见 svtr.ai/orgs）。标签与赛道说的都是被投公司的属性，不是机构自己的。Which investors back a given sector or topic: active AI investors ranked by confirmed deals in the last 24 months.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | SVTR industry topic tag of the portfolio companies (e.g. AI4S, 智能体, 人形机器人). Mutually exclusive with sector; if both are given, sector wins and the tag is reported as ignored. | |
| lang | No | Output language, default zh (Chinese). | |
| sector | No | SVTR standard sector of the portfolio companies. Mutually exclusive with tag. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only profile, so the bar is lower, and the description adds genuine behavioral context: the ranking is by confirmed deals within a specific 24-month window, and output language is controllable. It doesn't describe the shape/count of returned investors, but that is a minor 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?
Front-loads the core question and the ranking rule. The main inefficiency is that the Chinese and English halves largely restate each other, adding length, though the structure remains easy to parse.
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?
No output schema exists, but the description covers the ranking basis, time window, filter semantics, and language control, which is enough for a zero-required-parameter read tool. The only missing piece is a hint about the returned list's size or ordering details beyond 'ranked by deals'.
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 beyond the schema by clarifying that both sector and tag describe the portfolio companies' attributes rather than the investor's own, and it reinforces the sector-precedence rule. This nuance is not fully spelled out in the schema.
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+resource: ranks active AI investors by confirmed deal count in the last 24 months, filtered by a sector or topic. The example query ('投资 AI4S 的机构有哪些') makes the intent concrete. It does not name or distinguish itself from the potentially overlapping sibling get_sector_landscape, so it falls just 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?
Provides clear context for when to reach for it ('Which investors back a given sector or topic') plus a worked example. It does not state exclusions or explicitly route the agent to alternative tools for related questions, so no 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
某家 AI 公司的可比公司：按美国 / 中国 / 欧洲分组，每组至多 3 家，列最近轮次与时间、累计融资、已披露估值，以及可核对的对标理由（同细分赛道 / 同赛道 / 同阶段 / 累计融资同一量级）。与 svtr.ai 公司详情页「可比公司」同一份数据。Comparable companies for one AI company, grouped by US / China / Europe (up to 3 each), with latest round, total raised, disclosed valuation and verifiable match reasons.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Company slug, UUID, or name / alias (e.g. "lovable", "逐际动力"). | |
| lang | No | Output language, default zh (Chinese). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the structural constraint of at most 3 companies per region and the match-reason taxonomy, but says nothing about behavior such as how an unknown/ambiguous ref is handled. Adequate given annotation coverage, but not rich.
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 and the sentences are information-dense with no filler. The full text is duplicated verbatim in Chinese and English, which is defensible for a bilingual audience but does double the length.
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?
There is no output schema, so the description carries the return-value burden and does it well: grouping, per-group cap, included fields and match reasons are all enumerated. The only gap is error/edge-case handling for an unresolvable ref, which is minor for a read-only lookup.
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%, with both 'ref' (slug/UUID/name/alias) and 'lang' (enum zh/en) documented in the schema itself. The description adds no parameter-level detail beyond the schema, 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+resource (comparable companies for one AI company) and defines the exact shape of the result: grouping by US/China/Europe, up to 3 per group, with round, funding, valuation and match reasons. This scope is clearly distinct from sibling tools like get_sector_landscape (sector-level) or get_organization_profile (single company detail).
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 implies the use case (fetch comparables for one company) and notes the data mirrors the svtr.ai company-detail page, which gives some context. However, it never states when to choose this over get_sector_landscape, get_organization_profile, or search_organizations, and offers no exclusions or prerequisites beyond the implicit need for a company ref.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按名称或 slug 取一家公司/投资机构的公开档案：简介、赛道、总部、累计融资、近期融资史（含来源链接）、投资机构的代表出手。Get the public profile of one organization: intro, sector, HQ, total funding, recent funding rounds with sources.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Organization name, alias, or svtr.ai slug. | |
| lang | No | Output language, default zh (Chinese). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine behavioral value beyond them by disclosing exactly what data the profile contains, including that funding rounds come 'with sources' – useful for judging output trustworthiness.
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?
The content is front-loaded and each clause lists real return fields, but the entire description is duplicated in Chinese and English, so roughly half the text repeats itself rather than adding information.
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 simple two-parameter read tool with full schema coverage and annotations carrying the safety profile, the description covers purpose, lookup key and returned fields adequately. Without an output schema, naming the response contents is a reasonable substitute, though freshness or auth expectations are 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?
Schema description coverage is 100%, so both parameters (ref, lang with default zh) are already documented in the schema. The description restates that lookup works 'by name or slug' but adds no format, alias-resolution, or language-override detail beyond the schema.
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 ('Get the public profile of one organization') and enumerates the payload (intro, sector, HQ, total funding, funding rounds with sources). The 'one organization' scope implicitly contrasts with the plural search_organizations sibling, but it never names that sibling explicitly, 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 agent infers this is the tool to call when it already has a name/alias/slug for a single org. There is no statement of when to prefer it over search_organizations or get_person_profile, and no exclusions or prerequisites given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按姓名或 slug 取一位创始人/投资人的公开档案：现任机构与职务、工作经历、教育背景。Get the public profile of one founder or investor: current roles, work experience, education.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Person name or svtr.ai slug. | |
| lang | No | Output language, default zh (Chinese). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds that the data is 'public' and enumerates the returned fields, but says nothing about behavior on unknown refs, result freshness, or empty responses.
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?
Front-loaded with the core action and field list, two short sentences. The cost is that the Chinese and English halves are near-identical in content, doubling length for i18n purposes rather than adding information.
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 only two parameters, no output schema and annotations covering the safety profile, the description is largely sufficient; listing the three returned facets compensates for the absent output schema. It stops short of describing error behavior or how a slug is resolved.
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% and both parameters are documented in-schema (ref as name or svtr.ai slug, lang defaulting to zh). The description only restates the name/slug notion in Chinese and never mentions the lang parameter, so it adds no meaning beyond the schema. 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: fetch the public profile of one founder/investor, and enumerates the returned facets (current roles, work experience, education). The 'person' framing implicitly separates it from the sibling get_organization_profile, but no sibling is named explicitly.
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 implied by the input hint (look up by name or slug), but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as search_organizations or get_organization_profile. An agent can infer the intent but gets no guidance on edge cases like ambiguous names or missing profiles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
最近 7 天有公开来源的 AI 融资事件（公开档位时间窗），可按赛道/行业主题标签/阶段/公司名等单一维度筛选。Sourced AI funding events from the last 7 days (public-tier window), filterable by one dimension (sector, industry topic tag such as AI4S, stage, company, country, year).
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | SVTR industry topic tag of the funded company (e.g. AI4S, 智能体, 人形机器人; see svtr.ai/orgs). Narrower than sector. | |
| lang | No | Output language, default zh (Chinese). | |
| year | No | Filter by announced year. | |
| stage | No | Normalized funding stage. English names (e.g. Seed, Series A) are also accepted. | |
| sector | No | SVTR standard sector. English names (e.g. Robotics, Life Sciences) are also accepted. | |
| company | No | Company name filter. | |
| country | No | HQ country: Chinese name (美国), English name (United States) or ISO code (US). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral context — the 7-day window boundary and the 'public-tier' source restriction — but says nothing about result ordering, volume, or pagination behavior for what is presumably a feed.
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 parallel sentences, one per language, with the time window and the single-dimension constraint front-loaded. The bilingual duplication is justified because a lang parameter exists and the audience is bilingual; each sentence still carries the scope plus filter list.
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 7-optional-parameter list tool with no output schema, the definition covers selection well but omits anything about the returned record shape, expected result count, or whether an empty window yields an empty list. An agent can call it correctly, but cannot predict what comes back.
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 enums are documented, so the schema carries most parameter meaning. The description nonetheless adds a non-obvious constraint that filters apply along a 'single dimension' — i.e. these filters are not meant to be combined — which is not derivable from the schema and materially changes how an agent would call the tool.
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 gives a specific verb+resource+scope: 'AI funding events from the last 7 days (public-tier window)'. The 7-day recency window and 'public source' qualifier make it distinguishable from get_sector_landscape or search_organizations. It stops short of naming a sibling as the alternative for broader/older queries.
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 implied by the scoping ('last 7 days', public-tier), so an agent can infer this is the recency feed rather than a general search. However, there is no explicit when-not guidance and no named alternative for older events or multi-filter exploration, so the agent must infer routing from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI 赛道融资景观聚合统计：总额/笔数/中位数，全库赛道 Top10 或单赛道的阶段分布。仅聚合数字，无行级数据。Aggregated funding landscape: totals, top sectors, or stage breakdown for one sector.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Output language, default zh (Chinese). | |
| year | No | Filter by announced year. | |
| sector | No | Omit for cross-sector Top 10 landscape. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds meaningful context: output is aggregated only with no row-level data, which sets expectations about granularity and result 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?
Bilingual duplication means the same content is stated twice, adding bulk. However, each version is front-loaded and the key constraint (aggregates only) appears early, so the structure is sound despite the redundancy.
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?
There is no output schema, so the description must carry return-value expectations — and it does, listing totals, counts, median, Top 10 and stage breakdown. Combined with the 'no row-level data' note, an agent has enough to call it correctly, though response pagination or empty-result behavior 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%, so all three parameters (including lang default and year range) are already documented in the schema. The description's 'omit sector for Top 10' restates the schema's own note rather than adding syntax or semantics beyond it — 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 (aggregated funding landscape statistics) and enumerates the exact outputs — totals, deal counts, median, cross-sector Top 10, or per-sector stage distribution. The '仅聚合数字，无行级数据' note cleanly distinguishes it from row-level siblings like get_recent_funding_events.
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 describes the two usage modes — omit `sector` for the cross-sector Top 10, supply it for a single-sector stage breakdown — and clarifies that only aggregates are returned, implying row-level needs should go elsewhere. It never names the alternative sibling, so the routing guidance is contextual rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SVTR AI 创投库对外统计：已收录 AI 公司数、投资机构数、人物数、有公开来源的融资轮数、原创文章数。Public counts of the SVTR AI Venture Database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the lower bar applies. The description adds the scope of what is counted, notably the qualifier that funding-round counts are limited to those with public sources, which is behavioral detail not present in the annotations. However, it does not state the shape or key names of the response, and there is no output schema to fill that 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?
It is short and front-loaded, opening with the resource and then listing the counted entities. The same content is restated in Chinese and then English, so there is some duplication, but that bilingual structure is intentional 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 zero-parameter, read-only tool with no output schema, the description says why it exists and enumerates the five metrics returned, which is close to all the context an agent needs. The only remaining gap is the exact response format and key names, which an agent must discover by calling it.
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 of 4 applies, and the description introduces no confusing parameter-like language. Nothing beyond the baseline is needed here.
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 contains a specific verb ('对外统计' / public counts) plus the resource (the SVTR AI Venture Database) and even enumerates the countable entities: AI companies, investors, people, publicly-sourced funding rounds, and original articles. That is enough to separate it from sibling profile/search tools, though it never names a sibling explicitly.
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: an agent can infer this is the tool for headline/overview numbers, but the description contains no explicit 'use this when' statement, no ordering advice (e.g. call before search tools), and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索 SVTR AI 创投库的公司与投资机构（按名称/别名，如 "Anthropic"、"a16z"）。Search AI companies and investors in the SVTR AI Venture Database by name or alias.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Output language, default zh (Chinese). | |
| type | No | Restrict to AI companies or investors; omit for both. | |
| limit | No | Max results (default 5). | |
| query | Yes | Company or investor name/alias, 2-80 chars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the data-source scope (SVTR database, name/alias matching); it says nothing about result ordering, matching behavior (fuzzy vs exact), or empty-result handling.
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?
The lead statement is front-loaded and short, with the purpose stated in the first clause. However, the content is fully duplicated across Chinese and English, so half the tokens convey no new information for an English-reading agent.
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 some burden for describing the return shape, and it does not say what a result contains (name, alias, type, identifiers) or how matches are ranked. For a simple search tool with full schema coverage and read-only annotations, this is adequate but with a clear gap.
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 four parameters are already documented in the schema, including the type and lang enums and the limit bounds. The examples in the description add only marginal meaning beyond that baseline.
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 verb (search) and resource (companies and investors) and scopes it to the SVTR AI Venture Database, with concrete example queries ("Anthropic", "a16z"). It does not explicitly contrast itself with get_organization_profile, but the search-vs-fetch distinction is inferable from the names.
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 "by name or alias" phrasing and the examples suggest this is a lookup-entry-point tool, but there is no statement of when to prefer it over get_organization_profile or when not to use it. No alternatives or prerequisites are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索 SVTR 原创研究文章（Thesis 投资论文 / Profile 创始人深度 / Radar 事件判断 / 周报等，已发布口径）。Search SVTR original research articles.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Output language, default zh (Chinese). | |
| limit | No | Max results (default 5). | |
| query | Yes | Keyword in title or summary, 2-80 chars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered without the description. The description contributes one extra behavioral fact — that results are restricted to the published corpus ('已发布口径') — but says nothing about ranking, matching semantics, or pagination.
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?
The content-type enumeration is front-loaded and useful, but the English sentence is a straight translation of the Chinese with no added information, so roughly half the text is redundant for a bilingual reader.
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 simple three-parameter read-only search with no output schema, the definition covers what the tool searches over but not what a result contains or how matches are ranked. Adequate but with clear gaps for an agent deciding whether a hit is relevant.
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%: query (keyword in title or summary, 2-80 chars), lang (enum zh/en), and limit (1-10) are all documented in the schema. The description adds no parameter-level detail beyond that, so the baseline of 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 (SVTR 原创研究文章) and enumerates the content types covered (Thesis, Profile, Radar, 周报), which lets an agent tell this apart from search_organizations. It stops short of explicitly naming the sibling it differs from, so it lands at 4 rather than 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?
There is no when-to-use or when-not-to-use guidance and no alternative tool is named, despite search_organizations being an obvious near-neighbor. The only scoping signal is '已发布口径' (published only), which is a filter, not usage guidance.
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_recent_funding_events4 fields changedInput schema / properties / country / descriptionPrevious value: -"HQ country (Chinese name, e.g. 美国/中国)."New value: +"HQ country: Chinese name (美国), English name (United States) or ISO code (US)."Input schema / properties / sector / descriptionPrevious value: -"SVTR standard sector (26 values)."New value: +"SVTR standard sector. English names (e.g. Robotics, Life Sciences) are also accepted."Input schema / properties / stage / descriptionPrevious value: -"Normalized funding stage."New value: +"Normalized funding stage. English names (e.g. Seed, Series A) are also accepted."Input schema / properties / tagAdded value: +{
+ "description": "SVTR industry topic tag of the funded company (e.g. AI4S, 智能体, 人形机器人; see svtr.ai/orgs). Narrower than sector.",
+ "type": "string"
+}get_comparable_companiesget_active_investorsget_organization_profileget_person_profileget_recent_funding_eventsget_sector_landscapeget_svtr_statssearch_organizationssearch_svtr_articlesVC and startup intelligence: AI VC Finder, deal sourcing, deck analysis and market data.
Funding rounds, AI startup and investor search, email discovery, agent-readiness. No API key.
Agentic fundraising intelligence: 950+ tracked VC funds and 751 disclosed LPs over MCP
Pre-diligence AI for founders, investors, and firms — multi-agent pitch analysis and deal flow.
Add one secure layer between your agents and this server.
