Lists game assemblies (DLLs) with type counts to identify which DLL holds main game logic, narrowing search scope. Supports pagination via offset/limit with a has_more flag.
列出游戏里的程序集（dll）及各自的类型数量。支持 offset/limit 翻页并如实给 has_more。
用来判断「游戏逻辑主要在哪个 dll」，从而缩小搜索范围。
Args:
pattern: 名称子串过滤（如 "TeamTapas"）。
offset: 从第几条开始（翻页用）。
limit: 本页最多几条。被截断时 has_more 为 true。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| pattern | 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 behavior the annotations don't: offset/limit paging and the fact that has_more is returned truthfully when a page is truncated. Missing only ordering/return-shape details, which is minor here.
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 purpose and the paging rule are front-loaded, followed by a compact Args block. Every line carries information, with no filler.
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 three-parameter read-only listing tool with no output schema, the description covers what is listed (dlls plus type counts), how to page (offset/limit/has_more), and why to call it. Nothing an agent needs in order to call it correctly is missing.
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%, so the description must carry the parameter meaning, and it does: pattern is a name substring filter (with an example), offset is the start index, limit is the page size. Defaults aren't restated, but the semantics are fully clear.
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 states a specific action and resource: list the game's assemblies (dlls) with their type counts, plus pagination. This clearly differentiates it from siblings like search_classes or class_detail. The only friction is that the tool name 'list_images' suggests images rather than assemblies, so the description has to do remedial work.
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?
It gives a concrete decision rule: use it to determine which dll holds the game logic and thereby shrink the search space. It doesn't name an explicit alternative when this tool is the wrong choice, but the intended scenario is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.