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

Call one Bowmark function and keep the session open for the next call

session_call

Destructive

Runs ONE library function in a Bowmark session, so a flow that needs several calls in the SAME session can finish: a booking that texts the user a code, a cart filled over several steps, a form that waits on an answer from the user. run cannot do these, because every run starts fresh and nothing it held survives to the next run.

path is the function as a script writes it after bowmark., split on the dots: ["providers","opentable","startBooking"]. args are its arguments, in order. Look both up in get_library first. Omit sessionId on the first call: a session opens and its sessionId comes back. Pass that sessionId on every later call so it runs in the same session. A session runs one call at a time: never send parallel calls to the same sessionId with Promise.all. Each call waits for the previous one. For parallel work, open separate sessions or use run instead.

The answer is { sessionId, ok, status, result, logs, error?, code? }. status is ok, error or needs_user. needs_user pauses only this call for a sign-in and the session stays open: give the user meta.handoff.url, then repeat the call. A session closes itself after a few idle minutes, so ask the user for anything you need (a texted code) right away and make the next call as soon as they answer. Call session_close when the task is done.

Input Schema

Name	Required	Description
`args`	No	The function's arguments, in order, exactly as a script passes them.
`path`	Yes	The function to call, as the path a script writes after `bowmark.`: `["providers","opentable","startBooking"]` for `bowmark.providers.opentable.startBooking`.
`sessionId`	No	The `sessionId` an earlier `session_call` returned. Omit it on the first call and a new session opens.

Output Schema

Name	Required	Description
`ok`	No	True when the call completed without an error.
`error`	No	What went wrong, when it did.
`runId`	No	The run's id; pass it back to resume or collect it.
`result`	No	What the call returned.
`status`	No	How the call ended: `ok`, `partial`, `error`, `paused`…
`message`	No	Why the call failed, when `ok` is false.
`expiresAt`	No	When an idle session ends (ISO 8601).
`sessionId`	No	Pass it to the next `session_call` and to `session_close`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "error": {
+      "description": "What went wrong, when it did."
+    },
+    "expiresAt": {
+      "description": "When an idle session ends (ISO 8601).",
+      "type": "string"
+    },
+    "message": {
+      "description": "Why the call failed, when `ok` is false.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "True when the call completed without an error.",
+      "type": "boolean"
+    },
+    "result": {
+      "description": "What the call returned."
+    },
+    "runId": {
+      "description": "The run's id; pass it back to resume or collect it.",
+      "type": "string"
+    },
+    "sessionId": {
+      "description": "Pass it to the next `session_call` and to `session_close`.",
+      "type": "string"
+    },
+    "status": {
+      "description": "How the call ended: `ok`, `partial`, `error`, `paused`…",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

AddedOct 20, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds substantially more: the one-call-at-a-time constraint with an explicit Promise.all prohibition, the idle-timeout self-close, the `needs_user` handoff behavior, and the return envelope. It does not address permission requirements for the underlying library functions or what a destructive call actually changes, leaving that to annotations alone.

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-loaded with the core differentiator and structured into purpose, parameters, sequencing hazard, and return shape. Dense but readable; the `run` contrast is restated twice and a few sentences could be tightened.

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 stateful, destructive, open-world tool, the description covers initiation, continuation, concurrency limits, expiry, auth handoff, and teardown. An output schema exists, yet the description's return-envelope sentence adds useful interpretive guidance on `status` values rather than merely duplicating structure.

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 coverage is 100%, and the schema already documents the dotted `path` example, `args` being positional, and omitting `sessionId` on the first call. The description largely restates these; its genuinely additive content is workflow sequencing rather than parameter meaning, so baseline 3 applies.

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?

The description states a specific verb and resource ("Runs ONE library function in a Bowmark session") and immediately scopes it to stateful multi-step flows. It explicitly distinguishes itself from the sibling `run` by naming what `run` cannot do ("every run starts fresh and nothing it held survives").

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 gives positive use cases (booking with a texted code, multi-step cart, a form waiting on a user answer), a named alternative with the condition that selects it (`run` for stateless calls, separate sessions for parallel work), and a prerequisite workflow (`get_library` first, `session_close` when done).

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.