check_condition

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the tool does not intentionally wait, is for current-state checks only, and that text takes precedence over check. It could more explicitly state that a non-match returns False, but the 'boolean observation' phrasing and 'Return True when...' conditions make this largely clear.

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?

The description is front-loaded with the core purpose and then organizes usage guidance, arguments, and notes logically. It is slightly redundant because the note 'When text is provided, check is ignored' repeats the same statement from the parameter documentation, but every other sentence adds distinct value.

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 boolean-observation tool with no output schema, the description covers parameters, return semantics, no-wait behavior, and sibling alternatives. It could be more complete by explicitly stating what happens when the selector matches no elements or by defining the returned value for the false case, but the coverage is strong overall.

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 fully compensates. It explains the check enum values ('present', 'visible') with return conditions, describes selector as a CSS or SeleniumBase selector defaulting to 'body', and clarifies that text is optional, takes precedence over check, and scopes the visibility check.

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 clearly identifies the tool's purpose: checking the current state of an element or text and returning an immediate boolean observation. It names specific verbs and resources ('check', 'element', 'text') and distinguishes itself from wait_for and assert_condition, so an agent can differentiate it from siblings.

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 description provides explicit routing guidance: use wait_for when a condition may become true later, use assert_condition when failure should raise an assertion error, use find_elements for counts/details, and use get_content for reading actual content. This is comprehensive and leaves little to inference.

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