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

With no annotations at all, the description carries the full behavioral burden and does not meet it. It conveys that the action is scoped to the current page and depends on prior read state, but says nothing about whether a click navigates or mutates page state, whether the element numbering survives, whether a re-read is needed afterward, or how an invalid element number fails.

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?

One compact sentence with the action front-loaded and zero filler. It is efficient, though its brevity is close to under-specification for a stateful browser automation step.

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 one-parameter action tool with no output schema, the minimum is present, but the agent is left guessing about post-click state: whether the page changed and whether lichess_read must be called again before the next click. Given that this is an interactive browser tool where those questions determine the next call, the description is adequate but incomplete.

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 100%, and the single parameter is already documented as 'Element number from the last read.' The description adds no meaning beyond that — no range behavior, no note on numbering lifetime — so the baseline 3 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?

States a specific verb ('Click') and a specific resource ('a numbered element on the current Lichess page'), which is enough to distinguish it from lichess_type and lichess_open by implication. However, it never names or contrasts those siblings explicitly, so the differentiation is inferred rather than stated.

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 implies a usage sequence by requiring an element 'on the current Lichess page', and the schema reinforces this with 'Element number from the last read' — so an agent can deduce lichess_read must run first. There is no explicit statement of that precondition, no when-not guidance, and no guidance on what to do when the element number is stale.

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 supplied, so the description carries the full disclosure burden. It does add genuine behavioral context by explaining the consequence of not calling it (credits keep running), which is valuable and non-obvious. However, it says nothing about whether unsaved session state is lost, whether the call errors when no session exists, or whether it is idempotent — meaningful gaps for a teardown 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?

A single sentence with the action front-loaded and the motivation appended. Every clause earns its place: the verb, the target, the timing, and the cost rationale.

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 teardown tool with no output schema, the description covers the essential question of when and why to call it. The remaining gap — error behavior when no session is active and whether state is discarded — is minor but real for a lifecycle-ending 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, so there is nothing for the description to disambiguate and the baseline of 4 applies. The absence of parameters is consistent with a simple session teardown.

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?

States a specific verb and resource: 'Close the Lichess browser session.' This is clearly distinguishable from the sibling tools (lichess_open, lichess_read, lichess_click, lichess_type), which all operate on a live session rather than tearing it down. It stops short of naming a sibling explicitly, so it lands just under the top mark.

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?

'when the work is done' gives a clear trigger condition for calling it, and the implicit pairing with lichess_open makes the lifecycle obvious. It does not state what to do if a session was never opened or whether closing mid-task is acceptable, so it falls short of explicit when-not 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?

With no annotations, the description carries the full behavioral burden. It does disclose that the tool returns screen guidance and a sign-in link, implying a read-only informational response, but it never says so explicitly, nor does it describe response shape, length, or whether the guide is static. Adequate but thin for an annotation-free tool.

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 clauses with the key instruction ('Call this first') front-loaded at the end where it reads as a directive. The parenthetical example is useful, though the sentence packs three distinct ideas (screens, sign-in link, first-call) somewhat densely.

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 one-optional-parameter guide tool with no output schema, the description covers what it returns (screens, sign-in link) and when to invoke it, which is enough for an agent to call it correctly. Missing only a hint about what the caller should do with the returned guidance.

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 100%, so the single 'task' parameter is already documented as 'What you want done in Lichess, in your words.' The description adds no syntax, examples, or constraints for it. Baseline 3 applies since the schema does the work.

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?

States a specific resource: a how-to guide covering Lichess screens, sign-in link, and the two named workflows (accepting team join requests, messaging a team). This clearly distinguishes it from the lichess_open/click/type/read action siblings, which operate the UI rather than explain it. It falls short of a 5 only because 'How to work in Lichess' is slightly fuzzy framing for what is essentially a help/orientation tool.

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?

'Call this first' gives explicit sequencing guidance relative to the sibling action tools, which is exactly the routing signal an agent needs. It does not state any when-not-to-use condition (e.g., whether to re-call it once already oriented), so it stops short of full coverage.

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 behavioral burden. It usefully discloses that the browser is signed-in and authenticated and that the URL defaults, but it omits what happens if a page is already open (navigate vs. new tab), whether existing page state is replaced, and what the call returns (snapshot, handle, or nothing).

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?

One well-formed sentence that front-loads the core action and follows with the concrete use cases. The phrasing 'to work with accept team join requests' is slightly awkward and could be tightened, but nothing is superfluous.

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 one-parameter browser-opening tool with no output schema and no annotations, the definition covers the basics but leaves important gaps: return value, behavior on repeated invocation, and whether the opened page persists for sibling tools to act on.

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 100% for the single optional url parameter and the description only repeats the default already documented in the schema. Baseline 3 applies since no additional meaning, such as accepted URL forms or path-only values, is added.

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?

States a specific verb and resource ('Open a Lichess page') plus the session context ('signed-in Cloud Browser') and default URL, which separates it from the read/click/type siblings that act on an already-open page. It never names those siblings explicitly, so differentiation is implied rather than stated.

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 hints at usage through the listed tasks (accepting team join requests, messaging a team), which implies this is the entry step before lichess_read/lichess_click/lichess_type. However, it gives no explicit when-to-use rule, no statement that a page must be opened before other tools work, and no when-not conditions.

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 zero annotations the description carries the full behavioral burden. It does establish the read-only nature implicitly ('Read') and reveals the return shape — text plus numbered buttons, links and fields — but says nothing about whether reading mutates or scrolls anything, whether the numbering is stable across calls, or whether a page must be open first.

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?

One front-loaded sentence with no filler; the verb and object come first and the content list follows as a colon clause. It is efficient, though slightly compressed given the behavioral gaps.

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 simple (one optional param, no output schema, no annotations), so a short description is defensible. However, without annotations or an output schema, the description should explain how the numbered elements tie into the click/type siblings and whether a page must be opened first — a meaningful gap for a browser-inspection primitive.

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 single optional parameter 'element' has full schema description coverage ('Read only inside this element'), so the schema does the work. The description mentions reading 'the current Lichess page' in general and never addresses the scoping parameter, adding no semantics beyond the schema. Baseline 3 applies for 100% coverage.

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 ('Read') and resource ('the current Lichess page') and enumerates what comes back: text, numbered buttons, links and fields. That cleanly separates it from action-oriented siblings like lichess_click, lichess_type, and lichess_open, though no sibling is named explicitly.

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 no when-to-use guidance and no alternatives. It never says to call this first to discover the numbered elements that lichess_click/lichess_type presumably need, nor how it relates to lichess_status or lichess_guide, so the agent must infer the read-then-act workflow.

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 the three things inspected but says nothing about side effects (whether checking the Lichess connection initiates anything), cost, rate limits, or what the result looks like; for a no-output-schema tool, that leaves the agent guessing at the response shape.

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?

One front-loaded sentence with no waste; the enumerated facets (account, credits, connection) are compact and scannable. "Cotlet.dev account" is slightly ambiguous about whether it is the same as the authenticated user, but nothing is padded.

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 trivial zero-parameter status tool, the description covers what is checked but omits the return shape and any note that no annotations exist to convey safety. An agent knows what the tool inspects but not what it will get back or how to act on failure states.

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, so there is no parameter meaning to convey and the baseline of 4 applies. The description introduces no phantom inputs.

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 pairs a specific verb ("Check") with concrete resources: the Cotlet.dev account, credits, and the Lichess connection. That is enough to separate it from the sibling tools, which are all interaction commands (open, close, read, click, type), though it never says so explicitly.

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?

Readiness/status checking implies it should run before or when other Lichess actions fail, but the description never states that, nor does it name any alternative or prerequisite. Usage is inferable from the word "ready" rather than stated.

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 behavioral burden and falls short: it does not say whether typing replaces or appends to existing text, whether focus is required first, whether it triggers submission, or what happens if the field number is stale. Only the fact that the target is on the 'current' page is 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?

A single well-formed sentence with the action and target front-loaded and no redundant wording. It is efficient, though its brevity is part of why behavioral detail is missing.

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 two-parameter tool with fully documented schema and no output schema, the description covers the essentials. It omits what state results after typing (whether a re-read is needed to get updated field numbers), which is the main practical 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?

Schema description coverage is 100%, so both parameters are already documented ('Text to type', 'Field number from the last read'). The description adds no format, length, or escaping guidance beyond the schema, so baseline 3 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?

States a specific verb (type) and target (a numbered field on the current Lichess page), which is clearly distinct from siblings like lichess_read and lichess_click. It does not explicitly name those siblings, so differentiation is inferable rather than stated.

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 phrase 'numbered field' plus the schema's 'Field number from the last read' implies a read-then-type workflow, but there is no explicit statement of when to use this versus lichess_click or lichess_read, and no prerequisites such as a page needing to be open.

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