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?

Annotations only declare destructiveHint=false; the description adds real behavioral context beyond that – the transcript is copied 'WITHOUT deleting them anywhere', the destination is encrypted, and the browser-extension sign-in requirement is stated. It still doesn't say whether copying is idempotent or what happens on re-copy, so not a 5.

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 compact sentences with the copy-vs-delete distinction front-loaded and the prerequisite placed last. Slightly dense, but 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?

No output schema exists, so the description does need to orient the agent; it covers purpose, non-destructive behavior, destination, prerequisite, and where the result is consumed. It could be more explicit about sibling selection, but it is sufficient for a 2-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 coverage is 100%, so both parameters (site enum, chat_id with default 'locked') are already documented, which sets the baseline at 3. The description's note about chat_id='locked' mostly restates the schema rather than adding new syntax or constraints.

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 ('Saves the full transcript of ChatGPT or Claude chats into the encrypted AppLock vault') and immediately distinguishes the operation from destructive siblings by asserting it copies rather than deletes. An agent can tell it apart from hide_session/hide_browser_chat without opening another 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 the operative condition ('Use chat_id "locked" for every locked ChatGPT/Claude chat') and a hard prerequisite ('Needs the browser extension with that site signed in'), plus a downstream use case pointing to read_hidden. It stops short of explicitly contrasting when to pick this over a hide/restore sibling, which keeps it at 4.

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 visible effect (removed from sidebar, lock screen on open), the unlock path (Touch ID or password), and the reversibility implied by 'until unlocked'. It omits any statement about required permissions, failure modes, or what happens if the chat_id is stale.

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 sentences, front-loaded with the effect and followed by the one usage hint. No filler, no restating of the title.

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 mutation tool with no annotations and no output schema, the description covers the effect, the unlock mechanism, and the special chat_id value, which is most of what an agent needs. Missing only permission/auth requirements and error behavior if the extension is absent or the chat is unknown.

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%, so the baseline is 3, but the description adds genuine meaning by explaining that "current" refers to the chat open in the browser, which the schema only mentions as a literal value. It still leaves the `everywhere` ChatGPT archival flag entirely to 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 gives a concrete verb-plus-resource ('lock a web chat' via the AppLock browser extension) and names the target surfaces (ChatGPT/Claude/Gemini web chats), which separates it from sibling tools like hide_on_phone or hide_session. It stops short of explicitly naming the sibling it is not, so an agent must infer the browser-vs-other-platform boundary.

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 piece of usage guidance — use chat_id "current" for the chat open in the browser — but never states when to pick this tool over hide_session, hide_on_phone, or list_hidden, nor any exclusion or prerequisite. Usage is implied rather than declared.

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 cover idempotency and non-destructiveness; the description adds real behavioral context: chats are archived in the ChatGPT account, remain visible under Archived chats, unarchive when the lock is removed in the browser, and the feature is unavailable for Claude/Gemini. The extension prerequisite is also disclosed. It stops short of stating what the call returns or any failure modes.

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?

Four compact sentences, front-loaded with the action and its effect, followed by the unarchive rule, platform limitation, and prerequisite. Every sentence carries information; the density is high but not 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 2-parameter, no-output-schema toggle, the definition covers effect, side effects, platform limits, and the extension requirement, which is enough for an agent to call it correctly. Only a note on return/reporting behavior 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 50%: 'on' has no description, while 'apply_to_locked' is documented in the schema itself. The description's 'on or off' and 'locked chats are also archived' clarifies the on/apply behavior somewhat, but adds no syntax or default semantics beyond the schema. Baseline 3 fits.

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 concrete verb and setting (turns AppLock's 'Hide on your phone too' on/off) plus the concrete effect: ChatGPT chats get archived and vanish from the chat list. It is specific about scope (ChatGPT only, Claude/Gemini have no archive) but never contrasts itself with close siblings like hide_session or hide_browser_chat.

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 through the behavioral explanation (turn on to archive locked chats, lock removal unarchives), and the prerequisite 'Needs the AppLock browser extension' is stated. However, there is no explicit when-to-use-this-vs-alternatives guidance against the many hide_*/lock_* siblings, leaving routing to inference.

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?

readOnlyHint=true declares the tool does not modify its environment, but the description explicitly describes a state change ('unlocks hidden chats for a few minutes'). The description also adds genuinely useful behavior (auth happens on the user's device, up to 2-minute wait), but it directly contradicts the annotation's read-only claim, so the contradiction rule applies.

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?

Four short sentences, each front-loaded with an actionable fact: effect and duration, then authentication channel, then the security constraint, then the timeout. Nothing is padded or redundant.

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, no-output-schema tool, the description covers the observable outcome, the authentication channel, the security constraint, and the wait bound. The one thing it leaves ambiguous is how the agent should behave if the unlock times out or fails, but that is a minor 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 coverage is 100% with a documented enum and default, so the schema already carries the parameter meaning. The description adds indirect value by describing what the auth flow does (Touch ID prompt vs. browser passphrase page), but it never names or explains the 'method' parameter or the 'link' option, so it does not meaningfully exceed 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 (unlocks hidden chats) plus the scope of the effect ('for a few minutes'), which is the key differentiator from lock_vault and from read_hidden/list_hidden. An agent can tell immediately what this tool does 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 operational context: it triggers a Touch ID prompt on the user's Mac or a local browser page, the user authenticates on their own device, and the agent must never ask for the passphrase in chat. That covers when/how to use it, though it does not explicitly contrast itself with sibling tools like applock_status or read_hidden.

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