YRUZ x402 tools

YRUZ DependencyPulse Dependency Tree (0.01 USDC)

deps_get_dependency_tree

Read-onlyIdempotent

Bounded transitive dependency graph of an npm package version: every node with the declared range, the resolved version (highest published version satisfying the range, as a fresh install without a lockfile would pick), depth, parent, deprecation, and the OSV advisories that match it. Limits are enforced and reported: nothing is silently cut. Price: 0.01 USDC per call, paid with x402 (USDC on Base or Solana, no account, no API key); invalid input is refused before payment and a failed run is never charged. Without a payment the tool returns the x402 PaymentRequired. How to call it: get_example {"tool":"deps_get_dependency_tree"}. Same tool over HTTP: https://yruz.one/api/deps/tree?name=express&depth=2

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": {
      "name": "<name>"
    },
    "name": "deps_get_dependency_tree"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	npm package (required), e.g. express
`depth`	No	levels below the package, 1-4 (default 3)
`version`	No	version or range (default latest)
`optional`	No	1 to follow optionalDependencies (default 0)
`max_nodes`	No	graph size cap, 10-250 (default 150)

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026
- addedInput schema / properties / depth / examples
```
Added value: +[
+  "2"
+]
```
- addedInput schema / properties / name / examples
```
Added value: +[
+  "express"
+]
```
AddedOct 27, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already establish a safe, read-only, idempotent, open-world operation, and the description adds substantial behavioral context: limits are enforced and reported without silent truncation, invalid input is refused before payment, failed runs are not charged, and missing payment returns x402 PaymentRequired. It also discloses the price, payment rails, and no-account/no-API-key model.

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?

The description is front-loaded with the core purpose and return contents, then moves to limits, payment, refusal/failure behavior, and invocation details. It is dense rather than padded, though the HTTP endpoint and repeated payment details make it slightly longer than strictly necessary.

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?

For a paid external graph tool with no output schema, the description is complete enough: it enumerates the node-level return information, explains limit reporting, and covers payment, invalid input, failure, and PaymentRequired behavior. Combined with annotations covering safety and idempotency, no critical execution context is missing.

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 the schema already documents name, depth, version, optional, and max_nodes. The description adds context about resolved versions and graph limits, but it does not add parameter-specific meaning beyond what the schema provides, so the baseline 3 is appropriate.

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 states a specific verb and resource: a bounded transitive dependency graph for an npm package version, including per-node fields such as range, resolved version, depth, parent, deprecation, and matching OSV advisories. It is clearly distinct from audit/history/advisory sibling tools in substance, but it never explicitly names which sibling to use instead for adjacent tasks.

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?

The intended use is implied by the description of the graph contents, but there is no explicit guidance such as when to choose this over deps_get_package, deps_get_version_history, or deps_audit_project. Payment and call mechanics are covered, but routing guidance versus alternatives is left to inference.

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

All YRUZ x402 tools 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.