Skip to main content
Glama
Sign In

BuiltWith

by io.github.builtwith
OverviewDiscussionsAdmin

x402-recommendations-api

Technology recommendations for a domain. Deducts prepaid credits from a reusable key.

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": {
      "lookup": "<lookup>",
      "creditKey": "<creditKey>"
    },
    "name": "x402-recommendations-api"
  }
}

Input Schema

NameRequiredDescriptionDefault
lookupYes
creditKeyYesReusable prepaid key returned by x402-credit-purchase

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare this is not read-only but not destructive and closed-world, so the safety profile is largely covered. The description does add genuinely useful context beyond the annotations: the call consumes prepaid credits from a reusable key, meaning invocation has a monetary cost. It does not say how many credits are charged, whether credits are still spent on failure or empty results, or what happens with an exhausted key.

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 short sentences with no filler; the resource is front-loaded and the billing behavior follows. The terseness borders on under-specification rather than verbosity, which is the lesser flaw, but nothing is wasted.

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

Completeness3/5

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

For a two-parameter, non-destructive paid endpoint with no output schema, the definition covers the essentials of what it returns and that it costs credits. It leaves material gaps for an agent planning a call: credit cost per invocation, failure/refund behavior, and the expected format of 'lookup'.

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 50%: 'creditKey' is fully documented in the schema, while 'lookup' has no description at all. The description partially compensates by implying the lookup is a domain via 'for a domain', but it gives no format details (bare domain vs URL vs subdomain). Baseline 3 is warranted given the schema carries half the burden.

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

Purpose3/5

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

The description names the resource ('Technology recommendations for a domain'), which lets an agent infer the tool returns tech stack suggestions for a supplied domain. However it is a noun phrase with no explicit verb, and it does not distinguish this paid variant from the sibling 'recommendations-api' or explain what a 'recommendation' contains. Purpose is inferable but not sharp.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool, when not to, or which sibling to prefer (e.g. the free 'recommendations-api' versus this credit-charging x402 variant). The only guidance is implicit in the name prefix and the mention of credit deduction, which an agent must interpret on its own.

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

All BuiltWith toolsInspect
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