Connect an agent client to AMM MCP

View full-size screenshot ↗

Open the MCP control plane#

AMM's MCP server runs inside the AMM API process. Open System › MCP server to inspect Running/Stopped state, endpoint, connection snippets, clients, recent requests and exposed tools. Starting or stopping MCP changes which protocol calls are accepted; it does not start another daemon or stop active backtests, optimizations or live sessions.

The API must already be running. This MCP surface is intended for a desktop agent client on the same machine. Loopback-only access is the default and recommended operating boundary. A cloud-hosted agent cannot reach your machine's loopback endpoint simply by being given its URL.

Choose a transport#

Streamable HTTP is canonical, normally at /mcp on the selected API origin. Copy the generated HTTP URL/config from the page into a client that supports that transport. Prefer the generated snippet because it reflects the current path and installation. Legacy SSE /mcp/sse and /mcp/message transport paths are unavailable.

For a client that must spawn a command, use the generated stdio snippet. The stdio process proxies the canonical HTTP server; it does not execute a separate copy of AMM's business runtime. Its tool list follows the running API. If the page reports the stdio launcher unavailable, use direct HTTP or install/build the launcher through your supported AMM distribution rather than inventing a command path.

For source-based developer installations, the documented launch shape is:

dotnet run --project tools/AMM.Mcp.Stdio -- --server-url http://127.0.0.1:5100

Run that only from a source installation containing the project. Packaged users should copy the generated installed-client snippet. Authenticated HTTPS stdio connections use the supported token-file setting, not a token embedded in the URL.

Discover tools instead of freezing a list#

Connect the client and call MCP tools/list. AMM combines curated workflow tools with one generated tool for each registered REST operation. The MCP page and /api/mcp/status show the current combined catalogue. New REST operations become discoverable without maintaining a second endpoint list.

Useful curated starting points include amm_list_algorithms, amm_list_trading_venues, ui_list_commands and ui_invoke_command. Generated tool names begin amm_rest_ followed by a stable operation identifier; long names can contain a stable hash suffix. Discover the actual name rather than constructing it from a URL by hand.

The catalogue spans research, batches, walk-forward, portfolio/risk, instruments/groups, screeners, downloads, live sessions, audit, credentials and desktop control. Availability still follows the underlying service: a generated tool does not add unsupported broker operations, missing entitlements or a disconnected desktop.

Supply generated arguments correctly#

A generated tool exposes the REST operation's declared path, query, headers and body schema. Path values are named route values; query arrays repeat a key. Ordinary scalar query values are supported, nested query objects are not. Authentication/Host/Origin/cookie/framing header overrides are rejected because the transport owns that boundary.

Choose at most one body representation: JSON body, UTF-8 rawBody, binary bodyBase64, or multipart form. Use the declared content type. Multipart parts are text values or file entries with name, filename, base64 bytes and content type. Most user workflows need only JSON; do not wrap a JSON object in a string unless the schema asks for text.

Results retain statusCode, content type and response headers, plus JSON body, textual text or binary bodyBase64. Check the MCP error flag and HTTP status. A tool can return a structured error rather than throwing a transport exception. Binary exports remain exact bytes, not a prose summary of the file.

Verify actions and normal confirmations#

Begin with read-only discovery and state. For a mutation, inspect the input contract and current target. A live operation still requires the normal approved account graph, preflight and explicit LIVE confirmation. Credential fields remain write-only and profile/revision checks still apply. MCP does not bypass any of those services.

Desktop workflows require a connected elected primary app. Use command discovery, then invoke the intended command. For granular UI control, page through mounted targets, open the relevant item/dialog, rediscover, and invoke a currently enabled action. Targets can expire when widgets unmount or the app restarts.

Read completed, failed, scheduled, no-ui and timeout carefully. An accepted queued switch must be verified after reconnection at the new server. A timeout is an uncertain outcome; read current state before repeating an order or workspace mutation. Transport success alone is not task completion.

Monitor and recover#

The MCP screen groups tools and filters read-only/mutating calls. Recent requests show client, transport, tool, status and duration; client rows identify recent observed activity. Activity is bounded and in-memory, so it is useful diagnostics, not a permanent execution ledger. Clear activity resets that view only.

A stopped server returns 503. A non-loopback caller under loopback policy returns 403. An unsupported legacy path returns 404. If connection works but an action fails, inspect its returned REST/UI error, account identity and provider capability. Use REST API for the underlying contract and UI Command Bus for connected-desktop routing. Keep current generated snippets and discovery as the update path when AMM gains features.