boss_agent_run

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

No annotations are supplied, so the description carries the full burden. It says 'execution' happens on a live recruitment platform, but never states side effects (messages or greetings sent to real candidates), whether the run can be interrupted or resumed, how it relates to the stopped state implied by the resume parameter, rate limits, or what happens on partial failure. The availability clause is useful metadata, but the risk profile of an autonomous agent run is left undisclosed.

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?

One compact sentence lists the pipeline stages up front, followed by a bracketed availability tag. Nothing is redundant, though listing five stages in a comma chain is slightly dense and the availability tag could be separated more clearly.

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 and no annotations, the description should say more about what a round produces (leads, decisions, stats) and when the run halts. Parameter documentation in the schema is thorough, which offsets some of the gap, but the behavioral picture for an autonomous automation tool remains thin.

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 100%, and the three parameters (limit, resume, dry_run) already carry detailed semantics in the schema, including the dry_run default of true and the strict confirmation needed for resume. The description adds no parameter meaning beyond that, so the baseline of 3 for fully documented schemas applies.

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 names a concrete operation: a single automation round covering scan, decision, threshold control, execution and lead generation, along with the roles and platforms it applies to (zhipin). That is enough to distinguish it from granular siblings like boss_agent_stop, boss_agent_pending or boss_watch_run, though it never names those siblings 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?

The bracketed availability clause (roles=candidate/recruiter; platforms=zhipin) gives a clear precondition for use, which is genuinely useful. However, it offers no guidance on when to choose this over boss_watch_run, boss_agent_pending or boss_agent_stop, and no explicit when-not-to-use condition, so selection between it and its closest siblings must be inferred.

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