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

Wait for the user to finish signing in

wait_for_sign_in

Read-onlyIdempotent

Wait until the user finishes a sign-in link, so you know the moment they are done without asking them. Pass ref: meta.handoff.ref from a paused run, or ref from add_connection.

Call it right after you give the user the link, in the same turn. Write the link in your reply first, so they can see it while this waits. It holds for up to waitMs (default 45000, at most 50000) and answers the moment the sign-in finishes.

It returns state: • done: every site on the link is signed in. Send the SAME script again now (or carry on with the task after add_connection). Do not ask the user whether they are done. • pending: not yet; remaining names the sites still missing. Call it again with the same ref. Keep going while the link is live (expiresAt, 15 minutes); a person often takes a few minutes. • cancelled: the user pressed Cancel. Tell them, and do not re-send the script unless they ask. • expired: the link ran out first. Send the SAME script again; it pauses with a fresh link. • unknown: no link with that ref on this account. A ref starting site: cannot be watched: wait for the user instead.

If the user replies while you are waiting, answer them; the link is still live and you can wait again.

Input Schema

Name	Required	Description	Default
`ref`	Yes	`meta.handoff.ref` from a paused run, or `ref` from `add_connection`.
`waitMs`	No	How long to wait for the sign-in to finish, in ms. Default 45000, at most 50000.

Output Schema

Name	Required	Description
`ref`	No	The sign-in being waited on.
`sites`	No	Sites the link covers.
`state`	No	pending, done, cancelled, expired or unknown.
`message`	No	What to do next, in one paragraph.
`expiresAt`	No	When the link expires.
`remaining`	No	Sites not signed in yet.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "expiresAt": {
+      "description": "When the link expires.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "message": {
+      "description": "What to do next, in one paragraph.",
+      "type": "string"
+    },
+    "ref": {
+      "description": "The sign-in being waited on.",
+      "type": "string"
+    },
+    "remaining": {
+      "description": "Sites not signed in yet.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "sites": {
+      "description": "Sites the link covers.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "state": {
+      "description": "pending, done, cancelled, expired or unknown.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

AddedOct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the read-only/idempotent annotations: it discloses that the call blocks up to waitMs (default 45000, capped at 50000), that the link lives 15 minutes, and that answering the user mid-wait is fine and the link stays live. The state machine (done/pending/cancelled/expired/unknown) is spelled out with what to do in each.

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 action and the timing constraint, then uses a compact per-state bullet list that is easy to scan. It is longer than typical, but nearly all of it is actionable; the waitMs parenthetical and the ref sentence partially duplicate the schema.

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, yet the description still resolves the decisions an agent must make after each state, plus the rate/lifetime constraints of the underlying link. Nothing needed to call and recover from this tool correctly is missing.

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 the baseline is 3, but the description adds meaning: where `ref` comes from (paused run handoff vs add_connection) and the operational consequence of certain ref shapes ('site:' refs are unwatchable). waitMs detail largely repeats 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 (wait for the user to finish a sign-in link) and its practical payoff ('so you know the moment they are done without asking them'). It is clearly separable from siblings like add_connection, get_secret_link, and request_secret.

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?

Gives explicit timing guidance ('Call it right after you give the user the link, in the same turn'), tells the agent to write the link first, and prescribes a different action per returned state. It also names the exclusion case: a ref starting `site:` cannot be watched.

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.