Skip to main content
Glama

Banquish

Read a Workspace

read_workspace
Read-only

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.

Input Schema

NameRequiredDescriptionDefault
idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior5/5

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.

Conciseness3/5

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.

Completeness4/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.