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., "@wop-mcp 生成一对 RSA2048 密钥，私钥保存到本地，别在对话里显示"
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.
万联易达开放平台（WOP）MCP Server —— 让 AI 助手安全、正确地完成 WOP 对接
wop-mcp 是万联易达开放平台（WOP）的 Model Context Protocol Server，
帮助开发者通过 AI 助手（Claude Desktop、Cursor、Claude Code 等）完成 WOP 对接：
📚 文档获取：接入指南、API 索引、接口详情（自动穿透文档 URL 的时间戳后缀）
🔐 密钥对生成：RSA2048 / SM2，公钥按分发契约编码返回，可直接上报平台
🛡️ 安全纪律：私钥只写入本地 0600 文件，永不回显进 AI 对话（对齐 wop-skills SECURITY 纪律）
🔌 即插即用：stdio transport，uvx wop-mcp（PyPI 发布后）一行接入
Related MCP server: AWP MCP Server
工具 | 说明 |
| 接入指南（三步流程、securityReq 组合、公钥编码、SDK 列表）+ 实时 |
| API 详情；入参支持 API 路径（如 |
| 文档中心任意子页 / 外链内容（相对路径自动拼接基址，如 |
|
|
uvx wop-mcpgit clone https://github.com/wop-platform/wop-mcp.git
cd wop-mcp
uv sync
uv run wop-mcp{
"mcpServers": {
"wop-mcp": {
"command": "uvx",
"args": ["wop-mcp"],
"timeout": 600,
"autoApprove": ["wop_overview", "wop_api_detail", "wop_link_detail"]
}
}
}macOS：~/Library/Application Support/Claude/claude_desktop_config.json
Windows：%APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"wop-mcp": {
"command": "uvx",
"args": ["wop-mcp"]
}
}
}源码方式将 command/args 替换为：
{
"command": "uv",
"args": ["--directory", "/path/to/wop-mcp", "run", "wop-mcp"]
}
wop_gen_key_pair写本地私钥文件，建议保留人工确认（未列入 autoApprove）。
变量 | 默认值 | 说明 |
|
| 文档中心基址 |
|
| 私钥落盘目录（0600 文件） |
|
|
|
|
| HTTP 超时秒数 |
私钥只落盘不回显：wop_gen_key_pair 返回值不含任何私钥材料；私钥以 0600 权限独占创建于 WOP_KEYS_DIR。
公钥即上报格式：RSA = X.509 SPKI DER 的 Base64；SM2 = 未压缩点 04‖X‖Y（65 字节）的 Base64（crypto-strategy-spec §3.4，D10/D12）。
契约自检：每次生成后经 wop-python-sdk 官方加载器回读（含 SM2 曲线校验），编码不合约即报错。
keys/ 目录已入 .gitignore，严禁将私钥文件提交入库或粘贴进对话。
本工具密钥生成支持 RSA2048 / SM2。crypto-strategy-spec v0.4 草案的 securityReq
国际族档位为 RSA3072/RSA4096；平台实际接受的 RSA 档位以商户中心审核为准。
国密族与国际族禁止跨族组合。
uv sync # 安装依赖（含 dev 组）
uv run pytest --cov=wop_mcp --cov-fail-under=95 # 测试 + 覆盖率门禁
npm i -g lefthook && lefthook install # 激活 git 钩子（commitlint + 覆盖率门禁）提交信息遵循 Conventional Commits（commitlint 校验）
CI：GitHub Actions，Python 3.10–3.13 矩阵，覆盖率红线 95%
MIT © 2026 wop-platform
获取万联易达开放平台（WOP）指定 API 接口的详细定义。
支持三种入参形态（按优先级）：
1. API 路径：如 /staffing/open/v1/invoice/apply（可带 POST/GET 前缀，
支持省略业务域前缀的后缀匹配）
2. 接口中文名：如 转账提交
3. 完整 .md URL：直通下载
匹配到多个接口时返回候选列表，请用更精确的路径或 URL 重试。
Args:
api: str - API 路径、接口中文名或完整 .md URL
Returns:
str: API 接口详情（markdown 格式：基本信息、请求参数、响应参数、示例等）
| Name | Required | Description | Default |
|---|---|---|---|
| api | 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 must carry behavioral burden, and it does disclose suffix matching, optional POST/GET prefixes, direct-download behavior for URLs, and the ambiguous-match candidate-list outcome. It omits auth/rate-limit context, but the matching semantics are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then a numbered list for the input forms, then Args/Returns. The docstring-style Args/Returns block is somewhat redundant given the schema and output schema, but the overall structure is efficient and scannable.
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?
An output schema exists so return values need not be explained, yet the description still characterizes the markdown content. Combined with the matching-failure guidance, an agent has enough to call this correctly; only auth and error-code behavior are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there is one parameter, so the description must define it — and it does, enumerating three accepted value forms and how prefix/suffix matching resolves. This goes well beyond the empty schema entry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: retrieve the full definition of a named WOP API interface. It also delineates scope against siblings (wop_overview, wop_link_detail) by being explicitly about a single interface's detail definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives three ranked input forms with concrete examples and priority ordering, plus the recovery action when multiple interfaces match. It lacks explicit 'use this instead of X' routing to siblings, but the form guidance is unusually actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成 WOP 对接所需的非对称密钥对（RSA2048 / SM2）。
安全纪律：私钥只写入本地 0600 文件，不会出现在返回值或对话中；
返回的 publicKey 为分发契约编码（RSA：SPKI DER Base64；
SM2：未压缩点 04‖X‖Y Base64），可直接上报平台。
Args:
algorithm: str - "RSA2048"（别名 "RSA"）或 "SM2"，默认 "RSA2048"
Returns:
Dict 包含 algorithm / publicKey / privateKeyFile(路径) / message
| Name | Required | Description | Default |
|---|---|---|---|
| algorithm | No | RSA2048 |
| 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 and does so: it discloses the security discipline (private key written only to local 0600 file, never in return values or conversation), the exact encoding contracts for publicKey per algorithm, and the return shape. This is rich behavioral context an agent could not infer otherwise.
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?
Well-structured with a purpose line, a labeled security block, and explicit Args/Returns sections. Slight redundancy with both prose and Args/Returns sections, but every sentence carries meaning.
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 1-param, no-annotation mutation tool, the description fully covers the algorithm semantics, key-writing side effects, encoding contracts, and return fields. An output schema exists, so return structure needn't be over-explained, and it isn't.
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 compensate. It documents the single 'algorithm' parameter fully: accepted values 'RSA2048' (alias 'RSA') or 'SM2', and the default 'RSA2048' – including an alias not visible in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: generating an asymmetric key pair for WOP onboarding, with the exact algorithms named (RSA2048/SM2). Clearly distinguishable from siblings (overview, api_detail, link_detail), which are all read inspection 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?
Implies usage via 'WOP 对接所需' (needed for WOP integration) but gives no explicit when-to-use conditions, prerequisites, or alternatives. No sibling routing, though siblings are conceptually unrelated so routing is less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取万联易达开放平台（WOP）文档中心子页面或外部链接的详细内容。
接受完整 URL，或文档中心相对路径（自动拼接文档中心基址，
如 staffing/api/staffing/open/v1/invoice/apply.2026….md 或 llms-full.txt）。
Args:
url: str - 完整 URL 或文档中心相对路径
Returns:
str: 页面内容（markdown 格式）
| Name | Required | Description | Default |
|---|---|---|---|
| url | 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 behavioral burden. It usefully discloses that relative paths are automatically joined to the document center base and that the result is markdown content, but it does not address permissions, authentication, rate limits, error behavior, or whether the operation has any side effects.
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 and front-loads the core purpose, followed by a structured Args/Returns section. Most content earns its place, though the Returns section repeats information that may also be available in the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter fetch tool with an output schema, the description covers the essential input semantics and return format. It is nearly complete, but it omits sibling routing guidance and any mention of authentication or access constraints.
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% for the single url parameter, so the description must compensate. It does so by explaining that url can be either a complete URL or a document-center-relative path, including example paths and the automatic base concatenation behavior, which adds meaning beyond the bare schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb (获取) and resource (文档中心子页面或外部链接的详细内容), so an agent can tell it fetches page content rather than generates keys or shows an overview. It does not explicitly name or distinguish itself from siblings such as wop_api_detail or wop_overview, so it stops short of full sibling differentiation.
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 explains that the tool accepts a full URL or a document-center-relative path and that relative paths are automatically resolved against the document center base. This gives clear input context, but it does not say when to choose this tool over siblings like wop_api_detail or wop_overview, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取万联易达开放平台（WOP）的接入指南与全部 API 索引。
内容包含：三步接入流程、securityReq 算法组合、公钥分发编码、官方 SDK 与
工具列表，以及实时拉取的 llms.txt API 索引（按业务域分组）。
索引中的 API 可用 wop_api_detail 进一步获取详情，链接可用 wop_link_detail 获取。
Returns:
str: 接入指南 + API 索引（markdown 格式）
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 the scope of returned content (three-step flow, securityReq algorithm, public-key encoding, SDK/tool list, live llms.txt index grouped by domain) and notes the index is pulled in real time. It is clearly a non-destructive read; the only gap is it does not discuss caching/refresh behavior beyond '实时拉取'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then a content inventory, then sibling routing, then a brief Returns line. Every sentence contributes; the content enumeration is dense but useful rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, yet the description supplies a markdown-format note and full content inventory. For a parameterless overview/entry-point tool this is complete enough to invoke 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 tool takes zero parameters, so the schema baseline of 4 applies. There is nothing further the description could meaningfully add about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (获取/get) and resource (WOP 接入指南与全部 API 索引), and enumerates the exact contents. It also names the two sibling tools (wop_api_detail, wop_link_detail) that handle the follow-up detail, so the agent can distinguish it from them without opening a schema.
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 routes the agent: index APIs are fetched in detail via wop_api_detail, links via wop_link_detail, implying this tool is the entry point that produces the index. It stops short of an explicit 'call this first' statement or an exclusion rule, so it falls just short of a 5.
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.0wop_api_detailwop_gen_key_pairwop_link_detailwop_overviewScored across 4 tools
wop_overview and wop_gen_key_pair are clearly distinct, and wop_api_detail targets API definitions while wop_link_detail targets documentation pages. However, both detail tools accept URLs, so an agent could confuse which one to use for a given link despite the descriptions clarifying intent.
All tools use a consistent wop_ prefix and snake_case, which makes the set predictable. The only minor deviation is that wop_gen_key_pair uses a verb phrase while the other three are noun-oriented, but the pattern remains readable.
Four tools are well-scoped for a WOP integration server: one provides onboarding/index, two retrieve specific docs or API details, and one generates required key pairs. Each tool earns its place without redundancy or excessive surface area.
The server covers the core WOP integration lifecycle: overview/index, API detail lookup, documentation link retrieval, and key generation. Minor gaps exist, such as no standalone search across APIs or direct SDK download tool, but the overview and link tools provide workarounds.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
Tailor Platform for AI assistants: search, list and read the platform documentation.
Read and write KukGit repositories, files, issues and pull requests from an AI assistant.
Versioned documentation registry and semantic search for AI tools and coding assistants.
