JSON-RPC服务

它解决什么问题

JSON-RPC 服务遍地都是：内部工具网关、RPC 中台、各类带 rpc.discover 的 OpenRPC 服务端。但对模型来说，这些服务是黑盒——它不知道服务上暴露了哪些方法、参数长什么样。没有发现机制时，只能猜方法名、猜字段，然后拿到 Method not found 或者结构对不上的返回。

这个技能把「发现 + 调用」做成了两个明确工具，让路由决策留在模型侧，真正的网络请求留在代码侧。

核心能力

• scripts.tools.rpc_discover：对指定服务端发起一次 JSON-RPC 调用，请求 rpc.discover 方法，拿到该服务支持的方法清单。这是 OpenRPC 规范里为 JSON-RPC 服务定义的发现入口。
• scripts.tools.rpc_call：对任意服务端调用任意 JSON-RPC 方法，只需要给出 server、method 和字符串化的 params。

工作方式

模型是路由层，代码只负责发请求。执行顺序是：

1. 先检查 API 密钥。scripts.config.settings.api_key 为空时必须通过 AskUserQuestion 向用户索取，拿到后调用 scripts.config.set_api_key(key) 落盘。
2. 根据用户意图选工具。问「这个服务有哪些方法」走 rpc_discover；要求「用这些参数调某个方法」走 rpc_call。
3. 提取参数。params 是字符串化的 JSON，需要自行序列化；缺参数时用 AskUserQuestion 追问，不要臆造。
4. 以关键字参数调用，例如 scripts.tools.rpc_call(server='...', method='...', params='...')。
5. 整理 result["raw"] 后展示给用户，同时参考 result["success"] 和 result["message"] 判断是否成功。

适用边界与注意点

• API 密钥是硬前置条件。缺少密钥时禁止自行搜索或编造数据，必须先问用户。密钥申请地址为 https://xiaobenyang.com。
• 发现能力依赖服务端确实实现了 OpenRPC 的 rpc.discover。没实现的服务端，这个工具也拿不到方法清单。
• 该技能不做参数类型校验、重试、鉴权头注入或结果 schema 推断。params 的构造完全由调用方负责，传错结构会直接体现为服务端报错。
• 两个工具都只覆盖单个服务端的单次调用，没有批量、并发或长连接复用能力。