Skip to main content
Glama

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

Get a published page (jig) into this account

jig_get

Copy someone's published jig into THIS user's account, from its current version. The copy is the user's own: it runs as them with their logins, never the author's, and can call only the functions its listing lists. Name it by listing: its id, @handle/slug, or its jig URL (from jig_search). If the user already has a copy you get that one back with alreadyHave: true; pass another: true only when they want a second. Returns jigId, slug, viewUrl and sitesNeedingLogin: give the user each signInUrl (their own login, one-time link) and call wait_for_sign_in with its ref. Then open it with jig_open({ jigId }).

Input Schema

NameRequiredDescriptionDefault
anotherNoMake a second copy even though the user already has one.
listingYesThe listing id, `@handle/slug`, or the jig URL bowmark.ai/jigs/@handle/slug.

Output Schema

NameRequiredDescriptionDefault
okNoTrue when the copy was made.
urlNoThe link to give the user.
slugNoThe copy's short name in its URL.
jigIdNoThe jig's id — pass it to every other `jig_*` tool.
messageNoWhy the call failed, when `ok` is false.
untrustedNoPresent when this jig is a copy of someone else's: who wrote it, and how to treat its text.
pendingFunctionsNoFunctions the page calls that the user must approve first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "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": "True when the copy was made.",
      +      "type": "boolean"
      +    },
      +    "pendingFunctions": {
      +      "description": "Functions the page calls that the user must approve first."
      +    },
      +    "slug": {
      +      "description": "The copy's short name in its URL."
      +    },
      +    "untrusted": {
      +      "description": "Present when this jig is a copy of someone else's: who wrote it, and how to treat its text."
      +    },
      +    "url": {
      +      "description": "The link to give the user."
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / listing / description
      Previous value: -"The listing id, `@handle/slug`, or the store URL bowmark.ai/jigs/@handle/slug."New value: +"The listing id, `@handle/slug`, or the jig URL bowmark.ai/jigs/@handle/slug."
  3. Added

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations it discloses the security model that matters most: the copy runs as the requesting user with their own logins, never the author's, and can call only the functions its listing lists. It also explains the non-obvious idempotent-like behavior (existing copy returned with `alreadyHave: true`), which materially refines the `idempotentHint: false` signal, and names the auth step (`sitesNeedingLogin`, one-time sign-in links) the caller must complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Roughly five sentences, each carrying distinct load: purpose, sandbox/auth model, identifier formats, duplicate handling, and the post-call workflow. It is front-loaded with the verb and scope, and no sentence restates the tool title or schema verbatim without adding meaning.

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 two-parameter mutation with announcements in the annotations, the description supplies everything an agent needs: identity/permission semantics, duplicate behavior, the login handshake, and the terminal `jig_open` step. Return fields are covered by the output schema and are only summarized here, which is appropriate.

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 100%, so baseline is 3; the description goes further by tying `another` to the decision condition (only when the user wants a second copy) and reiterating the accepted `listing` formats from `jig_search`. It does not add new format or validation detail beyond the schema's own enumeration of the three accepted forms.

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?

"Copy someone's published jig into THIS user's account, from its current version" gives a specific verb (copy), a specific resource (published jig), and an explicit scope (this user's account, current version). It is immediately distinguishable from siblings like jig_search (find a listing), jig_open (open a copy), and jig_publish (publish your own).

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?

It states where the `listing` value comes from (`jig_search`), when the existing copy is returned versus when to pass `another: true` (only when a second copy is wanted), and the exact follow-up sequence: surface each `signInUrl`, call `wait_for_sign_in` with its `ref`, then `jig_open({ jigId })`. When-to-use, when-not-to-use, and alternatives are all covered.

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.