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

readOnlyHint=true already tells the agent this is a safe, non-mutating call, so the description earns credit for going further by enumerating the specific state fields the caller will learn (setup, lock state, hidden count, extension connection). It does not discuss permissions, caching, or refresh behavior, so it falls short of full 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?

A single front-loaded sentence that lists the returned state facts with no filler or redundancy. Every clause 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?

With no output schema, the description must convey what the call returns, and it does so completely: setup status, locked/unlocked, hidden chat count, and extension connectivity. For a zero-parameter read tool, nothing an agent needs to invoke or interpret it correctly is missing.

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, which is the baseline-4 case; there is nothing to misinterpret, and the description correctly implies the call is parameterless by framing it as a global status query.

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 read verb ('Shows whether') and the exact resource and facts reported: setup state, locked/unlocked, hidden chat count, and browser-extension connectivity. This is clearly separable from siblings like hide_session, unlock_vault, or list_hidden, which mutate or enumerate sessions rather than report AppLock state.

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 status-check use case (e.g., before locking/unlocking) but never says when to call it versus alternatives such as list_hidden or unlock_vault, nor any prerequisites. Usage is inferable from the intent but not spelled out.

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 and does well: it discloses the post-condition (chat is removed from the sidebar), what a user sees on access (lock screen), and the reversal path (Touch ID or password). It stops short of stating whether hiding itself requires authentication, whether it is idempotent, or any error behavior when the chat_id is unknown.

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 tight sentences with no filler; the effect of the operation is front-loaded before the parameter hint. Every clause 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 2-parameter tool with no annotations and no output schema, the description covers what happens and how to reverse it, which is what an agent mainly needs. It lacks prerequisite/auth context and any pointer to the unlock/restore siblings, leaving a small but real 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, including the 'current' sentinel and the ambiguity rule for 'site'. The description restates the 'current' usage but adds no new format, conflict, or edge-case semantics beyond the schema, so the baseline of 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?

The description states a specific verb and resource (lock a web chat) plus the mechanism ('tells the AppLock browser extension') and the visible effect (disappears from sidebar, lock screen). It is clear what the tool does, though it never explicitly contrasts with the similarly-named sibling hide_session, so sibling differentiation is left to inference.

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 one concrete invocation hint — use chat_id "current" for the open chat — which is actionable. However, it never says when to prefer this over hide_session, nor any prerequisites (e.g., vault/password configured, chat must exist in list_browser_chats) or 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?

Annotations only provide idempotentHint=false and destructiveHint=false; the description adds substantial context by explaining the session is encrypted into the vault, removed from history, and functions while locked. The deferred hide of 'current' until the session ends is a non-obvious behavioral trait that is well 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?

Three tight sentences with the core operation front-loaded, followed by the locked-state capability and the 'current' special case. Every sentence carries distinct information with no redundancy.

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 single required parameter, full schema coverage, and absence of an output schema, the description covers the operation, the special id value, and the timing edge case. It does not mention restorability, but that is handled by a sibling tool, leaving the definition essentially 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?

Schema coverage is 100% and the schema already documents the id format, so the baseline is 3. The description adds meaning by clarifying that id='current' targets the running session and describing the deferred hiding behavior, going modestly beyond 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?

States a specific verb and resource ('Encrypts a ... session into the vault and removes it from the app's history'), which distinguishes it clearly from sibling hide_browser_chat and the list/restore tools. An agent immediately understands this is a session-level hide-and-encrypt operation.

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 clear context on when to pass id='current' and notes it works while locked, which is useful for invocation timing. It does not explicitly state when-not to use it or name restore_hidden as the inverse, so it falls short of full alternative routing.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds genuine context beyond the annotation: the data originates from the AppLock extension's view of the browser sidebar, and the result includes the currently-open chat. No contradiction, but nothing about freshness, sync timing, or what happens when the extension is absent.

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 tight sentences, front-loaded with what is listed and where it comes from. The final clause about the open chat earns its place by disclosing an extra payload field, though phrasing is slightly casual.

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?

A simple read-only, zero-required-param tool with full schema coverage and no output schema. The description adequately conveys the data source and the notable extra field (currently open chat), so an agent can call it correctly; only the filtering behavior is left implicit.

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 there is a single optional 'query' param documented as 'Filter by title text'. The description never mentions filtering, so it adds no meaning beyond the schema; 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 (lists) and resource (browser chats) and names the concrete sources: ChatGPT, Claude.ai and Gemini sidebars as reported by the AppLock extension. It also distinguishes the payload by noting it includes which chat is currently open. It stops short of explicitly contrasting with nearby siblings like list_sessions or list_hidden, but the resource is 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?

There is no when-to-use guidance, no prerequisites, and no mention of when to prefer list_sessions, list_hidden, or hide_browser_chat instead. The agent must infer usage purely from the resource description.

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?

readOnlyHint=true already establishes this as a safe read, so the description carries a lower bar. It usefully adds the vault-unlock precondition, but discloses nothing about pagination, result ordering, or what happens on a locked vault beyond the requirement, so the added behavioral context is thin.

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, front-loaded with the action and followed by the prerequisite; nothing is wasted. It is not quite a 5 because the returned-field parenthetical is only loosely tied to the stated purpose.

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?

With zero parameters and no output schema, the description's burden is light and it covers the core action plus unlock prerequisite. It still omits how results relate to or differ from the other list_* and read_hidden siblings, and says nothing about result volume or pagination, leaving an agent to guess in a crowded sibling set.

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 there is nothing for the description to disambiguate; baseline is 4. The parenthetical field list is a small bonus that hints at output shape despite no output schema being present.

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 ('Lists everything in the vault') and names the returned fields (titles, sources, dates), which is enough for an agent to recognize a bulk read of hidden items. It does not distinguish itself from close siblings like read_hidden or list_sessions, and 'everything in the vault' is slightly broader than the name 'list_hidden', leaving a small ambiguity.

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 one precondition, 'Requires the vault to be unlocked', which is actionable guidance. However, it says nothing about when to choose this over read_hidden (single item) or list_sessions/list_browser_chats, so the agent must infer the selection criteria.

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 already declare readOnlyHint=true, so the safety profile is covered. The description adds behavioral detail beyond the annotations: the result ordering (newest first) and the visibility filter that excludes hidden sessions. It still omits return shape/pagination behavior, but for a simple read-only list this is a modest gap.

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 that front-loads the resource and scope, then the ordering, then the reason to call it. No redundant or filler 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?

With no output schema and only three simple optional parameters, the description covers what an agent needs to select and call the tool. Minor omissions (how many results return by default / pagination behavior) prevent a 5.

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 67%, with the query and source params documented in the schema and limit left undocumented there. The description adds no parameter-level meaning (nothing about limit, query, or source semantics), so it neither compensates for the gap nor exceeds the baseline.

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 (lists chat sessions), scopes it precisely (local Claude Code and Antigravity sessions that are currently visible, not hidden), and names the ordering (newest first). It implicitly distinguishes itself from the sibling list_hidden by specifying 'visible (not hidden)' and from hide_session by stating its goal ('find the one to hide').

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 trailing clause 'so you can find the one to hide' gives clear context for when the tool is used — as a discovery step before hide_session. It doesn't explicitly name siblings or state when-not to use it (e.g., use list_hidden for hidden sessions), so it falls short of full routing 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 annotations covering safety (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description still adds real value: it discloses that the key is 'forgotten immediately' and that web chats in the browser extension are re-locked, i.e., the session state the caller loses. It does not mention re-unlock requirements or rate limits, but coverage is solid.

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 tight sentence with zero filler; the consequence (key forgotten) is front-loaded ahead of the secondary effect (re-locking chats). Nothing is wasted.

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, no-output-schema tool with annotations already declaring the safety profile, the description supplies the missing behavioral context of what state is lost. Only the absence of any when-to-use steering keeps 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 zero parameters, so per the baseline there is nothing for the description to disambiguate; schema coverage is 100% and the empty object schema is self-explanatory. No meaningful gap exists here.

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 action (lock the vault) plus its concrete effects: the vault key is forgotten and browser-extension web chats are re-locked. An agent can distinguish this from unlock_vault by the word 're-locks', though no sibling is named outright.

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 explains what happens but never says when to call this versus alternatives like hide_session, applock_status, or unlock_vault. The only usage signal is the tautological title 'Lock the vault now', which offers no conditional guidance or exclusions.

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 only declare readOnlyHint, so the description carries the rest and does so well: it discloses an auth prerequisite ('Requires unlock') and a non-obvious side effect ('the text becomes part of the current, visible conversation'), which is exactly the kind of privacy consequence structured fields will not convey. It does not merely restate readOnlyHint.

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, front-loaded with the action and its scope, then prerequisite, then the warning. No filler; every clause carries information.

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 2-param read tool with no output schema and only a readOnlyHint annotation, the description covers return content, prerequisite, and side effect. The only gap is the undocumented max_chars parameter, which leaves truncation behavior unclear.

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 50%: 'id' is documented in the schema (including the 6+ char prefix hint), but 'max_chars' has no description anywhere. The description adds no parameter-level meaning, so it fails to compensate for the undocumented truncation parameter.

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 (returns the transcript of a hidden local session) plus the scope qualifier 'without restoring it', which directly distinguishes it from the sibling restore_hidden. An agent can tell what this does and what it does not do without opening the schema.

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?

'Without restoring it' implicitly routes the agent here when the session should stay hidden, in contrast to restore_hidden. The prerequisite 'Requires unlock' is stated, but the alternative (restore_hidden) is not named explicitly, so it stops just short of full when/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 must carry the behavioral load. It does disclose the effect ('shows up in the app again'), the decryption step, the unlock prerequisite, and the dual target contexts (app session vs. extension web chat). It does not say what happens if the id is not hidden, whether the operation is reversible, or how failures surface.

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 covering the effect plus a two-word prerequisite sentence. No redundancy, no filler, and the core action leads.

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 mutation with no annotations and no output schema, the description covers effect, prerequisite, and the app/extension distinction. It is slightly thin on edge cases (unhiding a non-hidden id, error behavior), but nothing essential is missing.

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 100% and the single 'id' parameter is fully documented in the schema (vault id or original session id), so the description need not repeat it. Baseline 3 applies when the schema does the heavy lifting and the description adds no parameter detail.

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 gives a specific verb and resource - it decrypts a hidden session back into the app's normal listing - which is clearly the inverse of hide_session and distinct from read_hidden/list_hidden. It never names a sibling explicitly, but the operation is 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?

It states the prerequisite ('Requires unlock'), which is useful context, but gives no explicit when-to-use vs. alternatives (e.g. when to restore vs. simply read a hidden chat). Usage is implied by the name rather than spelled out.

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 only declare readOnlyHint=true, so the description carries the real behavioral burden and does so well: it discloses where the auth prompt appears (Mac Touch ID prompt or local browser page), that the unlock is temporary, that the agent should never request the passphrase, and the 2-minute wait window. This is exactly the extra context annotations cannot provide.

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, front-loaded with the core action, followed by the authentication mechanism and the waiting constraint. No filler; every sentence carries distinct information.

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?

With no output schema, the description adequately covers the action, the auth flow, the security constraint, and the timeout. It does not say what the agent should do if authentication fails or times out, a minor gap for a single-optional-parameter tool.

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 'method' parameter already documents its enum and the meaning of 'auto'. The description alludes to Touch ID and passphrase flows but adds no syntax or selection guidance beyond the schema, 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 and resource ('Unlocks hidden chats') plus a temporal scope ('for a few minutes'), which cleanly separates it from siblings like lock_vault, list_hidden, and applock_status. An agent can identify the operation without opening the schema.

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?

Gives clear procedural context: the user authenticates on their own device and the agent must never ask for the passphrase in chat. It does not explicitly state when to prefer this over checking applock_status first or how it relates to lock_vault, so it stops short of full when/when-not guidance.

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