Skip to main content
Glama

DDG Agent Services

by io.github.daedalusdevelopmentgroup

ddg_data_query

Call an allowlisted DDG paid data endpoint (prediction-markets, dex-pairs, model-catalog, price-feed, dns-lookup, web-search, contract-abi, etc.).

Call with no payment_headers to receive the x402 402 price quote; retry with
payment_headers to get results. Most endpoints grant free-trial calls per agent_id.
Use ddg_list_services or the ddg://openapi resource for exact schemas and current prices.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNo
pathYes
agent_idNo
payment_headersNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the payment protocol (x402), the need for payment_headers, and the existence of free-trial calls. It does not detail error behavior or what happens if payment is missing, but it is reasonably transparent for a complex paid API endpoint.

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 description is three concise sentences, each serving a purpose: stating the function, explaining the payment flow, and directing to additional resources. It is front-loaded with the main action and avoids unnecessary details.

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?

Given the tool's complexity (paid API with multiple endpoints) and the presence of an output schema, the description adequately covers the workflow, payment handling, and hints at available endpoints. It directs the agent to ddg_list_services for exhaustive information, making it complete in the context of the available metadata.

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 0%, so the description must add meaning. It explains the payment_headers parameter's role in the two-step process and mentions agent_id for free trials. However, the path parameter is described only as 'allowlisted endpoint' without specific values, and body is not explained, so coverage is partial but helpful.

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 it calls an allowlisted paid DDG data endpoint and lists examples, distinguishing it from sibling tools like ddg_ethereum_rpc_query or ddg_fetch_public_resource. The verb 'call' with the resource 'allowlisted DDG paid data endpoint' is specific and informative.

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?

The description explicitly explains the two-step process: call without payment_headers for a price quote, then retry with payment_headers for results. It also mentions free-trial calls and directs the agent to ddg_list_services for exact schemas and prices, providing clear when-to-use and how-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 DDG Agent Services toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose, ranging from status checks to order management to payment processing. Despite the large number, descriptions make them easy to differentiate, with no obvious overlap.

Naming Consistency3/5

All tools share the 'ddg_' prefix, but naming patterns vary: some use verb_noun (e.g., ddg_list_models) while others use noun_noun (e.g., ddg_agent_status). This mix reduces consistency, though readability remains acceptable.

Tool Count4/5

With 25 tools, the count is at the high end but scales to cover diverse aspects of payable services (status, orders, payments, models, x402). Minor consolidation could be possible, but most tools earn their place.

Completeness4/5

The tool surface covers core workflows like order lifecycle, payment, and service discovery. Minor gaps (e.g., no cancellation or refund tools) exist but do not severely hinder typical agent interactions.

Resources