Bull OTC

bull_get_quotes

Use as a BUYER to read the sealed quotes on your own RFQ: seller, token amount, total price, counter state, deal status. Returns a list of quotes with quoteIds. Only the RFQ's buyer can read it. 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": {
      "rfqId": "<rfqId>",
      "address": "<address>"
    },
    "name": "bull_get_quotes"
  }
}

Input Schema

Name	Required	Description
`rfqId`	Yes	RFQ id.
`address`	Yes	Your wallet address (the buyer or seller). Required.
`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.5/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses that quotes are sealed, that only the RFQ's buyer may read them, and the non-obvious two-step signing protocol (first call returns a message to sign; retry with the same arguments plus timestamp and signature). It does not cover failure behavior on a bad/expired signature or whether quote contents can change between calls.

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?

Three short sentences, front-loaded with the actor and purpose, then the return shape, then the auth constraint and signing loop. Every clause carries information an agent needs; there is no filler or repetition.

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?

There is no output schema, so the description supplies the return content itself (list of quotes with quoteIds), and it covers the access constraint and the signing handshake, which are the two things an agent can most easily get wrong. Nothing material is missing for correct invocation.

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?

Schema coverage is 100%, so per-parameter meaning is already documented and the baseline would be 3. The description adds procedural meaning the schema only implies: the retry loop with identical arguments plus timestamp and signature, and the role of `address` as the buyer. That is genuine value beyond the field-level text, though it does not clarify format or validation rules.

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?

States a specific verb (read), a specific resource (sealed quotes on your own RFQ), enumerates the returned fields (seller, token amount, total price, counter state, deal status), and notes the return shape (list of quotes with quoteIds). This clearly separates it from the mutating siblings like bull_send_quote or bull_counter_quote and from single-object readers like bull_get_deal.

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?

"Use as a BUYER to read the sealed quotes on your own RFQ" plus "Only the RFQ's buyer can read it" gives an explicit caller role and precondition, which is the key selection criterion here. It does not name an alternative for the seller side (e.g. a status/lookup tool) or state what to do if you are not the buyer, so it stops short of full when/when-not routing.

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?