AI kiểm chứng từng bước của luồng E2E

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

With no annotations, the description carries the full burden, and it does disclose one meaningful behavioral rule: a step with no actual assertion will be BLOCKED. That is valuable policy information. It does not disclose prerequisites (an active session from tester_browser_start), sequencing enforcement, error behavior, or whether a started step that is never finished leaves state dangling.

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?

Two compact sentences that front-load the ordering requirement and the assertion constraint, with no filler. Structure is slightly dense (multiple workflow rules chained with commas) but nothing is wasted.

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-required-parameter lifecycle tool with zero annotation and zero schema-description coverage and no output schema, the description explains the workflow spine but leaves prerequisites, phase semantics, id provenance, and return/failure behavior undocumented. An agent would likely need to inspect siblings before calling it correctly.

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% for all three parameters. The description only indirectly hints at phase via 'Bắt đầu... finish' and vaguely implies id is a step within a flow case; it never explains the id pattern, the meaning of the phase enum values, or what project refers to. Most of the parameter burden is left unaddressed.

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 says it advances/validates a step of a flow created via tester_browser_case kind=flow, which gives a verb and a resource and ties it to a sibling. However, it frames itself as 'start the step' while the schema's phase enum covers both start and finish, so the tool's true scope (step lifecycle: start and finish) is only obliquely implied by 'rồi finish bước'. An agent can guess the purpose but not state it crisply.

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 usable sequence: take steps in order from tester_browser_case kind=flow, perform the action and verify with tester_browser_assert, then finish the step. That is real when-to-use guidance, but there is no exclusion or contrast against tester_browser_action or tester_browser_finish, both of which sound adjacent to 'act' and 'finish the step', leaving boundary inference to the agent.

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