Universal Data API

api_growth_distribution

Read-onlyIdempotent

Agent Growth Autopilot — generate a channel-matched, reusable organic distribution plan for customer-owned API, MCP or developer software; records approvals and channel requirements without claiming submission. One call costs 0.01 USDC on Base x402; customer-owned provider credentials use X-Provider-Key header where needed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>",
      "name": "<name>",
      "kind": "<kind>"
    },
    "name": "api_growth_distribution"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	HTTPS public product homepage owned or controlled by the customer
`kind`	Yes	Product type: api, mcp or software
`name`	Yes	Customer product name (2–90 characters)
`category`	No	Optional developer-focused category; informational only
`description`	No	Truthful 15–600 character functional product description
`api_endpoint`	No	Optional public HTTPS URL of an actual x402-paid API, for x402-specific discovery channels
`mcp_endpoint`	No	Optional actual HTTPS Streamable HTTP MCP endpoint

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, yet the description still adds genuinely useful behavioral facts: a per-call cost of 0.01 USDC on Base x402 and a required X-Provider-Key header for customer-owned credentials. The phrase 'records approvals and channel requirements' is slightly in tension with readOnlyHint=true, since 'records' implies persistence, but the same sentence clarifies it produces a plan 'without claiming submission', which reads as returning content rather than mutating state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences that front-load the core action before cost and credential details. The 'Agent Growth Autopilot' label and some hyphenated marketing phrasing could be trimmed, but there is no filler and each clause carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a seven-parameter, non-destructive planning tool with no output schema, the description covers scope, the negative guarantee (no submission), the paid-call cost and the credential mechanism. The main residual gap is what the returned plan looks like and whether 'records approvals' persists anything, but overall it is sufficient to call the tool correctly.

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 description coverage is 100%, so every one of the seven parameters is already documented in the schema and the baseline is 3. The description only reinforces the 'kind' semantics (api, MCP or developer software) and adds an auth header, which is not a parameter; it supplies no additional meaning for url, name, category, description, api_endpoint or mcp_endpoint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and artifact: 'generate a channel-matched, reusable organic distribution plan' for 'customer-owned API, MCP or developer software'. That is far more specific than the tool name alone, and no sibling in the list covers organic distribution planning, so differentiation is implicit rather than stated. The branding phrase 'Agent Growth Autopilot' adds noise but the operative sentence is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Eligibility is implied by 'customer-owned API, MCP or developer software', which tells the agent the target resource type, and 'without claiming submission' hints at a boundary. However, there is no explicit when-to-use / when-not-to-use framing and no alternative tool is named for adjacent needs such as submission or paid-channel placement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Universal Data API tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?