ai_actor_list
系统演员列表
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | ||
| pose | No | ||
| limit | No | ||
| gender | No | ||
| offset | No | ||
| sort_by | No | ||
| industry | No | 按服务端行业分类过滤(如 `beauty` / `fitness` / `finance` 等);取值集以服务端注册表为准。 | |
| ethnicity | No | ||
| shot_type | No | ||
| situation | No |
系统演员列表
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | ||
| pose | No | ||
| limit | No | ||
| gender | No | ||
| offset | No | ||
| sort_by | No | ||
| industry | No | 按服务端行业分类过滤(如 `beauty` / `fitness` / `finance` 等);取值集以服务端注册表为准。 | |
| ethnicity | No | ||
| shot_type | No | ||
| situation | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing further — no mention of pagination behavior, result volume, or how the enum filters combine — so it contributes no behavioral context of its own.
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?
Seven characters is not concise, it is under-specified. There is no wasted language, but the single noun phrase carries too little content to be considered appropriately sized for a 10-parameter filtering tool.
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 tool with 10 filter parameters, no required params, no output schema, and no annotations describing return behavior, the description supplies none of the missing context: not the meaning of the enum dimensions, not pagination defaults, not the shape of the returned list.
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 10% across 10 parameters; only industry (and the root schema note about lowercase/hyphenated values) is documented. The description says nothing about any parameter — no explanation of array-vs-scalar semantics, sort_by values, enum meanings, or how filters are AND/OR-combined — so it fails to compensate for the large coverage gap.
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?
"系统演员列表" is essentially a Chinese restatement of the tool name ai_actor_list — a noun phrase with no verb and no scope detail. It does not distinguish itself from siblings like ai_actor_perform or ai_actor_say beyond the trivially obvious "list" semantics already in the name.
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?
There is no guidance on when to call this tool, when not to, or which sibling to prefer for related tasks (e.g. ai_actor_perform for generating an actor action). The agent must infer usage entirely from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.