npm Release Tracker — new Node.js packages & JavaScript dependency updates (npmwatch)

data_session_open

Buy per-query access to live data listings - first taste free via data_preview. Listing: npmwatch: New npm package releases & JavaScript dependency updates (0.01 USDC/query (max 20 queries/session)). Open a prepaid session, then fund and query.

Input Schema

TableJSON Schema

Name	Required	Description
`listing_id`	No	UUID of the listing. Provide exactly one of listing_slug or listing_id.
`max_queries`	No
`listing_slug`	No	Public listing slug (from benchmarks_get / data_directory_get). Provide exactly one of listing_slug or listing_id.
`open_tx_hash`	No
`buyer_address`	No	Buyer EVM address. Optional: defaults to your own platform wallet when omitted.
`proof_escrow_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedSep 7, 2026

addedInput schema / description

Added value: +"MCP-only input for ``data_session_open``.\n\nSubclasses the REST ``DataSessionOpen`` payload without mutating it (the\n``FaucetUsdcDripInput`` approach) so the shared constraints\n(``max_queries`` bounds, ``open_tx_hash`` length, the EVM address check)\nstay declared once. Two friction-free relaxations, MCP surface only:\n\n* the listing may be named by its public slug OR its UUID (exactly one) -\n  the benchmark route and the purchase-gate 409 hand the agent a slug, and\n  demanding a UUID re-creates the slug-to-UUID lookup hop;\n* ``buyer_address`` is optional - when omitted the handler defaults to the\n  caller's own platform wallet (``WalletService.own_wallet_address``),\n  the same argument-filling default the USDC faucet uses.\n\nThe REST endpoint ``POST /api/v1/data-sessions`` keeps requiring\n``listing_id`` + ``buyer_address`` unchanged.\n\nThe ``type: ignore[assignment]`` marks are the intended pydantic override\n(narrowing the REST fields to Optional here); mypy reads that as an LSP\nviolation even though the model validator enforces exactly one listing\nreference and the handler guards the Optionals."

addedInput schema / properties / buyer_address / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / buyer_address / default
```
Added value: +null
```

addedInput schema / properties / buyer_address / description

Added value: +"Buyer EVM address. Optional: defaults to your own platform wallet when omitted."

removedInput schema / properties / buyer_address / type
```
Removed value: -"string"
```

addedInput schema / properties / listing_id / anyOf

Added value: +[
+  {
+    "format": "uuid",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / listing_id / default
```
Added value: +null
```

addedInput schema / properties / listing_id / description

Added value: +"UUID of the listing. Provide exactly one of listing_slug or listing_id."

removedInput schema / properties / listing_id / format
```
Removed value: -"uuid"
```
removedInput schema / properties / listing_id / type
```
Removed value: -"string"
```

addedInput schema / properties / listing_slug

Added value: +{
+  "anyOf": [
+    {
+      "minLength": 1,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Public listing slug (from benchmarks_get / data_directory_get). Provide exactly one of listing_slug or listing_id.",
+  "title": "Listing Slug"
+}

removedInput schema / required

Removed value: -[
-  "listing_id",
-  "buyer_address"
-]

changedInput schema / title

Previous value: -"DataSessionOpen"New value: +"DataSessionOpenInput"

First observedSep 6, 2026

TDQS

B3.3/5.0

Behavior3/5

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

Annotations are minimal (all false). The description discloses that it creates a prepaid session and mentions per-query costs, but it omits side effects like blockchain interactions, session ID return, or any implicit funding steps. The majority of the description is about input schema implementation details, not behavioral outcomes.

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

Conciseness2/5

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

The description is overly verbose and includes extensive technical notes about pydantic overrides, type ignore markers, and REST payload subclasses. These implementation details are not necessary for an agent calling the tool and detract from actionable guidance. The core intent gets buried under API design commentary.

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

Completeness2/5

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

With no output schema, the description does not explain what the tool returns (e.g., session ID, status). It mentions 'open a prepaid session' but lacks details on how the session is identified for subsequent funding/querying steps, and omits any failure modes or prerequisites. The agent is left without a complete picture of the tool's results.

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 description coverage is 50% (3 of 6 parameters have descriptions). The description adds valuable context for listing_id/slug and buyer_address (relaxation rules), but max_queries, open_tx_hash, and proof_escrow_id remain undocumented, and the overall description does not clarify their purpose beyond basic constraints.

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 clearly states the tool opens a prepaid data session for per-query access, and the title 'Open Data Session' reinforces the specific action. It distinguishes itself from sibling tools by implying a sequential workflow (open then fund/query).

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

Usage Guidelines3/5

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

The description explains MCP-specific relaxations versus the REST endpoint, but does not explicitly contrast with sibling tools like data_session_fund or data_session_attach_escrow. It gives a general workflow hint ('Open a prepaid session, then fund and query') but lacks explicit when-to-use/when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All npm Release Tracker — new Node.js packages & JavaScript dependency updates (npmwatch) 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.

Resources

Need Help?