Hosted MCP for IT桔子 primary market company, funding, investor and sector data.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.7/5 across 17 of 17 tools scored. Lowest: 2.7/5.
Each tool targets a distinct resource and action: counting vs searching vs retrieving profiles vs ranking vs resolving. There is no ambiguity as tools like count_companies and search_companies have clearly separated purposes (count vs list). Even similar tools like search_companies and search_closed_companies are distinguished by company status.
All tool names follow the verb_noun pattern (e.g., search_companies, get_company_profile, resolve_companies) using snake_case consistently. The naming is predictable and clear, with only minor variations like aggregate_funding_by_tags which still starts with a verb.
With 17 tools, the server covers a comprehensive set of operations for a company/funding database without being overwhelming. Each tool serves a specific need, and the count aligns well with the domain's complexity.
The tool set covers all major operations for querying companies, funding, investors, events, FA cases, tags, and lookups. It includes both aggregated counts and detailed listings, ranking, and name resolution. No obvious gaps for a read-only data retrieval server.
aggregate_funding_by_tagsAInspect按公司标签、时间段和地区聚合融资事件数、披露金额事件数、获投公司数和融资总额，适合回答某赛道或标签集合在全国/城市之间的融资统计和同比、环比对比；统计默认包含未披露水下事件。
| Name | Required | Description | Default |
|---|---|---|---|
| regions | Yes | ||
| tag_ids | No | ||
| location | No | ||
| scope_ids | No | ||
| date_ranges | Yes | ||
| is_underwater | No | ||
| sub_scope_ids | No | ||
| event_category | No | investment | |
| tag_match_mode | No | union | |
| exclude_round_ids | No | ||
| include_round_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that statistics include undisclosed underwater events by default, but other behavioral aspects like pagination, handling of multiple date ranges, or effect of optional parameters are not explained.
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 with no redundancy. The key information is front-loaded: purpose, metrics, typical use cases, and a notable default. Every sentence adds 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?
Given the complexity (11 parameters, output schema exists), the description covers the essential purpose and a key default. With an output schema documenting return values, the description does not need to explain output format. It is adequate for an experienced user.
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 0%, so the description must compensate. It explains the core parameters (tags, time, region) and a default behavior (including underwater events). However, many parameters like tag_match_mode, event_category, and various ID lists are not addressed, leaving gaps.
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 clearly states the tool aggregates funding metrics (events, disclosed amount events, invested companies, total amount) by tags, time period, and region. It distinguishes itself from sibling search/lookup tools by being an aggregation tool.
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 specifies this tool is suitable for answering funding statistics and YoY/QoQ comparisons across regions for a set of tags, giving clear usage context. It does not explicitly mention when not to use it, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
count_closed_companiesAInspect按行业、标签、地区、成立年份、发展阶段、公司资质、关闭日期、关闭原因或一级关闭原因统计死亡/关闭公司数量。适合回答某赛道倒闭公司有多少家、某年度关闭公司数量、某原因下关闭公司总数；不要为了计数遍历 search_closed_companies 分页。
| Name | Required | Description | Default |
|---|---|---|---|
| cities | No | ||
| keyword | No | ||
| tag_ids | No | ||
| location | No | ||
| provinces | No | ||
| scope_ids | No | ||
| is_unicorn | No | ||
| born_year_end | No | ||
| is_horse_club | No | ||
| sub_scope_ids | No | ||
| close_date_end | No | ||
| tag_match_mode | No | union | |
| born_year_start | No | ||
| fund_status_ids | No | ||
| close_date_start | No | ||
| closure_type_ids | No | ||
| qualification_type_ids | No | ||
| closure_parent_type_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. Description mentions counting by dimensions but does not specify output format (single count vs grouped counts) or other traits. Partially transparent but lacks complete behavioral disclosure.
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?
Description is a single focused paragraph, front-loaded with purpose and usage guidance. Efficient but could be structured with bullet points for clarity.
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?
Tool has 18 parameters and an output schema, but description omits return value details and parameter mappings. Incomplete for complex input, leaving gaps for agent understanding.
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 0% (no parameter descriptions). Description lists high-level dimensions (industry, tag, region) but does not map them to specific parameter names (e.g., scope_ids for industry). Does not add precise meaning beyond 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?
Description clearly states it counts closed companies by multiple dimensions and distinguishes from sibling search_closed_companies by explicitly saying not to paginate for counting.
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 explicit usage examples and excludes the alternative search_closed_companies. Clearly states when to use: for counting by industry, year, reason, etc.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
count_companiesAInspect按公司关键词、行业、标签、中国/海外地区、成立年份、发展阶段、千里马、独角兽、公司资质等条件统计对外可见公司总数。适合回答多少家公司、总计几家、数量是多少；不要为了计数遍历 search_companies 分页。
| Name | Required | Description | Default |
|---|---|---|---|
| cities | No | ||
| keyword | No | ||
| tag_ids | No | ||
| location | No | ||
| provinces | No | ||
| scope_ids | No | ||
| is_unicorn | No | ||
| born_year_end | No | ||
| is_horse_club | No | ||
| sub_scope_ids | No | ||
| tag_match_mode | No | union | |
| born_year_start | No | ||
| fund_status_ids | No | ||
| qualification_type_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool counts only externally visible companies (对外可见公司总数), which is a behavioral trait. It does not mention rate limits, authentication, or side effects, but for a simple count operation these are less critical. The description is truthful and non-contradictory.
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 description is a single short paragraph with no superfluous content. It front-loads the filter conditions and ends with usage guidance. Every sentence adds value, achieving high information density.
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?
The description provides the overall purpose and usage guidance, but lacks detailed parameter semantics. The output schema presumably returns a count, but the description does not confirm this. For a tool with many optional filters, more explanation of how filters combine and what defaults apply would improve completeness.
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?
There are 14 parameters with 0% schema description coverage. The description lists filter categories (关键词, 行业, 标签, etc.) but does not map them to specific parameter names or explain their valid values. For example, the difference between tag_ids, scope_ids, and sub_scope_ids is unclear. This reliance on implicit understanding reduces usability for an AI agent.
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 clearly states the tool counts externally visible companies by various filters (keyword, industry, tags, location, founding year, etc.). It provides specific use cases ('回答多少家公司、总计几家、数量是多少') and explicitly distinguishes from iterating search_companies, which differentiates it from sibling tools like search_companies.
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 explicitly states when to use this tool (for answering questions about company counts) and provides a clear warning against using search_companies for counting ('不要为了计数遍历 search_companies 分页'). This gives strong guidance on appropriate usage and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_company_funding_eventsAInspect按公司ID分页查询公司融资历史，返回轮次、金额、币种、投资方、FA和估值等信息。
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| fields | No | ||
| page_size | No | ||
| company_id | Yes | ||
| is_underwater | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation returning history but does not disclose pagination mechanics (e.g., cursor-based), rate limits, or authentication requirements. The description is adequate but lacks some behavioral details.
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 description is a single concise sentence that efficiently conveys the purpose and key return information. It is front-loaded but could be restructured to list parameters or usage notes without adding 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?
With an output schema existing and 5 parameters, the description covers the basic purpose and returns but omits details on filtering (is_underwater) and field selection. It is minimally complete for the tool's complexity but leaves room for improvement.
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 0%, so the description must explain parameters. It mentions company_id and pagination (cursor, page_size) but fails to describe 'fields' (selectable fields) or 'is_underwater' (filter). With 5 parameters, only partial coverage is provided, leaving significant gaps.
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 clearly states the tool queries company funding history by company ID with pagination, returning specific details like round, amount, currency, investors, FA, and valuation. It distinguishes itself from sibling tools like search_companies or aggregate_funding_by_tags by focusing on a single company's 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?
The description implies usage for querying a company's funding history with pagination, which is evident from the parameter mention. However, it does not explicitly state when to use this tool over others like search_company_investment_cases or provide exclusions, though the context makes it reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_company_profileAInspect按公司ID查询公司画像，包括公司简称、工商全称 registered_name、行业、标签、地区、简介、最新融资和历史投资方等字段；工商名称、工商注册名称均对应 registered_name。
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | ||
| company_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description indicates the tool is a read-only query by listing returned fields, but does not explicitly state safety, side effects, or authentication needs.
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 with clear purpose and field list, front-loaded with action and resource. No wasted words.
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?
Covers main fields and clarifies registered_name mapping. Output schema exists, so structure details are not needed. Lacks mention of pagination or limits, but acceptable for a simple query.
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 0%, but description adds context for company_id and lists possible response fields; however, it does not explain the 'fields' parameter for selecting subsets.
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?
Description clearly states the tool queries company profile by company ID and lists key fields returned. It distinguishes itself from sibling tools like get_company_funding_events by focusing on the broader profile, but does not explicitly differentiate.
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 usage when a company profile is needed by ID, but provides no guidance on when to use alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_investor_profileBInspect按机构ID查询投资机构画像，包括投资案例数、最近投资时间和活跃行业摘要。
| Name | Required | Description | Default |
|---|---|---|---|
| fields | No | ||
| investor_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return fields but does not explicitly state that the operation is read-only or has no side effects. The name implies a query, so it is partially transparent.
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 description is a single sentence that is concise and front-loaded with the key action. However, it lacks structure (e.g., bullet points or separate lines) that could improve readability for an AI 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?
Given the existence of an output schema, the description does not need to detail return values, but it does mention them. However, it fails to explain the 'fields' parameter or any prerequisites, leaving the tool partially incomplete for an agent.
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 0%. The description adds meaning for the investor_id parameter (by organization ID) but provides no explanation for the 'fields' parameter, which is an array of strings. This leaves a significant gap in parameter understanding.
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?
Description clearly states the tool queries investor profile by organization ID, listing specific fields returned (investment cases count, recent investment time, active industry summary). This is a specific verb+resource, and the tool distinguishes itself from siblings like search_investors or get_company_profile.
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?
No guidance on when to use this tool versus alternatives such as search_investors or get_company_profile. The description only states what it does without specifying context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_lookup_optionsAInspect查询小型字典选项，用于把自然语言条件映射为ID，例如行业、子行业、融资轮次、省份、发展阶段、机构类型、公司资质和死亡原因。不传 lookup_type 时只返回字典类型和数量摘要。标签数量较大，不要用本工具获取标签全集；赛道或标签词映射请调用 search_tags。
| Name | Required | Description | Default |
|---|---|---|---|
| lookup_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that without lookup_type it returns only type and count summary, and warns about not using for large tag lists. Could elaborate on response format or limits, but still informative.
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 purpose, efficient, no wasted words. Every sentence adds necessary context.
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?
Given output schema exists, return explanation not needed. Description covers purpose, parameter semantics, and usage constraints completely for a simple query tool.
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 0%, but description explains the single parameter (lookup_type) well: optional, if absent returns summary. Adds value beyond schema, though could note valid values or types.
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?
Description clearly specifies the tool's purpose: querying small dictionary options to map natural language conditions to IDs. Provides concrete examples (industry, sub-industry, etc.) and distinguishes from sibling tools like search_tags.
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 states when to use (mapping conditions to IDs) and when not to (avoid for large tag sets; use search_tags for tag mapping). Provides clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rank_companies_by_fundingAInspect按公司动态汇总融资事件等值人民币金额并排序，支持公司标签、行业、地区、时间和轮次过滤；适合回答某赛道公司融资总额TOP排名，并可排除IPO上市、IPO上市后等轮次；统计默认包含未披露水下事件。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cities | No | ||
| fields | No | ||
| date_end | No | ||
| location | No | ||
| provinces | No | ||
| scope_ids | No | ||
| date_start | No | ||
| is_underwater | No | ||
| sub_scope_ids | No | ||
| company_tag_ids | No | ||
| exclude_round_ids | No | ||
| include_round_ids | No | ||
| company_tag_match_mode | No | union |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the core aggregation, sorting, and filtering behavior, including that underwater events are included by default and that certain rounds can be excluded. However, it does not mention the limit parameter or pagination behavior, which would be useful for an agent.
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 description is two sentences that front-load the primary action and key filtering capabilities. Every sentence adds value, and there is no redundancy or unnecessary detail.
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?
Given the tool has 14 parameters and no annotations, the description provides a high-level overview but leaves significant gaps. While an output schema exists, the description does not clarify sorting order or required credentials. It is adequate but not fully complete for an agent to use confidently.
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 0%, and the description does not explicitly name any parameter. It only broadly mentions filtering dimensions (tags, industry, region, time, round), leaving the agent to map these to specific properties. Many parameters like limit, is_underwater, scope_ids are not described at all, resulting in poor semantic clarity.
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 clearly states it aggregates and ranks companies by total funding amount in RMB, with support for various filters (company tags, industry, region, time, round). It specifies suitability for answering top rankings in a track, distinguishing it from sibling tools like aggregate_funding_by_tags, which aggregates by tags rather than per-company ranking.
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 indicates appropriate use cases (answering top funding rankings) and mentions that IPO rounds can be excluded. However, it does not explicitly state when not to use this tool or compare it to alternatives, leaving implied but not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_companiesAInspect批量把用户给出的公司简称或工商全称解析为 IT桔子 company_id，返回每个输入名称的候选匹配；工商名称、工商注册名称、工商全称对应字段 registered_name。适合处理用户给定的一批公司名单，例如先解析19家独角兽公司，再调用 get_company_funding_events 查询融资历史。
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | ||
| fields | No | ||
| exact_only | No | ||
| limit_per_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full burden. It states it returns candidate matches per input name and maps registered_name field, but lacks detail on error handling, fuzzy matching, concurrency, or required permissions. It does not contradict anything.
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 description is two sentences long, starting with the core functionality and following with usage guidance and an example. Every sentence adds value; no 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?
The description covers the main use case and usage scenario adequately. However, it lacks details about optional parameters and edge cases. Given the existence of an output schema, the agent can understand return values, but param explanation is incomplete.
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 0%. The description explains that 'names' are company abbreviations or full registered names and mentions the 'registered_name' field, but does not clarify the meaning of 'fields', 'exact_only', or 'limit_per_name'. Partial coverage of parameters.
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 clearly states that the tool resolves company abbreviations or full registered names into IT桔子 company_id, returning candidate matches. It distinguishes itself from sibling tools like search_companies and get_company_profile by specifying it is a batch resolution tool for name-to-ID mapping.
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 explicitly says it is suitable for processing a batch of company names and provides a concrete example: first resolve 19 unicorn companies, then use get_company_funding_events. This tells agents exactly when to use it and suggests a next step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_closed_companiesAInspect分页查询死亡/关闭公司库。按公司关键词、行业、标签、中国/海外地区、成立年份、发展阶段、千里马、独角兽、公司资质、关闭日期、关闭原因或一级关闭原因筛选，返回公司画像、最新融资摘要、关闭日期和死亡原因。适合回答最近倒闭了哪些公司、某赛道死亡公司清单、某关闭原因下有哪些公司。如用户只问总数、多少家、数量，优先使用 count_closed_companies。
| Name | Required | Description | Default |
|---|---|---|---|
| cities | No | ||
| cursor | No | ||
| fields | No | ||
| keyword | No | ||
| tag_ids | No | ||
| location | No | ||
| page_size | No | ||
| provinces | No | ||
| scope_ids | No | ||
| is_unicorn | No | ||
| born_year_end | No | ||
| is_horse_club | No | ||
| sub_scope_ids | No | ||
| close_date_end | No | ||
| tag_match_mode | No | union | |
| born_year_start | No | ||
| fund_status_ids | No | ||
| close_date_start | No | ||
| closure_type_ids | No | ||
| qualification_type_ids | No | ||
| closure_parent_type_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It mentions pagination (分页) and return fields, but lacks details on pagination defaults, rate limits, or side effects. The description is adequate but could be more transparent.
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 description is well-structured: purpose, filters, return fields, examples, sibling guidance. It is slightly long but each sentence adds value. It could be slightly more concise, but overall efficient.
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?
Given the complexity (21 params, output schema exists), the description covers the high-level purpose and return fields but omits details on many parameters (e.g., cursor, page_size, provinces). It is adequate for basic understanding but not fully complete.
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?
With 0% schema description coverage, the description must compensate. It lists filter categories in prose (keyword, industry, etc.) but does not map them to parameter names or provide format details. For 21 parameters, this is insufficient for precise usage.
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 clearly states it searches closed companies with many filters, lists return fields, and gives examples. It distinguishes itself from siblings like search_companies and count_closed_companies by explicitly naming them and providing context.
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 provides explicit guidance: 'if user only asks for total count, use count_closed_companies' and lists typical use cases (recent closures, sector list, by cause). It effectively tells when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_companiesAInspect按公司关键词、行业、标签、中国/海外地区、成立年份、发展阶段、千里马、独角兽、公司资质等条件分页查询对外可见公司，适合回答有哪些公司、按名称找公司和补充项目背景；工商名称、工商注册名称、工商全称对应字段 registered_name。如用户只问总数、多少家、数量，优先使用 count_companies。
| Name | Required | Description | Default |
|---|---|---|---|
| cities | No | ||
| cursor | No | ||
| fields | No | ||
| keyword | No | ||
| tag_ids | No | ||
| location | No | ||
| page_size | No | ||
| provinces | No | ||
| scope_ids | No | ||
| is_unicorn | No | ||
| born_year_end | No | ||
| is_horse_club | No | ||
| sub_scope_ids | No | ||
| tag_match_mode | No | union | |
| born_year_start | No | ||
| fund_status_ids | No | ||
| qualification_type_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention side effects, authentication needs, rate limits, or whether the tool is read-only. It only implies a paginated query but lacks explicit behavioral warnings.
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 description is a single block but effectively front-loads the key conditions and purpose. It is concise with no wasted words, though structured formatting could improve readability.
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 tool with 17 parameters and no annotations, the description covers the main purpose and some filter hints. However, it lacks details on pagination, field selection, and tag match mode. The presence of an output schema reduces the need to explain return values.
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 0%. The description explains some parameters (keyword, tag, location, born year, etc.) but many are left unexplained (cities, provinces, cursor, page_size, tag_match_mode, etc.). It adds value for a subset but insufficiently for 17 parameters.
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 specifies a clear verb ('search') and resource ('companies') with multiple filter criteria. It distinguishes from sibling 'count_companies' by explicitly stating to use that tool when only a count is needed.
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 states when to use this tool ('回答有哪些公司、按名称找公司和补充项目背景') and when not to use it ('如用户只问总数、多少家、数量，优先使用 count_companies'). This provides explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_company_investment_casesAInspect查询企业对外投资案例，按组织关系归并公司和机构投资主体；适合回答某赛道企业做过哪些对外投资，例如具身智能企业投了哪些公司；高权限套餐可查看未披露水下事件标识。
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| fields | No | ||
| date_end | No | ||
| page_size | No | ||
| round_ids | No | ||
| date_start | No | ||
| is_underwater | No | ||
| investor_tag_ids | No | ||
| target_scope_ids | No | ||
| investor_scope_ids | No | ||
| investor_company_ids | No | ||
| target_sub_scope_ids | No | ||
| investor_sub_scope_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Mentions that high-permission packages can see undisclosed underwater event markers, which is a useful behavioral note. However, does not disclose other behaviors like rate limits, pagination, or destructive actions (likely read-only). Adds some context but not comprehensive.
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 concise sentences covering function, merging behavior, use case, and permission nuance. No fluff, front-loaded with core purpose.
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?
Tool has 13 parameters, no annotations, no parameter descriptions. Description is too brief to guide usage of these parameters. Output schema exists but does not help with input. Leaves significant gaps for an agent to correctly invoke the tool.
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 has 13 parameters with 0% description coverage. Description does not explain any parameter individually; only hints at 'underwater' via permissions. Does not compensate for lack of schema descriptions, making it hard for agents to know how to use parameters like round_ids, investor_company_ids, etc.
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?
Description clearly states it queries company outward investment cases, merges by organizational relations, and gives a concrete use case. Verb '查询' + resource '企业对外投资案例' is specific. Distinguishes from sibling tools like search_companies or get_company_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 says suitable for answering what outward investments a company in a certain track has done, with an example. Does not explicitly state when not to use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_eventsCInspect按时间、行业、标签、轮次等条件分页查询事件。event_type 表示物理来源：invse 融资/轮次事件、merger 并购事件；event_category 表示业务分类：investment 投资轮次、listing 上市相关、merger 并购；is_underwater 可筛选未披露水下事件，尝鲜版和标准版不可查看水下事件明细。
| Name | Required | Description | Default |
|---|---|---|---|
| cities | No | ||
| cursor | No | ||
| fields | No | ||
| tag_ids | No | ||
| date_end | No | ||
| location | No | ||
| page_size | No | ||
| provinces | No | ||
| round_ids | No | ||
| scope_ids | No | ||
| date_start | No | ||
| event_type | No | ||
| is_underwater | No | ||
| sub_scope_ids | No | ||
| event_category | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only discloses meaning of three parameters (event_type, event_category, is_underwater) and the pagination behavior is implicit. It does not mention read-only status, side effects, rate limits, or other important behaviors for a complex search 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?
The description is concise at three sentences, front-loading the purpose. However, it combines parameter explanations inline, which could be structured more clearly (e.g., bullet points or separate explanation section).
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?
Given the tool's complexity (15 parameters) and lack of annotations, the description is incomplete. It only covers a few parameters and gives high-level purpose; missing parameter details, behavioral notes, and output format context. The output schema exists but the description does not leverage it for completeness.
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 0%, so the description must explain all parameters. It only explains 3 out of 15 parameters (event_type, event_category, is_underwater) and vaguely mentions filters like 'by time, industry, tag, round' without linking to specific parameter names. The remaining 12 parameters are entirely undocumented.
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 clearly states this tool searches/querys events with pagination by various criteria (time, industry, tag, round). It differentiates event_type and event_category, providing a clear purpose distinct from sibling tools like search_companies.
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?
No explicit guidance on when to use this tool versus alternatives like get_company_funding_events or aggregate_funding_by_tags. The only usage hint is the restriction on underwater events for trial/standard versions, but overall lacks clear when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_fa_casesBInspect查询结构化FA服务案例，返回FA机构、被服务公司、融资轮次、金额、时间和行业等信息；高权限套餐可查看未披露水下事件标识。
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| fa_ids | No | ||
| fields | No | ||
| date_end | No | ||
| page_size | No | ||
| round_ids | No | ||
| scope_ids | No | ||
| date_start | No | ||
| company_ids | No | ||
| is_underwater | No | ||
| sub_scope_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals one behavioral aspect: high-authority packages can view underwater events. However, without annotations, it does not explain pagination (cursor, page_size), read-only nature, or other constraints, leaving gaps in transparency.
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 description is concise with two sentences, no fluff. It front-loads the main purpose. However, it could be better structured by separating the core function from the access control note.
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 11 parameters and no schema descriptions, the description fails to explain parameter usage or filter mechanics. It covers only a high-level list of returned fields and one feature. The output schema may help, but the description is insufficient for complete understanding.
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 0%, so the description must explain parameters. It only hints at 'is_underwater' via the underwater events mention. Most parameters (cursor, fa_ids, dates, etc.) are undefined, forcing the agent to infer or guess.
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 clearly states the tool queries structured FA service cases and returns specified fields (FA institution, serviced company, financing round, etc.). It differentiates from sibling tools which focus on companies or 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 description implies usage for FA case searches but provides no explicit guidance on when to use this tool versus siblings like search_company_investment_cases or search_investor_cases. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_investor_casesAInspect按机构ID分页查询机构投资案例，可按被投公司标签、行业和轮次筛选，适合回答某机构投过哪些具身智能、机器人、AI等标签公司；高权限套餐可查看未披露水下事件标识。
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| fields | No | ||
| page_size | No | ||
| round_ids | No | ||
| scope_ids | No | ||
| investor_id | Yes | ||
| is_underwater | No | ||
| sub_scope_ids | No | ||
| company_tag_ids | No | ||
| company_tag_match_mode | No | union |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses pagination, filtering behaviors, and a permission-based behavior (undisclosed events). It does not mention idempotency, rate limits, or side effects, but adequately conveys it is a read operation.
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?
Description is concise, two sentences front-loading the main purpose and filters. Every word adds value, with no unnecessary repetition.
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?
Given the tool has 10 parameters and no annotations, the description covers the core functionality well and mentions the output schema existence (implied by context). However, it could elaborate on parameters like cursor and fields to be fully complete.
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 0%, so description must compensate. It explains filters for tags, industry, and round, which map to several parameters (company_tag_ids, scope_ids, round_ids, is_underwater). However, it does not explain parameters like cursor, fields, or company_tag_match_mode, leaving gaps.
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?
Description clearly states the verb (paginated query), resource (investment cases by institution ID), and available filters (tags, industry, round). It distinguishes from sibling tools like search_company_investment_cases by focusing on investor-specific cases.
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?
Description provides clear context on when to use (answering which companies an institution invested in) and mentions a permission-based limitation (high-permission packages can view undisclosed underwater events). However, it does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_investorsCInspect按机构名称关键词搜索投资机构，返回机构ID、案例数、最近投资时间和活跃行业。
| Name | Required | Description | Default |
|---|---|---|---|
| is_fa | No | ||
| cursor | No | ||
| fields | No | ||
| keyword | No | ||
| prop_ids | No | ||
| page_size | No | ||
| is_state_owned | No | ||
| is_government_guidance_fund | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like pagination, rate limits, or side effects. It only mentions return fields, which adds minimal transparency.
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 description is a single concise sentence, but it could include more details without being verbose.
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 tool with 8 parameters and no schema descriptions, the description is incomplete. It does not explain the usage of most parameters.
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 schema has 8 parameters with 0% description coverage. The description only mentions the keyword parameter implicitly, ignoring other parameters like cursor, page_size, and 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 clearly states the action (search by keyword) and resource (investment institutions), and lists returned fields. However, it does not differentiate from sibling tools like search_companies or search_investor_cases.
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 provides no guidance on when to use this tool versus alternatives, such as other search tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_person_investment_casesAInspect按人物ID或人物姓名分页查询人物投资案例，可按被投公司标签、行业和轮次筛选，适合回答某位投资人个人参与投资过哪些公司；高权限套餐可查看未披露水下事件标识。
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| fields | No | ||
| page_size | No | ||
| person_id | No | ||
| round_ids | No | ||
| scope_ids | No | ||
| is_underwater | No | ||
| sub_scope_ids | No | ||
| person_keyword | No | ||
| company_tag_ids | No | ||
| company_tag_match_mode | No | union |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses pagination, filter dimensions, and a non-obvious permission-dependent behavior: '高权限套餐可查看未披露水下事件标识'. It does not explicitly state read-only, but the 'search' prefix and '查询' imply it. This is good but not exhaustive.
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 description is a single, compact sentence that front-loads the action and resource, then adds filter dimensions, a use case, and a permission nuance without redundancy. Every clause earns 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?
For an 11-parameter tool with zero parameter descriptions, the description covers the primary search dimensions and a key permission trait, but falls short of fully explaining several parameters (e.g., fields, company_tag_match_mode). An output schema exists, so return values don't need detailing, but the parameter gap keeps completeness at a moderate level.
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 0%, so the description must compensate. It maps several key parameters: '人物ID或人物姓名' to person_id/person_keyword, '被投公司标签' to company_tag_ids, '行业' to scope-related params, '轮次' to round_ids, '分页' to cursor/page_size, and '水下事件' to is_underwater. However, fields, company_tag_match_mode, and sub_scope_ids are left unexplained, leaving gaps.
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 opens with '按人物ID或人物姓名分页查询人物投资案例', clearly naming the resource (人物投资案例) and the action (分页查询). It further distinguishes from sibling tools by specifying the use case of '某位投资人个人参与投资过哪些公司', differentiating it from company-level or general investor case searches.
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 phrase '适合回答某位投资人个人参与投资过哪些公司' provides a concrete, actionable use case. It gives clear context for when to use this tool, though it does not explicitly mention alternatives or when not to use it, making it a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_tagsAInspect按关键词搜索标签，适合把用户输入的赛道词如人工智能、机器人、低空经济映射为 tag_id。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| keyword | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool searches tags by keyword, but does not mention whether the operation is read-only, any permissions required, or details about the output (e.g., what fields are returned). The presence of an output schema partially compensates, but the description itself is minimal.
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 description is a single sentence that conveys the main purpose efficiently. It is front-loaded with the action and resource. However, it omits details about parameters, which slightly reduces clarity.
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?
Given the tool has an output schema and only two optional parameters, the description is moderately complete. It covers the primary use case but lacks parameter details and specifics about the output format, which are important for an agent to use 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 description coverage is 0%, meaning the input schema has no descriptions for 'keyword' and 'limit'. The description only implies 'keyword' is the search term but does not explain the 'limit' parameter. This is insufficient; the description should clarify both parameters.
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 clearly states the tool searches tags by keyword and specifies a concrete use case: mapping user-input track words (e.g., AI, robotics) to tag_id. This distinguishes it from sibling tools which focus on companies, investors, and funding.
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 provides a specific context for use ('suitable for mapping user-input track words to tag_id'), but does not explicitly state when not to use or mention alternatives. Since it is the only tag-related tool, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.