Buy per-query access to live data listings — first taste free via data_preview. Listing: exploitdb: Exploit-DB — New Public Exploits & PoCs (0.01 USDC/query (max 20 queries/session)). Open a prepaid session, then fund and query.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes | ||
| max_queries | No | ||
| open_tx_hash | No | ||
| buyer_address | Yes | ||
| proof_escrow_id | No |
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 only indicate read/write and idempotency flags; the description adds useful cost and quota context (0.01 USDC/query, max 20 queries/session) and indicates the session is prepaid. However, it does not explain side effects for a financial operation, such as what transaction hash or escrow inputs are needed or whether funds are committed at open time.
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?
Two sentences, no fluff, and the most important action is front-loaded. The hardcoded listing example is somewhat distracting but not bloated.
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?
Without an output schema or detailed annotations, the description is too thin for a 5-parameter session-opening tool. It omits required-input semantics, transaction requirements, and how the returned session is used with data_session_fund/query.
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?
With 0% schema description coverage, the description needed to explain the five parameters, but it only indirectly references listing_id via the exploitdb listing and gives a per-query price. buyer_address, max_queries, open_tx_hash, and proof_escrow_id are not explained, and the stated 'max 20 queries/session' conflicts with the schema's max_queries maximum of 50.
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 a concrete action ('Open a prepaid session') and what it provides ('per-query access to live data listings'), and it names data_preview as the free alternative. It does not fully explain how opening differs from the sibling funding/escrow/query session tools, so it falls short of perfect differentiation.
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?
It gives clear usage context: preview for free first, then open a prepaid session, then fund and query. It names the intended next steps via data_preview/query flow but does not explicitly say when to avoid this tool or mention data_session_fund/attach_escrow by name.
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 overlap in purpose: data_session_fund, data_session_funding_package, and data_session_attach_escrow all concern funding/escrow; a2awire_guide, get_recommended_action, and onboard_start all provide guidance/state; and discover_agents, find_paid_work, and hire_and_execute all point at marketplace hiring. Descriptions help, but the boundaries between these clusters are still easy for an agent to misjudge.
Most tools follow a readable snake_case verb_noun pattern such as data_session_open, discover_agents, and verify_contract. There are minor deviations like a2awire_guide, data_session_funding_package, and register, but the overall convention is fairly consistent.
16 tools is at the borderline heavy end, and many tools belong to a generic A2AWire marketplace/onboarding layer rather than the Exploit-DB data-access purpose. The count is not extreme, but the server feels over-scoped for what should be a focused per-query data listing.
The Exploit-DB flow covers preview, open, fund, attach escrow, and query, but there are notable dead ends: find_paid_work tells you to call start_job, and get_recommended_action references start_admission, yet neither tool exists. There is also no explicit withdraw/close-session tool, leaving the lifecycle incomplete.