Skip to main content
Glama
Sign In
vibatchium

vibatchium

by trueoriginlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

map_compact

Read-only

Renders a token-efficient, one-line-per-element browser snapshot with optional interactive-only filtering, depth limits, and real bounding-box coordinates for agent navigation.

Instructions

One-line-per-element rendering of the snapshot (token-efficient): @eN role "name" [state…], preserving state ([checked]/[disabled]/[expanded]/[level=N]). interactive=only actionable roles; bbox=append real bounding_box() coords (bbox=x,y,w,h) — genuine layout geometry.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "map_compact"
  }
}

Input Schema

NameRequiredDescriptionDefault
bboxNoAppend real-Chrome bounding-box coords per element.
depthNoLimit snapshot depth.
leaseNoOptional lease token to present if the target session is leased (0.7.0). Threaded per-call; never read from the server's env.
sessionNoOptional session name to target (omit for the shared 'default'). On a daemon shared with other agents, pass a UNIQUE name for stateful multi-step work (go→click→fill) so you don't collide on 'default'.
max_charsNoCap the returned snapshot.
interactiveNoOnly actionable roles (button/link/textbox/checkbox/…).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.21.0
    • addedInput schema / properties / max_chars
      Added value: +{
+  "default": 40000,
+  "description": "Cap the returned snapshot.",
+  "type": "integer"
+}
  2. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

With readOnlyHint/openWorldHint annotations and no output schema, the description does real work by documenting the returned line format and the state markers that are preserved. However, it says nothing about truncation behavior (max_chars default 40000), how depth affects output, or what happens on a leased/colliding session — behavioral traits an agent would want before calling.

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 semicolon-dense sentences that are front-loaded with the output format, which is the most decision-relevant fact. Every clause carries information, though the heavy symbol notation makes it slightly hard 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 read-only snapshot renderer with no output schema, describing the exact emitted line format and state markers is the critical missing piece and it is supplied. Gaps remain around truncation and depth effects, but nothing essential to choosing or calling the tool is absent.

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 coverage is 100%, so the baseline is 3. The description adds genuine meaning for `interactive` (only actionable roles) and `bbox` (real bounding_box coords, format bbox=x,y,w,h, 'genuine layout geometry'), going beyond the schema wording, but it says nothing about `depth`, `max_chars`, `session`, or `lease` beyond what the schema already documents.

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 names a specific operation on a specific resource: a one-line-per-element, token-efficient rendering of the snapshot, with the exact output line format (`@eN role "name" [state…]`). It is clearly distinguishable from screenshot/text/html siblings, though it never explicitly names the sibling `map` tool that presumably does the richer variant.

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 only implied: '(token-efficient)' suggests when to prefer this over richer tools, and the two flags are characterized inline. There is no explicit when-to-use/when-not-to-use statement and no routing to `map`, `content`, or `extract` as alternatives, so the agent must infer the choice.

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

Deploy Server

Other Tools