Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@trade-agent-mcp Find German buyers for eco-friendly water bottles and check their credit standing."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Foreign Trade Business Producer — 把外贸销售岗的全套方法论， 封装成 10 个可被任何 MCP 客户端直接调用的确定性工具。
Related MCP server: silicon-army-mcp
外贸业务员的日常，本质上是一条重复率极高的信息流水线：
收到询盘 → 这公司是真的吗 → 这市场能做吗 → 推什么品 → 写给谁 → 报多少钱每一步都在做同一件事：拿信息、套方法、出结构化结论。但大模型直接干这事有三个硬伤：
硬伤 | 后果 | 这里的做法 |
算不准 | 报价、汇率、到岸成本，口算即错 |
|
会编造 | 查不到就"合理补全"一个注册号 |
|
不可复现 | 同样的问题每次答案不一样 | 工具是规则/模板实现，同输入必同输出 |
所以这个项目不是"又一个会聊天的外贸助手"，而是一套方法论的固化：把资深业务员的判断逻辑拆成可调用、可审计、可自动评测的工具，Agent 只负责调度和表达。
一句话：你策展能力，Agent 只是入口。
* 为必填参数。完整 JSON Schema 见 tools.json。
git clone https://github.com/hanjiajiade/trade-agent-mcp.git
cd trade-agent-mcp
pip install -r requirements.txt # 或 pip install .
python mcp_server.py # 默认 streamable-http @ 0.0.0.0:8080自检（HTTP 模式）：
python -c "import urllib.request,json; req=urllib.request.Request('http://127.0.0.1:8080/mcp', data=json.dumps({'jsonrpc':'2.0','id':1,'method':'initialize','params':{'protocolVersion':'2025-03-26','capabilities':{},'clientInfo':{'name':'probe','version':'0'}}}).encode(), headers={'Content-Type':'application/json','Accept':'application/json, text/event-stream'}); print(urllib.request.urlopen(req, timeout=10).status)"预期输出 200。
{
"mcpServers": {
"trade-agent-mcp": {
"command": "python",
"args": ["mcp_server.py"],
"env": { "MCP_TRANSPORT": "stdio" }
}
}
}安装后也可直接用入口命令：
{
"mcpServers": {
"trade-agent-mcp": {
"command": "trade-agent-mcp",
"env": { "MCP_TRANSPORT": "stdio" }
}
}
}{
"mcpServers": {
"trade-agent-mcp": {
"url": "https://your.domain/mcp"
}
}
}解析顺序：显式环境变量 → 自动探测 → 默认
设了 MCP_TRANSPORT 就以它为准；
没设，但检测到 stdin 不是终端（说明是被 MCP 客户端当子进程拉起的）→ 走 stdio；
都不满足 → 走 streamable-http。
容器里
stdin同样不是终端，会被第 2 条误判。因此Dockerfile内已显式写死ENV MCP_TRANSPORT=streamable-http，服务器部署无需担心。
calc_quotation — 报价核算成本 → 各贸易术语 → 到岸成本 → 建议售价 → 实际毛利率，一次性算穿。
{
"incoterm": "CIF",
"cost_currency": "CNY",
"quote_currency": "USD",
"moq": 500,
"unit_landed_cost": 859.1,
"suggested_unit_price": 1073.88,
"unit_profit": 214.77,
"actual_margin": 0.2,
"breakdown": {
"exw_出厂成本": 100,
"freight_to_port_本地费用": 0.0,
"fob_离岸价": 100.0,
"international_freight_国际运费": 15,
"cfr_成本加运费": 115.0,
"insurance_保险费": 6,
"cif_到岸价": 121.0,
"duty_关税": 0.0,
"other_landed_cost_其他到岸成本": 0.0,
"landed_cost_总到岸成本": 121.0,
"suggested_price_建议售价": 1073.88,
"profit_单件利润": 214.77,
"actual_margin_实际毛利率": 0.2
},
"notes": ["报价币种 USD 按汇率 7.1 换算（成本币种 CNY）"],
"_discipline": "报价为测算值，关税/运费/汇率以实际成交与目的国海关口径为准，需专业确认。"
}check_redflags — 红旗规则引擎命中即升级，输出 clear / review / block 三档裁定。
{
"verdict": "block",
"hits": [
"免费邮箱域名冒充公司（如 @gmail/@163 自述为采购方）",
"以关税/保证金/运费等名目要求预付或代付"
],
"hit_count": 2,
"note": "裁定为规则模式识别，非法律/信用结论；命中 block 须人工复核并索取证照材料。"
}classify_claim — 结论三分类任何一条结论，强制归入 已验证事实 / 合理推断 / 待核实。 带来源不一定就是事实，不带来源一律不得升格——这是整套纪律的地基。
plan_pipeline — 总控编排判断信息充分度与调查深度（quick / standard / deep），派发应调用的工具，
并显式列出缺什么信息。它不替你做决定，它告诉你还差什么。
工具是骨架，纪律是外壳。SYSTEM_PROMPT.md 是本服务的系统提示词层，把它设为 Agent 的 system prompt，工具输出就会自动带上可信分析的外壳。
核心三条：
原则 | 含义 |
三分类 | 每个结论必须标明是事实、推断还是待核实，不许含糊带过 |
来源可追溯 | 机构名 + URL + 日期，缺一不可；没有来源就老实标「待核实」 |
不编造 | 检索不到时返回结构化的检索计划（查什么、去哪查），而不是编一个答案 |
方法论来源：Perplexity「客户背调」合集 + D&B 风控结构（实体锚定、登记处核验、七轴证据、三档置信度 Confirmed / Reported / Alleged）。
web_search 与 research_company 在未配置 API key 时，返回的是检索计划——
包含该查哪些查询、去哪些权威来源查。这不是降级，而是设计：
保证服务永远有输出，可离线运行、可被自动评测；
把"不知道"显式暴露出来，而不是让模型悄悄补全。
配上 TAVILY_API_KEY 或 SERPER_API_KEY 后，自动切换为真实检索结果。
以真实案例 Chile Brasil Projetos Ambientais（巴西净水设备采购方）为例：
步骤 | 调用 | 结果 |
1. 判断该查多深 |
| 信息不足 → 判定 |
2. 实体核验 |
| 6 组查询变体均无法在公开源定位该实体 |
3. 结论定性 |
| 「待核实」——没有为了给结论而降格 |
4. 最终裁定 |
| REVIEW，建议索取证照与注册号后再推进 |
这个案例的价值恰恰在于它的结论是"查不到"。一个会编造的助手会给你一份漂亮的巴西市场报告； 这套工具给你的是一次诚实的失败，以及下一步该去哪里查。
cp .env.example .env # 按需填入变量
docker compose up -d --build监听 0.0.0.0:$PORT，路由 /mcp。用 Nginx 反代 + Let's Encrypt 即可对外提供
https://your.domain/mcp。
生产环境请务必显式设置
MCP_TRANSPORT=streamable-http，不要依赖自动探测。
MCP initialize 成功
tools/list 在 15 秒内返回至少 1 个工具
每个工具的入参是合法 JSON Schema（python scripts/export_tools.py 可重新导出核对）
至少调用一次核心工具并得到非错误响应
从外部网络（非开发机）访问仍可用
上架后不再更改工具名或输入 Schema
变量 | 必填 | 说明 |
| 否 |
|
| 否 | 默认 |
| 否 | 默认 |
| 否 | 启用 |
| 否 | 同上，走 Serper Google 检索 |
密钥只走环境变量，不写进源码；.env 已被 .gitignore 排除。
trade-agent-mcp/
├── mcp_server.py # FastMCP 服务入口，10 个工具
├── SYSTEM_PROMPT.md # 方法论层（Agent 系统提示词）
├── tools.json # 工具定义（由 scripts/export_tools.py 生成）
├── pyproject.toml # 打包配置（pip install . / 命令入口）
├── requirements.txt # mcp[cli] / requests
├── scripts/
│ └── export_tools.py # 导出 tools.json
├── Dockerfile # 已写死 streamable-http
├── docker-compose.yml
├── .env.example
├── icon.png
└── README.md10 个工具 + 总控编排
stdio / Streamable HTTP 双传输
真实握手验证（10 工具、protocolVersion 2025-03-26）
多语种开发信（西语 / 葡语 / 阿语）
汇率与关税实时接口
判例库：积累真实询盘的红旗样本
发布到 MCP 服务市场
工具为确定性 / 结构化实现，可独立运行与被自动评测；分析性表达由接入方 Agent 叠加 SYSTEM_PROMPT.md 完成。
报价、市场规模、合规判断均为测算与参考值，以实际成交与目的国监管口径为准，需专业确认。
不提供规避制裁、出口管制、海关申报、付款风控方面的建议。
红旗裁定属规则模式识别，不是法律或信用结论；命中 block 须人工复核。
MIT © 2026 hanjiajiade
外贸报价/利润核算。给定成本与贸易术语，算出 FOB/CIF/CFR、到岸成本、建议售价与利润。
Args: product_cost: 工厂成本/采购成本（EXW 或出厂价），成本币种。 currency: 成本币种（CNY/USD/EUR）。 moq: 最小起订量（用于单价展示）。 incoterm: 贸易术语 EXW/FOB/CIF/CFR/DDP。 freight_to_port: 出厂到起运港本地费用（EXW 时填入）。 international_freight: 国际运费（到目的港）。 insurance: 保险费。 duty_rate: 目的国关税税率（0-1，如 0.1 表示 10%）。 other_landed_cost: 其他到岸成本（清关/仓储/内陆派送等）。 target_margin: 目标毛利率（0-1）。 exchange_rate: 成本币种 -> 报价币种 汇率（同币=1）。 quote_currency: 报价币种（留空=与成本币种相同）。
| Name | Required | Description | Default |
|---|---|---|---|
| moq | No | ||
| currency | No | CNY | |
| incoterm | No | FOB | |
| duty_rate | No | ||
| insurance | No | ||
| product_cost | Yes | ||
| exchange_rate | No | ||
| target_margin | No | ||
| quote_currency | No | ||
| freight_to_port | No | ||
| other_landed_cost | No | ||
| international_freight | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does disclose that the tool computes multiple quotation and profit outputs from cost and incoterm inputs. However, it does not explain exact formula behavior, how incoterms alter the calculation, or how zero/default fields are treated, leaving some behavioral uncertainty.
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 opens with a concise Chinese summary and then presents a scannable parameter list. The length is justified by the 12 parameters, and there is no unnecessary prose.
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 complex 12-parameter calculator with no output schema and no annotations, the description covers input semantics thoroughly and states the output categories. It does not define the exact output structure or detailed per-incoterm formulas, but an agent has enough context to invoke the tool 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?
The schema has no property descriptions, but the description's Args section defines all 12 parameters with meaningful details: duty_rate is a 0-1 range, exchange_rate direction is specified, and quote_currency defaults to the cost currency when empty. This fully compensates for the missing schema-level documentation.
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 uses a specific verb ('算出') and resource ('外贸报价/利润核算'), and explicitly names the outputs: FOB/CIF/CFR, landed cost, suggested price, and profit. This makes the tool clearly distinguishable from the unrelated sibling research and outreach tools.
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 summary clearly states the tool is for foreign-trade quotation and profit calculation, giving a clear usage context. It does not explicitly name alternatives or when-not-to-use, but no sibling tool performs pricing calculations, so the ambiguity is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
统一红旗规则引擎：根据客户/供应商画像命中红旗，给出 clear/review/block 裁定。
红旗命中即升级，不等同最终定性；本工具只做模式识别。
| Name | Required | Description | Default |
|---|---|---|---|
| refuses_video | No | ||
| refuses_sample | No | ||
| domain_age_days | No | ||
| rushes_contract | No | ||
| asks_fee_upfront | No | ||
| company_age_years | No | ||
| email_free_domain | No | ||
| claims_big_company | No | ||
| claims_large_order | No | ||
| price_quantity_absurd | No | ||
| has_independent_website | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses that it is only pattern recognition and that a hit is an escalation signal, not a final verdict – useful context. However, it omits any mention of side effects, determinism, or whether it is read-only, leaving gaps 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?
Two sentences with no filler. The first sentence front-loads the core purpose and output, and the second adds a critical caveat. Extremely 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?
Despite having 11 parameters and no output schema, the description does not explain how inputs map to the verdict, what the verdict values mean, or any edge cases. It gives the output categories but not the logic or input semantics. The tool is simple in concept but the description is insufficient for reliable invocation.
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 provides no explanation of any of the 11 parameters (e.g., refuses_video, domain_age_days). It only vaguely references 'customer/supplier profile' without connecting it to the actual inputs. The description completely fails to compensate for the undocumented 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?
The description states a clear purpose: a unified red flag rule engine that evaluates customer/supplier profiles and produces clear/review/block verdicts. It explicitly says it only does pattern recognition, distinguishing it from final judgment tools. This is a specific verb (check) plus resource (red flags) and clearly separates from research or search siblings.
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 customer/supplier profile is available and you want to detect red flags, but it does not explicitly compare to alternative tools or state when not to use it. It does clarify that hits mean escalation, not final determination, which helps interpretation but not selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
把一条结论归类为「已验证事实 / 合理推断 / 待核实」，并给出信号依据。
Args: text: 待分类的结论文本。 has_source: 是否附带来源（机构名+URL+日期）。
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| has_source | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the classification task and that signal basis is produced. It omits whether the tool performs any independent verification, how has_source impacts the classification, and whether there are side effects, limitations, or external dependencies.
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 front-loaded sentence immediately followed by compact argument explanations. There is no filler, redundant text, or restatement of the tool name, making it efficient for an agent 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?
The description covers the core task and parameter meanings, but with no output schema and no annotations, it leaves gaps: it does not specify the exact output format, how the classification result and signal basis are presented, or how has_source influences the categorization. These details are relevant for an agent deciding how to invoke the tool and interpret its response.
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 Args section is critical and it delivers: text is defined as the conclusion text to classify, and has_source is described as indicating whether a source with institution, URL, and date is attached. This provides real semantic meaning beyond the bare schema types and defaults.
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 uses a specific verb, '归类' (classify), with a clear resource, '一条结论' (a claim/conclusion), and enumerates the three output categories: verified fact, reasonable inference, and to-be-verified. This makes the tool's function easy to distinguish from the sibling tools, which all concern different activities like researching companies or drafting outreach, though it does not explicitly name a sibling.
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. It only states the operation and arguments, leaving the agent to infer its place in the workflow. No context, exclusions, or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成开发信首封（100-150 词量级）+ 主题 A/B + 3 封递进跟进。模板化、确定性、可运行。
Args: target_company: 目标公司名。 country: 目标国别。 product: 产品/品类。 persona: 客户画像要点（决策人关注点）。 certs: 相关认证（如 CE/ANVISA/INMETRO）。 contact: 称呼。 me: 发件人署名。 language: en / zh（其他语言回退 en）。 tone: professional / casual。
| Name | Required | Description | Default |
|---|---|---|---|
| me | No | （您的署名） | |
| tone | No | professional | |
| certs | No | （待补） | |
| contact | No | Procurement Team | |
| country | Yes | ||
| persona | No | ||
| product | Yes | ||
| language | No | en | |
| target_company | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有提供注释，因此描述承担了行为披露的责任。描述提到'模板化、确定性、可运行'，表明输出是可预测且稳定的，这提供了有用的行为线索。但未说明是否会产生外部副作用（如发送邮件）、是否需要权限或返回格式。对于生成草稿的工具，这些信息虽非关键，但仍有缺失。
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?
描述结构清晰，开头一句概括主要功能，随后以Args列表形式逐条说明参数，没有冗余内容。虽然列表较长，但每个参数都有必要，信息密度高，整体效率良好。
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?
对于9个参数的复杂工具，描述提供了所有参数的解释，并明确了输出内容（首封、主题、跟进）。虽然没有输出schema，但描述已足够让调用者理解返回结构。缺少的是返回值格式和可能的错误处理，但不算严重缺陷。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
尽管schema描述覆盖率为0%，但描述文本中为每个参数提供了清晰的一行解释（如'目标公司名'、'目标国别'等），涵盖了全部9个参数。这充分补偿了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?
描述明确说明了工具的具体功能：生成开发信首封（指定字数）、主题A/B以及3封跟进邮件。动词'生成'和资源'开发信'非常具体，且与兄弟姐妹工具（如research_company、scan_market）有明显区别，因为那些工具聚焦于研究或市场分析，而非内容生成。
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?
描述没有明确说明何时使用此工具或何时不使用，也没有提及替代工具。但描述本身表明它用于生成外联邮件草稿，这隐含了使用场景。由于兄弟姐妹中没有直接类似工具（如generate_persona可能有部分重叠），缺少排除条件不算严重，但未明确给出条件仍是不足。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据已知信息生成一页纸客户/账户画像（决策人、痛点、切入点、异议）。缺信息显式标注待核实。
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | ||
| country | Yes | ||
| industry | No | ||
| products | No | ||
| known_facts | No | ||
| decision_maker_role | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral aspects. It mentions that missing information will be explicitly marked as 'to be verified', which is a useful behavioral trait. However, it does not disclose other critical aspects such as data sources, whether it performs web searches, or any dependencies on existing data. For a generation tool, the lack of clarity on data sourcing is a notable 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?
The description is concise, consisting of two sentences. It effectively front-loads the core purpose and includes a key behavioral note about marking missing info. The language is clear and to the point, with no unnecessary fluff. It could be slightly more structured but is appropriately brief.
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 fully explain what the tool returns. It describes the content of the persona page (decision maker, pain points, etc.), which is helpful, but it lacks details on formatting, length, or how the output is delivered (e.g., as a text block). With 6 parameters and no annotations, the description leaves gaps that an agent might need to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning the description must add meaning to the parameters. The description clarifies that the output is a 'one-page persona' and specifies the content areas (decision maker, pain points, etc.), which gives context to what parameters like known_facts and decision_maker_role contribute. However, it does not detail each parameter's specific usage, but the overall purpose helps infer their roles.
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 explicitly states the tool's purpose: to generate a one-page client/account persona including decision maker, pain points, entry points, and objections. It clearly identifies the resource (a persona document) and the action (generate). While it doesn't explicitly distinguish from siblings, the specific output format and content make it unique enough among the listed tools.
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 like research_company, web_search, or draft_outreach. It does not state prerequisites (e.g., need initial research) or indicate that this is for client-facing documents. Users are left to infer that it might be used after research, but no explicit direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
总控编排：判断信息充分度与调查深度，派发 skill，列出缺信息与研究问题。
Args: client_name: 客户/公司名。 website: 官网。 country: 国别。 inquiry_text: 询盘/邮件正文。 has_cnpj: 是否已提供注册号。 has_bank_info: 是否已提供银行信息。 report_depth: auto/quick/standard/deep。
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ||
| website | No | ||
| has_cnpj | No | ||
| client_name | No | ||
| inquiry_text | No | ||
| report_depth | No | auto | |
| has_bank_info | No |
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 judges sufficiency/depth, dispatches skills, and outputs missing info and research questions. However, it does not explain side effects, whether it actually invokes other tools, how depth selection works, or what the returned data structure is. Moderate 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 compact and front-loaded with the tool's purpose, followed by a structured Args block. There is no redundant fluff, and the parameter list is neatly organized. Slight room for improvement in making the prose more formal, but it remains 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?
For a 7-parameter orchestrator with no annotations, no required fields, and no output schema, the description provides basic context — it lists missing info and research questions — but does not explain how parameters combine, what the default 'auto' report_depth implies, or what the agent should do with the results. Adequate but 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%, so the description must compensate. It lists all 7 parameters in Chinese with human-readable explanations (e.g., has_cnpj as '是否已提供注册号') and enumerates report_depth values (auto/quick/standard/deep). This adds meaning beyond the bare schema titles, though some glosses are terse.
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's role as master orchestration: it judges information sufficiency, determines investigation depth, dispatches skills, and lists missing information and research questions. This distinguishes it from sibling tools like research_company or web_search, which are specific execution steps rather than the central planner.
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 explicit guidance on when to use this tool versus alternatives. The '总控编排' (master orchestration) role implies it should be invoked early, but the description does not specify conditions, prerequisites, or exceptions. An agent is left to infer usage from the tool's name and role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
资信背调计划：实体锚定清单、登记处、研究问题、红旗监视、缺信息。可选启用真实检索。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| extra | No | ||
| country | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden and it does disclose a key behavior: real retrieval is optional (可选启用真实检索), implying the default is a plan without live search. It also implies the output includes red-flag monitoring and missing-information reporting, but it does not describe side effects, whether it mutates anything, or what happens when real retrieval is enabled.
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 short and front-loads the plan category, but it compresses six concepts (entity anchors, registries, research questions, red flags, missing info, optional retrieval) into a dense, jargon-heavy phrase. It earns its place partly because of the optional-retrieval detail, yet readability suffers.
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 no annotations, no output schema, and 0% parameter coverage, the description should explain inputs, output format, and mode behavior. It provides a component list and mentions optional real retrieval, but omits parameter semantics, when to enable retrieval, and what a returned plan looks like, leaving an agent to select and invoke it with significant uncertainty.
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 explain any of the three parameters: name, extra, or country. An agent gets no guidance on what extra should contain, what country format is expected, or how these map to the entity-anchoring/registry/research-question components. The required name is self-evident but the other fields are opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the output is a 'credit investigation plan' (资信背调计划) for a company and lists its components, so an agent can infer it produces a structured research/planning artifact rather than directly researching. However, it never states an explicit verb/action ('generates', 'returns', 'searches'), and the plan's relationship to siblings such as check_redflags or web_search is not clarified.
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 when-to-use guidance or exclusions against sibling tools. The phrase 'optionally enable real retrieval' hints that this tool can be a planning-only mode, but the description does not say when to prefer it over web_search or check_redflags, nor when real retrieval should be toggled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
市场扫描：有数据则按模板结构化输出；无数据返回检索计划（权威来源 + 查询）。
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | ||
| category | Yes | ||
| provided_data | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavior. It usefully discloses the conditional output and the no-data fallback plan. However, it doesn't explain where the data comes from, what 'has data' means, or what the template/authoritative sources look like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with two clear branches and no filler; the core behavior is front-loaded. It earns its length even though more detail would be welcome.
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 without annotations or an output schema, this is incomplete: it omits the template format, the nature of the retrieval plan, how region and category shape the scan, and what counts as 'data.' An agent would need additional inference to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description doesn't define region or category. It only hints that the presence of input data governs the output via '有数据则...无数据...', which likely maps to provided_data but never explicitly names it.
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 identifies a market-scan operation and states the two possible outcomes: structured template output when data exists, or a retrieval plan with authoritative sources and queries when it does not. This is specific about behavior, though it doesn't explicitly contrast with siblings like web_search or research_company.
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 guidance about when to prefer scan_market over web_search, research_company, or other sibling tools. The data-dependent branch describes internal behavior, not the circumstances that should lead an agent to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
对多个候选产品按多指标加权评分与排序，辅助选品决策。
Args: products: 每项形如 {"name":..., "market_demand":0-100, "competition":0-100(越低越好填高分), "margin":0-100, "compliance_risk":0-100(越低越好填高分), "fit":0-100}。 weights: 各指标权重（默认 market_demand .3 / competition .2 / margin .25 / compliance .15 / fit .1）。
| Name | Required | Description | Default |
|---|---|---|---|
| weights | No | ||
| products | 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 the scoring model, default weights, and the special handling for competition and compliance_risk (lower is better, encoded as high scores). However, it does not describe the output format, sorting direction, or behavior with missing/invalid fields.
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 compact and front-loaded: the main purpose appears in the first sentence, followed by a tight parameter breakdown. Every sentence contributes meaningful information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple scoring/ranking tool and gives enough input detail to invoke it. However, with no output schema and no annotations, the absence of return-format information and edge-case behavior leaves a moderate gap in 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 coverage is 0%, so the description compensates by documenting each product field with explicit 0-100 ranges and clarifying scoring direction for competition and compliance_risk. It also lists default weights for the optional weights parameter, though it does not specify whether weights must sum to 1 or how custom weights behave.
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 scores and ranks multiple candidate products using weighted multi-criteria, with the specific purpose of aiding product selection. It names the resource ('products') and the operation ('score and rank'), though it does not explicitly differentiate from siblings like scan_market or calc_quotation.
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 '辅助选品决策' implies use during product selection when comparing candidates, but there is no explicit when-to-use guidance, exclusions, or mention of alternative tools. Usage context is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
联网检索。设置 TAVILY_API_KEY 或 SERPER_API_KEY 后返回真实结果；否则返回检索计划。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It transparently discloses that real results are returned only when TAVILY_API_KEY or SERPER_API_KEY is set, otherwise a search plan is returned. However, it omits other behavioral details such as output format or error conditions.
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 short sentences with the purpose front-loaded and the key conditional behavior stated efficiently. No filler or redundant content.
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 two-parameter tool with no output schema and no annotations, the description covers the most critical non-obvious behavior but leaves out parameter details and usage context relative to sibling tools. It is serviceable but 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%, and the description does not explain the query or top_k parameters. While 'query' may be inferred from the tool's name, top_k's meaning and behavior are left 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 states the verb '检索' (search) and the resource '联网' (web), making the tool's purpose clear as a generic web search tool. It does not explicitly differentiate from the sibling tools, but the name and verb provide sufficient clarity.
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 is provided on when to use this tool versus alternatives like research_company or scan_market. The only conditional mentioned concerns API keys, not tool selection, leaving usage context to be inferred.
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.
v0.1.0calc_quotationcheck_redflagsclassify_claimdraft_outreachgenerate_personaplan_pipelineresearch_companyscan_marketscore_productsweb_searchScored across 10 tools
Most tools target clearly distinct activities: research, market scanning, pricing, red flags, search, scoring, outreach, persona, orchestration, and claim classification. Minor overlap exists between plan_pipeline and research_company/scan_market (all plan or list missing info) and between research_company and check_redflags (both address red flags), but descriptions mostly clarify boundaries.
All ten tool names follow the same snake_case verb_noun pattern: research_company, scan_market, calc_quotation, check_redflags, web_search, score_products, draft_outreach, generate_persona, plan_pipeline, classify_claim. There is no mixing of conventions or vague generic verbs.
Ten tools is well-scoped for a trade-agent server. Each tool serves a distinct stage in the trade workflow—research, market analysis, quotation, risk assessment, search, product scoring, outreach, persona generation, orchestration, and claim verification—without redundancy or bloat.
The toolset covers the full trade-agent lifecycle: finding and qualifying companies, scanning markets, calculating quotations, checking red flags, scoring products, generating personas and outreach emails, orchestrating pipelines, and classifying claims. There are no obvious dead ends; missing formal document generation (e.g., PIs) is a minor extension, not a core gap.
AI sales — prospect discovery, ICP scoring, outreach generation.
AI-native B2B sales research, ranking, and CRM enrichment.
Sales intelligence for B2B SMEs — lead scoring, ICP fit, CRM enrichment & writeback.
Sales research and prep tools for B2B reps. Prospect briefs, angles, citations.
