Use Tradewink with Claude, Codex, and the signals API

Use an AI assistant to explain the idea and organize your checks. Keep research, signal retrieval, and order permissions separate so you know what the assistant can actually do.

Before installing tools or choosing a plan, inspect a public signal record. Use the timestamp, reasoning, and missing fields to decide whether this is the kind of research you want in your own workflow.

Choose MCP or the signal API

MCP: Connects Claude, Codex, or another compatible client to Tradewink tools for market data, strategies, analysis, and account workflows. MCP access is available on the Free plan, subject to tool permissions and account requirements.

REST signals API: Retrieves published signal records for your own application. This requires Pro or Elite API access. The current MCP tool set does not include a dedicated subscriber signal-feed tool. Strategy results are not interchangeable with delivered signal records.

For a no-code explanation, open a signal and provide its non-secret contents to your assistant. Include its ID, timestamp, symbol, asset class, direction, levels, and reasoning. Ask it to identify missing facts instead of guessing.

Connect your assistant

Install Node.js with npm if your computer does not already have it. For Claude Code, run:

claude mcp add tradewink -- npx -y @tradewink/mcp

For Codex CLI, run:

codex mcp add tradewink -- npx -y @tradewink/mcp

The package also provides an interactive setup helper for supported installed clients:

npx @tradewink/mcp setup

On first use, complete Tradewink's browser authorization and review the account you are authorizing. Restart or reconnect your client if needed, then confirm the Tradewink tools appear. Use MCP setup for other clients and the current connection details. Claude's official MCP documentation explains client scopes and approvals.

Keep tool approvals enabled. Do not select an unrestricted auto-approve mode for trading tools. Never put broker secrets or account tokens into a prompt.

Start with a research-only prompt

Explain this Tradewink signal in plain language. Check its symbol, timestamp, asset, proposed entry, invalidation, and target. Separate facts from assumptions. Compare with current data if available. Tell me what is missing and whether the original setup is stale. Do not place orders, change preferences, or enable trading.

Retrieve actual signals in your application

Generate or manage your eligible signal API key in API Keys. Store it server-side. This read-only POSIX-shell example expects the key in an environment variable; it does not place a trade:

curl --fail --silent --show-error \
  -H "Authorization: Bearer $TRADEWINK_SIGNAL_API_KEY" \
  "https://tradewink-signals.fly.dev/api/v1/signals?limit=5"

The response contains a signals array. The endpoint supports ticker, signal_type, and limit filters. Pass only relevant signal fields to your assistant; do not pass the authorization header. A 401 means authentication needs attention; an entitlement rejection requires checking the API plan. Do not retry either indefinitely.

Polling this endpoint is your application's job; connecting MCP does not create a background signal subscription. Deduplicate by signal ID and evaluate age before proposing any action. If you want push delivery instead, use webhooks.

Preview an order before any submission

After independently choosing your paper account and proposed ticket, ask:

Verify which broker account and paper/live environment are selected. If you cannot verify them, stop. Prepare a place_order preview with confirm=false for the exact ticket I provide. Show the symbol, side, quantity, type, price constraints, and estimated cost. Do not submit, close, cancel, change preferences, or substitute missing fields. Wait for my explicit approval.

The current place_order tool defaults to confirm=false and returns a PREVIEW. This is neither a submitted order nor a simulated fill. A subsequent confirm=true call can submit an order if the connected account and risk checks permit it. A prompt is not a security control: use client approvals and application-enforced limits too.

The tool's basic entry-order parameters do not create a complete bracket merely because a signal contains a stop and target. Review any exit workflow separately. Do not assume all broker-native features are exposed through MCP.

Verify what happened

An order response is not fill proof. Reconcile the broker order ID, status, filled quantity, and average fill price in the broker account. Use get_open_orders for outstanding orders and available history tools for supporting records; an order disappearing from the open list alone does not prove a fill.

For a custom AI-to-broker integration, enforce symbol/asset validation, freshness, deduplication, size limits, an explicit approval step, and a stop mechanism outside the model. Start with the Alpaca paper checklist. Live broker workflows remain optional and eligibility-dependent.

Educational information only, not investment advice. AI can make mistakes, and paper or live orders can be rejected, remain open, or fill differently than expected.