This server is a deterministic pre-trade risk gate for AI-proposed Binance trades: it checks a trade's thesis against historical evidence and current market costs, then returns a verdict (APPROVE/CAUTION/VETO) with supporting numbers.
second_opinion – core tool: given symbol, side (BUY/SELL), notional, optional thesis text, horizon, and optional replay date, it classifies the chart into setups, computes historical base rates (median forward return, hit rate, sample size, 95% CI) and round-trip cost from live book+fees, then returns a verdict with all driving metrics.
base_rates – retrieve forward-return statistics for every setup on a symbol, plus which setups are currently active on the last completed daily bar; supports custom horizon and historical as-of date.
cost_estimate – get round-trip cost in basis points for a given symbol and notional size, including taker fees both legs and order-book impact against live depth.
list_setups – see the entire setup taxonomy (e.g., THREE_UP, THREE_DOWN, BREAKOUT_20D) and the thesis words that map to each, so you know what the system can verify.
audit_log – view recent decisions from the hash-chained audit log and check whether the chain verifies, ensuring tamper-evident history.
All tools are deterministic, use no lookahead, and are safe to call before any real order tool; they work offline with fixtures when no live data is needed.
Provides pre-trade verification for Binance by evaluating proposed trades against historical Binance market data and live order book, returning APPROVE, CAUTION, or VETO decisions before execution.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@second-opinion Check SOL buy $100 with thesis "momentum breakout""
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Every trade an AI proposes gets its base rate before Binance Agent OS executes it.
Demo video (90 s): https://youtu.be/cv1XzbzABII · Site: https://dannytrillion.github.io/second-opinion/
Binance's own MCP documentation warns that an agent "can make mistakes, act on outdated or hallucinated information, or send incorrect parameters, always verify before execution." Every guardrail built so far verifies the order: size caps, slippage collars, symbol allowlists. Nothing verifies the reasoning. When an agent says "buy SOL, momentum is strong," nothing checks whether that setup has ever paid.
Second Opinion is a deterministic, zero-LLM adversary that sits between the AI and the Binance MCP server. For each proposed trade it answers three questions from real Binance history and the live order book:
Is the claimed setup actually on the chart? "Momentum" has to mean something measurable. If the rationale does not match the signal bar, that is a hallucinated thesis and a hard veto.
What happened the last N times this setup appeared on this symbol? Median forward return, hit rate, sample size, and a bootstrap 95% interval, computed from the symbol's own daily candles with no lookahead.
Does the edge survive the round trip? Taker fees both legs plus order-book impact both legs, walked against the live depth for the proposed size.
The answer is APPROVE, CAUTION, or VETO, and every veto prints the observed value, the limit, and the unit. Two runs on the same data produce a byte-identical decision and the same SHA-256.
Built in one day for the Binance Agent OS Mini Hackathon, Track A. Stock Python 3.9+, no dependencies.
A momentum buy on SOL, replayed on 27 August 2026, the day SOL closed up 6.9% and broke out to a 20-day high:
$ python3 -m secondopinion check SOL buy 100 --thesis "strong momentum, SOL just broke out" --as-of 2026-08-27
VETO BUY SOLUSDT $100.00 horizon 3d
claimed: BIG_UP_DAY, THREE_UP, BREAKOUT_20D; on the chart: BIG_UP_DAY, BREAKOUT_20D, RSI_OVERBOUGHT, ABOVE_SMA50
setup BIG_UP_DAY: n=80, median -1.51%, hit 40%, CI95 median [-3.17%, +0.15%]
same setup by horizon (median/hit): 1d +0.21%/54%, 3d -1.51%/40%, 7d -1.23%/46%
all days: n=985, median +0.13%, hit 51%
round trip cost 30.0 bps (assumed)
edge after cost -181.2 bps (CI low -346.6 bps)
- edge_after_cost: observed -181.19, limit 0.0 (bps)
- edge_ci_low: observed -346.62, limit 0.0 (bps (lower 95% bound))
- hit_rate: observed 0.4, limit 0.5 (share of past occurrences that paid)
body sha256 b0c8b71a0b21799bThe chart really did show a big up day and a breakout. The problem is what followed the previous 80 of them: SOL lost a median 1.5% over the next three days and paid only 40% of the time. (What actually followed: SOL closed at $109.14 on 27 August and $101.75 three days later, -6.8%.)
A thesis that is not on the chart at all (live run on 8 September 2026):
$ python3 -m secondopinion check ETH buy 50 --thesis "momentum breakout"
VETO BUY ETHUSDT $50.00 horizon 3d
claimed: BIG_UP_DAY, THREE_UP, BREAKOUT_20D; on the chart: ABOVE_SMA50
- thesis_present: observed none of ['BIG_UP_DAY', 'THREE_UP', 'BREAKOUT_20D'], limit at least one claimed setup on the signal bar (setups) - the stated rationale does not match what the chart showsAnd a dip buy after three red days on BTC. Three red days is the one setup with a positive median on all four majors, and it clears the cost bar with confidence on five of the twenty markets tested below:
$ python3 -m secondopinion check BTCUSDT buy 100 --thesis "buy the dip" --as-of 2026-08-12
CAUTION BUY BTCUSDT $100.00 horizon 3d
setup THREE_DOWN: n=109, median +0.96%, hit 62%, CI95 median [+0.15%, +1.80%]
same setup by horizon (median/hit): 1d +0.56%/60%, 3d +0.96%/62%, 7d +0.95%/58%
edge after cost +65.7 bps (CI low -14.8 bps)
- positive median edge but the 95% interval straddles zero; this is a coin flip with a small tiltHonest output: the median edge is positive, but the lower bound of the interval is not, so Second Opinion asks rather than approves.
Related MCP server: chainz-sentinel-mcp
Running the same base rates over 20 USDT pairs (up to 1,000 daily bars each, through today) gives docs/EVIDENCE.md. Two findings carry the whole project:
setup | markets where it paid after cost | markets where it reliably lost | markets tested |
Three green days in a row ( | 0 | 8 | 20 |
20-day breakout ( | 0 | 4 | 20 |
Big up day ( | 0 | 3 | 20 |
Three red days in a row ( | 5 | 0 | 20 |
"Paid" means the lower 95% bound on the median 3-day return clears a 30 bps round trip; "lost" means the upper bound does not reach it. Chasing strength has not paid anywhere in this sample. Buying three red days has, on SOL, LINK, LTC, PEPE and TON. This is exactly the pattern an AI's language runs against: "momentum" sounds like a reason, and the record says it is the one setup to be most suspicious of.
Every receipt shows the primary setup at 1, 3 and 7 days, so a 3-day coin flip cannot hide a 7-day edge or loss:
setup BIG_UP_DAY: n=80, median -1.51%, hit 40%, CI95 median [-3.17%, +0.15%]
same setup by horizon (median/hit): 1d +0.21%/54%, 3d -1.51%/40%, 7d -1.23%/46%docs/EVALUATION.md is a walk-forward test: Second Opinion judged a $100 buy on every one of 5,568 days across eight symbols, using only the bars available on each day, and the realized 3-day return was recorded afterwards. No thresholds were tuned on this result. Here is what it found, including the parts that do not flatter the tool.
days with a specific setup on the chart | days | median 3d | hit rate | mean net of 30 bps |
every such day, no gate | 2,440 | +0.08% | 51% | +0.05% |
the days the gate did not veto | 1,480 | +0.33% | 53% | +0.13% |
vetoes on strength setups (momentum, breakout, overbought) | 742 | -0.68% | 45% | -0.20% |
vetoes on weakness setups (dips, oversold) | 218 | +0.47% | 55% | +0.37% |
approvals | 109 | -0.04% | 50% | -0.62% |
What works. The gate's core job is stopping an AI from chasing strength, and out of sample that is where it is right: the 742 strength-chasing trades it vetoed lost a median 0.68% and paid 45% of the time. The 559 vetoes on big up days and three green days alone lost a median 1.13%. Filtering only by the gate's vetoes raised the median outcome of setup days from +0.08% to +0.33%.
What does not. APPROVE is not a buy signal. Only 109 of 5,568 days cleared the confidence bar, and they did no better than average, because a lower-CI-above-cost test on small samples selects flukes. Read APPROVE as "no objection found." And the gate is wrong when it vetoes dip buys: those 218 days went on to pay. The base-rate evidence that dips pay is stronger than the gate's per-day confidence test admits.
Both findings are left in the code and the tables rather than tuned away, because a gate that was fitted to its own evaluation would be worth nothing.
Claude Code / Claude Desktop / Cursor / Codex
| |
| tools/call | PreToolUse hook (Claude Code)
v v
+-------------------+ +------------------------+
| second-opinion | | secondopinion hook | deny / ask / allow
| MCP server (stdio)| | fires on every |-------------------------+
| second_opinion | | mcp__binance-mcp- | |
| base_rates | | server__* order call | v
| cost_estimate | +------------------------+ +------------------------------+
+-------------------+ | Binance MCP Server |
^ | agent.binance.com/mcp/agentic|
| public candles + live depth | confirm-before-execute, |
| data-api.binance.vision (no keys) | Agentic sub-account |
+------------------------------+Two ways in, and they cannot disagree because they share one code path.
As an MCP server. Register it beside binance-mcp-server. Any client can call second_opinion before it calls an order tool. Five tools: second_opinion, base_rates, cost_estimate, list_setups, audit_log.
As a Claude Code hook. A PreToolUse hook on mcp__(claude_ai_)?binance-mcp-server__.* (the server added locally, or inherited from a claude.ai connector) runs Second Opinion on every order the model tries to place: spot_newOrder, margin_marginAccountNewOrder, convert_sendQuoteRequest, convert_placeLimitOrder, and anything routed through the server's tool_execute proxy, which is unwrapped and judged as the inner call. A convert quote can only be accepted if the quote request was approved in the last 15 minutes. VETO denies the call and the model sees why. CAUTION also denies by default and tells the model to bring the numbers to you, because in a headless run (claude -p, cron, CI) a permission prompt cannot block and the order would go through; set SECOND_OPINION_CAUTION=ask in interactive sessions if you prefer a prompt. APPROVE allows it and attaches the receipt. Read-only tools pass silently. Anything the hook cannot parse asks; it never silently allows an unknown shape. Approved orders still go through Binance's own confirm-before-execute step.
Second Opinion holds no keys and no scopes. It reads public market data only. The Binance MCP server keeps the account.
git clone https://github.com/DannyTrillion/second-opinion.git
cd second-opinion
# judge a trade (live candles + live order book, no keys)
python3 -m secondopinion check SOL buy 100 --thesis "momentum"
# replay a past decision on the committed fixtures, no network
python3 -m secondopinion check SOL buy 100 --thesis "momentum" --as-of 2026-08-27 --offline
# what has paid on this symbol, by setup
python3 -m secondopinion rates BNBUSDT
# round-trip cost for a size, from the live book
python3 -m secondopinion cost BTCUSDT 250
# play the three reference scenarios, then run the tests (45, offline)
python3 -m secondopinion demo --offline
python3 -m unittest discover -s tests -vExit codes: 0 approve, 1 caution, 2 veto, 3 error, so it drops straight into a shell pipeline or cron.
Claude Code:
claude mcp add second-opinion --env PYTHONPATH=/ABSOLUTE/PATH/TO/second-opinion -- python3 -m secondopinion serveClaude Desktop, Cursor, Codex: copy the second-opinion block from mcp_config.json and set the path.
python3 -m secondopinion install-hook # prints the settings block
python3 -m secondopinion install-hook --apply # merges it into ~/.claude/settings.json, keeps a .bakThen, in a Claude Code session with the Binance MCP server connected, ask for a trade. If the model calls an order tool, the hook runs first. The real order tools have no rationale field, so the hook recalls the thesis the model gave second_opinion for the same symbol and side in the last 15 minutes; the two entry points work together. docs/HOOK_TRANSCRIPT.md is a verbatim transcript of the hook vetoing a momentum buy inside a real Claude Code session against a stand-in server, and docs/HOOK_TRANSCRIPT_LIVE.md is the same hook denying a spot_newOrder call against the real Binance Agent OS server, connected with read-only scopes.
Set SECOND_OPINION_MODE=advisory to make the hook never deny, only ask with the receipt attached.
To watch the hook fire without a Binance account, run scripts/try_hook.sh from a normal terminal. It registers examples/fake_binance_mcp.py, a stand-in server that never places anything, under the name binance-mcp-server in a throwaway project, installs the hook there, and asks Claude Code for a momentum buy. The model's order call is intercepted before the server ever sees it, and the audit trail is printed at the end.
skills/second-opinion/SKILL.md packages the same workflow as an agent skill in the Binance Skills Hub format: when to call second_opinion, how to read thesis_present first, and how to act on each verdict. Copy the folder into any client that loads skills; for Claude Code that is .claude/skills/second-opinion/ in your project.
Thresholds come from the symbol's own trailing 250 days, so "big" means big for that coin, not a constant. Every flag on bar i is computed only from bars up to i. The test suite proves this by truncating the series and checking nothing changes.
Setup | Definition | Thesis words that claim it |
| Signal-bar return at or above the trailing 90th percentile | momentum, strength, rally, surge, pump |
| At or below the trailing 10th percentile | dip, pullback, bounce, reversion, cheap, crash, drop |
| Three consecutive green / red closes | momentum, trend / dip, pullback, bounce |
| Close above the prior 20-bar high / below the low | breakout / breakdown, crash |
| 14-day RSI at or above 70 / at or below 30 | overbought / oversold, bounce |
| Trend context; never a veto on its own | trend / downtrend |
Base rate for a setup at horizon h: enter at the signal close, exit h completed bars later, over every prior occurrence. Median, mean, hit rate, 10th and 90th percentile, and a 1,000-draw bootstrap interval on the median with a fixed seed.
Check | Fails when | Effect |
| none of the claimed setups is on the signal bar | VETO |
| size not positive, policy or exchange filter breached | VETO |
| cost above policy cap, or visible depth cannot fill the size | VETO |
| last completed bar older than the policy allows | VETO |
| fewer than | CAUTION |
| median directional return minus cost is not positive, or the setup paid less than half the time | VETO for a specific setup, CAUTION if only trend context is active |
| lower 95% bound minus cost is not positive | CAUTION |
Policy lives in second_opinion.policy.json (see the example); defaults are a $1,000 notional cap, 60 bps maximum round trip, 30-day sample minimum, 3-day horizon.
The decision body contains no timestamps. It records the SHA-256 of the exact close series it used, the policy, every check with observed value and limit, and its own body hash. tests/test_engine.py pins the hash of the SOL 27 August replay on the committed fixture; if the maths changes, that test fails.
Every decision, whether from the CLI, the MCP server, or the hook, is appended to ~/.second_opinion/audit.jsonl as a hash chain. python3 -m secondopinion audit --verify recomputes the chain and reports the first tampered line.
It does not predict. A base rate is what happened, not what will happen. A 62% hit rate on 109 occurrences is a tilt, not a promise, and the output says so.
Daily bars only, up to 1,000 of them. Intraday setups are out of scope; the MCP server's candle tool can be swapped in later.
Spot pricing only. Futures funding is not modelled; a perp position's carry is a separate question.
The hook matches the real server's 73 tools by exact name (docs/BINANCE_MCP_TOOLS.md, observed through an authenticated connector on 8 September 2026, since Binance has not published the list). Names outside that catalog fall back to heuristics and, if still unrecognised, ask rather than allow. scripts/probe_binance_mcp.py re-fetches the list when Binance changes it.
Headless agents are the reason CAUTION denies. A hook decision of "ask" only holds when a human is at the keyboard; in claude -p the call proceeds. That was found by running scripts/try_hook.sh, and it is why the default is deny.
No filled trade is in this repository. The hook was exercised against the real Agent OS server with read-only scopes and an unfunded sub-account, which is the safe way to prove a gate; a filled order would only prove that the server accepts orders.
secondopinion/
data/binance.py public market data, verified TLS only, on-disk cache, offline mode
engine/indicators.py SMA, RSI, percentiles, no numpy
engine/setups.py setup taxonomy, no-lookahead thresholds
engine/baserate.py forward returns, bootstrap CI, fixed seed
engine/cost.py fees + order-book walk
engine/verdict.py checks, verdict, multi-horizon, body hash
engine/evidence.py cross-symbol base-rate tables
engine/walkforward.py day-by-day out-of-sample test of the gate
service.py the one entry point the CLI, server and hook all use
mcp/server.py stdio JSON-RPC MCP server, 5 tools
hook/pretooluse.py Claude Code PreToolUse hook, fail closed
hook/binance_tools.py the real server's tool catalog, matched exactly
audit.py hash-chained JSONL log
__main__.py CLI
fixtures/ up to 1,000 real daily bars for 20 USDT pairs; a depth snapshot; exchange filters
docs/ EVIDENCE.md, EVALUATION.md, HOOK_TRANSCRIPT.md, HOOK_TRANSCRIPT_LIVE.md, BINANCE_MCP_TOOLS.md
skills/ Skills Hub packaging
tests/ 45 tests, all offline
hooks/ Claude Code settings example
examples/ stand-in Binance MCP server for demos
scripts/try_hook.sh watch the hook fire in a real Claude Code session, no account needed
scripts/probe_binance_mcp.py list the real Agent OS server's tools and input fieldsMIT.
Recent Second Opinion decisions from the hash-chained audit log, and whether the chain verifies.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool surfaces recent decisions and reports whether the hash chain verifies, which is useful behavioral context. However, it does not explicitly state that the operation is read-only or describe behavior when the chain fails verification, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler. It states the core content ('Recent Second Opinion decisions') and the unique verification aspect compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of return-value and safety information. It communicates the general content of the result but not its shape, ordering, or what 'chain verifies' means in the output. For a simple one-parameter tool this is mostly adequate, but there are gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter `limit` has no schema description and the description does not mention it directly. 'Recent' hints at limiting the number of entries, and the parameter name plus default value make it reasonably inferable, but the description adds almost no explicit meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (hash-chained audit log of Second Opinion decisions) and the distinctive output (whether the chain verifies). It implicitly distinguishes itself from the sibling `second_opinion` by focusing on audit history rather than creating/getting a decision, though it lacks an explicit verb like 'returns' or 'lists'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as `second_opinion` or `list_setups`. The context can be inferred from the tool name and sibling names, but the description itself provides no when-to-use or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Historical forward-return statistics for every setup on a symbol, plus which setups are active on the latest completed daily bar.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| symbol | Yes | ||
| horizon_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must carry the burden of behavioral disclosure. It does reveal meaningful behavioral context: it returns historical forward-return statistics and identifies active setups based on the latest completed daily bar. However, it does not explicitly state that this is a read-only operation, describe how statistics are computed, or clarify timezone/session details. The description is transparent about output scope but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence with no filler. It front-loads the main purpose (historical forward-return statistics) and appends the secondary output (active setups). Every phrase adds value, and it avoids repeating the tool name or schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, no annotations, and 0% schema parameter coverage, the description leaves important gaps. It does not explain how to use as_of or horizon_days, does not describe the shape of the returned statistics, and provides no indication of typical use cases or limitations. An agent would need to guess several details before confidently invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the input schema's lack of explanations. It only clarifies the symbol context ('on a symbol') and indirectly references the daily bar timing. The as_of and horizon_days parameters are not explained at all, despite horizon_days having a default and as_of being a required-independent string. This leaves significant ambiguity for an agent choosing parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's main function: providing historical forward-return statistics for setups on a symbol, plus which setups are active on the latest completed daily bar. It is specific about the resource (setups on a symbol) and the two kinds of information returned. It does not explicitly contrast with sibling tools like list_setups, but the core purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as list_setups or second_opinion. There are no stated conditions, exclusions, or references to sibling tools. While the description implies it is useful for forward-return statistics, it does not say when a user should prefer it over related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Round-trip cost in basis points for a given notional: taker fees both legs plus order-book impact both legs, measured against mid from the live Binance depth.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| notional_usd | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the calculation methodology thoroughly: taker fees and order-book impact on both legs, measured against mid from live Binance depth, with output in basis points. It does not discuss latency, error cases, or whether the estimate is indicative, but it gives a strong account of what the tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every clause adds useful information: output unit, input notional, fee components, impact components, and data source. It is concise without sacrificing meaningful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema and no annotations, the description covers the central semantics well: it defines the output, the unit, the calculation inputs, and the data source. It is missing minor but useful details such as edge-case behavior, but overall an agent has enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'notional' is the quantity for which the cost is estimated and implies 'symbol' selects the Binance market. However, it does not explicitly describe either parameter, their formats, or unit constraints beyond what the parameter names already suggest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool computes: a round-trip cost in basis points for a given notional, specifying the components (taker fees and order-book impact on both legs) and the reference (live Binance depth mid). It is specific enough to distinguish the tool from generic siblings, though it does not explicitly differentiate from sibling tool names like base_rates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a given notional' implies the tool should be used when the user wants a cost estimate for a specific trade size. However, there is no explicit guidance on when to use this tool versus alternatives, no exclusion criteria, and no mention of sibling tools or fallback conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The setup taxonomy Second Opinion can test, and the thesis words that map to each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the call is read-only, whether it has side effects, what response shape to expect, or any other runtime behavior. The description only characterizes content, not behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler words. It front-loads the core concept of the setup taxonomy, though it would be clearer if it began with an action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool with no output schema, the description conveys the main content of the result. However, it lacks any usage context, behavioral guarantees, or relationship to sibling tools, leaving the agent to infer when and why to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds useful context about what the returned data represents, which is more than the empty input schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (the setup taxonomy and thesis-word mappings) but uses a noun phrase rather than an action verb like 'lists' or 'returns.' It is not a tautology and gives more specific content than the name alone, but the agent must infer the action from 'list_setups'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of base_rates, cost_estimate, audit_log, or second_opinion. The mention of 'Second Opinion' hints at a relationship to a sibling tool, but no explicit condition, alternative, or exclusion is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deterministic pre-trade check for an AI-proposed Binance trade. Classifies the current chart into measurable setups, computes the historical base rate of the proposed trade on this symbol (median forward return, hit rate, sample size, 95% CI), the round-trip cost from the live order book and fees, and returns APPROVE / CAUTION / VETO with every number that drove it. Call this before any order tool.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | ||
| as_of | No | YYYY-MM-DD to replay a past decision (no live order book) | |
| symbol | Yes | e.g. BTCUSDT (BTC, BTC/USDT also accepted) | |
| thesis | No | the rationale in plain words, e.g. 'momentum after today's breakout'. Second Opinion checks whether the claimed setup is actually present. | |
| horizon_days | No | holding horizon the trade is judged on | |
| notional_usd | Yes | order size in quote currency (USD-equivalent) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses that the tool is deterministic, that it analyzes the current chart and order book, and that it returns a verdict with supporting numbers. The phrase 'pre-trade check' and 'before any order tool' strongly imply no order is placed, though it could have stated the read-only nature more explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences front-load the core purpose, then describe the computed metrics and output verdict, ending with a clear call-to-action. No redundant phrasing or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool computes and what it returns, which is important because there is no output schema. It covers the main workflow context and the as_of replay case is handled in the schema. It stops short of describing edge cases like low sample sizes or exact verdict thresholds, but the returned numbers are meant to inform the agent's decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, so the schema already documents most parameters. The description adds context about how thesis is checked and that costs come from the live order book and fees, but it does not add detail that the schema lacks for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific function: a deterministic pre-trade check that classifies chart setups, computes historical base rates and round-trip costs, and returns an APPROVE/CAUTION/VETO verdict. This clearly distinguishes it from the sibling tools base_rates and cost_estimate, which only provide individual pieces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Call this before any order tool' gives explicit placement in the agent's workflow, and the pre-trade framing makes the intended context clear. It does not spell out when to prefer the sibling tools instead, but the integration role is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0audit_logbase_ratescost_estimatelist_setupssecond_opinionScored across 5 tools
base_rates and cost_estimate partially overlap with second_opinion since they provide inputs to that decision, but they are clearly framed as standalone data queries while second_opinion is the primary decision gate. The remaining tools are distinct in purpose.
All tool names are clean snake_case, but only list_setups follows a verb-first command pattern; the rest are noun phrases like base_rates and audit_log. This makes the naming readable but not consistently patterned.
Five tools is well-scoped for a pre-trade second-opinion service: taxonomy, historical rates, cost estimation, the main decision, and audit access. Each tool serves a clear purpose with no obvious redundancy.
The toolset covers the full intended workflow: understand setups, inspect historical base rates, estimate costs, get the deterministic pre-trade verdict, and review past decisions. There are no obvious missing operations for the server's stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered crypto trading signals: direction, confidence, TP/SL, thesis, technicals. 8 strategies.
Deterministic pre-execution audit for trading agents. PASS/WAIT/FAIL, reproducible verdict_hash.
Pre-trade token safety check for AI agents. Simulates a sell before you buy, then returns one low/medium/high/unknown verdict with the signals behind it: sellability, buy/sell tax, liquidity depth, pair age, same-ticker impersonation, owner powers from bytecode. Ethereum, BSC, Base, Solana. Fail-closed - a check that cannot run answers unknown, never low. Publishes its own measured error rate with the benchmark harness in the repo. Free, no signup, no API key, MIT.
Pre-trade token safety checks for AI agents on Solana and Base. x402 USDC per call, no key.
