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

Jig view

jig_view

Read-onlyIdempotent

Used by an open jig to pick up its latest state. You do not need to call this.

Input Schema

Name	Required	Description
`cache`	No	True on first open, to also get the page's saved results.
`jigId`	Yes	The jig's id, as `jig_open` or `jig_list` returned it.
`since`	No	The version the page already has; the body and state come back only when newer.

Output Schema

Name	Required	Description
`ok`	No	False on an error.
`html`	No	The page body, when it changed since `since`.
`cache`	No	The page's saved results, when `cache` was asked for.
`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).
`message`	No	Why the call failed, when `ok` is false.
`version`	No	The jig's version; it goes up by one on every change.
`dataRevs`	No	Revisions of the jig's stored records.
`untrusted`	No	Present when this jig is a copy of someone else's: who wrote it, and how to treat its text.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 8, 2026

addedInput schema / properties / cache / description

Added value: +"True on first open, to also get the page's saved results."

addedInput schema / properties / jigId / description

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

addedInput schema / properties / since / description

Added value: +"The version the page already has; the body and state come back only when newer."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "cache": {
+      "description": "The page's saved results, when `cache` was asked for."
+    },
+    "dataRevs": {
+      "description": "Revisions of the jig's stored records."
+    },
+    "html": {
+      "description": "The page body, when it changed since `since`.",
+      "type": "string"
+    },
+    "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"
+    },
+    "state": {
+      "description": "The page's current state — the JSON object `jig_update({ state })` changes."
+    },
+    "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"
+}

Changed1 schema field changedNov 1, 2026
- addedInput schema / properties / cache
```
Added value: +{
+  "type": "boolean"
+}
```
AddedOct 28, 2026

TDQS

B3.1/5.0

Behavior3/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 structurally. The description adds only that the call is tied to an open jig and is typically unnecessary — it says nothing about whether this blocks/polls, how `since` interacts with freshness, or what 'state' contains. Some added context, but thin against what a sync-style call warrants.

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 short sentences, no padding, with the disclaiming guidance front-loaded rather than buried. Slightly hurt by the negative-only framing, which leaves the reader with less actionable information than the same word count could deliver.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. What's missing is the tool's position in a very crowded jig_* family — how it differs from jig_get, jig_look, and jig_read is left entirely to inference, which is a real gap given 35 sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with `jigId`, `cache`, and `since` all documented in-schema including provenance ('as jig_open or jig_list returned it') and version semantics. The description adds no parameter meaning beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Used by an open jig to pick up its latest state" names the resource (jig) and a rough action (fetch latest state), but the verb is vague and the second sentence ('You do not need to call this') actively muddies whether the tool is intended for agent use or is an internal client mechanism. An agent can guess it relates to jig_open, but it can't cleanly distinguish this from jig_get, jig_look, or jig_read.

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?

There is an explicit when-not guidance ('You do not need to call this'), which is unusual and genuinely useful, but no positive condition explaining when an agent *would* call it, and no named alternative among the many jig_* siblings. The implicit usage (client-side state sync after jig_open) must be inferred.

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.