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

With no annotations provided, the description carries the full burden and delivers: it reveals that close is conditional, explains that closing a test-owned session would terminate running execution, and clarifies that attachment only forgets the session while the session continues to live. This is non-obvious, high-value behavioral context.

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?

Three short sentences, no filler: main action is front-loaded, then the condition, then the rationale/alternative. Every sentence earns its place.

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 parameterless tool with an output schema, the description covers the important context: what is closed, under what condition, and why. It does not explicitly state the failure/no-op behavior when the condition is false, but that is a minor gap given the output schema and low complexity.

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?

The tool has zero parameters, so there is no parameter semantics for the description to add; the 4 baseline applies. The description's session-ownership discussion further clarifies the implicit resource being acted on.

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 first sentence states a specific verb-resource pair: 'Ferme la session' (closes the session), and adds a decisive ownership qualifier ('uniquement si ce serveur l'a créée') that distinguishes this lifecycle operation from merely forgetting a session. It is immediately clear what the tool does and what it is not for.

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 gives an explicit use condition (only for server-created sessions) and a clear counter-case (test-opened sessions must not be closed because it would cut execution). It refers to the alternative 'rattachement' conceptually, but does not name the sibling tool (connect_to_session), so the guidance is not fully explicit.

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

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

With no annotations, the description carries the behavioral burden and does so well: it reveals that the tool may attach to an existing session or create a new Appium session, a side-effectful action. It stops short of describing failure modes or what happens when create_if_needed=false and no session exists.

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 compact and scannable: one intro sentence, three behavior bullets, and an Args list. No filler, and the most important branching logic is front-loaded.

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?

The tool is a moderately complex connection helper with three optional parameters and an output schema to describe the return value. The description covers the main behavior and parameter semantics, but omits the no-session/no-create edge case and error conditions.

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 Args section is the only source of parameter meaning. It clearly explains appium_url, session_id, and create_if_needed, though it leaves the create_if_needed=false/no-active-session case implicit.

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 opens with a specific action and resource: 'Se connecte à un serveur Appium'. The conditional bullets (attach to provided session, find active, create if needed) make the tool's role unmistakable and distinguish it from siblings like get_page_source, tap_element, or close_session.

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 gives clear selection context: it is the session setup operation, and it states the branches for session_id, active-session discovery, and create_if_needed. It does not explicitly mention when not to use it or name alternative connection tools, but among the sibling set it is the only connection entry point.

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

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 does not state whether the operation is read-only, what happens when no elements match, whether it waits for elements, or how results are returned. The strategy details are useful but do not cover these behavioral traits.

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 compact and structured with an Args block. It front-loads the purpose, then gives parameter examples and allowed values without unnecessary prose. Every line adds 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?

Given the tool's moderate complexity and the presence of an output schema, the description covers locator syntax and strategy values well. However, it omits important context such as session requirements, error behavior, and what 'find' returns when multiple elements match. These gaps leave the agent with some uncertainty for correct invocation.

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%, and the description fully compensates with rich parameter documentation. It provides concrete examples for the locator parameter and explains the strategy options including 'auto', 'text_search', and explicit strategies, adding meaning far beyond the bare schema.

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 the tool searches for elements in the application, which is a specific verb-resource pair. It does not explicitly differentiate from siblings like get_element_info or suggest_locators, but the name and description make the primary purpose clear.

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?

No guidance is given on when to use find_elements versus sibling tools, nor any prerequisites or exclusions. The description only explains how to construct locators and strategy options, which is parameter guidance rather than usage guidance.

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

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

No annotations are provided, so the description carries the behavioral burden. The verb 'Récupère' implies a read-only operation and the listed outputs clarify what the agent can expect, but the description does not mention side effects, session requirements, or failure behavior, which would add transparency.

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 brief, front-loaded with the tool's primary purpose, and every sentence adds useful information. The parameter explanation is compact and directly tied to the only input.

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 single-parameter read tool with an output schema, the description provides enough about inputs and purpose. It lacks explicit prerequisite context such as requiring an active session, but the sibling connect_to_session helps fill that gap.

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?

The schema only provides a 'locator' string with no description, so the description meaningfully compensates by explaining the locator can be XPath, accessibility_id, id, etc. This is useful guidance beyond the raw schema.

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 uses a specific verb ('Récupère') and resource ('toutes les informations d'un élément'), and enumerates concrete data categories such as text, position, size, attributes, visibility, and clickability. This clearly distinguishes it from sibling tools like find_elements or tap_element.

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 implied: an agent should call this when it needs detailed information about an already-located element. However, the description does not explicitly state when not to use it or name alternatives such as find_elements or get_page_source for different needs.

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

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 explains the tool returns an XML tree and details the effect of the 'simplified' parameter (full vs. reduced attributes). However, it does not mention potential side effects, error conditions, or performance implications. For a read-only retrieval tool, the core behavior is transparent, though edge cases are unaddressed.

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 concise: two sentences for purpose plus a clear arg explanation. It is front-loaded with the core purpose and the parameter description is directly attached. No filler or redundant content; every sentence earns its place.

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?

Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description is largely complete for calling the tool correctly. It covers the purpose and the parameter effect. It omits any prerequisites like an active session, but given sibling tools like connect_to_session, this may be assumed. The description is adequate, though it could explicitly note that a session must be active.

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?

The schema provides no description for the 'simplified' parameter (coverage 0%), but the description fully explains its meaning and the difference between True and False, listing the included attributes. This completely compensates for the schema gap, giving the agent exact semantic information needed to use the parameter correctly.

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 states the tool retrieves the XML tree of the current screen, using a concrete analogy ('équivalent du DOM') that distinguishes it from siblings like find_elements or get_element_info. The verb 'Récupère' plus the resource 'arbre XML de l'écran actuel' is specific and unambiguous.

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 does not explicitly state when to use this tool versus alternatives, such as find_elements for targeted queries. The DOM analogy implies it is for getting the full structure, but no direct guidance is given about when to prefer it or when to avoid it. The usage context is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. The verb 'Retourne' implies a read-only operation, and 'session en cours' suggests an active session is required, but it does not explicitly state that there are no side effects or what happens if no session exists. Basic behavioral context is present but not deeply disclosed.

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 a single, short sentence that immediately states the tool's action and provides illustrative examples. It is concise, front-loaded, and contains no filler.

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?

This is a simple tool with no parameters and an output schema, so the description does not need to explain return formats or parameters. It sufficiently states what the tool returns and implies the active-session context. It could be more explicit about the precondition of an active session, but overall it is complete for the tool's complexity.

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?

The tool has zero parameters and the schema reflects that, so there are no parameter semantics to document. The description does not need to add anything about parameters. Baseline of 4 for 0-parameter tools 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 clearly states the tool 'Retourne les informations de la session Appium en cours' and lists examples (platform, capabilities, screen size). This makes the specific resource and action clear, and it is distinct from sibling tools like get_page_source or get_element_info.

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 gives no guidance on when to use this tool versus alternatives. It does not mention comparisons, prerequisites, or exclusions. An agent must infer from the tool name and examples that this is for retrieving session details.

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

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

With no annotations, the description carries the full burden for behavioral disclosure, but it only specifies the platform. It does not disclose effects on navigation state, failure conditions such as no previous screen, or whether an active session is required.

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?

A single sentence with no filler; the core action is front-loaded and the platform qualifier is parenthetical. It is appropriately concise for the tool's simplicity.

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 zero-parameter action with an output schema, the description is minimally viable, but it omits practical context such as when to invoke it or how it interacts with the current session. The gaps in usage and behavioral context prevent it from being fully complete.

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?

The tool takes no parameters, so the schema already covers the parameter surface completely. The description has no parameter details to add, making the zero-parameter baseline appropriate.

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 ('Appuie') and resource ('le bouton retour') and scopes the action to Android/Windows. This clearly distinguishes go_back from siblings like tap_element or screenshot, even without schema inspection.

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?

No guidance is given for when to use this tool versus alternatives, and no exclusions or prerequisites are mentioned. The name and imperative phrasing imply a back-navigation action, but the agent is not explicitly told when this is the right choice among the sibling tools.

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

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

No annotations are provided, so the description carries the full burden of disclosure. It does add one meaningful behavioral trait beyond the obvious action: a copy is written to the system's temporary directory, which is a genuine side effect an agent should know. However, it does not disclose other relevant behaviors such as whether an active session is required or what image format is returned.

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 primary action is front-loaded, and the secondary side effect (temp file write) follows naturally. Every sentence earns its place.

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 zero-parameter tool with no output schema, the description is largely complete: it states what happens and the side effect. Minor gaps remain, such as the return format of the image and whether a session must be active, but these are modest for such a simple operation.

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?

The tool takes zero parameters and schema description coverage is 100%, so there is nothing for the description to explain. Per the rubric, 0 parameters sets a baseline of 4, and the description correctly adds no redundant parameter information.

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 ('Prend une capture' / takes a screenshot), a clear resource (the current screen), and the result (returned for analysis). Among the sibling tools (connect_to_session, get_page_source, type_text, find_elements, etc.), none perform screen capture, so the purpose is unmistakable and naturally differentiated.

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?

No guidance is given about when to use this tool versus alternatives. In particular, the distinction between get_page_source (DOM structure) and screenshot (visual rendering) is not mentioned, nor is any when-not-to-use condition stated. The reader must infer the use case entirely from the tool name.

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

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

No annotations are provided, so the description carries the full burden. It discloses that results are ranked by stability and that matching is by text/description. However, it does not mention prerequisites like an active session, behavior when no match is found, or whether the operation has side effects.

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 concise and front-loaded, with every sentence serving a purpose: the core operation, the use case, and the argument description. No redundant content.

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?

The output schema exists, so return values are covered. However, the description omits important context such as whether a session must already be connected and how edge cases (no match, multiple matches) are handled. For a one-parameter tool this is a moderate gap.

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?

With 0% schema description coverage, the description fully compensates by explaining text_or_description as 'Texte visible, label, ou description de l'élément.' This adds meaningful semantics beyond the bare property title in the schema.

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 states it searches an element by text/description and suggests the best Robot Framework locators, ranked from most to least stable. This is a specific verb+resource distinction and is unique among siblings like find_elements, which actually finds elements rather than suggesting locators.

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?

Provides an explicit use case: 'quel locator utiliser pour le bouton Valider ?' which directly tells an agent when to use this tool. It does not explicitly contrast with alternatives like find_elements, but the guidance is clear enough to route selection.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that verify compares the screen before and after and reports taps without effect, at the cost of two page-source reads. It does not cover failure behavior, but the performance caveat is valuable context beyond the raw operation.

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 short, front-loaded with the action, and structured into a clear action line plus an Args section. Every sentence earns its place, including the cost note on verify.

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?

Given the tool's simplicity and the presence of an output schema, the core requirements are covered: the action, the parameters, and the verify side-effect are all described. Minor gaps remain, such as locator syntax and explicit usage conditions, but nothing blocks a competent agent from invoking 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%, and the description compensates by explaining both parameters: locator is the element to click, and verify is defined with its behavioral effect and cost. It stops short of specifying locator syntax formats, but it adds real meaning beyond the parameter names.

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 opens with a precise action verb ('Tap ou clic') and identifies the target resource ('un élément de l'application'), clearly distinguishing it from sibling tools like type_text or go_back. The operation is unambiguous and immediately usable.

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?

There is no guidance on when to use this tool versus an alternative such as type_text, get_element_info, or find_elements. The description explains what the tool does but not the conditions that should lead an agent to select it.

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

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

Annotations are absent, so the description must carry the burden of behavior. It only says text is typed; it does not disclose whether text replaces or appends, whether the element must be visible or focused, whether a session is required, or what side effects occur. No contradictions, but minimal disclosure.

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 short, front-loaded with the purpose, and uses an Args block to label parameters. There is no filler or redundant information; every sentence contributes.

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 tool with no annotations and a mutating side effect, the description is thin. It does not state session requirements, element readiness, or locator syntax, and the output schema does not cover behavioral preconditions. An agent has enough to guess the call shape but not to avoid common errors.

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?

The description adds a terse semantic gloss for both parameters ('locator of the input field', 'text to enter'), which is some compensation for 0% schema coverage. However, it omits the locator format or strategy (e.g., CSS selector, XPath) and any text encoding or escaping details, so the parameters remain under-specified.

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 the action explicitly: 'Saisit du texte dans un champ de l'application' (types text into an application field). It is specific about the resource and distinguishes it from siblings such as tap_element, though it does not explicitly name alternatives or non-goals.

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?

There is no guidance about when to choose this tool over siblings, nor any mention of prerequisites or exclusions. The only usage signal is the action itself, leaving the agent to infer when typing text is appropriate. This is essentially no usage guidance beyond the tool name.

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