Amazon Q Developer CLI

Add the server

Either the CLI:

q mcp add --name vike-trader --command vike-cli --args '["mcp", "--node", "127.0.0.1:7879"]'

or edit the config file directly.

Global, at ~/.aws/amazonq/mcp.json — available in every workspace:

{
  "mcpServers": {
    "vike-trader": {
      "command": "vike-cli",
      "args": ["mcp", "--node", "127.0.0.1:7879"]
    }
  }
}

Per workspace, at .amazonq/mcp.json in the project directory — the same shape, scoped to that project.

Scoping what the tools reach

Both vike-cli mcp flags are optional and both only widen what the tools reach. --node <host:port> is the running vike-tradehub the live tools observe and control — no default. --addr <host:port> is the vike-datahub the backtest tools ship profiles to, defaulting to 127.0.0.1:7878. With neither, the four offline authoring tools — validate_strategy, discover_params, list_templates, list_indicators — still work, which makes a flag-less entry a reasonable first step:

{
  "mcpServers": {
    "vike-trader": { "command": "vike-cli", "args": ["mcp"] }
  }
}

The entry also takes an optional timeout in milliseconds — how long the client waits for a tool response, defaulting to 60,000. Every tool here answers in well under that, with one shape worth knowing: a confirmed write waits up to two seconds for the node's acknowledgement (ACK_WAIT in crates/vike-cli/src/cmd/mcp.rs) and then answers outcome: "unknown" rather than hanging, so the client timeout is not what protects you from a slow node.

If the binary is reported as not found, give command an absolute path.

The node keys

The entry takes an env block, and the two node keys are the only credentials involved — there is no Vike account and nothing here is metered:

{
  "mcpServers": {
    "vike-trader": {
      "command": "vike-cli",
      "args": ["mcp", "--node", "127.0.0.1:7879"],
      "env": { "VIKE_TRADEHUB_OBSERVE_KEY": "..." }
    }
  }
}

Prefer not to. Each key resolves from the process environment first and then from <project>/settings/secrets.env, the same store the vike-tradehub daemon reads (crates/vike-cli/src/cmd/nodekeys.rs's resolve), so on a configured box the store already reaches this server and one copy serves both halves. That matters most for VIKE_TRADEHUB_CONTROL_KEY: it places orders, and a per-workspace .amazonq/mcp.json sits inside the repository, one git add away from being committed.

vike-cli secrets path prints which store a directory resolves to; vike-cli secrets list shows whether a key is in it, by name — never values.

Verify

q mcp list
q mcp status --name vike-trader

Then, in a session:

list the vike strategy templates

list_templates is offline: no key, no node, no network. If it answers, the subprocess is running and the protocol is working, and anything still failing is an address or a key rather than the setup. With a node configured, "show me the node snapshot" proves the observe key too.

Troubleshooting

The server is not listed. Check which file you edited against q mcp list, and remember the union rule above — a name in both files resolves to the workspace copy.

It is listed but tools are never called. Name the tool — "use the list_templates tool" — to confirm the wiring before trusting the model to reach for it on its own.

The offline tools work and the node tools do not. That is an address or a key, not the MCP wiring. The two failures are worded differently on purpose: "no vike-tradehub node configured" means --node never arrived; "set neither in the process environment nor in the credential store" names a key, and names both places it looked.

A write tool answered but no order exists. Not a client problem. A write executes only when a call carries both confirm: true and the preview_token its own preview returned; anything less returns a fresh preview, will_execute: false, and no error at all. Live node is the contract.

Where this shape came from

The two config paths, the union-and-workspace-wins merge rule, the mcpServers object with command/args/env/timeout, and the q mcp add --name … --command … --args form were read from AWS's own Amazon Q Developer MCP documentation in September 2026, not from memory. That documentation is the authority if it has moved since; this page is the copy. Note that the CLI subcommands are documented under both q mcp and qchat mcp — the same command set.

The data server too

Amazon Q holds both Vike servers in the same mcpServers object — the hosted data server is a remote entry carrying type and url instead of command, beside this one. Data client setup has its shape. The names must differ, or the second replaces the first.