AI kiểm chứng kết quả

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

With no annotations supplied, the description carries the full burden, and it does add a genuine interpretive rule — that matching an HTTP status is insufficient to conclude authorization or business outcomes without a final-state check. However, it omits critical behavior: what happens on a failed assertion (throw, return error, halt the run, record a finding), whether the call mutates test state, and whether it needs an active browser session.

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 short sentences with no filler; the assertion targets are front-loaded. The second sentence is a caution rather than operating detail, but it is brief and does not pad the definition.

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 an 8-parameter, 2-required tool with no annotations, no output schema, and no parameter documentation, the definition is thin. It never explains how to construct the required project/type pair, what a failed assertion looks like, or how this differs from the other observation tools in the family.

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 0% across 8 parameters, so the description must compensate and largely does not. It hints at what the assertion targets are (UI, URL, HTTP status, overflow), giving loose meaning to type/expected/selector, but says nothing about project, path, role, name, or method, and does not explain how selector pairs with type or whether expected is a literal or pattern.

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 specific verb ("Xác nhận" / assert) and concrete targets — UI, URL, HTTP status, horizontal overflow — which broadly map to the type enum values (visible, hidden, containsText, url, responseStatus, noHorizontalOverflow). An agent can tell this is the assertion/verification step, though it does not explicitly separate itself from siblings like tester_browser_see or tester_browser_inspect.

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?

Usage is only implied: "đã quan sát trong test case" (observed in the test case) suggests calling it after observation, and the second sentence warns that an HTTP code alone does not prove authorization or business success. There is no explicit when-to-use vs. which sibling, no preconditions, and no statement about ordering relative to tester_browser_step or tester_browser_see.

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