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., "@company-reconcile 对碰这两份公司清单，name_threshold 设为 90，date_tolerance_days 设为 1"
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.
把两份表格（Excel / CSV / 电子版 PDF）按 公司名称 + 日期 做模糊对碰，
AND 逻辑：名称相似度达标 且 日期在容差内才算匹配。结果分三档：
已匹配 / 待复核 / 未匹配，每条带名称相似度分与日期相差天数。
以 stdio 启动，依赖由 uvx 自动安装：
{
"mcpServers": {
"company-reconcile": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/uerdshds/company-data-mcp.git@main",
"company-reconcile-mcp"
]
}
}
}工具：reconcile_company_tables(file_a, file_b, name_threshold=85, date_tolerance_days=0, ...)。
Related MCP server: payroll-normalizer-mcp
文件 | 作用 |
| 核心逻辑：读取 + 表头识别 + 公司名规范化 + rapidfuzz 匹配（与 MCP 解耦） |
| FastMCP 服务，StreamableHTTP 传输，端点 |
| 本地直接测核心逻辑（不经 MCP） |
| MCP 客户端连服务测试（模拟 DEAP 调用） |
| 示例数据（含全角/简称/日期格式/容差等噪声） |
| DEAP「JSON 导入」用的配置 |
# 1. 装依赖（已建好 .venv）
.venv/Scripts/python.exe -m pip install -r requirements.txt
# 2. 直接测核心逻辑
.venv/Scripts/python.exe test_local.py # 默认 容差0
.venv/Scripts/python.exe test_local.py --tol 1 # 日期容差1天
# 3. 启动 MCP 服务
.venv/Scripts/python.exe server.py # 监听 0.0.0.0:8000/message
# 4. 另开终端，用 MCP 客户端验证
.venv/Scripts/python.exe test_client.py魔搭 MCP 托管底层是函数计算 FC，部署后给一个稳定 StreamableHTTP 端点：
https://mcp.api-inference.modelscope.net/<id>/mcp（本项目 id 已为 9a8d78b7a7f649）。
部署物：Dockerfile + matcher.py + server.py + requirements.txt。
镜像已设 MCP_HTTP_PATH=/mcp、MCP_TRANSPORT=streamable-http、端口读 PORT，与魔搭端点对齐。
若魔搭 FC 运行时要求 stdio 包装，把环境变量改成 MCP_TRANSPORT=stdio 即可。
本地+ngrok 仍可用作联调：
MCP_HTTP_PATH=/message ngrok http 8000。
拿到公网端点：魔搭托管地址 https://mcp.api-inference.modelscope.net/9a8d78b7a7f649/mcp。
注册自定义技能：企业技能中心 → 自定义技能 → 新建 MCP 插件
快速创建：类型选 StreamableHTTP，HTTP URL 填上面的魔搭 /mcp 地址。
或 JSON 导入：用 deap-config.json。
点「插件检测」，应能拉到工具 reconcile_company_tables。
把技能加到智能体：智能体 → 技能 → 添加插件 → 选本技能。
配置智能体提示词，让模型在用户要"对碰/核对"两份表时调用本技能（见下）。
当用户提供两份文件并要求"对碰/核对/匹配"时，调用【公司名对碰】插件，
把两个文件地址传给 file_a / file_b；需要时设置 name_threshold(默认85)、
date_tolerance_days(默认0)。拿到 matched/to_review/unmatched 三档结果后，
用简洁中文汇总，并务必如实列出"待复核"条目，不得自行判定为匹配。传输：StreamableHTTP（DEAP 不支持 Stdio）。服务路径默认 /mcp，可用环境变量 MCP_HTTP_PATH 改；传输用 MCP_TRANSPORT 切 stdio。
文件入参：file_a/file_b 支持「可下载 URL（钉盘链接）」或本地路径。DEAP 场景下，
由智能体把用户上传文件的下载地址作为参数传入，本服务自行下载解析。
鉴权（可选）：设 MCP_API_KEY=xxx 后，请求需带 Header X-Api-Key: xxx
（在 DEAP 技能的「请求头」里加同名 Header）。系统还会自动注入
X-DingTalk-User-Id / X-DingTalk-User-Job-Number。
PDF：仅支持电子版（文字可选）；扫描件需先 OCR（项目里 ../agent-mcp-workflow/OCR.py 可参考）。
参数 | 默认 | 含义 |
| 85 | 公司名相似度阈值(0-100)，越高越严 |
| 0 | 日期容差天数，0=必须同一天 |
| false | 比对时剥离「有限公司」等组织形式后缀 |
| 自动 | 手动指定列名（留空则按表头别名自动识别） |
把两份表格按【公司名称 + 日期】做模糊对碰 (AND逻辑: 名称与日期都满足才算匹配)。
返回三档结果:
matched : 名称相似度>=阈值 且 日期在容差内
to_review : 日期满足但名称相似度落在复核区间(阈值下10分内), 需人工确认
unmatched : 无日期匹配候选, 或名称相似度过低 每条含 name_score(名称分) 与 day_gap(日期相差天数), 另附 summary 汇总。
| Name | Required | Description | Default |
|---|---|---|---|
| file_a | Yes | 表A: 可下载的文件URL(钉盘链接)或本地路径, 支持 .xlsx/.csv/.pdf | |
| file_b | Yes | 表B: 可下载的文件URL(钉盘链接)或本地路径, 支持 .xlsx/.csv/.pdf | |
| name_threshold | No | 公司名相似度阈值(0-100), 默认85, 越高越严格 | |
| date_tolerance_days | No | 日期容差天数, 0=必须同一天(AND严格), 默认0 | |
| name_col_a | No | 表A名称列名, 留空自动识别 | |
| date_col_a | No | 表A日期列名, 留空自动识别 | |
| name_col_b | No | 表B名称列名, 留空自动识别 | |
| date_col_b | No | 表B日期列名, 留空自动识别 | |
| strip_suffix | No | 比对时是否剥离'有限公司'等组织形式后缀, 默认False |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining the fuzzy matching logic, result tiers, and output fields (name_score, day_gap, summary). Annotations (readOnlyHint=true, openWorldHint=true) are consistent and not contradicted.
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 extremely concise, using a short paragraph and bullet points to convey the matching logic, three result tiers, and output fields. 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 tool's complexity (9 parameters, 2 required) and the presence of a detailed input schema, the description effectively covers the tool's purpose, matching logic, result categories, and output structure, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the tool description does not need to repeat parameter details. It focuses on overall behavior rather than individual parameter semantics, which is acceptable given the schema's thoroughness.
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 reconciles two tables by fuzzy matching on company name and date with AND logic. It specifies three result tiers (matched, to_review, unmatched) and the output fields. No sibling differentiation 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 provides clear context about the matching logic and result categories, implying the tool is for reconciling company tables. Without siblings, it adequately guides usage, though explicit when-to-use scenarios could be added.
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.0reconcile_company_tablesScored across 1 tool
With only one tool, there is no risk of confusion between tools. The tool's purpose is clearly defined.
The single tool uses a descriptive snake_case verb_noun pattern. Consistency is not an issue with only one tool.
A single tool for company reconciliation is borderline; it bundles multiple operations (matching, reviewing, summarizing) into one, which may lack modularity.
The tool covers the core reconciliation process, but lacks separate controls for thresholds, detailed inspection of unmatched items, or history features.
Compare CSV tables by key; report changes and ambiguous rows. 0.05 USDC on Base via x402.
Find duplicate records in 30 seconds. Zero-config entity resolution, 97.2% F1 out of the box.
Map messy columns to a known schema — 7 scorers, domain dictionaries, F1 0.84. Zero config.