Agent Revenue Network

by dev.workers.nadirventurelabs.agent-revenue-network

Verified Translation · Canadian French / Spanish / French

verified_translation

Read-onlyIdempotent

Discover QA-verified translation for up to 2,000 characters on calibrated EN→ES, EN→FR, ES→FR and FR→ES routes. sourceLang defaults to EN, targetLang selects ES or FR, protectedTerms must remain unchanged, and optional context, domain or locale hints guide approved memory and wording; live locale research is excluded. This free MCP discovery call does not execute the advertised capability and does not charge; it returns the exact x402 endpoint, price and payment guide for execution.

Input Schema

Name	Required	Description	Default
`text`	Yes	Source text or Markdown to translate.
`domain`	No	Optional domain label used for approved translation-memory lookup.
`locale`	No	Optional locale hint such as ES-419 or fr-CA. This verified tier does not yet perform live web locale research.
`context`	No	Optional tone/domain context.
`sourceLang`	No	Source language.	EN
`targetLang`	Yes	Target language. The source/target pair must be a currently calibrated route.
`protectedTerms`	No	Terms/names that must remain unchanged.

Output Schema

Name	Required	Description
`price`	Yes
`method`	Yes	HTTP method for paid execution.
`endpoint`	Yes	Canonical absolute ARN HTTP URL to POST the same tool arguments to for paid execution.
`protocol`	Yes	Payment protocol required by the HTTP execution endpoint.
`instruction`	Yes	How to execute the capability after receiving the payment requirement.
`paymentGuide`	Yes	Public setup guide with a working x402 v2 Base-mainnet client example.
`paymentRequired`	Yes	Always true for paid ARN capabilities exposed over MCP.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 20, 2026

changedOutput schema / properties / endpoint / description

Previous value: -"ARN HTTP path to POST the same tool arguments to for paid execution."New value: +"Canonical absolute ARN HTTP URL to POST the same tool arguments to for paid execution."

addedOutput schema / properties / endpoint / format
```
Added value: +"uri"
```

addedOutput schema / properties / method

Added value: +{
+  "const": "POST",
+  "description": "HTTP method for paid execution.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "paymentRequired",
-  "protocol",
-  "endpoint",
-  "price",
-  "paymentGuide",
-  "instruction"
-]New value: +[
+  "paymentRequired",
+  "protocol",
+  "method",
+  "endpoint",
+  "price",
+  "paymentGuide",
+  "instruction"
+]

Changed2 schema fields changedOct 8, 2026

addedOutput schema / properties / paymentGuide

Added value: +{
+  "description": "Public setup guide with a working x402 v2 Base-mainnet client example.",
+  "format": "uri",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "paymentRequired",
-  "protocol",
-  "endpoint",
-  "price",
-  "instruction"
-]New value: +[
+  "paymentRequired",
+  "protocol",
+  "endpoint",
+  "price",
+  "paymentGuide",
+  "instruction"
+]

Changed1 schema field changedOct 8, 2026

changedInput schema / properties / locale / description

Previous value: -"Optional locale hint such as ES-419. This verified tier does not yet perform live web locale research."New value: +"Optional locale hint such as ES-419 or fr-CA. This verified tier does not yet perform live web locale research."

AddedOct 4, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description is consistent with them. It then adds genuinely non-obvious behavior beyond the annotations: no charge, no execution, and a return payload of x402 endpoint plus price and payment guide. That is exactly the kind of behavioral disclosure an agent needs before invoking.

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?

Three dense sentences that front-load the capability and route scope before the crucial 'this does not execute' caveat. Some redundancy with the schema (routes and the 2,000-character limit appear in both), but no filler sentences.

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 payment/x402 discovery tool, the description covers the non-obvious essentials: no execution, no charge, and the exact return contract. An output schema exists so return values needn't be detailed, yet the description still summarizes them helpfully. Nothing an agent needs to call this correctly 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% and the schema already documents every parameter, including the sourceLang default and the protectedTerms semantics. The description largely restates this (sourceLang defaults to EN, protectedTerms unchanged) plus a light note that context/domain/locale guide memory and wording. Marginal additive value, 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 (Discover) and resource (QA-verified translation), names the calibrated routes, and the 2,000-character scope. It is distinguishable from both the sibling tools and, crucially, from the actual execution capability. The wording 'Discover' is slightly euphemistic for what is really a pricing/endpoint lookup, but the third sentence removes the ambiguity.

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

Usage Guidelines4/5

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

The description clearly frames the discovery context: it is 'free', 'does not execute the advertised capability and does not charge', and returns the endpoint/price/payment guide, which tells the agent when this call is the right choice versus the eventual paid execution. No sibling tools overlap, so no exclusions are needed. It stops short of an explicit 'use this before X' routing statement.

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

All Agent Revenue Network tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?