YRUZ x402 tools

YRUZ RealityGraph Conflicts (0.02 USDC)

reality_get_conflicts

Read-onlyIdempotent

Source-conflict report for an entity: properties that should hold one current value but hold several (and whether a preferred rank settles it), time series with different values for the same date, deprecated claims with the stated reason, and core facts without a reference or only imported from Wikipedia. Every listed value carries its references so an agent can judge. Price: 0.02 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":"reality_get_conflicts"}. Same tool over HTTP: https://yruz.one/api/reality/conflicts?id=Q312

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

Input Schema

Name	Required	Description	Default
`id`	Yes	Wikidata id (required)
`lang`	No	language of labels, 2-3 letters (default en)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026
- addedInput schema / properties / id / examples
```
Added value: +[
+  "Q312"
+]
```
AddedOct 27, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond the standard annotations by detailing the financial transaction process (0.02 USDC), the payment mechanisms (x402, no API key), and the exact failure behavior when payment is missing (returns x402 PaymentRequired). This is critical for operational success and risk management.

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?

While long due to the high operational complexity (payment, rates, multiple conflict types), every sentence serves a vital function. The critical usage and payment information is presented early, making the structure highly efficient for an agent needing operational guidance.

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?

The tool is highly complex due to its cost, payment logistics, and specific data formats (Wikidata IDs). The definition is entirely complete, providing all necessary information to attempt the call and handle potential operational failures, including informing the agent about the cost per call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description clarifies the required 'id' is a Wikidata ID and explains the purpose of the optional 'lang' parameter as the language code for labels. Since schema coverage is 100%, this primarily provides context rather than defining parameters, thus a high score is appropriate.

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 provides an exhaustive definition of the tool's output (source-conflict report), listing exactly what types of discrepancies it addresses like value conflicts, time series differences, and lack of references. This is highly specific and clearly separates it from general entity retrieval tools.

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 tool description clearly defines its scope—finding conflicts—and provides operational usage guidance including the required calling format and the equivalent HTTP endpoint. This helps agents determine if the tool is necessary versus a general 'get' operation.

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.