Skip to main content
Glama

CVE Security Advisories (NVD High & Critical) — buy per-query in-session (cvewatch)

data_session_fund

Idempotent

Buy per-query access to live data listings — first taste free via data_preview. Requires an agent API key (Authorization: Bearer or X-API-Key). Platform-execute funding for a testnet sandbox wallet minted at register (approve + createEscrowWithProof + attach). Testnet only; user-supplied wallets still self-sign via data_session_funding_package. Not guest-callable. No REST analogue.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_idYesUUID of a data session you opened (from data_session_open).

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses auth requirements (Bearer or X-API-Key), the platform-executed funding flow (approve + createEscrowWithProof + attach), environment restrictions (testnet only), guest-call restriction, and the absence of a REST analogue. This is meaningful behavioral context that annotations do not provide.

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?

The most important purpose statement is front-loaded, followed by compact, high-signal sentences covering auth, execution flow, environment, alternatives, and restrictions. No filler or repetition.

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 one-parameter funding tool with rich annotations and a well-described schema, the description covers prerequisites, invocation context, alternatives, and environment. Nothing an agent needs to safely decide or call the tool is missing.

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%: session_id is documented as a UUID of an opened data session from data_session_open. The description adds context that the session is used for per-query funding but does not elaborate on the parameter itself, so the schema already carries the parameter-semantic burden.

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?

Description opens with a specific verb and resource: 'Buy per-query access to live data listings'. It also distinguishes itself from data_preview (free taste) and data_session_funding_package (user-supplied wallets), making its role among siblings unambiguous.

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 states when to use alternatives: data_preview for a first free taste, and data_session_funding_package when user-supplied wallets must self-sign. It also states constraints (testnet only, not guest-callable, requires agent API key), so an agent can route to the correct tool.

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.

TDQS

A3.6/5.0
Disambiguation3/5

A few clusters could cause misselection: data_session_fund, data_session_funding_package, and data_session_attach_escrow all involve paying for data sessions, and both a2awire_guide and get_recommended_action provide next-step guidance. However, most tools target distinct resources and actions, and the detailed descriptions help resolve most ambiguity.

Naming Consistency2/5

Names fall into two competing styles: verb-first commands like discover_agents/find_paid_work/get_agent_contract, and resource-first names like data_preview/data_session_open/data_session_funding_package. Within the data_session_* family, forms are inconsistent (fund vs funding_package vs attach_escrow), and a2awire_guide/onboard_start don't follow either pattern.

Tool Count3/5

16 tools is at the borderline/heavy end but not unreasonable for a platform spanning onboarding, discovery, hiring, escrow, and data-session payments. The count feels inflated mainly because much of that scope is unrelated to the server's advertised CVE-advisory purpose.

Completeness1/5

The server name promises CVE Security Advisories from NVD, yet there is no CVE-specific search, list, get, or filter tool. The only query path is generic data_session_query, which could target any data listing, so an agent cannot reliably accomplish the server's core advertised workflow.

Resources