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

Publish a page (jig) so others can get it

jig_publish

Publish the user's jig (name it by jigId or your jig's jigSlug) as a listing others can get: it snapshots the page and state AS THEY ARE NOW into version N+1, and later edits stay private until you publish again. Call with dryRun: true first and show the user what would ship: every function the page calls (tagged read / write / pay), its sites, and the defaultState a copy starts with — blank anything personal with defaultState. A first publish needs the user's public handle (the @name in bowmark.ai/jigs/@/, permanent; ask them, or claim it earlier with jig_set_handle). visibility: "unlisted" is reachable by link only; "public" also appears in search. Returns the jig URL. To unlist a published jig or change its title, tagline or description, call again with the new values and detailsOnly: true: no new version is written.

Input Schema

Name	Required	Description
`slug`	No	First publish only; made from the title when omitted. It cannot change.
`jigId`	No	The jig's id. Give this or `jigSlug`.
`title`	No
`dryRun`	No	Return exactly what would ship and write nothing.
`handle`	No	The user's public handle, first publish only.
`jigSlug`	No	The slug of the caller's OWN jig (from `jig_list`), instead of `jigId`. Not the listing `slug` below.
`tagline`	No
`changelog`	No	What changed in this version.
`extraSites`	No	Extra sites to list it under for discovery. The derived ones always stay.
`visibility`	Yes
`description`	No
`detailsOnly`	No	Change only the listing (visibility, title, tagline, description); writes no version. Use it to unlist.
`screenshots`	No	Up to 8 screenshots (png/jpeg/webp ≤ 5 MB) or a short clip (mp4/webm ≤ 20 MB) for the jig page, each a `url` or `base64` — give exactly one. YOU capture them (a screenshot of the page with sample data, never the user's private data); Bowmark never captures the user's live jig.
`defaultState`	No	The state a copy starts with. Default: the jig's own default (its template's, or the version it was installed from), never its live state.

Output Schema

Name	Required	Description
`ok`	No	True when the jig was published.
`url`	No	Where anyone can open it.
`message`	No	Why the call failed, when `ok` is false.
`listingId`	No	The published listing's id.
`versionNo`	No	The listing version this publish made.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "listingId": {
+      "description": "The published listing's id."
+    },
+    "message": {
+      "description": "Why the call failed, when `ok` is false.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "True when the jig was published.",
+      "type": "boolean"
+    },
+    "url": {
+      "description": "Where anyone can open it."
+    },
+    "versionNo": {
+      "description": "The listing version this publish made."
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedNov 7, 2026

changedInput schema / properties / screenshots / description

Previous value: -"Up to 8 screenshots (png/jpeg/webp ≤ 5 MB) or a short clip (mp4/webm ≤ 20 MB) for the store page, each a `url` or `base64` — give exactly one. YOU capture them (a screenshot of the page with sample data, never the user's private data); Bowmark never captures the user's live jig."New value: +"Up to 8 screenshots (png/jpeg/webp ≤ 5 MB) or a short clip (mp4/webm ≤ 20 MB) for the jig page, each a `url` or `base64` — give exactly one. YOU capture them (a screenshot of the page with sample data, never the user's private data); Bowmark never captures the user's live jig."

Changed3 schema fields changedNov 5, 2026

addedInput schema / properties / jigId / description

Added value: +"The jig's id. Give this or `jigSlug`."

addedInput schema / properties / jigSlug

Added value: +{
+  "description": "The slug of the caller's OWN jig (from `jig_list`), instead of `jigId`. Not the listing `slug` below.",
+  "maxLength": 300,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "jigId",
-  "visibility"
-]New value: +[
+  "visibility"
+]

AddedNov 5, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond the annotations (which only say non-read-only, open-world, non-idempotent): it discloses the versioning model (snapshot AS THEY ARE NOW into N+1), that later edits stay private, that `handle` and `slug` are permanent, and that screenshots must be captured by the agent with sample data. It does not discuss rate limits, failure modes, or what happens to an existing listing's version history on republish, which keeps it off 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and the versioning consequence, then routes through dry-run, handle prerequisite, visibility, and detailsOnly in a logical order. It is dense and long for a single block — the em-dash parentheticals and 'AS THEY ARE NOW' emphasis add length — but nearly every clause carries decision-relevant information.

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

Completeness5/5

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

For a 14-parameter mutation tool with nested screenshot objects, the description covers the prerequisites, the destructive/private-data concerns, the dry-run safety path, and the two publish modes; the return value (jig URL) is stated even though an output schema exists. Nothing an agent needs to call it correctly appears absent.

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

Parameters4/5

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

Schema coverage is 71%, and the description still adds real meaning beyond it: disambiguates `jigId` vs `jigSlug` in prose, explains `defaultState` as the place to blank personal data, and clarifies the agent's responsibility for `screenshots`. It adds little on `slug`, `title`, `tagline`, `changelog`, `description`, and `extraSites`, which are left largely to the schema.

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

Purpose5/5

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

States a specific verb and resource ('Publish the user's jig ... as a listing others can get') and immediately distinguishes it from related siblings by naming `jig_set_handle` and by explaining that `detailsOnly: true` avoids writing a version (contrast with `jig_update`). The snapshot-to-version-N+1 mechanic makes the operation unmistakable.

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

Usage Guidelines5/5

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

Explicit when-to guidance across every branch: call `dryRun: true` first and show the user the payload, first publish requires a public `handle` (with the pre-req flow via `jig_set_handle`), `detailsOnly: true` for unlisting or metadata changes. It also spells out what each visibility value means, leaving nothing to inference.

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.