Place and inspect orders on your own exchange accounts from an MCP-connected agent.
Scored across 8 tools
Most tools map to distinct workflow stages: setup/catalog/connect/hooks for account and exchange management, command/alert for building TradingView alerts, entry for execution, and events for reading results. However, command and alert overlap because alert is a superset that fuses command and hooks, and entry vs command both handle cancel/close/flat actions (one executes, one builds strings). The descriptions mitigate confusion by recommending alert when webhook, expiration, and resolution are needed, but the boundaries require careful reading.
All tool names are lowercase single words with no underscores or camelCase mixing, giving a consistent surface style. However, they do not follow a predictable verb_noun pattern; connect is a verb while setup, alert, command, entry, events, hooks, and catalog are nouns, so the semantic pattern is less consistent than the formatting.
Eight tools are well-scoped for the domain, covering the full lifecycle from account setup to order execution and event reading without redundancy. Each tool earns its place, and the count falls comfortably within the ideal 3-15 range.
The core lifecycle is covered: setup, catalog, connect, hooks, command/alert, entry, and events. Minor gaps exist, such as no dedicated disconnect or credential-update tool and hook rotation being website-only, but these are workable around and do not block main workflows.
Build everything TradingView's create_alert(webhook, message, expiration, resolution) needs, in one call: fuses command (the message) and hooks (the webhook URL for hook_id), and fills in the expiration (default 1 year out -- TradingView itself defaults to only 30 days, which silently stops the alert) and resolution (default "1") TradingView also needs. Returns warnings you should read, including never putting the hook's key in the message field. Dry-run by default like command; set live:true to build a command that trades for real once the alert fires. Requires your Autoview account token.
| Name | Required | Description | Default |
|---|---|---|---|
| live | No | false (default) = build a dry-run preview command (appends d=1); true = build a command that places a real order when the alert fires | |
| side | No | order direction; required unless action is set, where it is an optional buy/sell filter for cancel/close (omit for flat) | |
| type | No | order type; defaults to market | |
| unit | No | "currency" treats quantity as a CURRENCY amount to convert to units at the resolved price (u=currency) — e.g. quantity:10 with unit:"currency" on BTC/USD buys $10 of BTC instead of 10 BTC. Only meaningful with a fixed (non-percent) quantity. | |
| price | No | absolute limit price; required for limit, post_only, ioc, fok, and stop_limit | |
| token | No | your Autoview account token — an av_mcp_ personal access token, generate one at /account/tokens/ on the Autoview site. Omit this if your MCP client already sends it as an `Authorization: Bearer` header (Claude Code, Cursor, and most non-browser clients do this automatically once configured). | |
| action | No | manage EXISTING orders/positions on symbol instead of placing a new one: cancel = cancel open orders, close = close open positions, flat = cancel every order AND close every position (Tradovate only). When set, side (if given) is an optional buy/sell filter (not applicable to flat), and quantity/type/price/trigger/brackets/unit are ignored. | |
| symbol | Yes | the instrument symbol, e.g. EUR_USD, XBTUSD, BTC_USD | |
| hook_id | Yes | the hook whose URL becomes the alert's webhook (see the `hooks` tool) | |
| trigger | No | absolute trigger (stop) price; required for stop and stop_limit | |
| exchange | No | optional — one of OANDAPRACTICE, KRAKEN, CRYPTO, CRYPTODEMO, BYBITTESTNET, BYBITSPOTTESTNET, TRADOVATESIM validates order-type and bracket support against that exchange's capabilities; any other exchange id known to Autoview (see `catalog`) is also accepted but skips that check; omit entirely to skip validation | |
| priceRef | No | reference price for percent sizing and brackets | |
| quantity | No | order size: a positive number (contracts/units), or a percent-of-balance string like "50%" (1-100%). Required unless action is set. | |
| stopLoss | No | attached bracket stop-loss as a POINT distance from the fill; pairs with takeProfit or a trail leg | |
| trailStop | No | auto-trail stop distance in points; requires trailActivate | |
| expiration | No | ISO 8601 timestamp for TradingView's alert expiration; defaults to 1 year from now | |
| resolution | No | chart timeframe TradingView's create_alert needs; defaults to "1" (1 minute) | |
| takeProfit | No | attached bracket take-profit as a POINT distance from the fill; pairs with stopLoss or a trail leg | |
| trailActivate | No | points of profit before the trail starts; required whenever trailStop is set | |
| trailFrequency | No | how often the trailing stop re-checks price; defaults to 1 if omitted | |
| sizeAgainstEquity | No | for a percent quantity, size against equity instead of available balance (y=equity) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/idempotentHint already covering the safety profile, the description still adds real behavioral value: it warns that TradingView's own 30-day default silently kills alerts (its own default is 1 year), that it returns warnings the caller should read, that the hook key must never go in the message field, and that an Autoview account token is required. It also clarifies the build-vs-execute distinction ('builds a command that trades for real once the alert fires'), which pre-empts misreading readOnlyHint as 'no trading impact'.
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?
Front-loaded with the core purpose, then the defaults, warnings, dry-run mode, and auth requirement. It is a dense run-on sentence with em-dash asides, but nearly every clause carries information (the 30-day TradingView pitfall, the key-in-message warning) rather than 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?
For a 21-parameter builder tool with no output schema, the description covers what the tool produces (a create_alert command plus warnings), the safety mode, and auth needs. It does not describe the shape of the returned command or how warnings are surfaced, which is the only meaningful gap for an agent that must act on the output.
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 coverage is 100% so the baseline is 3, but the description goes beyond it by explaining the semantic relationship between the inputs: `command` supplies the message and `hooks` supplies the webhook URL for hook_id, plus the non-obvious defaults for expiration and resolution that the schema only states, not motivates.
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 opening clause names a specific verb ('Build... in one call'), the concrete resource (TradingView's create_alert payload with its four required fields), and explicitly positions the tool as a fusion of the `command` and `hooks` siblings. An agent can distinguish this from catalog/command/hooks 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear operating context: dry-run by default (matching `command`), set live:true for a real trading command, and it routes the webhook source to the `hooks` tool. It stops just short of an explicit 'use this instead of X when Y' exclusion statement, so 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up exchanges beyond setup's certified seven -- Autoview's integrations cover many more, filterable by paper (testnet/practice/sim, no real money), free (no Autoview subscription required), and name. Each entry's certified flag tells you whether it also works with entry (full order-type/bracket validation + connect) or only command/alert (builds the alert syntax; connect and full validation are certified-only for now) -- see connect_url to add credentials for one. Requires your Autoview account token.
| Name | Required | Description | Default |
|---|---|---|---|
| free | No | filter to (true) or exclude (false) exchanges that need no Autoview subscription; omit for both | |
| name | No | case-insensitive substring match against the exchange's display name or id, e.g. "binance" | |
| paper | No | filter to (true) or exclude (false) paper/testnet/sim exchanges; omit for both | |
| token | No | your Autoview account token — an av_mcp_ personal access token, generate one at /account/tokens/ on the Autoview site. Omit this if your MCP client already sends it as an `Authorization: Bearer` header (Claude Code, Cursor, and most non-browser clients do this automatically once configured). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond that: the account-token requirement, the meaning of the certified flag, and that full validation/connect are certified-only for now — behavioral constraints the annotations don't convey.
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?
Purpose is front-loaded, but the body is a single dense paragraph of stacked em-dashes and nested parentheses that is hard to parse on first read. It earns its information, yet the structure could be broken up for clarity.
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, the description usefully explains what each catalog entry yields (certified flag, connect_url) and covers authentication and filtering, which is enough for an agent to call it correctly. Minor gaps remain around pagination or result-size expectations.
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 coverage is 100%, so all four parameters (free, name, paper, token) are already documented with equal or better detail. The description restates the filter dimensions and adds minor glosses ('no real money', 'no Autoview subscription required') that mostly duplicate the schema, so baseline 3 is right.
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?
States a specific verb and resource ('Look up exchanges') and immediately scopes it against setup's certified seven, so an agent knows this is the browse-everything-else tool. It also names the semantic fields (certified flag, connect_url) that matter, distinguishing it from entry/command/alert/connect without opening their schemas.
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?
Explains when the certified flag routes you to entry (full validation + connect) versus only command/alert, and points to connect_url for credential setup. That is strong contextual routing, though it stops short of an explicit 'use catalog instead of setup when X' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build an Autoview alert command string from structured order fields (symbol, side, quantity, type, price, trigger) without placing an order — the output is the value TradingView's create_alert message field should carry. Also builds cancel/close/flat management commands via action (see entry's description). Dry-run by default: a bare call returns a preview command (appends d=1); set live:true to build a command that trades for real once TradingView fires the alert. Prefer the alert tool if you also need the destination webhook, expiration, and resolution in one call. Requires your Autoview account token — live:true requires a live-scoped token. exchange is optional: pass one of OANDAPRACTICE, KRAKEN, CRYPTO, CRYPTODEMO, BYBITTESTNET, BYBITSPOTTESTNET, TRADOVATESIM for full order-type/bracket validation, or any other exchange id configured on Autoview (see the catalog tool) to build a generic command for it with that extra validation skipped; omit exchange entirely to build a generic command routed by whichever exchange(s) the destination hook is linked to.
| Name | Required | Description | Default |
|---|---|---|---|
| live | No | false (default) = build a dry-run preview command (appends d=1); true = build a command that places a real order when the alert fires | |
| side | No | order direction; required unless action is set, where it is an optional buy/sell filter for cancel/close (omit for flat) | |
| type | No | order type; defaults to market | |
| unit | No | "currency" treats quantity as a CURRENCY amount to convert to units at the resolved price (u=currency) — e.g. quantity:10 with unit:"currency" on BTC/USD buys $10 of BTC instead of 10 BTC. Only meaningful with a fixed (non-percent) quantity. | |
| price | No | absolute limit price; required for limit, post_only, ioc, fok, and stop_limit | |
| token | No | your Autoview account token — an av_mcp_ personal access token, generate one at /account/tokens/ on the Autoview site. Omit this if your MCP client already sends it as an `Authorization: Bearer` header (Claude Code, Cursor, and most non-browser clients do this automatically once configured). | |
| action | No | manage EXISTING orders/positions on symbol instead of placing a new one: cancel = cancel open orders, close = close open positions, flat = cancel every order AND close every position (Tradovate only). When set, side (if given) is an optional buy/sell filter (not applicable to flat), and quantity/type/price/trigger/brackets/unit are ignored. | |
| symbol | Yes | the instrument symbol, e.g. EUR_USD, XBTUSD, BTC_USD — or the exchange-native symbol a TradingView EXCHANGE:TICKER maps to | |
| trigger | No | absolute trigger (stop) price; required for stop and stop_limit | |
| exchange | No | optional — one of OANDAPRACTICE, KRAKEN, CRYPTO, CRYPTODEMO, BYBITTESTNET, BYBITSPOTTESTNET, TRADOVATESIM validates order-type and bracket support against that exchange's capabilities; any other exchange id known to Autoview (see `catalog`) is also accepted but skips that check; omit entirely to skip validation | |
| priceRef | No | reference price for percent sizing and brackets | |
| quantity | No | order size: a positive number (contracts/units), or a percent-of-balance string like "50%" (1-100%). Required unless action is set. | |
| stopLoss | No | attached bracket stop-loss as a POINT distance from the fill; pairs with takeProfit or a trail leg | |
| trailStop | No | auto-trail stop distance in points; requires trailActivate | |
| takeProfit | No | attached bracket take-profit as a POINT distance from the fill; pairs with stopLoss or a trail leg | |
| trailActivate | No | points of profit before the trail starts; required whenever trailStop is set | |
| trailFrequency | No | how often the trailing stop re-checks price; defaults to 1 if omitted | |
| sizeAgainstEquity | No | for a percent quantity, size against equity instead of available balance (y=equity) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true), and the description adds substantial non-derivable behavior: dry-run default with a d=1 marker, that live:true 'trades for real once TradingView fires the alert', the live-scoped-token requirement, and that validation is skipped for unlisted exchanges.
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?
Front-loaded with purpose, then live/dry-run, then sibling routing, then token and exchange constraints — good ordering. It is dense and the final exchange sentence is a long run-on, but every clause carries operational information that an 18-parameter tool genuinely needs.
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?
No output schema exists, and the description compensates by defining the return value ('the output is the value TradingView's create_alert `message` field should carry'). Combined with auth requirements, validation behavior, and mode switching for an 18-param tool, an agent has everything needed to invoke it 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 coverage is 100%, so the baseline is 3. The description nonetheless adds cross-field semantics beyond the schema — that `action` delegates order semantics to 'entry's description', that exchange choice determines whether order-type/bracket validation runs, and that omitting exchange routes by the destination hook's linked exchanges.
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 first sentence states a specific verb and resource — 'Build an Autoview alert command string from structured order fields' — and explicitly negates order placement ('without placing an order'), which is the key ambiguity for a tool named 'command'. It also names the sibling `alert` and the create_alert `message` field, so an agent can distinguish it from every sibling without opening a schema.
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?
Explicit routing is given: 'Prefer the `alert` tool if you also need the destination webhook, expiration, and resolution in one call.' It further splits usage into order vs. action modes and dry-run vs. live, and gives a concrete selection rule for `exchange` (validated list vs. generic vs. omit).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect one of the seven certified exchanges (see setup's exchange list) to your account: creates a webhook and links it to your already-saved credentials for that exchange, the same steps 2-4 the website's setup wizard runs. Safe to call more than once -- if a webhook is already linked, it reports connected:true and creates nothing new. If you have no credentials saved for this exchange yet, returns connect_url instead: open it in a browser to add them (no exchange secret can be pasted into this chat), then call connect again with the same exchange. Connecting a real-money (non-paper) exchange requires a live-scoped token; any token can connect a paper/testnet exchange. Requires your Autoview account token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | your Autoview account token — an av_mcp_ personal access token, generate one at /account/tokens/ on the Autoview site. Omit this if your MCP client already sends it as an `Authorization: Bearer` header (Claude Code, Cursor, and most non-browser clients do this automatically once configured). | |
| hook_id | No | link this specific existing hook instead of letting connect pick or create one (see the `hooks` tool for your hook ids) | |
| exchange | Yes | the exchange to connect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, and the description reinforces this with concrete behavior ('Safe to call more than once -- if a webhook is already linked, it reports connected:true and creates nothing new'), plus auth requirements (live-scoped token for real-money, any token for paper) and the security constraint that secrets cannot be pasted into chat. This is behavior well beyond the structured hints.
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?
Purpose is front-loaded in the first clause and every sentence carries actionable information (idempotency, fallback flow, auth scope). It runs long as a single dense paragraph, which slightly hurts scanability, but there is no 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?
No output schema exists, and the description compensates by describing both return shapes (connected:true vs. connect_url) and the follow-up action for each. Auth requirements for both token types are also covered, so an agent has everything needed to call this 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 100%, so the baseline is 3; the description adds a little by framing `exchange` around the seven certified options and the paper/live distinction, and by explaining that `hook_id` lets connect pick or create instead. It does not add syntax or format detail beyond the schema, so it stays modestly above baseline.
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?
States a specific verb and resource ('Connect one of the seven certified exchanges... creates a webhook and links it to your already-saved credentials'), and differentiates itself from siblings by naming the setup wizard steps and the `hooks` tool. An agent can distinguish it from `setup` and `hooks` 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly covers when to call (connect an exchange), what happens on repeat calls (idempotent, returns connected:true), the alternative path when credentials are missing (returns connect_url, open in browser, then call again), and the token-scope rule separating paper from live exchanges. Conditions and alternatives are spelled out rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place an order on a supported exchange, right now — or manage existing orders/positions on symbol via action (cancel open orders, close open positions, or flat/liquidate everything — Tradovate only). You fill structured order fields (symbol, side, quantity, type, price, trigger) — Autoview assembles the order for you. Dry-run by default: a bare call returns the parsed order without placing it; set live:true to place a real order. On a paid exchange without an active Autoview subscription, live:true is silently downgraded to a dry-run — the response then carries dry_run_forced:true and a dry_run_reason explaining why (see the setup tool for which exchanges this applies to, and where to subscribe). The order is relayed to the exchange asynchronously: this returns { queued, trace, canonical_id } immediately, not the fill. For a dry-run (the default), entry waits up to ~10s for the exchange's own reply and returns it as dry_run_events when it arrives in time — otherwise dry_run_pending:true, and you can poll the events tool with canonical_id (or trace) a moment later. Credentials come from hook_id -- the credentials you already linked to one of your hooks (see the hooks or setup tool) -- so no exchange secret ever enters this chat. exchange is optional when that hook links to exactly one exchange; pass it explicitly if the hook links to more than one. If you don't have credentials linked yet, use the command tool to check an order's shape without a hook. Requires your Autoview account token.
| Name | Required | Description | Default |
|---|---|---|---|
| live | No | false (default) = a dry-run preview that returns the parsed order without placing it; true = place a real order on your live account | |
| side | No | order direction; required unless action is set, where it is an optional buy/sell filter for cancel/close (omit for flat) | |
| type | No | order type; defaults to market. limit/post_only/ioc/fok and stop_limit need a price; stop/stop_limit need a trigger. An entry stop keeps the order side. Not every exchange supports every type (e.g. OANDA has no stops; Kraken spot no ioc/fok). | |
| unit | No | "currency" treats quantity as a CURRENCY amount to convert to units at the resolved price (u=currency) — e.g. on BTC/USD, quantity:10 with unit:"currency" buys $10 of BTC instead of 10 BTC. Only meaningful with a fixed (non-percent) quantity. On TRADOVATESIM also pass priceRef (or price) — see priceRef. | |
| price | No | absolute limit price; required for limit, post_only, ioc, fok, and stop_limit. Also accepted (optional) on a market order as a stand-in for priceRef. | |
| token | No | your Autoview account token — an av_mcp_ personal access token, generate one at /account/tokens/ on the Autoview site. Omit this if your MCP client already sends it as an `Authorization: Bearer` header (Claude Code, Cursor, and most non-browser clients do this automatically once configured). | |
| action | No | manage EXISTING orders/positions on symbol instead of placing a new one: cancel = cancel open orders, close = close open positions, flat = cancel every order AND close every position (Tradovate/TRADOVATESIM only — see setup's flat per exchange). When set, side (if given) is an optional buy/sell filter (not applicable to flat), and quantity/type/price/trigger/brackets/unit are ignored. | |
| symbol | Yes | the instrument symbol, e.g. EUR_USD, XBTUSD, BTC_USD | |
| hook_id | Yes | use the credentials already linked to this hook (see the `hooks` tool). The hook must belong to your account. | |
| trigger | No | absolute trigger (stop) price; required for stop and stop_limit | |
| exchange | No | the exchange to trade on; omit when hook_id links to exactly one exchange (see the hooks tool) -- otherwise required to disambiguate | |
| priceRef | No | reference price for percent sizing and brackets (price=); percent quantity divides balance by it. Optional on exchanges with a live quote feed (the zone fetches one); REQUIRED on TRADOVATESIM (no live market-data feed — Tradovate charges separately for it, and a Simulation account never has it) whenever quantity is a percent, unit is "currency", OR any of stopLoss/takeProfit/trailStop is set. Omitting it there fails late with a live exchange error instead of a clear one — pass an approximate current price. | |
| quantity | No | order size: a positive number (contracts/units), or a percent-of-balance string like "50%" (1-100%). Required unless action is set. On TRADOVATESIM (no live market-data feed), a percent quantity also requires priceRef — see priceRef. | |
| stopLoss | No | attached bracket stop-loss as a POINT distance from the fill; pair with takeProfit for a fixed OCO, or with a trailing leg. Market entry, bracket-capable exchanges only (Tradovate). On TRADOVATESIM also pass priceRef (or price) — see priceRef. | |
| trailStop | No | attached TRAILING stop as a POINT distance the stop keeps behind price once the trail activates (atsl=). Requires trailActivate. Rides winners: pairs with a stopLoss (hard stop + trail) or stands alone. Market entry, trail-capable exchanges only (Tradovate). On TRADOVATESIM also pass priceRef (or price) — see priceRef. | |
| takeProfit | No | attached bracket take-profit as a POINT distance from the fill; pair with stopLoss, or with a trailing leg. On TRADOVATESIM also pass priceRef (or price) — see priceRef. | |
| trailActivate | No | POINTS of profit the price must move before the trailing stop starts trailing (atx=). Required whenever trailStop is set | |
| trailFrequency | No | how often the trailing stop re-checks price (atf=); defaults to 1 if omitted | |
| sizeAgainstEquity | No | for a percent quantity, size against equity instead of available balance (y=equity) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true) cover the safety profile, and the description adds substantial context beyond them: silent downgrade of live:true to dry-run on unpaid exchanges with dry_run_forced/reason, async relay semantics, ~10s dry-run wait, and that no exchange secret enters the chat. No contradiction with the destructive/open-world annotations.
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?
Front-loads the core action and dry-run default before drilling into async/credential details, which is the right ordering for a 19-param tool. It is dense and long, but most sentences carry load-bearing behavioral facts; a little tightening would help.
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?
No output schema exists, so the description carries return-value burden and does so fully: { queued, trace, canonical_id }, dry_run_events, dry_run_pending, dry_run_forced, dry_run_reason. It also covers credentials, subscription gating, and the credential-free alternative, leaving nothing essential missing.
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 coverage is 100%, so the baseline is 3, but the description adds real routing value: hook_id supplies credentials, exchange is optional only when the hook links to exactly one exchange, and it summarizes the structured order fields and the action filter behavior. It doesn't add syntax beyond the already-rich schema, capping it below 5.
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?
States a specific verb+resource ('Place an order on a supported exchange') and explicitly covers the second mode ('manage existing orders/positions on symbol via action'). It names siblings (setup, hooks, events, command) so an agent can route without opening schemas.
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?
Gives explicit when-to-use guidance: dry-run is the default, set live:true to place a real order, use `command` if credentials aren't linked, see `setup` for subscription/exchange coverage. It also explains fallback paths (poll `events` with canonical_id/trace).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read what your orders did. Pass trace (the id entry or command's caller received) to read one order's events; omit trace to list your account's recent events instead, newest first, optionally narrowed by hook_id and/or canonical_id — this is the only way to see an order a TradingView (or other webhook) alert fired directly, since it never went through entry and has no trace. Requires your Autoview account token. Poll this a moment after an order if the events are not there yet — the exchange reports back out-of-band.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max events to return (default 20) | |
| token | No | your Autoview account token — an av_mcp_ personal access token, generate one at /account/tokens/ on the Autoview site. Omit this if your MCP client already sends it as an `Authorization: Bearer` header (Claude Code, Cursor, and most non-browser clients do this automatically once configured). | |
| trace | No | the trace id returned by the entry tool for the order you want to inspect; omit to list your account's recent events instead | |
| hook_id | No | when trace is omitted, narrow the account-wide listing to events reported for this hook | |
| canonical_id | No | when trace is omitted, narrow the account-wide listing to events reported for one webhook delivery (the canonical id a webhook call produces) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the tool requires an Autoview account token, events may arrive out-of-band (poll after an order), and the listing is newest-first. It doesn't describe pagination or error behavior, but the annotations plus the description cover the key behavioral traits.
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 dense paragraph but every sentence earns its place: mode selection, filtering, the webhook edge case, token requirement, and polling advice. It front-loads the core purpose and mode distinction before the less common use cases. No wasted words.
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 read-only list/detail tool with no output schema, the description covers the essential context: how to select a single order vs. list, how to filter, the webhook edge case, authentication, and eventual consistency. It doesn't describe the event object shape or pagination, but with no output schema and a simple list operation, the description is largely complete. A small gap is not specifying what fields appear in the response, but that's minor.
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 100%, so the schema already documents all five parameters. The description adds the mode-switching semantics (trace vs. omit) and the narrowing relationship between hook_id and canonical_id, which is useful. However, it doesn't add much beyond what the schema descriptions already state, so a baseline 3 is appropriate.
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 opens with a clear verb and resource ('Read what your orders did') and immediately distinguishes the two modes: pass trace for one order's events, omit trace for account-wide listing. It also names the sibling context (entry, TradingView/webhook alerts) that makes it distinct from other tools. This is a specific, well-scoped purpose statement.
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 explicitly states when to use each mode: pass trace to read one order's events, omit trace to list recent events, optionally narrowed by hook_id and/or canonical_id. It also explains the only way to see webhook-fired orders (no trace) and gives polling guidance if events aren't immediately available. This is explicit when-to-use guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your Autoview webhook URLs — the destination for a TradingView (or any other) alert's webhook field. Each hook already knows which exchange(s) it is linked to; there is nothing further to configure on the Autoview side. Pair with the command tool (or use alert to build both at once). Requires your Autoview account token. The returned URL is itself a bearer secret for unattended trading — treat it like a password; rotate a hook's key from /account/hooks/ on the Autoview site if it leaks.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | your Autoview account token — an av_mcp_ personal access token, generate one at /account/tokens/ on the Autoview site. Omit this if your MCP client already sends it as an `Authorization: Bearer` header (Claude Code, Cursor, and most non-browser clients do this automatically once configured). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds meaningful behavioral context beyond the readOnlyHint/destructiveHint annotations: the returned URL is a bearer secret for unattended trading, must be treated like a password, and can be rotated from /account/hooks/. This security disclosure is exactly the kind of behavior an agent needs to know that is not visible in annotations.
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 front-loaded with the primary purpose and includes only essential context: the alert destination relationship, the related tools, and the security warning. Each sentence earns its place, and the length is justified by the important caveats.
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 simple listing tool with no output schema, the description covers what is returned, the token requirement, and the security sensitivity. It could specify output format or additional returned fields, but nothing critical is missing for correct invocation.
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 coverage is 100%, and the schema's token description already covers what the parameter is, where to generate it, and when to omit it. The tool description's requirement for a token adds no new detail beyond what the schema provides, so a baseline 3 is appropriate.
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?
States the specific action 'List your Autoview webhook URLs' and identifies the resource and the destination for an alert's webhook field. It distinguishes the tool by noting it requires no further configuration on the Autoview side and refers to sibling tools alert and command.
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 clearly sets the context for use: this tool lists existing webhook URLs and suggests pairing with `command` or using `alert` to build both at once. It names the alternatives but does not explicitly explain when not to use the tool, so it stops short of a full when/when-not breakdown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read this FIRST. Returns your account overview: token scopes (live/exchange), which exchanges your token can call at all (callable), which of those allow a real live order right now vs. force a dry-run for lack of an active subscription (live_allowed/dry_run_forced, with upgrade_url when forced), per-exchange facts (supported order types, symbol format example, bracket/flat support, whether a manual priceRef is required, whether it's a free paper/no-real-money venue, its setup_url and required credential labels), and your hooks with their linked exchanges. If no hook is linked to any exchange yet, recommended_first_exchange points at a free paper venue to start with. failing_hooks flags any hook whose last several alerts all failed with the SAME error (a stuck webhook loop). Requires your Autoview account token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | your Autoview account token — an av_mcp_ personal access token, generate one at /account/tokens/ on the Autoview site. Omit this if your MCP client already sends it as an `Authorization: Bearer` header (Claude Code, Cursor, and most non-browser clients do this automatically once configured). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it requires an Autoview account token, and it explains semantics annotations cannot express (live_allowed vs. dry_run_forced with upgrade_url, paper venues, failing_hooks meaning a stuck webhook loop).
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 imperative "Read this FIRST" is front-loaded and every sentence carries substantive content about the return surface. It is one very long, heavily parenthesized sentence, which costs readability, but there is no filler or restatement of the name.
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, the description rightly takes on the burden of describing the payload field-by-field, including conditional fields (upgrade_url, recommended_first_exchange, failing_hooks), and it states the auth requirement. It omits error/empty-state behavior and any note on refresh cadence, which keeps it from a 5.
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 100% and the schema already documents the token parameter, including the full `Authorization: Bearer` header fallback. The description adds only "Requires your Autoview account token," which restates the schema rather than extending it, so the baseline 3 is appropriate for a single fully-documented parameter.
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?
States a specific verb and resource (account overview) and then enumerates the exact data returned: token scopes, callable exchanges, live vs. dry-run gating, per-exchange facts, hooks. An agent can tell immediately that this is the orientation/introspection tool, distinct from mutating siblings like connect or command.
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?
"Read this FIRST" gives explicit ordering guidance, which is strong context for an entry-point tool. However, it never names an alternative sibling (catalog, hooks, connect) or states when not to call it, so it stops short of the 5-level routing guidance.
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.
alertcatalogcommandconnectentryeventshookssetupAgent-native marketplace. Bootstrap, list inventory, search, negotiate, and trade via MCP.
Trade 16 crypto exchanges + MetaTrader 5 from your AI assistant via one MCP connection.
Agent-to-agent marketplace with escrow-protected trades via MCP tools.
Agentic brokerage access to a US brokerage account: quotes, orders, positions, cash and documents.
Add one secure layer between your agents and this server.
