Bowmark web data: LinkedIn, Amazon, YouTube, Reddit, Airbnb, Instagram

Look at a page (jig)

jig_look

Read-onlyIdempotent

See what an open jig is showing the user right now — the items on screen, which view they are on — plus what they just did on it (watched, hid, searched) and its current state. Call it before you curate: when the user says "clear the slop" or "why is this here", look first, then change the page with jig_update. It also says how fast the page last loaded and which calls failed (perf, advice): fix what advice names with jig_update.

Input Schema

Name	Required	Description	Default
`jigId`	Yes	The jig's id, as `jig_open` or `jig_list` returned it.

Output Schema

Name	Required	Description
`ok`	No	False on an error.
`perf`	No	How fast the page last loaded and which calls failed.
`jigId`	No	The jig's id — pass it to every other `jig_*` tool.
`state`	No	The page's current state — the JSON object `jig_update({ state })` changes.
`title`	No	The page's title (fenced text when the jig is a copy of someone else's).
`advice`	No	What to fix with `jig_update`.
`opened`	No	Whether anyone has opened the page yet.
`message`	No	Why the call failed, when `ok` is false.
`showing`	No	What the page reported it shows right now.
`storage`	No	The jig's stored records, summarised.
`version`	No	The jig's version; it goes up by one on every change.
`controls`	No	The state keys a built-in page reads.
`untrusted`	No	Present when this jig is a copy of someone else's: who wrote it, and how to treat its text.
`reportedAt`	No	When the page last reported.
`recentActions`	No	What the user just did on the page.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 8, 2026

addedInput schema / properties / jigId / description

Added value: +"The jig's id, as `jig_open` or `jig_list` returned it."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "advice": {
+      "description": "What to fix with `jig_update`."
+    },
+    "controls": {
+      "description": "The state keys a built-in page reads."
+    },
+    "jigId": {
+      "description": "The jig's id — pass it to every other `jig_*` tool.",
+      "type": "string"
+    },
+    "message": {
+      "description": "Why the call failed, when `ok` is false.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "False on an error.",
+      "type": "boolean"
+    },
+    "opened": {
+      "description": "Whether anyone has opened the page yet."
+    },
+    "perf": {
+      "description": "How fast the page last loaded and which calls failed."
+    },
+    "recentActions": {
+      "description": "What the user just did on the page."
+    },
+    "reportedAt": {
+      "description": "When the page last reported."
+    },
+    "showing": {
+      "description": "What the page reported it shows right now."
+    },
+    "state": {
+      "description": "The page's current state — the JSON object `jig_update({ state })` changes."
+    },
+    "storage": {
+      "description": "The jig's stored records, summarised."
+    },
+    "title": {
+      "description": "The page's title (fenced text when the jig is a copy of someone else's)."
+    },
+    "untrusted": {
+      "description": "Present when this jig is a copy of someone else's: who wrote it, and how to treat its text."
+    },
+    "version": {
+      "description": "The jig's version; it goes up by one on every change.",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

AddedOct 28, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered without the description. The description earns credit by disclosing what the call actually surfaces beyond a plain read — user actions (watched, hid, searched), load speed, failed calls, and an `advice` block naming what to fix — which explains why an agent should call it repeatedly rather than treat it as a one-shot fetch.

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?

It is front-loaded with the payload ('See what an open jig is showing the user right now') before the procedural guidance, and every sentence does work. It is slightly dense — the final sentence packs perf, advice, and the remedy into one line — but there is no filler.

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?

With an output schema present and annotations covering the safety profile, the description only needs to explain purpose and sequencing, which it does. The one real gap is its failure to situate itself relative to the other read-oriented jig tools in a crowded sibling set.

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?

There is a single required parameter (jigId) with 100% schema description coverage, including where to obtain the id from jig_open or jig_list. The description adds nothing about the parameter, which is the expected baseline when the schema already carries full semantics.

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 concrete operation on a concrete resource: inspect what an open jig is currently displaying (items, view, recent user actions, state, perf, advice). That is far more specific than the title's 'Look at a page'. It does not, however, distinguish itself from the similar-sounding read siblings jig_get, jig_read, and jig_view, which an agent would plausibly confuse it with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is explicit and paired with an alternative: call it before curating, when the user says 'clear the slop' or 'why is this here', then change things with jig_update, and fix what `advice` names via jig_update. There is no when-not guidance, and the read-side siblings (jig_get/jig_read/jig_view) are never positioned against this tool, so the routing story is incomplete on the read side.

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

All Bowmark web data: LinkedIn, Amazon, YouTube, Reddit, Airbnb, Instagram tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.