AZPay Monetize — Sepolia Sandbox

Negotiate price

negotiate_price

Use this to propose a test-USDC unit price and a quantity, or to accept the tier price. Use get_quote if you only need the list price. Required input: resource_id. Optional: unit_price_usdc, quantity from 1 to 100, and session_id. Returns an accepted offer or a counteroffer with offer_id and expiry. Does not pay.

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

Input Schema

Name	Required	Description
`quantity`	No	Optional number of paid accesses, from 1 to 100. Defaults to 1.
`session_id`	No	Optional session id from an earlier negotiate_price call for the same resource.
`resource_id`	Yes	Required. Resource id from search_resources or get_quote.
`unit_price_usdc`	No	Optional offered unit price in test USDC, for example 0.008. Omit it to ask for this quantity's price.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedNov 9, 2026

removedInput schema / properties / id

Removed value: -{
-  "description": "Deprecated alias of resource_id.",
-  "maxLength": 120,
-  "type": "string"
-}

removedInput schema / properties / preco_usdc

Removed value: -{
-  "description": "Deprecated alias of unit_price_usdc.",
-  "maxLength": 32,
-  "type": "string"
-}

removedInput schema / properties / quantidade

Removed value: -{
-  "description": "Deprecated alias of quantity.",
-  "maximum": 100,
-  "minimum": 1,
-  "type": "integer"
-}

changedInput schema / properties / quantity / description

Previous value: -"Number of paid accesses, from 1 to 100."New value: +"Optional number of paid accesses, from 1 to 100. Defaults to 1."

changedInput schema / properties / resource_id / description

Previous value: -"Resource id."New value: +"Required. Resource id from search_resources or get_quote."

addedInput schema / properties / resource_id / minLength
```
Added value: +1
```

removedInput schema / properties / sessao

Removed value: -{
-  "description": "Deprecated alias of session_id.",
-  "maxLength": 80,
-  "type": "string"
-}

changedInput schema / properties / session_id / description

Previous value: -"Session id from an earlier negotiation of the same resource."New value: +"Optional session id from an earlier negotiate_price call for the same resource."

changedInput schema / properties / unit_price_usdc / description

Previous value: -"Offered unit price in test USDC, for example 0.008. Omit it to ask for the list price."New value: +"Optional offered unit price in test USDC, for example 0.008. Omit it to ask for this quantity's price."

addedInput schema / required
```
Added value: +[
+  "resource_id"
+]
```

AddedNov 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the description's main job is to add outcome information — which it does by stating it returns 'an accepted offer or a counteroffer with offer_id and expiry' and by ruling out settlement ('Does not pay'). What it does not cover is the failure path (e.g., rejected offers, expired sessions) or any rate/expiry semantics beyond mentioning that expiry exists.

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

Conciseness5/5

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

Four short sentences ordered as purpose, alternative, inputs, return, and caveat — the most decision-relevant information is front-loaded and no sentence is filler. The 'Does not pay' clause is a compact, high-value boundary statement rather than padding.

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?

With no output schema, the description correctly explains the two possible return shapes and their key fields (offer_id, expiry), which is exactly what is otherwise missing. No annotations explain auth or approval prerequisites for an openWorld price-proposal tool, so a small gap remains around what happens to an offer that is never followed by a checkout.

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 100%, so all four parameters including quantity bounds (1-100), session_id chaining, and the unit_price example are already documented in the schema. The description restates required and optional parameters and the quantity range without adding format, precision, or pricing-floor guidance beyond that. Baseline 3 applies when the schema carries the semantics.

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 states a specific verb and resource ('propose a test-USDC unit price and a quantity, or to accept the tier price') and names the sibling that handles the simpler case ('Use get_quote if you only need the list price'). An agent can distinguish this from get_quote and pay_and_access without opening any schema.

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?

It gives an explicit alternative with the condition that selects it ('Use get_quote if you only need the list price') and states the boundary against payment ('Does not pay'), pointing the agent to pay_and_access for that step without naming it. Required vs optional inputs are spelled out up front.

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

All AZPay Monetize — Sepolia Sandbox 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?