hire_staff开一个新的数字员工岗位。参数：templateId 必填（list_templates 里 canOpen=true 的，如 kb-assistant 知识库问答员）；name 员工名字；kbs 开岗时就配上的知识库。返回 slug、画布链接 canvasUrl（发给顾客 / 挂服务号的就是它）和实际配上的知识库 kbs（名下没有的库名会被忽略，以返回为准）。代价：新岗位先免费试用几天，之后按月从主人余额扣 Token，对话按次另计——开之前跟用户确认；每个账号岗位数有上限，到上限会报错，让用户先删掉不用的。
| Name | Required | Description | Default |
|---|---|---|---|
| kbs | No | 开岗时就配上的知识库名（必须是我名下已发布的） | |
| name | No | 员工名字，顾客会看到 | |
| templateId | Yes | 岗位模板，从 list_templates 里挑 canOpen=true 的 |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond annotations: return values (slug, canvasUrl, actual kbs), cost model (free trial then monthly Token deduction, per-conversation charge), requirement to confirm with user, account limit and error behavior, and that invalid kbs names are silently ignored. Annotations already declare readOnlyHint=false and destructiveHint=false, and the description is consistent with them.
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 purpose, then parameters, returns, cost, and limits. Every sentence carries operational value; no redundant restatement of the name or title.
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?
No output schema exists, but the description explains the key return fields. It covers cost, confirmation, error conditions, and parameter sourcing, so an agent has enough to invoke the tool correctly given the annotations and schema.
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 100%, so the baseline is 3, but the description adds meaning: templateId must be from list_templates canOpen=true with a concrete example, name is what customers see, and kbs must be published under the user's name or will be ignored. It does not add format or validation details beyond the schema for all parameters.
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: opening a new digital employee position (开一个新的数字员工岗位). The word 'new' distinguishes it from sibling update/config tools like patch_staff_config, and the return values clarify what the operation produces.
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 clear prerequisites and conditions: templateId must come from list_templates where canOpen=true, the user must be asked to confirm before opening, and account limits trigger an error requiring cleanup. It does not explicitly name when-not-to-use or an alternative sibling tool for modifying existing staff.
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.