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

Claim the user's public handle (permanent)

jig_set_handle

Idempotent

Claim the user's public handle: the @name in the links to pages they publish, bowmark.ai/jigs/@/. It is PUBLIC and PERMANENT: it can never be changed or released. Ask the user which one they want BEFORE calling, suggesting one from their name, and never choose it for them. A handle is 2 to 30 lowercase letters, digits and single hyphens. Calling again with the handle they already hold is fine. A taken or invalid handle is refused with a free suggestedHandle to offer instead. Call it with no handle to see whether they have one and a free one to suggest; that writes nothing. jig_open tells you when a new jig's owner has none yet.

Input Schema

Name	Required	Description	Default
`handle`	No	The handle the user chose, with or without the @. Omit it to only look.

Output Schema

Name	Required	Description
`ok`	No	True when the handle was set.
`handle`	No	The account's public handle, the @name in a jig link.
`message`	No	Why the call failed, when `ok` is false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "handle": {
+      "description": "The account's public handle, the @name in a jig link."
+    },
+    "message": {
+      "description": "Why the call failed, when `ok` is false.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "True when the handle was set.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

AddedNov 6, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already mark this as a non-destructive, idempotent write, and the description adds the crucial facts annotations cannot express: the handle is public and permanent and can never be changed or released. It also discloses the failure path (taken/invalid handles are refused with a free `suggestedHandle`) and that omitting `handle` writes nothing — a dry-run mode not visible in annotations.

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?

Front-loads the single most consequential fact (public and permanent) before any procedural guidance, then moves to the pre-call user interaction, then format rules, then edge cases. Dense but every sentence carries a distinct, load-bearing constraint.

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?

An output schema exists, so return shapes need not be explained; the description instead covers the things an agent could still get wrong — user consent, idempotent re-calls, refusal handling, and the look-only mode. Nothing needed to invoke this correctly is missing.

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

Parameters5/5

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

Schema coverage is 100%, but the description still adds meaning the schema lacks: the 2–30 character length rule, the allowed character set (lowercase letters, digits, single hyphens), that the @ is optional, and that omission means look-only. The only friction is the schema's maxLength of 40 versus the stated 30, a minor mismatch that does not obscure intent.

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 — claim the user's public handle — and immediately grounds it in concrete terms (the @name in published page links, with an example URL). It is unmistakable against siblings like jig_get or jig_update.

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?

Explicitly instructs to ask the user which handle they want BEFORE calling, to suggest one derived from their name, and never to choose for them. It also names the check-only invocation (no `handle`) and points to `jig_open` as the trigger for when an owner has none yet.

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.