Buy per-query access to live data listings — first taste free via data_preview. Listing: CISA Known Exploited Vulnerabilities (kevwatch) (0.01 USDC/query). Returns fund instructions after data_session_open.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | UUID of a data session you opened (from data_session_open). |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool returns fund instructions and includes concrete pricing, which adds context beyond the read-only, idempotent, and non-destructive annotations. However, the lead phrase 'Buy' could mislead an agent into thinking this call executes payment, and the content or format of the returned fund instructions is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using two sentences to convey purpose, free-trial alternative, listing identity, price, and prerequisite. It is efficiently structured, though front-loading the actual 'returns fund instructions' behavior instead of 'Buy' would make it even clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only tool, the description covers the main prerequisite and the high-level output. But it does not define what the fund instructions contain or how to consume them, and it stops short of connecting to the likely next steps, data_session_fund and data_session_attach_escrow. The absence of an output schema increases the burden on the description, which is only partially met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, session_id, is already fully described in the input schema as the UUID of a data session opened via data_session_open. The tool description reinforces the ordering but does not add meaningful semantic detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool returns fund instructions for per-query access to a specific live data listing (CISA KEV) and references data_preview for a free trial. It is clear about the general purpose, but the phrase 'Buy per-query access' overstates what the tool itself executes. It also does not clearly distinguish itself from data_session_fund or data_session_attach_escrow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit temporal cue: use this after data_session_open. It also points users who want a free sample to data_preview, which serves as an alternative. However, it does not explain how this step relates to data_session_fund or data_session_attach_escrow after the fund instructions are returned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Several tools occupy hazy boundaries: data_session_fund, data_session_funding_package, and data_session_attach_escrow all concern session payment/funding, and a2awire_guide overlaps with get_recommended_action as a navigation/guidance tool. Agents may easily pick the wrong call without reading descriptions carefully.
Most names follow a clear snake_case verb_noun pattern such as data_session_open, find_paid_work, and verify_contract. Minor deviations like a2awire_guide, data_session_funding_package, and register keep it from being perfectly uniform, but the convention is generally predictable.
16 tools is at the heavy edge of a normal surface, and many of the tools are generic A2AWire marketplace helpers rather than KEV-specific functionality. A dedicated KEV server would feel tighter with fewer, but the count is not extreme.
The set describes a wider marketplace but omits a referenced start_job tool, creating a dead end after find_paid_work. It also lacks any direct KEV query/metadata/session-status tool beyond the payment/session flow, so agents cannot fully complete the advertised workflows.