assert_text

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

With no annotations, the description carries the burden. It discloses a key behavior: never throws an exception and always returns a PASS/FAIL text, which is valuable. But it does not state whether the operation is read-only or has any side effects, nor what happens on failure beyond returning a string.

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 paragraphs, front-loaded with the core purpose, followed by usage context and the critical behavioral guarantee. No redundant sentences.

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 simple assertion tool with an output schema, the description covers purpose, typical use, and error behavior. However, the untouched serial parameter and the lack of explicit mapping of the should_exist flag mean an agent might not invoke it entirely correctly on the first try.

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 explain parameters. It indirectly explains 'text' and the negation semantics of should_exist, but it never mentions the 'serial' parameter or how to set should_exist to false explicitly. This leaves a significant gap.

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 states a specific verb ('Ellenorzi' / checks) and resource (text visibility on screen), and clarifies it can assert both presence and absence. It positions itself as a final verification step in test flows, which distinguishes it from waiting or observation tools like wait_for_text.

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 clear context: use as a closing step of automated test flows, with examples of checking for a success message or absence of an error message. However, it does not explicitly name alternatives or exclusion criteria, so it stops short of a 5.

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