Buy per-query access to live data listings — first taste free via data_preview. Listing: usnwatch: Ubuntu Security Notices (USN) (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?
Annotations already provide readOnly, idempotent, and non-destructive hints, so the description needs less behavioral disclosure. It adds useful context about the session prerequisite and the returned fund instructions, but the verb 'Buy' is ambiguous next to readOnlyHint=true; it should clarify that no payment is executed and only purchase instructions are returned.
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 and front-loaded: purpose, alternative, listing, price, and prerequisite are each covered in a short statement with no filler. Every sentence earns its place.
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 low-complexity, single-parameter tool whose annotations already establish safety, the description covers the essential context: when to call, what listing is involved, the price, and the output type. It does not detail the structure of the fund instructions or the next step, but this is a minor gap given the tool's simplicity.
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 input schema already covers the single parameter fully, including that session_id is the UUID from data_session_open. The description reinforces this prerequisite but contributes no meaning beyond what the schema provides, so the baseline 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 names a specific action and resource: buy per-query access to live data listings, with a concrete listing and price provided. It also distinguishes itself from data_preview by calling out the free first taste, making the tool's scope and purpose clear.
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 a clear prerequisite ('after data_session_open') and points to data_preview as the free alternative. It does not explicitly state when to use this tool instead of data_session_fund or data_session_attach_escrow, so it lacks full exclusionary guidance.
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 adjacent territory: data_session_fund, data_session_funding_package, and data_session_attach_escrow all relate to funding, while a2awire_guide and get_recommended_action both provide navigation guidance. Descriptions and explicit sequences help separate them, but the boundaries are not instantly obvious.
Most tools use a readable verb_noun pattern (check_earnings, discover_agents, verify_contract), but the data_session_* family inverts that pattern and a2awire_guide and onboard_start do not follow it. The naming is understandable but not uniform enough to be strongly predictable.
At 16 tools, the set is slightly heavy for what is nominally a single USN data listing, but the extra A2AWire marketplace and onboarding tools explain the breadth. It feels bloated rather than unwieldy.
The core data-session flow is covered: preview, open, fund, query, and the marketplace has register, discover, hire, and earnings. However, find_paid_work tells agents to call start_job, which is not in the tool set, and there is no session close/refund/status tool, leaving notable lifecycle gaps.