Create a WeChat Pay V3 Native order for QR-code payment. Returns a signed request spec for pre-flight checks, or calls WeChat API to obtain a code_url.
微信支付V3 Native 扫码下单：execute=false 仅返回已签名的请求规格；true 真实调用微信 API 返回 code_url（二维码内容）。
| Name | Required | Description | Default |
|---|---|---|---|
| cred | No | 凭证（可省略，改用环境变量；PEM 字段可直接传 PEM 全文或 .pem 文件路径） | |
| order | Yes | ||
| execute | No | true=真实请求微信；false=仅构造（默认 true） | |
| notifyUrl | Yes | 微信异步回调 HTTPS 地址 |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burdenpa. It clearly explains that execute=false returns a signed request spec while execute=true calls the WeChat API and returns a code_url, giving the agent a concrete mental model of the tool's 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?
A single, dense sentence front-loads the core purpose and then explains both execution modes without wasted words. Every clause contributes essential routing or behavioral information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description compensates by specifying return expectations for both execute modes. Credential and order parameter details live in the input schema, and the description covers the remaining ambiguity around what each mode returns.
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 already covers 75% of parameter descriptions, so the baseline is 3. The main description adds meaningful semantics for the execute parameter by stating the actual outputs for each value, which goes beyond the schema's 'true=真实请求微信；false=仅构造' wording.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: creating a WeChat Pay V3 Native scan-code order. It also distinguishes the two execution modes, which separates it clearly from sibling tools like wechat_create_jsapi_order and alipay_precreate.
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 'Native 扫码下单' makes the intended use case clear, and the execute flag explains when to sign-only versus actually call WeChat. However, it does not explicitly state when not to use this tool or name alternatives, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.