Skip to main content
Glama
Harmantaj

AppLock

by Harmantaj

List web chats seen by the extension

list_browser_chats
Read-only

Lists ChatGPT, Claude.ai, and Gemini chats from your browser sidebar and shows which one is open. Filter by title to find a specific chat.

Instructions

Lists ChatGPT, Claude.ai and Gemini chats visible in the sidebar of the user's browser, as reported by the AppLock extension. Also says which chat is open right now.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoFilter by title text

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.2/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.