Skip to main content
Glama
Sign In
wx-mp-mcp

wx-mp-mcp

by k98crypto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Run code in mini-program sandbox

mp_sandbox_run

Runs arbitrary JavaScript in an offline WeChat Mini Program sandbox to load app-service bundles, call SDK signing functions, analyze encryption logic, and extract runtime data.

Instructions

在离线沙箱中加载小程序 bundle (app-service.js)，执行任意 JS 代码。用于调用 SDK 签名函数、分析加密逻辑、提取运行时数据。需要先 mp_analyze 解包。 【eval 作用域契约】代码运行在 ESM AsyncFunction 里，注入 5 个参数： · ctx —— 沙箱上下文 (ctx.sandbox / ctx.requireMod / ctx.wpRequire / ctx.setTimestamp 等) · requireMod(path) —— 按 WeChat 模块路径取模块；wpRequire(id) —— 按 webpack 数字 id 取模块(惰性、不引导 app) · sandbox —— 沙箱全局对象：微信全局走 sandbox.wx / sandbox.getApp()，模块工厂里 self===sandbox · runInContext(code, ms=8000) —— 在沙箱 realm 内【带超时】执行(同步死循环会抛 timeout 而非拖死)；JSVMP/VMP 签名调用建议用它 注意：这是 ESM 上下文，没有 node 的 require；要用 globalThis.crypto / Buffer。 分包里的签名 SDK(依赖主包 runtime)用 bundle_paths 传[主包,分包]协同加载。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "appid": "<appid>",
      "code": "<code>"
    },
    "name": "mp_sandbox_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
uaNo覆盖 navigator.userAgent (VMP 常把 UA 编进签名，需与目标客户端一致)
codeYes要执行的 JS 代码；可用 ctx/requireMod/wpRequire/sandbox/runInContext
appidYes小程序 appid
deviceNo真机种子 JSON：覆盖 wx 系统/设备信息字段(如 {"platform":"android","system":"Android 14","model":"...","screenWidth":414,"screenHeight":896,"SDKVersion":"3.16.1"})，使离线签名环境指纹与目标设备一致。不传则用默认。
storageNo预设 wx storage JSON (如 '{"key":"value"}')
timeout_msNo沙箱进程整体超时 (默认 60000)
bundle_pathNo自定义 app-service.js 路径 (默认按 appid 自动查找)
bundle_pathsNo多 bundle 协同加载[主包,分包,...]，顺序拼接单次载入(分包签名 SDK 依赖主包 runtime 时用)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the full burden, and it does so unusually well: it discloses the ESM AsyncFunction execution realm, the exact five identifiers injected (ctx, requireMod, wpRequire, sandbox, runInContext), the absence of node's require, the requirement to use globalThis.crypto/Buffer, and timeout semantics. It even warns that a synchronous infinite loop throws a timeout instead of hanging the host, and gives default timeout values (8000 ms for runInContext, 60000 ms for the sandbox process).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured: a one-line purpose followed by a clearly-headed scope contract. Every clause about the injected context and timeouts is load-bearing for correct invocation, though the parenthetical list of ctx members is slightly padded with '等' and could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter, annotation-free code-execution tool this covers the hard parts: execution realm, injected globals, module resolution modes, timeout behavior, and multi-bundle loading. The notable remaining gap is the return surface — with no output schema, the description never says what the tool hands back (return value of the code, console output, or errors), and it does not state that the sandbox is side-effect-free with respect to the real mini-program.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented in the schema, making 3 the baseline. The description adds real meaning only for the multi-bundle case (main package + subpackage loaded in order so that a subpackage signing SDK can resolve the main-package runtime) and otherwise leaves semantics of device, storage, ua, and bundle_path to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb and resource — loading an app-service.js bundle into an offline sandbox and executing arbitrary JS — and names its concrete purposes (calling SDK signing functions, analyzing encryption logic, extracting runtime data). It also names the prerequisite sibling mp_analyze, though it does not distinguish itself from mp_sandbox_export or mp_sandbox_modules by name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The definition gives clear when-to-use conditions (SDK signing calls, encryption analysis, runtime data extraction) and an explicit prerequisite ('需要先 mp_analyze 解包'). It additionally routes VMP/JSVMP signing calls toward runInContext instead of raw code, which is real alternative-routing guidance. What is missing is explicit exclusion against the sibling tools; no 'do not use this when...' statement appears.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools