Bull OTC

bull_counter_quote

Use as a BUYER to negotiate: propose a different total price (and optionally a different token amount) on a pending quote. Returns the stored counter. The seller can answer with bull_revise_quote. Works only while the quote is pending. Signed: the first call returns a message to sign; call again with the same arguments plus timestamp and signature.

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": {
      "quoteId": "<quoteId>",
      "price": "<price>",
      "address": "<address>"
    },
    "name": "bull_counter_quote"
  }
}

Input Schema

Name	Required	Description
`price`	Yes	Your proposed total price in ETH.
`tokens`	No	Your proposed token amount (optional).
`address`	Yes	Your wallet address (the buyer or seller). Required.
`quoteId`	Yes	Quote id.
`signature`	No	EIP-191 personal_sign of `message` from the previous response. Leave empty on the first call.
`timestamp`	No	From the previous bull_* response. Leave empty on the first call.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are supplied, so the description carries the full behavioral burden, and it delivers the most important trait: a two-step signed flow where the first call returns a message to sign and the second repeats the arguments with timestamp and signature. It also discloses the pending-state constraint and that the stored counter is returned. Gaps remain on the destructive/overwrite semantics (does a counter replace a prior one?) and failure behavior, which keeps it from a 5.

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 tightly packed sentences: role and action first, return value second, sibling routing third, state constraint fourth, signing procedure last. No filler and the critical constraints are front-loaded.

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?

For a stateful, signed mutation tool with no annotations and no output schema, the description covers the signing handshake, the pending-state gate, the returned artifact, and who can respond. It stops short of describing overwrite behavior or error conditions, but an agent has enough to invoke it correctly.

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 every parameter is already documented, and the description adds little beyond restating that price and optional tokens are proposals. Its explanation of the signature/timestamp retry is useful context but duplicates the schema text 'Leave empty on the first call.' Baseline 3 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 names a specific verb and resource — propose a counter price on a pending quote — plus the actor role (BUYER) and the optional token-amount variant. It also distinguishes itself from the closest sibling by noting that the seller answers with bull_revise_quote, so an agent can route correctly without opening either 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 explicit when-to-use conditions: only as a buyer, only while the quote is pending, and only for negotiation (the seller's counterpart action is bull_revise_quote). This is enough to select between countering, revising, and accepting without inference.

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

All Bull OTC 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?