Extract /Script/ module names and object paths from an Unreal Engine game executable to identify available game systems; failures return ok=false with an error.
从 UE 游戏 exe 里提取 /Script/ 模块名与对象路径。失败时按契约给 ok=false + error。
这是字符串证据，不是反射元数据：能告诉你游戏大致有哪些系统 （如 /Script/Engine、/Script/GameplayAbilities）， 但拿不到父类链和属性偏移——那需要运行时。
Args: exe: 游戏可执行文件路径。留空则用当前会话的主程序。 limit: 每类最多返回多少条。
| Name | Required | Description | Default |
|---|---|---|---|
| exe | No | ||
| limit | No |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context: the failure contract (ok=false + error) and the fact that results are string evidence rather than reflection metadata, but it does not describe result shape or how strings are grouped 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 the purpose, then the key limitation, then the args; each block earns its place. The bold emphasis and mixed prose/Args formatting are slightly heavier than necessary but not wasteful.
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?
With no output schema, the description covers the return domain (/Script/ module names and object paths) and the error contract, plus the key caveat about missing class/field metadata. It stops short of describing the actual result structure or whether results are deduplicated across modules.
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 carry the parameters, and it does: exe is the game executable path with the non-obvious fallback to the current session's main program, and limit is the per-category cap. It does not state what a 'category' is or what limit applies to more precisely.
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: extract /Script/ module names and object paths from a UE game exe. It is contrasted with runtime reflection tools (no parent chains or property offsets), which separates it from siblings like runtime_class_info, though that sibling is not named explicitly.
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 a clear exclusion: it cannot provide parent class chains or property offsets because those require runtime, so an agent knows when to pick a runtime sibling instead. The alternative is described but not named, and no explicit 'use this when' positive trigger is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.