Answer with the live web: compose live parts of real pages into a Workspace in the Banquish Mac app.
Scored across 19 tools
Most tools have clearly distinct resource-and-action scopes: page inspection (open_page/expand/find/reveal/screenshot), Panel CRUD, Note CRUD, layout, and workspace lifecycle are separated. A few boundaries require careful reading, especially add_panel versus update_panel when re-proposing content, and expand/find/reveal all explore an open page, so the set is not perfectly unambiguous.
The set uses lower snake_case throughout, and the CRUD tools follow a readable verb_noun pattern (add_note, update_panel, remove_panel, create_workspace). However, several tools are bare verbs with implied objects (arrange, expand, find, reveal) and two image-related tools break the pattern as nouns/noun phrases (screenshot, workspace_image), making conventions mixed rather than fully predictable.
At 19 tools the surface is slightly heavy, but the complexity of the domain—workspace creation, page inspection, Panel/Note editing, layout, and image output—justifies most tools. Each major workflow has dedicated operations without obvious filler, though the total sits above the ideal compact range.
Core workflows are well covered: create/list/read/rename workspaces, open and inspect pages, add/update/remove Panels and Notes, arrange Tiles, read content, and finish work. The main gap is workspace lifecycle beyond rename—there is no delete or archive operation for Workspaces, and no direct way to edit a Workspace's prompt—but agents can otherwise complete the intended tasks.
Add a Note to a Workspace: a few words of your own beside its Panels. Formatted text only, shown in Banquish's own style: "# Heading" (or "## Smaller heading"), paragraphs, "- " or "1. " list items, and links; anything else, HTML included, shows as the text it is. No bold or italic: write plain words (** is dropped). At most 2000 characters. Placement is where its Tile goes on the grid, as in arrange; without one it goes full width below the last Tile. With h, a Note's Tile is that tall, even taller than its text. The user can undo it with the rest of your Working stretch. Returns the Fit report: at the user's window, which Tiles are scaled below their Panel's minimum width, scroll inside, fell back to crop, are broken or ambiguous, or leave their Tile's width unused, and any gaps between Tiles; and, not as an issue, which Panels are shorter than the h of their Tile, so show centred in it. A Tile whose page hasn't laid it out at its width yet (one not on screen, say) is settling: a later report says how it fits. While a settling Tile's minimum width isn't known, whether the Workspace shows as one column isn't either: oneColumn is left out, and the summary says so.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| placement | No | ||
| workspace | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds substantial context on top: a 2000-character cap, undo scope tied to the Working stretch, exact default placement, and the meaning of h overriding text height. It also discloses a non-obvious edge case — a settling Tile leaves oneColumn out of the report.
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?
Everything is front-loaded correctly, but it arrives as one dense run-on block with heavy jargon (Banquish, Tile, Panel, Working stretch, Fit report) and the lengthy Fit-report catalogue occupies half the text. Each clause carries information, yet the lack of structure makes it hard to scan.
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 correctly takes on the return value, enumerating the Fit report's issue categories and the settling-Tile caveat. It is close to complete for a mutation tool with a nested placement object; only the workspace identifier format and error behavior are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the load and does well: text is constrained to formatted-text syntax with a length limit, and placement is explained as grid coordinates analogous to arrange, including the h-vs-text-height rule. The workspace parameter's expected form (id vs. name) is left unexplained, and x/w/y are only covered indirectly by reference to arrange.
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 opening states a specific verb and resource — "Add a Note to a Workspace" — and clarifies the note sits "beside its Panels," which makes the artifact concrete. It never explicitly separates itself from update_note or remove_note, but the create semantics are 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?
Usage is implied by "Add a Note to a Workspace" and the reference to arrange for placement, but there is no statement of when to add a note versus a panel, no prerequisites, and no pointer to update_note for edits. The agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose a Panel from candidate ids of an open page. Banquish confirms it on the page, which the first Panel from it takes over as its own. The page stays open to you for more Panels: its ids stay valid for expand, find, add_panel and update_panel, and each further Panel gets a fresh copy of the page, where Banquish replays your reveals and finds the parts again, which takes a few seconds (refused if they aren't found). It answers within about 45 s: a Panel whose page is still loading then gives its id with "loading"; a later Fit report or read_workspace shows it settled. reveal and screenshot need the page opened again once a Panel has taken it. Each id is one part: take the smallest part that answers. Several ids make one Composite Panel, for parts of the page that act on each other (a player and its transcript, a chart and its time picker): they show together in one tile and stay live together. exclude takes ids of candidates inside the chosen parts that the Panel leaves out (the site's buttons and menus, an ad, a reply box, the rest of a container whose text you want); any other id is refused with the reason. Mode is "item" (follow this specific thing, the default) or "spot" (whatever occupies this place). Placement is where its Tile goes on the Workspace's grid, as in arrange; without one it goes full width below the last Tile. A width below a Panel's minimum width is taken, and its Panel shows scaled down to as little as 85% of that minimum on the user's screen; below 85% of it, the whole Workspace shows as one column. With h, a Panel's Tile is that tall: a taller Panel scrolls inside it, and a shorter one shows centred in it, which the Fit report mentions. Returns the Fit report: at the user's window, which Tiles are scaled below their Panel's minimum width, scroll inside, fell back to crop, are broken or ambiguous, or leave their Tile's width unused, and any gaps between Tiles; and, not as an issue, which Panels are shorter than the h of their Tile, so show centred in it. A Tile whose page hasn't laid it out at its width yet (one not on screen, say) is settling: a later report says how it fits. While a settling Tile's minimum width isn't known, whether the Workspace shows as one column isn't either: oneColumn is left out, and the summary says so.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | item | |
| page | Yes | ||
| exclude | No | ||
| placement | No | ||
| workspace | Yes | ||
| candidates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark this as a non-idempotent open-world write, but the description discloses the operational facts an agent actually needs: the ~45 s answer window, 'loading' status for still-loading pages, that the page stays open with ids still valid, that each further Panel gets a fresh copy where reveals are replayed and refused if not found, the 85% minimum-width and one-column fallbacks, and settling Tiles with oneColumn omitted.
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?
It is one dense wall of text of roughly 300 words with nested parentheticals, so it is poorly front-loaded; the reader must wade through Fit-report and settling details to get back to core input guidance. Nearly every sentence carries real information, which keeps it from scoring lower, but the structure needs breaking up and the return-value detail could be deferred.
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 complex nested-object mutation with no output schema, it explains both the mutation's effects (Panel creation, page copy, confirmation step) and the returned Fit report contents. Remaining gaps are minor: workspace and page identifiers are never characterized, and the 'Banquish confirms it' step is asserted without saying what the agent should do if confirmation fails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description carries the full burden and mostly delivers: candidates (one id = one part), exclude (ids inside chosen parts that the Panel leaves out; other ids refused with a reason), mode (item = follow this specific thing vs spot = whatever occupies this place), and placement/h/w semantics including defaults and scaling. Only workspace and page are left essentially unexplained.
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 opening sentence 'Propose a Panel from candidate ids of an open page' gives a specific verb (propose/add) and resource (Panel) scoped to an open page's candidates. It is distinguishable from update_panel and arrange only indirectly (placement 'as in arrange'), and the domain jargon 'Panel'/'Banquish' assumes prior context, so it falls short of a clean 5.
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?
Strong guidance on how to pick inputs: 'Each id is one part: take the smallest part that answers', use several ids for a Composite when parts act on each other, and use exclude for the site's chrome or an ad. It also gives an important prerequisite/state rule ('reveal and screenshot need the page opened again once a Panel has taken it'). It does not explicitly contrast itself with update_panel or explain when to add a new Panel vs modify an existing one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place any number of Tiles (Panels and Notes, by id) on a Workspace's grid in one call: x and w in 12 columns, y and h in rows of 8 px at the user's laptop window (1512 px wide; gaps 16 px, margins 24 px). No h means the Tile is as tall as its Panel or Note, at most about two-thirds of the user's window height (a taller Panel scrolls inside it). With h, a Panel's Tile is that tall: a taller Panel scrolls inside it, and a shorter one shows centred in it, which the Fit report mentions. With h, a Note's Tile is that tall, even taller than its text. To give a row one height, give its Tiles one h. Only the listed Tiles move. Tiles float up: y orders them, and each sits right under whatever is above it in its columns; a Tile placed on others pushes them, and those under them, down, hidden Tiles too. y is a row in the placements as the last call returned them (this one or read_workspace), so reuse those values, not ones you sent earlier: a Tile given the y of another lands on it. add_panel and add_note return only their own Tile's placement, and one placed on others pushes them down, so call read_workspace before reusing the other Tiles' y. Tiles given the same y in the same columns stack in the order you list them, the first on top. x + w over 12, or a negative or zero value, is refused with the reason, and then nothing moves; so is a Tile you can't see. A width below a Panel's minimum width is taken, and its Panel shows scaled down to as little as 85% of that minimum on the user's screen; below 85% of it, the whole Workspace shows as one column. Returns every Tile's placement. Returns the Fit report: at the user's window, which Tiles are scaled below their Panel's minimum width, scroll inside, fell back to crop, are broken or ambiguous, or leave their Tile's width unused, and any gaps between Tiles; and, not as an issue, which Panels are shorter than the h of their Tile, so show centred in it. A Tile whose page hasn't laid it out at its width yet (one not on screen, say) is settling: a later report says how it fits. While a settling Tile's minimum width isn't known, whether the Workspace shows as one column isn't either: oneColumn is left out, and the summary says so.
| Name | Required | Description | Default |
|---|---|---|---|
| tiles | Yes | ||
| workspace | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far beyond the annotations, it explains layout semantics, push-down behavior, validation refusal rules, fallback scaling, settling behavior, and the Fit report contents. This is unusually rich disclosure for a mutation 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?
The core action and constraints are front-loaded, and nearly every detail serves the complex layout behavior. However, it is a dense run-on paragraph with some repeated push-down phrasing that could be structured more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's layout complexity, no output schema, and sparse annotations, the description is complete: it covers return values, the Fit report, validation failures, and the settling case. An agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates thoroughly: x and w are 12-column values, y and h are rows of 8 px, h has different effects for Panels and Notes, and tile refers to Panels/Notes by id. It adds meaning well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: placing Tiles on a Workspace grid in one call. It explicitly distinguishes this bulk arrangement operation from add_panel and add_note, which only return their own Tile's placement.
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 clear context for arranging existing Tiles and states an important prerequisite: call read_workspace before reusing other Tiles' y values. It does not spell out explicit when-not-to-use conditions, but the sibling distinction and read_workspace guidance make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Workspace, named plainly after the task. By default use one per answer. The prompt is the user's request, in their words (at most 1,000 characters). Banquish shows it only on a Share of this Workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| prompt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write/idempotency/open-world profile, so the bar is lower, and the description still adds genuine behavioral context: the 1,000-character cap on the prompt and the fact that the prompt is only surfaced on a Share of the workspace. It does not say what happens on duplicate names or whether creation returns an identifier needed by add_note/add_panel.
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 the naming rule, with no filler. The "Banquish shows it only on a Share of this Workspace" sentence is slightly awkward phrasing but carries unique 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 two-parameter, non-destructive create tool with no output schema, the description covers both parameters and the one non-obvious side effect (prompt visibility). The remaining gap is the return value / how the new workspace is referenced afterward, which matters since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (both params are bare strings), so the description must carry the load and it largely does: it explains the naming convention for `name` and the source/format/length limit for `prompt` (max 1,000 chars, not encoded in the schema). It stops short of saying whether `prompt` is optional or how it affects behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ("Create a Workspace") that is unambiguously distinct from siblings like rename_workspace, read_workspace and list_workspaces. It also adds naming intent ("named plainly after the task"), but doesn't state what a Workspace is or what creating one produces.
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?
"By default use one per answer" gives a real default-behavior rule, which is more than most create tools offer. However, it never addresses when NOT to create one (e.g. reuse an existing workspace via list_workspaces/read_workspace) or when to prefer rename_workspace instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show a candidate's children on an open page as it is now, in at most 40 lines like open_page's, opening the largest first. A candidate with more than 40 children is paged: pass pageNo for the next pages. Says how many candidates the page gained since you last looked (+N new), with new ids. If the page can't be read again, it is closed: open it again with open_page. After about 45 s it answers "still opening; call expand again" while its page is still opening, or "still working; call expand again" while its work goes on.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| pageNo | No | ||
| candidate | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare read-only, open-world, non-destructive behavior. The description adds substantial context: max 40 lines, largest-first ordering, paging, '+N new' counts with ids, closed-page recovery, and ~45s timeout messages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main action is front-loaded and the description packs necessary behavioral detail without outright waste. It is a long paragraph with some repetition and dense fallback/timeout details, but appropriately sized for the tool's complexity.
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?
There is no output schema and parameter descriptions are absent, yet the description covers return shape (up to 40 lines, +N new ids) and timeout/fallback behavior. It still omits page and candidate identifier format details, keeping it short of 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?
Schema description coverage is 0%, so the description must carry parameter meaning. It explains pageNo paging and the roles of page and candidate, but does not define identifier formats or schema constraints/default for pageNo.
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: 'Show a candidate's children on an open page', with ordering and line-limit behavior. It also explicitly references open_page for comparison and fallback, making it distinguishable from the sibling 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?
Explains paging via pageNo, fallback to open_page when the page cannot be read again, and repeated expand calls on timeout messages. It does not say when to prefer expand over read_panel or find, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the smallest candidates on an open page, as it is now, whose text, heading, label, id or classes contain every word, in at most 40 lines like open_page's. Says how many candidates the page gained since you last looked (+N new). If the page can't be read again, it is closed: open it again with open_page. After about 45 s it answers "still opening; call find again" while its page is still opening, or "still working; call find again" while its work goes on.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| words | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld annotations: caps output at 40 lines in open_page's format, reports a '+N new' delta since the last look, discloses the ~45 s timeout with the two exact retry responses ('still opening' / 'still working'), and explains the closed-page failure mode. That is unusually rich operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and match rule, then prerequisites and failure modes. The quoted retry strings are long but earn their place as verbatim agent-facing signals; overall it is dense 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?
With no output schema, the description still conveys result shape (at most 40 lines mirroring open_page's format, plus a new-candidate count) and all failure/timeout behaviors. Only the ordering and precise line format of results remain unspecified, and those are delegated to open_page.
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 0%, so the description must carry the load, and it does: 'words' is defined as every word needing to match against text/heading/label/id/classes, and 'page' is constrained to an open page in its current state. It doesn't specify word-splitting or case sensitivity, keeping it short of a 5.
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 (find) and resource (candidates on an open page) plus the exact match rule: text, heading, label, id or classes must contain every word. This separates it from siblings like read_panel or screenshot, though the term 'candidates' is never defined, leaving some ambiguity about what is returned.
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?
Clearly scopes usage to an already-open page ('as it is now') and gives an explicit recovery path: if the page can't be read again it is closed, so call open_page. It does not contrast against read_panel/read_workspace for content retrieval, but the precondition and fallback are concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Signal that you've finished working: the working mark clears, Staging pages no Panel came from are discarded, your changes become one step the user can undo, and the user is told your answer is ready on the Workspaces you changed. No Fit report is sent after it. It returns each Workspace you changed: its name, its link, and what it holds (each Panel's parts and site, each Note's first line). Tell the user what you built from this, with its link. Never quote values.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover only the safety profile (not read-only, not destructive, idempotent); the description goes well beyond by disclosing what is destroyed (Staging pages no Panel came from), that changes become a single undoable step, that the user is notified, and that no Fit report follows. It also describes the return payload.
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?
Front-loaded with the trigger and effects, and every sentence carries content — effects, return shape, then instructions. Some clauses are dense and multi-part ('its name, its link, and what it holds'), but nothing is 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?
With no parameters and no output schema, the description must carry both the effects and the return contract; it does both, naming the fields returned per Workspace and how to relay them to the user. Nothing an agent needs 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, so the baseline of 4 applies; there is nothing for the description to disambiguate. The schema is empty and fully consistent with the description's no-argument framing.
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 act (signalling completion of work) and enumerates its concrete effects: clearing the working mark, discarding orphan Staging pages, collapsing changes into one undo step, notifying the user. No sibling tool does anything similar, so an agent can distinguish it immediately.
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 opening clause 'Signal that you've finished working' makes the triggering condition explicit, and the closing lines prescribe what to do with the result (tell the user what you built, include the link, never quote values). There is no explicit when-not guidance or named alternative, which is the only gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's Workspaces, most recently viewed first: id, name, Panel count, when the user last viewed it, whether it is archived, and its link. With a query, only Workspaces whose name contains every word.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful behavior: results are ordered most recently viewed first and include specific fields like Panel count, archived status, and link. Pagination or result limits are not mentioned, which keeps it from 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?
It is a single well-structured sentence with the primary operation front-loaded and the return fields and filtering behavior compactly appended. No sentence 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 simple read-only list tool with no output schema, the description is complete enough: it states what is listed, the ordering, the optional filter semantics, and the fields returned. An agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameter, and it does: a query restricts results to Workspaces whose name contains every word. That is meaningful matching semantics beyond the bare string type. Case sensitivity and empty-query behavior are unspecified.
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 ('List the user's Workspaces') and immediately adds scope, ordering, and return fields. It is clearly distinguishable from single-workspace siblings like read_workspace or write siblings like create_workspace.
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 clearly establishes the default behavior (list all Workspaces) and explains the optional query filter. It does not explicitly name alternatives such as find or read_workspace, but the context for when to use this listing tool is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a URL as a hidden Staging page with the user's profile: a page you may take Panels from, or one your own tools can't read properly. Find which pages to open with your own search; Banquish has no search. It waits for the page to load and settle, and you get the outline of its Candidate tree: the meaningful parts of the page, largest sections opened first, in at most 40 lines. The result holds the page id and the lines, each one string per candidate: [id] ^parent kinds tag#htmlId.classes[role=…][aria="label"] @x,y wxh | counts | h:"heading" | "text" | +k. ^parent is the candidate it sits in (^- for none); kinds are list:N (N items), item, ctl (a control), scrolls:H, fixed, or range a-b of n (a slice of a long level); @x,y wxh is its box on the page in CSS px; counts are the images, media, buttons, inputs and links inside it, left out when none; h: is its heading, left out when the text starts with it, and "text" the start of its text; +k counts candidates inside it not shown. The result says if the page still shows a loading screen, and names the HTTP status when the page answered with an error (400 or above). It answers within about 45 s: a page still loading then gives its page id and "still loading; expand and find wait for it". Use expand and find to see more, as the page is then; ids stay valid while their candidates are on the page. Only your few most recently used pages keep running: one you leave behind (or unused for a few minutes) is unloaded to save memory and opened again when you next use it, keeping the ids of what's still in the same place. Pages on the user's Private sites are refused.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses substantial behavior: the page is hidden/staging, it waits for load and settle, it answers in about 45 seconds, still-loading pages return a specific message, error statuses are named, only a few recent pages stay loaded, unused pages are unloaded and reopened, and private sites are refused. This is unusually rich context for an openWorld read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The paragraph is dense and long, but it is front-loaded with the core purpose and follows with usage, behavior, and the detailed Candidate-tree output format. Much of the length is justified because there is no output schema, though the mini-format spec could be easier to scan as structured text.
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 a single input parameter, the description carries the full burden and does so thoroughly: it explains the return value (page id and Candidate lines), the line format, loading and error status reporting, the 45-second timeout behavior, and page-lifecycle memory behavior. An agent has enough information to call and interpret the 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?
The schema has only one parameter with zero description coverage, so the description must compensate. It says the tool opens a URL, which is minimal but sufficient given the schema's format: uri constraint; however, it provides no further semantics about acceptable URL forms, schemes, or relative paths beyond refusing Private sites.
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: 'Open a URL as a hidden Staging page with the user's profile.' It also distinguishes the tool from its siblings by explaining that it is for pages you may take Panels from or that your own tools can't read, and that Banquish has no search so you must find pages yourself.
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 clear usage conditions: use it to obtain a page you can take Panels from or one your tools can't read properly, find URLs with your own search, and use expand/find afterward. It also states a when-not condition ('Pages on the user's Private sites are refused'), but does not compare against all relevant siblings such as screenshot or reveal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a Panel's current identity and values, kept apart (identity: what it is, e.g. heading, label, link; values: prices, counts, times), with its state and how fresh the read is. Banquish reloads an unloaded page if needed. To protect sites, values read under a minute ago are served as they are, and an unloaded page is reloaded at most every 5 minutes: reads in between get the last values, stale since they were read. A not-responding Panel's page isn't reloaded for a read: it waits for the user to reload it. A read still going after about 45 s gives the last values, stale, and "still reading; call again".
| Name | Required | Description | Default |
|---|---|---|---|
| panel | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, which only mark the tool as a read-only, non-destructive, open-world operation, the description discloses crucial behaviors: cached values under a minute old are served as-is, unloaded pages are reloaded at most every 5 minutes, stale values are returned with a freshness marker, non-responding panels are not reloaded for a read, and a read exceeding ~45 seconds returns the last values with a 'still reading; call again' signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the core purpose and then layers on caching and timeout behavior in a structured, information-dense way. It is somewhat long but most sentences carry distinct behavioral value; minor awkwardness ('Banquish reloads an unloaded page if needed') does not seriously hurt readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's non-trivial caching and staleness semantics and the absence of an output schema, the description does a good job explaining what is returned conceptually (identity, values, state, freshness) and how edge cases behave. It still leaves the 'panel' parameter's expected format unexplained, which is a completeness gap for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter ('panel') with 0% schema description coverage. The description never explains what form the panel identifier takes, how it can be obtained, or what values are acceptable, so it fails to compensate for the schema's lack of 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 uses a specific verb and resource ('Read a Panel') and explains that the result separates identity (heading, label, link) from values (prices, counts, times). It clearly distinguishes this tool from write-oriented siblings like update_panel or add_panel, but does not explicitly differentiate it from read_workspace or open_page.
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 operational guidance such as calling again after a partial read and not expecting a non-responding panel to be reloaded, but it never states when to choose read_panel over alternatives like open_page or read_workspace. Usage is implied by the tool's purpose rather than explicitly contrasted with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a Workspace: every Tile in one list, in reading order (top to bottom, then left to right), and the user's current window size. Each Tile has its kind and placement on the grid: x and w in 12 columns, y and h in rows of 8 px at the user's laptop window (1512 px wide; gaps 16 px, margins 24 px), each y being where the Tile floats up to. No h means the Tile is as tall as its Panel or Note, at most about two-thirds of the user's window height (a taller Panel scrolls inside it). With h, a Panel's Tile is that tall: a taller Panel scrolls inside it, and a shorter one shows centred in it, which the Fit report mentions. With h, a Note's Tile is that tall, even taller than its text. A Panel has its id, Source page, mode, state (live while it shows its content; restoring, unloaded, broken, ambiguous, needs-peek or not-responding otherwise) and Fit status at the user's window, as the Fit report gives it. tier says how its content was last found: exact, healed (found by similarity after a reload), ambiguous (with the candidate ids on its running page that might be it) or not-found; moved means an item-mode Panel found its content somewhere else on the page; foundByPlace means it found its content by its place and size, as what it is no longer clearly matched. A Note has its id, text and when it was last written. A hidden Tile is a Panel from one of the user's Private sites: only its placement, which you can't move or remove. On a Panel or Note, userChanged means the user moved or resized it since you last placed Tiles on this Workspace (with arrange, or add_panel or add_note with a placement). A broken or ambiguous Panel you meet on a Workspace you're working on is yours to resolve with update_panel as part of your task.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds extensive behavioral context beyond the readOnly, non-destructive, closed-world annotations. It explains reading order, coordinate conventions, hidden Tile privacy constraints, Panel state and Fit semantics, tier/moved/foundByPlace meanings, and userChanged behavior. Nothing contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main return shape, but it is a very dense single paragraph with many semicolon-linked clauses. Much of the detail is useful given the lack of an output schema, but the structure could be easier to scan.
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 complex read tool with no output schema, the description does a thorough job explaining the returned Tile, Panel, Note, state, tier, and placement semantics. The main remaining gap is that it never explains the required id parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, id, with 0% description coverage. The description never explains what that id refers to, so it does not compensate for the schema gap; an agent must infer that it is a workspace id from the tool name and surrounding context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: it reads a Workspace and returns all Tiles in reading order plus window size. It is immediately distinguishable from siblings like read_panel or list_workspaces by its returned layout, though it does not explicitly name those alternatives.
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 mostly implied: an agent must infer that this tool is for reading a Workspace's layout. The only explicit routing guidance is that broken or ambiguous Panels encountered on a Workspace should be resolved with update_panel, which is follow-up guidance rather than when-to-use guidance for read_workspace itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a Note from its Workspace. The user can undo it with the rest of your Working stretch. Returns the Fit report: at the user's window, which Tiles are scaled below their Panel's minimum width, scroll inside, fell back to crop, are broken or ambiguous, or leave their Tile's width unused, and any gaps between Tiles; and, not as an issue, which Panels are shorter than the h of their Tile, so show centred in it. A Tile whose page hasn't laid it out at its width yet (one not on screen, say) is settling: a later report says how it fits. While a settling Tile's minimum width isn't known, whether the Workspace shows as one column isn't either: oneColumn is left out, and the summary says so.
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive=true, readOnly=false, and idempotent=true. The description adds substantial context beyond those annotations: undo within the Working stretch, the detailed Fit report returned, and the settling edge case for unlaid-out Tiles.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, but the return explanation is a long, densely packed sentence with many layout terms and later settling caveats. The information is useful but not tightly structured, making it overlong rather than crisp.
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?
There is no output schema, and the description usefully explains the return report and settling behavior. However, it leaves the single input parameter semantically undefined and relies on dense prose for a complex result, so it is only partially complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required 'note' string parameter with 0% schema description coverage, and the description never clarifies whether it is an ID, title, path, or other identifier. The word 'Note' is the only clue, so the description does not compensate for the missing schema documentation.
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?
Front-loads a specific verb and resource: 'Remove a Note from its Workspace.' That verb distinguishes it from siblings such as add_note, update_note, and remove_panel without requiring schema inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it by saying 'Remove a Note,' but gives no explicit when-to-use, when-not-to-use, or alternative guidance relative to update_note or remove_panel. Usage is therefore only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a Panel from its Workspace (a hidden Tile can't be removed). The user can undo it with the rest of your Working stretch. Returns the Fit report: at the user's window, which Tiles are scaled below their Panel's minimum width, scroll inside, fell back to crop, are broken or ambiguous, or leave their Tile's width unused, and any gaps between Tiles; and, not as an issue, which Panels are shorter than the h of their Tile, so show centred in it. A Tile whose page hasn't laid it out at its width yet (one not on screen, say) is settling: a later report says how it fits. While a settling Tile's minimum width isn't known, whether the Workspace shows as one column isn't either: oneColumn is left out, and the summary says so.
| Name | Required | Description | Default |
|---|---|---|---|
| panel | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the description earns credit for what it adds beyond them: the hidden-Tile exclusion, the user-undo path, and a detailed account of the Fit report returned. The report text is dense but discloses real post-mutation state, including the settling-Tile edge case where oneColumn is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The removal action and its constraint are front-loaded correctly, but more than half the text is a run-on sentence enumerating Fit-report fields in heavy jargon ("settling", "Working stretch", "leave their Tile's width unused"). It is informative but not efficiently structured.
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 destructive one-parameter mutation with no output schema, the description covers the safety story (undo, hidden-Tile restriction) and the return payload in unusual depth. The only material omission is what the `panel` argument actually identifies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required `panel` string, and the description says nothing about what value it expects — an ID, a name, or a handle — or whether it must belong to the current Workspace. With the schema carrying no semantics at all, the description should have compensated and does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first clause states a specific verb and resource ("Remove a Panel from its Workspace") and adds a real constraint that a hidden Tile can't be removed, which an agent cannot infer from the name. It is clearly distinct from add_panel and update_panel by virtue of the verb, though it never names those siblings.
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 only implied: the parenthetical about hidden Tiles rules out one case, and the undo note suggests when removal is acceptable. There is no explicit statement of when to remove vs. update_panel or hide, and no prerequisites such as required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a Workspace, plainly. The user can undo it with the rest of your Working stretch.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one piece of context beyond annotations: that the user can undo the rename. That is useful given destructiveHint=true, but it is vague (what does "the rest of your Working stretch" mean?) and says nothing about what changes, whether the old name is recoverable, or any side effects on panels/pages.
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?
It is short and front-loads the purpose, which is good. However, the second sentence uses undefined internal jargon ("Working stretch") and "plainly" is filler, so the brevity comes partly at the cost of clarity.
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 destructive, non-read-only mutation with two undocumented parameters and no output schema, the description should clarify scope, reversibility, and parameter meaning. It gestures at undoability but leaves an agent guessing about what exactly is renamed and how.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention either parameter. The names id and name are fairly self-explanatory, but there is no statement of format, constraints, or whether id refers to a workspace vs. a nested object, so the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first clause states a clear verb and resource ("Rename a Workspace"), so an agent immediately knows the operation. It offers no differentiation from siblings like create_workspace or update_panel, and the qualifier "plainly" adds nothing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this rather than create_workspace or other workspace tools, nor any prerequisites. The only usage-adjacent statement is about undoing the change, which is a behavioral note, not a selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reveal content hidden behind a control on an open page (a tab, an expand toggle, a disclosure, a "more" button): Banquish clicks the candidate for you (or the one button or link inside it, when it holds just one), stopping any request that could write, any navigation and any new window meanwhile, and checks that new content appeared. Returns the updated tree in lines like open_page's: the new candidates, then the outline. Ids you had stay valid; new content gets new ids. A Panel made from the page afterwards comes back in the revealed view after a reload. If the click tries to navigate or open a window, moves the page to another path, or shows nothing new, the reveal is refused with the reason: use content reachable by URL instead. Never on the user's Private sites. Reveals on different pages may run in parallel. After about 45 s it answers "still opening; call reveal again" while its page is still opening, or "still working; call reveal again" while its work goes on.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| candidate | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral detail beyond the annotations: it clicks the candidate or its single inner button/link, blocks write requests, navigation, and new windows, verifies that new content appeared, preserves existing ids while assigning new ones, and explains the Panel reload behavior. It also documents refusal reasons, private-site restrictions, parallel execution, and the approximate 45-second timeout responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and all sentences carry operational information, including return shape, id stability, refusals, private-site restrictions, and timeout behavior. It is somewhat long and monolithic, but the density is justified by the complexity of the tool.
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 absence of an output schema, the description explains the return format in useful detail: updated tree lines like `open_page`, new candidates, outline, and id behavior. It also covers safety constraints, refusal conditions, private sites, parallelism, and timeout handling, so an agent has enough context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for two required parameters, the description partially compensates by framing `page` as an open page and `candidate` as the control to click, including the case where it contains exactly one button or link. However, it does not explicitly define the expected id formats, where `page` comes from, or how `candidate` relates to ids returned by `open_page`.
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: revealing content hidden behind a control on an open page, with examples such as tabs, expand toggles, disclosures, and 'more' buttons. It is clear what the tool does, but it does not explicitly differentiate itself from the sibling `expand` tool, leaving the agent to infer when one is preferable.
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 explicit usage conditions (hidden content behind a control on an open page), exclusions (never on the user's Private sites; refuse when navigation, new window, path change, or no new content occurs), and an alternative approach for refused cases (use content reachable by URL instead). It also notes that reveals on different pages may run in parallel.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
An image of one candidate of an open page, and nothing else, for content text can't describe (a canvas chart, an image). Use it sparingly: the Candidate tree usually says enough. After about 45 s it answers "still opening; call screenshot again" while its page is still opening, or "still working; call screenshot again" while its work goes on.
| Name | Required | Description | Default |
|---|---|---|---|
| page | Yes | ||
| candidate | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/non-destructive, but the description adds value they don't carry: the return is an image only, and the ~45 s timeout yields 'still opening; call screenshot again' or 'still working; call screenshot again'. That retry semantics is genuinely useful operational context; only the exact image format/size is left unstated.
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 sentences, front-loaded with the purpose, then usage restraint, then timing behavior. Dense and mostly waste-free, though the opening sentence is a run-on that could be split for clarity.
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, and the description does cover the return type plus the retry messages, which is exactly the missing piece. The remaining gap is identifier provenance for the two required params, which 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 coverage is 0% and both parameters (page, candidate) are required with no documentation. The description only obliquely implies that 'page' is an open page and 'candidate' is an entry in the Candidate tree, without saying how to obtain either identifier (e.g., from open_page or read_panel output). With 0% schema coverage the description should compensate and it largely does not.
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 output (an image of one candidate of an open page, 'and nothing else') and implicitly contrasts with workspace_image and the Candidate tree. The intended use case (content text can't describe — canvas chart, image) sharpens the purpose further, though the phrasing is slightly convoluted.
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?
Explicitly says to use it sparingly because 'the Candidate tree usually says enough', which gives a clear when-not condition and points at the textual alternative. It doesn't name the specific sibling tool to prefer, so the agent must infer that read_panel is the substitute.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rewrite a Note's text, in the same formatted text as add_note. It keeps its id and placement; place it with arrange. The user can undo it with the rest of your Working stretch. Returns the Fit report: at the user's window, which Tiles are scaled below their Panel's minimum width, scroll inside, fell back to crop, are broken or ambiguous, or leave their Tile's width unused, and any gaps between Tiles; and, not as an issue, which Panels are shorter than the h of their Tile, so show centred in it. A Tile whose page hasn't laid it out at its width yet (one not on screen, say) is settling: a later report says how it fits. While a settling Tile's minimum width isn't known, whether the Workspace shows as one column isn't either: oneColumn is left out, and the summary says so.
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | ||
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive/not-read-only/idempotent, so the bar is lower, and the description adds genuinely new behavior: the edit is undoable within the user's Working stretch, and it returns a Fit report whose contents are enumerated. It does not say whether permissions or a settled layout are prerequisites, but the mutation and recovery profile is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The action is front-loaded in the first clause, which is good, but the bulk of the text is a dense, jargon-heavy enumeration of the Fit report that takes four long sentences to say what could be said in one or two. Given there is no output schema the return detail earns some place, but the settling/oneColumn explanation is verbose relative to its decision value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the full return-value burden and does so thoroughly, including the settling-tile caveat and the omitted oneColumn field. Combined with the undo note and annotation coverage of the safety profile, an agent has enough to call it correctly, though the two undocumented parameters remain the weak point.
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 0%, so the description must compensate; it partially does by implying `note` is the identifier ("keeps its id") and `text` is the new body, and by pointing at add_note's formatted-text convention for the text parameter. It never states the expected identifier format for `note` (id vs. name) or how text is encoded, leaving a real gap at zero schema 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?
"Rewrite a Note's text" names a specific verb and resource, and the reference to add_note's formatted text plus "keeps its id and placement" separates it from add_note and remove_note without the agent opening a schema. It is immediately clear this mutates existing note content rather than creating or deleting one.
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 scope of the operation (text only, id and placement preserved) and routes the agent to the sibling `arrange` for placement, which is real alternative-routing guidance. It stops short of explicit when-not conditions, e.g. when to prefer remove_note + add_note or whether an existing note must be found first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change a Panel: re-propose its content, change what it leaves out, or switch it between Item and Spot mode, in any combination. Re-proposing is how you resolve an ambiguous or broken Panel: resolve those you meet on a Workspace you're working on as part of your task, and any the user points you at. For an ambiguous Panel, give candidates from the ids read_workspace offers for it. Otherwise open its Source page (or another) with open_page and give that page with candidate ids from it. The page is used as add_panel uses it: the first Panel from it takes it over as its own, and it stays open to you for more Panels; from a page a Panel has taken, the Panel gets a fresh copy where Banquish replays your reveals and finds the parts again (refused if they aren't found, and the Panel gets its old content back). Several ids make a Composite Panel. exclude takes ids of candidates inside the chosen parts that the Panel leaves out. Given without candidates, exclude changes what the Panel leaves out of its parts, with ids from the page you made it from while that page is still open to you; [] brings everything back. mode is "item" (follow this specific thing) or "spot" (whatever occupies this place): from then on the Panel finds its content that way: at once, and again whenever its page loads. It answers within about 45 s: a change whose page is still loading then gives the Panel with "loading"; a later Fit report or read_workspace shows it settled. The Panel keeps its id and placement; place it with arrange.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| page | No | ||
| panel | Yes | ||
| exclude | No | ||
| candidates | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag destructive/openWorld/idempotent; the description adds substantially more: a ~45 s response window, a 'loading' return state that later resolves via Fit report or read_workspace, page-takeover semantics mirroring add_panel, and a disclosed failure mode where unfound reveals are refused and old content is restored. It also states the Panel keeps its id and placement, which materially reduces the perceived destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence front-loads the three actions well and nearly every sentence carries real information, but the body collapses into long run-on clauses dense with undefined domain jargon ('Banquish replays your reveals', 'Fit report'), making it hard to parse in one pass. Content is justified; presentation is not.
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 five-parameter mutation tool with no output schema and no parameter descriptions, this covers timing, intermediate states, failure recovery, id stability, and the composite-Panel case. Only the panel identifier's format and the exact shape of the returned state are left unstated, which is a minor residue rather than a functional 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 0%, so the description must carry everything, and it largely does: candidates, page, exclude (including the empty-array restore case), and mode's item-vs-spot meaning are all defined. The 'panel' parameter is only implicitly identified as an id and its accepted format is never stated, which is the one meaningful gap.
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?
Opens with a specific verb-plus-resource and enumerates the three distinct mutations it performs: re-proposing content, changing exclusions, and switching between Item and Spot mode. It names the siblings it composes with (add_panel, open_page, read_workspace, arrange), so an agent can separate it from read_panel or arrange without inspecting either 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?
Explicitly says when to re-propose (any ambiguous or broken Panel on a Workspace you're working on, plus any the user points you at) and which two paths to take depending on whether the Panel is ambiguous: candidate ids from read_workspace, or a page opened with open_page. The alternatives are named and the selecting condition is stated each time.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A JPEG of a Workspace as the user's window shows it now (the part in view). With width (CSS pixels), a preview of the whole Workspace at that window width instead: the placement adapted to that width, each Tile's last frame rescaled, so it's approximate. A Workspace not on the user's screen is previewed at the user's window width. Tiles you can't see (Private sites') are plain boxes labelled "Private site".
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | ||
| workspace | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, non-destructive, closed-world), the description discloses meaningful behavior: previews are approximate because tiles are rescaled from last frames, off-screen workspaces are rendered at the user's window width, and private sites are masked as labelled boxes. These caveats go well past what the structured fields convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main behavior is front-loaded, but the middle sentences are grammatically broken and run-on ('With width (CSS pixels), a preview of the whole Workspace at that window width instead: ...'), which slows comprehension. Every sentence carries content, but the phrasing could be tightened considerably.
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 two-parameter read-only image tool it covers rendering fidelity and privacy masking well. It still leaves the required workspace identifier undefined and does not indicate how the image is returned (e.g., inline image content), and there is no output schema to fill those gaps.
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 0%, so the description must carry parameter meaning. It handles width well (CSS pixels, effect on output, preview semantics) but says nothing about the required 'workspace' parameter — whether it is an ID, a name, or a handle — leaving the most important input ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly establishes the resource (a Workspace) and the output (a JPEG), and it distinguishes two modes: the current on-screen view versus a full-workspace preview when width is supplied. It does not, however, differentiate this from the sibling 'screenshot' tool, leaving the agent to infer which imaging tool to pick.
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 explicit conditional guidance for the width parameter ('With width ... a preview of the whole Workspace at that window width instead'), which is genuinely useful. But there is no guidance on when to use this tool versus the sibling screenshot tool, and no prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
add_noteadd_panelarrangecreate_workspaceexpandfindfinish_worklist_workspacesopen_pageread_panelread_workspaceremove_noteremove_panelrename_workspacerevealscreenshotupdate_noteupdate_panelworkspace_imageScreenshots and clean markdown of any public web page, rendered in a real Chrome browser.
Search the live web and fetch clean content from source pages.
Collaborative, cache-first web search for agents — cited answers from a shared live-web pool.
Capturewren: screenshot any URL (banners removed) plus status, title and clean page text for agents.
Add one secure layer between your agents and this server.
