Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses returned fields and that llmMode only reveals BYOK status without the key, but it does not state permission requirements, side-effect-free read behavior, or any rate/limit context.

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-loads the purpose, then details fields, the parameter, and the key warning in a compact package. The long parenthetical field list is dense but every element is relevant, with little wasted text.

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 helpfully enumerates returned configuration fields, and the pre-modification warning adds important operational context. It is nearly complete for a simple read tool, though slug semantics and permission requirements remain unaddressed.

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 compensate. It only says 'slug 必填,' which merely repeats the schema's required list and does not explain what a slug identifies, its format, or where to obtain it.

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 ('读岗位配置') and enumerates exactly what configuration fields are read, distinguishing it from the mutation sibling patch_staff_config. An agent can tell what this tool returns without opening the schema.

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?

Explicitly says to read before modifying, and explains the consequence of not doing so ('会用想当然的人设覆盖客户调过的版本'). This gives clear context for when to use it, though it does not name patch_staff_config directly as the alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.