This MCP server provides access to 106+ agent-payable micro-services across AI/ML, web, security, blockchain, and utility domains — all payable via x402 or direct crypto with no human in the loop.
Service Discovery & Catalog
List all available services (ddg_list_services) with pricing, view public resource index (ddg_public_resource_index), fetch specific DDG manifests/docs (ddg_fetch_public_resource), and check agent/service/rail status (ddg_agent_status).
AI & Model Services
List available models (ddg_list_models) and local runtime options like Ollama, llama.cpp, LM Studio, vLLM (ddg_list_local_runtime_options).
Run paid AI model routes (ddg_run_paid_model) for chat completions, LLM judging, embeddings, summarization, sentiment analysis, translation, and image generation.
Request new Ollama models for operator review (ddg_request_ollama_model).
Payments & Orders
Quote payment cost without executing compute (ddg_quote_payment), submit paid orders (ddg_submit_order), poll order status (ddg_order_status), and fetch completed artifacts (ddg_order_artifact).
Run a $0.01 transaction smoke test (ddg_tx_smoke_test) and review checkout/payment conformance (ddg_checkout_conformance).
Security & Safety
Review the MCP security profile (ddg_mcp_security_profile), browse the security service catalog (ddg_security_service_catalog), and run free static AI skill/workflow safety scans (ddg_skill_safety_scan).
Key Paid Services Available
Web/Network: Web search, URL fetching, screenshots, DNS lookups, WHOIS, IP geolocation, robots.txt checks.
Security: Threat check, SSL cert info, HTTP header analysis, TLS audit, subdomain enumeration, prompt injection scan, MCP tool security audit.
Blockchain: Contract ABI lookup, EVM RPC proxy, price feeds.
Compute/Docs: Python code execution (Docker sandbox), PDF extraction, OCR, QR code generation.
Utilities: Hashing, base64 encode/decode, UUID generation, timestamps, random data, JSON validation, text diff, language detection.
Stripe payment rail integration for processing payments (not yet live).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@io.github.daedalusdevelopmentgroup/ddg-agent-services-mcp run a payment readiness audit on my agent"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Pay-per-call AI agent services gateway. DDG gives agents one x402/direct-crypto entry point for callable tools, OpenAI-compatible routes, readiness audits, MCP security checks, discovery repair, receipts, and marketplace-ready proof artifacts.
124 x402/direct-crypto services for AI agents. The largest agent-payable service surface in the x402 ecosystem — from $0.001 utilities (DNS, hash, UUID) to $0.01 social/financial/agent-infra services. All fully automated with zero human in the loop. Includes an OpenAI-compatible gateway (/v1/chat/completions, /v1/models, /v1/embeddings).
https://agents.daedalusdevelopmentgroup.comfrom ddg_agent_services_mcp import ddg
client = ddg(agent_id="my-agent", private_key="0x...")
result = client.post("/v1/site-audit", {"url": "https://example.com"})Or configure once via environment:
export DDG_AGENT_ID="my-agent"
export DDG_PRIVATE_KEY="0x..."from ddg_agent_services_mcp import ddg
client = ddg() # reads from envDrop-in replacement for openai-python — point any OpenAI client at DDG:
from ddg_agent_services_mcp import create_openai_client
client = create_openai_client(agent_id="my-agent", private_key="0x...")
response = client.chat.completions.create(
model="auto",
messages=[{"role": "user", "content": "Hello"}],
)
print(response.choices[0].message.content)Supported routes: GET /v1/models, POST /v1/chat/completions, POST /v1/embeddings
Or use the standard openai package directly:
from openai import OpenAI
client = OpenAI(
base_url="https://agents.daedalusdevelopmentgroup.com/v1",
api_key="ddg-x402",
default_headers={"X-Agent-Id": "my-agent"},
)pip install ddg-agent-services-mcp
# With framework support:
pip install ddg-agent-services-mcp[langchain] # or crewai, openai-agents, autogen, etc.
pip install ddg-agent-services-mcp[all-frameworks] # everythingfrom ddg_agent_services_mcp.tools import create_langchain_tools
tools = create_langchain_tools(
agent_id="my-agent",
private_key="0x...", # Your EVM wallet key (Base USDC)
)
# Pass tools to your LangChain agent8 frameworks supported: LangChain, CrewAI, OpenAI Agents SDK, AutoGen, PydanticAI, LlamaIndex, Google ADK, and MCP.
{
"mcpServers": {
"ddg-agent-services": {
"command": "npx",
"args": ["-y", "@smithery/cli@latest", "install", "0xcircuitbreaker/ddg-agent-services-mcp"]
}
}
}Or direct HTTP: https://mcp.daedalusdevelopmentgroup.com/mcp
Related MCP server: remit.md MCP Server
Rail | Status | Networks |
x402 | ✅ Live | Base, Polygon, Arbitrum, World Chain, Solana (USDC) |
direct_crypto_auto | ✅ Live | 13 asset families: EVM/stablecoins (ETH, USDC, USDT), BTC, BCH, LTC, DOGE, SOL, TRX, XRP, XLM, ALGO, DOT, ZEC, XMR |
direct_crypto_manual | ✅ Live | Operator-confirmed fallback |
MPP/Tempo | ✅ Live | Settlement-proven |
Service | Price | Description |
| $0.01 | Search Twitter/X posts via public syndication |
| $0.01 | Search Reddit posts and comments |
| $0.01 | Get a Reddit post with top comments |
| $0.01 | Get transcript/subtitles for a YouTube video |
| $0.01 | Search Hacker News stories and comments |
Service | Price | Description |
| $0.01 | Current stock price, OHLC, 52-week range (Yahoo Finance) |
| $0.01 | Historical OHLCV candles (Yahoo Finance) |
| $0.01 | Gold, silver, oil, copper, wheat, etc. |
| $0.01 | Foreign exchange rates for any pair |
| $0.01 | Search SEC EDGAR filings by ticker/query |
Service | Price | Description |
| $0.01 | Webhook delivery with retry, HMAC signing, delivery proof |
| $0.01 | Schedule one-shot or recurring HTTP tasks via systemd |
| $0.01 | Playwright browser automation: navigate, click, fill, extract |
| $0.01 | Extract structured JSON from any URL using fetch + LLM |
| $0.01 | Detect content changes at a URL (hash-based diff) |
Service | Price | Description |
| pay-per-call | OpenAI-compatible chat completions gateway |
| free | List available model aliases |
| $0.0005 | 768-dim vectors (Ollama nomic-embed-text) |
| $0.03 | Stable Diffusion v1.5 on GPU |
| pay-per-call | Bounded agent-task endpoint (local runtime) |
| $0.02 | Multi-model consensus via llm-judge |
| $0.01 | Neutral judge for multi-model consensus |
| $0.005 | Local LLM summarization |
| $0.002 | Sentiment analysis |
| $0.003 | Language translation |
| $0.001 | Language detection |
Service | Price | Description |
| $0.005 | SearXNG aggregator (20+ engines) |
| $0.002 | Raw content + headers from any URL |
| $0.001 | Quick HEAD liveness check |
| $0.001 | robots.txt compliance check |
| $0.001 | IP → country/city/ISP |
| $0.001 | DNS records (A/AAAA/MX/TXT/NS) |
| $0.002 | Domain registration data |
| $0.002 | Extract hyperlinks from a page |
| $0.002 | Clean markdown extraction |
| $0.005 | Headless Chromium screenshot |
Service | Price | Description |
| $0.005 | URL/wallet reputation (URLhaus + TLS) |
| $0.002 | SSL certificate chain + expiry |
| $0.001 | Security header analysis |
| $0.005 | Subdomain discovery via CT logs |
| $0.002 | TLS version + cipher suite audit |
| $0.01 | Prompt injection vulnerability scan |
| $0.05 | MCP server security audit |
Service | Price | Description |
| $0.002 | Verified ABI from block explorers |
| $0.005 | EVM RPC proxy (Base/Ethereum) |
Service | Price | Description |
| $0.01 | Python in Docker sandbox (no network) |
| $0.005 | Text extraction from PDFs |
| $0.005 | Image text extraction (Tesseract) |
| $0.001 | QR code PNG generation |
| $0.03 | Text-to-image (Stable Diffusion) |
Service | Description |
| SHA-256/MD5/BLAKE2 hashing |
| Encode/decode base64 |
| UUID v1/v3/v4/v5 |
| Current time in all formats |
| Secure random data |
| JSON Schema validation |
| Infer JSON Schema from sample |
| Text comparison/diff |
| Language detection |
| Crypto/forex prices |
See pricing.json for all 124 services.
Surface | URL |
AI manifest |
|
x402 discovery |
|
OpenAPI spec |
|
llms.txt |
|
Pricing |
|
Status |
|
Agent catalog |
|
Component | Hardware |
Payment edge | T620 (48 cores, 377GB RAM, 24/7) |
GPU (SD + embeddings) | T620 GTX 1080 8GB |
LLM inference | T620 Ollama (24 models) |
Code execution | Docker isolated containers |
Web search | SearXNG (self-hosted, 20+ engines) |
Email relay | Postfix |
Node | Alienware RTX 3080 8GB (secondary) |
MIT
Return DDG's machine-readable service/rail/MCP status document.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies a read operation returning a document, but doesn't confirm idempotency, safety, or side effects. Adequate for a simple parameterless tool.
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?
Single sentence, front-loaded with key information, no wasted words.
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?
Given zero parameters and existence of output schema, description is mostly complete. Could mention return format (JSON) but not critical.
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?
No parameters and schema coverage is 100% (empty). Baseline score of 4 is appropriate as description adds no parameter info.
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?
Clear verb 'Return' and specific resource 'DDG's machine-readable service/rail/MCP status document'. Distinct from sibling tools like ddg_checkout_conformance or ddg_mcp_security_profile.
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?
No explicit guidance on when to use vs alternatives, but the purpose is straightforward and siblings are clearly different, so implication is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return DDG's public checkout conformance profile without spending money.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool is non-destructive ('without spending money'), providing key behavioral context. However, it lacks details on idempotency or rate limits, which are minor for this simple read operation.
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?
Single sentence with clear verb and resource. No unnecessary words. Front-loaded information.
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?
Given no parameters, presence of output schema, and simple operation, the description fully covers the tool's purpose and behavior. No additional context needed.
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?
No parameters exist, so description cannot add meaning beyond the schema. The baseline for zero-parameter tools is 4.
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 clearly states the verb 'Return' and the resource 'DDG's public checkout conformance profile'. It distinguishes this tool from siblings that involve other operations like fetching resources, listing models, or submitting orders.
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 implies usage for checking conformance without cost but does not explicitly provide when to use or when not to use compared to alternatives. No exclusion criteria or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch an allowlisted DDG public manifest/doc by id or ddg:// URI with redaction and size caps.
| Name | Required | Description | Default |
|---|---|---|---|
| resource | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions redaction and size caps, but omits critical behaviors like authentication, rate limits, error handling, or side effects for a mutation-free fetch. Incomplete for a tool with zero annotations.
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?
Single sentence of 17 words, front-loaded with action and context. No wasted words; every element adds information (allowlisted, redaction, size caps).
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?
With only one parameter and an output schema, the description covers the essential purpose and input format. Mentions redaction/size caps which are implied constraints. Could be improved by noting the output schema existence or providing a usage example, but overall adequate.
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?
Schema coverage is 0%, but description adds value by specifying that the `resource` parameter can be an id or ddg:// URI. This goes beyond the bare schema definition. Still, no constraints or examples are given.
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?
Clearly states the verb (Fetch), resource (allowlisted DDG public manifest/doc), and input format (id or ddg:// URI). Distinguishes from sibling ddg_public_resource_index by specifying retrieval of a single resource by identifier.
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?
No explicit guidance on when to use this tool versus alternatives like ddg_public_resource_index. Does not mention prerequisites or context such as first obtaining a resource ID from index.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List free-seat status plus requestable local runtimes such as Ollama, llama.cpp, LM Studio, OpenAI-compatible servers, and vLLM.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states what the tool lists, but does not mention side effects, authentication needs, rate limits, or whether the operation is read-only. The name implies a read operation, but that is implicit.
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 a single concise sentence that contains all necessary information without fluff. It is front-loaded with the verb and key resources.
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?
Given the tool has no parameters and includes an output schema, the description is sufficient for understanding the tool's purpose. It does not explain return values, but the output schema presumably covers that. Some additional context about when to list runtimes versus other list tools would improve completeness.
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?
There are zero parameters, so the schema provides 100% coverage. The description adds value by clarifying the content of the list (free-seat status and runtimes), which goes beyond just the schema.
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 clearly states the verb 'List' and the resources 'free-seat status' and 'requestable local runtimes', with specific examples (Ollama, llama.cpp, LM Studio, etc.). This distinguishes it from sibling tools like ddg_list_models and ddg_list_services.
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 provides no guidance on when to use this tool versus alternatives. Sibling tools exist for listing models, services, public resources, etc., but no explicit when/when-not or alternative names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List local/free Ollama models and queryable paid/account-backed route labels.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states what is listed without mentioning side effects, authentication needs, or whether the operation is read-only. For a list tool this is minimal transparency.
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 a single sentence of 12 words, front-loaded with the action verb, and contains no filler. Every word adds value, making it optimally concise.
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?
Given the tool has zero parameters and an output schema (which covers return values), the description is reasonably complete for a simple list operation. It names two categories of output, though it could mention if the list is exhaustive or requires any prior setup.
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?
Since there are zero parameters, the schema coverage is 100% and the description is not required to add parameter details. The description adds value by specifying the types of models listed (local/free and paid/account-backed), which is helpful context beyond the empty schema. Baseline 4 applies per guidelines.
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 uses a specific verb 'List' and identifies two concrete resources: 'local/free Ollama models' and 'queryable paid/account-backed route labels'. It clearly distinguishes from siblings like ddg_request_ollama_model (requesting) and ddg_run_paid_model (running), making the tool's purpose unambiguous.
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 implies usage for discovering available models before requesting or running them, but it does not explicitly state when to use this tool versus alternatives like ddg_list_local_runtime_options or ddg_public_resource_index. No when-not-to-use scenarios are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List DDG live/manual services from the public pricing and catalog surfaces.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It only states that it lists services from public surfaces, implying a read-only operation. It does not disclose auth requirements, rate limits, error conditions, or what happens with no results.
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 a single, front-loaded sentence with no filler. Every word earns its place, clearly stating what the tool does and the data sources.
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 zero-parameter tool with an output schema, the description adequately explains the tool's purpose and data sources. It could be slightly more specific about which exact surfaces are queried, but overall it is sufficiently complete.
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 has zero parameters with 100% coverage (empty schema). The description does not add parameter info, but baseline is 3 per guidelines. No parameters means no additional semantic detail is needed.
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 clearly states the verb 'List' and the resource 'DDG live/manual services' from specific surfaces (public pricing and catalog). It is specific enough to differentiate from siblings like ddg_list_models or ddg_fetch_public_resource, but does not explicitly contrast with alternatives.
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 provides no guidance on when to use this tool versus alternatives, no context on prerequisites or exclusions. The only implied usage is that it lists services, but no when-not or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return this MCP wrapper's local security controls and publication gates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns information (read behavior), but does not explicitly state safety, side-effects, or authentication needs. Since no annotations are provided, the description carries full burden, and it only partially fulfills it.
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?
A single, front-loaded sentence that conveys the tool's purpose without any waste. Every word is meaningful and 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?
Given the tool has no parameters and an output schema exists, the description is adequate. It explains what is returned. Minor omission: could mention it is a safe read operation, but not necessary.
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?
There are no parameters, and schema coverage is 100%, so the description does not need to add param info. It adds value by describing the return value (security controls and publication gates), which is helpful beyond the empty schema.
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 clearly states the tool returns 'local security controls and publication gates' for the MCP wrapper, using a specific verb and resource. It distinguishes from sibling tools by focusing on the wrapper's local security, which is unique among the listed siblings.
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?
No guidance on when to use this tool versus alternatives. The description does not mention context, prerequisites, or exclusions, leaving the agent without decision support for tool selection among similar security-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch an agent-scoped DDG order artifact when ready.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | ||
| agent_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must carry behavioral burden. It implies readiness check ('when ready') but fails to disclose caching, blocking, polling, error handling, or what happens if artifact is not ready.
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?
Single sentence with no redundancy, but overly terse – could be expanded with minimal structure to cover key details without becoming verbose.
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?
Despite having output schema, description lacks guidance on when to call vs siblings, what triggers 'ready', and parameter interaction; insufficient for a two-parameter tool with no annotations.
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?
Schema description coverage is 0%; description only hints at 'agent-scoped' for agent_id and 'order artifact' for order_id, without explaining constraints, formats, or the role of optional agent_id.
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 uses a specific verb 'Fetch' and resource 'DDG order artifact', with qualifiers 'agent-scoped' and 'when ready', clearly distinguishing it from sibling tools like ddg_order_status or ddg_submit_order.
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?
No guidance on when to use this tool versus alternatives, such as ddg_order_status for order state or ddg_submit_order for creation. Absence of any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll an agent-scoped DDG order status URL.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | ||
| agent_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as read-only nature, authentication requirements, or side effects. It only states the action without elaboration.
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 a single concise sentence, but it is overly terse given the lack of other documentation. It could include more detail while remaining concise.
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?
With 2 parameters and no annotations, the description is incomplete. It does not cover return values, error handling, or how it fits with sibling tools, leaving the agent uninformed.
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?
Schema description coverage is 0%, and the description does not explain the parameters. 'order_id' and 'agent_id' are not clarified regarding format, meaning, or how 'agent-scoped' 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 uses the specific verb 'Poll' and resource 'DDG order status URL', clearly indicating the tool's function. It distinguishes from siblings like ddg_submit_order, but lacks detail on the scope.
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?
No guidance on when to use this tool versus alternatives like ddg_agent_status or ddg_submit_order. The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List allowlisted DDG public manifests/docs available as MCP resources.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action, missing details like side effects (none expected), update frequency, authorization needs, or what 'allowlisted' means. The simplicity reduces harm, but transparency is minimal.
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?
Single, efficient sentence with no fluff. Every word contributes to meaning. Ideal length for a parameterless list tool.
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?
Output schema exists, so return value details are covered. However, the description lacks context like how to use the list (e.g., with ddg_fetch_public_resource) or what format the list is in. Adequate but minimal for the tool's role in the workflow.
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?
No parameters exist, so schema coverage is 100%. The description adds no param info, which is acceptable, but it could hint at output structure. Baseline for 0 params is 4.
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 uses a specific verb ('List') and resource ('allowlisted DDG public manifests/docs'), clearly distinguishing it from the sibling tool 'ddg_fetch_public_resource' which fetches individual resources.
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 implies usage (list before fetch) but provides no explicit when-to-use, when-not-to-use, or alternative guidance. The purpose is clear but the usage context is not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the payment challenge for a supported DDG protected route without executing backend compute.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | /v1/model/chat-completions | |
| agent_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It notes the tool does not execute backend compute, which is a key behavioral trait. However, it lacks disclosure on side effects, authentication requirements, or error conditions (e.g., unsupported path).
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?
A single sentence that is front-loaded with the primary action and outcome. Every word serves a purpose, with no extraneous information.
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?
The description is minimal for a tool related to payment challenges in a complex system. Despite having an output schema, the description does not indicate what the returned challenge looks like or how it should be used. More details about supported routes or prerequisites would improve completeness.
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 and two parameters (path, agent_id), the description offers no explanation of their meaning or purpose. This leaves the agent without guidance on how to set these parameters, especially since path has a default and agent_id is nullable.
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 clearly states it returns a payment challenge for a DDG protected route without executing backend compute. The verb 'Return' and specific resource 'payment challenge' are well-defined, but it does not differentiate from sibling tools like ddg_run_paid_model or ddg_submit_order.
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 implies it is a pre-payment step by saying 'without executing backend compute,' but it provides no explicit guidance on when to use this tool versus alternatives like ddg_run_paid_model or ddg_submit_order. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe the planned free receipt-verification tool contract.
This is intentionally marked not-live until /v1/receipt-verify is implemented
and backed by payment-edge audit/state reconciliation.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | ||
| receipt_hash | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description transparently communicates that the tool is a design contract and not yet functional. This key behavioral trait (non-live, planning stage) is clearly stated, helping the agent avoid misuse.
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 concise sentences: the first states the tool's purpose, the second adds essential context about liveness. No redundant or irrelevant information.
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?
Given that this is a design tool with an output schema, the description should mention what the output represents (e.g., a contract specification). It is silent on the output, leaving the agent to guess. However, for a non-live planning tool, the core purpose and limitation are covered.
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 adds no information about the two parameters (order_id, receipt_hash). The agent only knows their names and types, missing details on format, purpose, or constraints.
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 'Describe the planned free receipt-verification tool contract,' which is a clear verb-resource pair indicating a design/planning tool. It distinguishes itself from sibling operational tools like ddg_order_status and ddg_submit_order by being explicitly non-live and design-focused.
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 provides context on when not to use the tool ('intentionally marked not-live until /v1/receipt-verify is implemented'). However, it does not explicitly state when to use it or compare it to alternative tools for receipt verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queue a local model/runtime request. This never auto-downloads by public request.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| reason | No | requested by agent swarm | |
| expected_size_gb | No | ||
| runtime | No | ollama | |
| agent_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that it 'never auto-downloads by public request,' which is a key behavioral constraint. However, it lacks details on side effects, error conditions, or required permissions, and annotations are absent.
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 short and front-loaded, but it is under-specified. It could include more detail without being verbose, so it scores average on conciseness.
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?
Given the tool has 5 parameters with no documentation and no behavioral annotations, the description is incomplete. It fails to provide sufficient context for an agent to use the tool correctly.
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 fails to explain any of the 5 parameters. It does not add meaning beyond the parameter names in the schema, leaving the agent without guidance on how to use them.
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 clearly states it queues a local model/runtime request, which distinguishes it from list tools like ddg_list_models and run tools like ddg_run_paid_model. The additional note about no auto-download adds specificity.
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?
No guidance on when to use this tool versus alternatives such as ddg_run_paid_model or ddg_order_artifact. No prerequisites or conditions for use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a paid model/chat or agent-run route after caller supplies valid payment headers.
| Name | Required | Description | Default |
|---|---|---|---|
| route | Yes | ||
| prompt | Yes | ||
| payment_headers | No | ||
| agent_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'paid model' implying cost but does not describe idempotency, failure modes, rate limits, or whether the operation is destructive. The description is insufficient for an agent to understand side effects.
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 a single sentence, making it concise. However, it could be structured to separate purpose from preconditions. The brevity leaves out important details.
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?
Given the tool's complexity (payment, model execution, multiple parameters) and the lack of annotations, the description is incomplete. It does not cover return values (though output schema exists), error scenarios, or required payment header format. An AI agent would lack sufficient context for reliable use.
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?
Schema description coverage is 0%, meaning the description adds no meaning to the parameters. The description does not explain 'route', 'prompt', 'payment_headers', or 'agent_id'. For a tool with 4 parameters, this is a critical gap, and the description fails to compensate for the low coverage.
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 clearly states the tool runs a paid model/chat or agent-run route, with the precondition of valid payment headers. The verb 'run' and noun 'paid model' make the action specific. However, it does not explicitly differentiate from sibling tools like ddg_request_ollama_model or ddg_list_models, leaving some ambiguity.
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 only mentions a precondition (valid payment headers) but provides no guidance on when to use this tool versus alternatives. It does not explain when not to use it or refer to sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return DDG's AI-agent cybersecurity service catalog.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It only says 'Return... catalog,' implying a read operation, but lacks details on side effects, permissions, or data scope.
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 a single, concise sentence with no unnecessary words. It is front-loaded with the core action.
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?
With zero parameters and an output schema present, the description could still be more informative about what the catalog contains. It is adequate but minimal.
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 tool has zero parameters, and the input schema coverage is 100%. The description adds no param info, which is acceptable since none are needed. Baseline score of 4 is appropriate.
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 clearly states the tool returns a specific catalog (DDG's AI-agent cybersecurity service catalog), distinguishing it from sibling tools like ddg_list_services or ddg_public_resource_index.
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?
No guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. Usage is only implied by the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the free static-only DDG AI skill/workflow safety scan.
The scan never executes submitted code and redacts secret-like evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_markdown | Yes | ||
| label | No | mcp-client-submission | |
| agent_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the scan never executes code and redacts secret-like evidence, providing key safety and privacy behaviors.
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, front-loaded with purpose, no wasted words. Highly efficient.
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?
Missing parameter descriptions and usage prerequisites, but output schema exists and safety scan concept is simple. Adequate but not comprehensive.
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?
Schema coverage is 0%, but description adds no explanation for the three parameters (skill_markdown, label, agent_id). Agent cannot infer their meanings from description alone.
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?
Description clearly states the tool runs a safety scan, with specific verb 'run' and resource 'DDG AI skill/workflow'. No sibling tool shares this purpose.
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?
Indicates the scan is static-only and never executes code, but does not explicitly state when to use this tool versus alternatives. However, sibling tools are distinct, so context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a paid operator-reviewed DDG order after caller supplies valid payment headers/proof.
| Name | Required | Description | Default |
|---|---|---|---|
| service_id | Yes | ||
| request | Yes | ||
| payment_headers | No | ||
| agent_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It indicates that the order is 'operator-reviewed' and requires payment proof, which are useful behavioral traits. However, it omits details about side effects, idempotency, authentication needs, or error conditions, leaving significant gaps.
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 a single, efficient sentence without excess words. However, it omits important details that could be included without harming conciseness, so it is not maximally helpful.
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?
Given 4 parameters with no schema descriptions, no annotations, and an existing output schema, the description fails to cover parameter meanings, output expectations, or error handling. It is too brief to be considered complete.
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?
Schema description coverage is 0%, and the description provides no information about any of the 4 parameters. The agent must rely solely on parameter names and types, which is insufficient for correct usage.
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 uses a specific verb ('Submit'), identifies the resource ('paid operator-reviewed DDG order'), and includes a condition ('after caller supplies valid payment headers/proof'). This clearly distinguishes the tool from siblings like `ddg_order_status` or `ddg_quote_payment`.
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 explicitly states when to use the tool: after the caller has valid payment headers/proof. However, it does not mention when not to use it or provide alternatives, missing some guidance for the agent to differentiate from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exercise the one-cent DDG transaction smoke-test route with caller-supplied payment headers.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_headers | No | ||
| agent_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only indicates a 'smoke-test' implying non-production testing, but doesn't explain side effects, authentication needs, or error behaviors. Minimal transparency.
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 a single, efficient sentence of 12 words with no fluff. However, it could be slightly restructured to front-load the key action, but it's already concise.
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?
Given the tool has an output schema and two parameters, the description does not explain return values, the role of agent_id, or how payment_headers should be structured. It lacks completeness for safe invocation.
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?
Schema coverage is 0%, placing burden on description. It mentions 'caller-supplied payment headers' corresponding to one parameter, but the other parameter 'agent_id' is ignored. No details on parameter formats or constraints.
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 clearly states the verb 'exercise' and the specific resource 'one-cent DDG transaction smoke-test route', making the tool's purpose unambiguous. It names the resource distinctively, aiding differentiation from sibling tools.
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?
No guidance is provided on when to use this tool versus alternatives, nor any context about prerequisites or exclusions. The description only states what the tool does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0ddg_agent_statusddg_checkout_conformanceddg_fetch_public_resourceddg_list_local_runtime_optionsddg_list_modelsddg_list_servicesddg_mcp_security_profileddg_order_artifactddg_order_statusddg_public_resource_indexddg_quote_paymentddg_receipt_verify_designddg_request_ollama_modelddg_run_paid_modelddg_security_service_catalogddg_skill_safety_scanddg_submit_orderddg_tx_smoke_testEach tool has a clearly distinct purpose, with no overlapping functionality. Even related tools like ddg_list_local_runtime_options, ddg_list_models, and ddg_list_services target different aspects of the system.
All tools follow a consistent 'ddg_verb_noun' pattern using lowercase with underscores. The naming is uniform and predictable, making it easy for an agent to infer tool behavior from the name.
With 18 tools, the count is slightly above the ideal range of 3-15, but the broad scope of the server (status, orders, models, security, payments, etc.) justifies the number. Each tool covers a distinct function without feeling bloated.
The tool set covers a wide range of operations but lacks some lifecycle management features. For example, there is no tool to list orders or update/cancel them, and no tool to manage models beyond requesting. This leaves some potential dead ends for workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Payment decisions, durable evidence, x402 resource discovery and live gateway status for AI agents.
Paid token risk and security intelligence for AI agents over MCP with x402 payments.
Machine-service catalogue, payment hand-off and free market discovery for autonomous AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/daedalusdevelopmentgroup/ddg-agent-payable-services'
If you have feedback or need assistance with the MCP directory API, please join our Discord server