Connecting an MCP client to ABI

Start with the intended workflow

Evaluate a local integration from an MCP client into the ABI tool catalog.

The handler catalog defines twelve tools spanning AI completion, learning and training, WDBX query and statistics, scheduler inspection, connectors, GPU status and plugins. Requests pass through explicit argument validation and dispatch.

Local entry points

Build the MCP binary from the ABI checkout (`./tools/cargo.sh build -p abi-mcp`); `mcp/launcher.sh` runs `target/release/abi-mcp` or `target/debug/abi-mcp` and exits if neither exists. Use disposable data for evaluation; do not connect a test to a live memory store.

ABI_WDBX_PERSIST=0 ./mcp/launcher.sh stdio

Acceptance and limits

Start with initialization and tool discovery, then a harmless read-only call. Validate the exact client transport and required arguments. Enable writes or provider calls only within the intended application permissions.

The best-effort loopback HTTP listener (127.0.0.1 only) serves MCP 2024-11-05 HTTP+SSE sessions; it is not a general web server and not Streamable HTTP (2025-03-26).

A listed tool does not prove provider credentials, production access or remote deployment.

A minimal read-only protocol exercise

After building the ABI MCP binary, send newline-delimited requests using the local launcher. Persistence is explicitly disabled for this example. The initialization request, tool discovery and gpu_status call exercise handshake, catalog and read-only dispatch. Match response IDs and inspect protocol errors rather than treating process startup as successful integration. The binary always attempts its loopback HTTP listener at startup; the resulting stderr line (listening, or unavailable and continuing with stdio only) must be interpreted separately from stdio responses.

ABI_WDBX_PERSIST=0 ./mcp/launcher.sh stdio <<'JSONRPC'
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"mlai-research-check","version":"1"}}}
{"jsonrpc":"2.0","method":"notifications/initialized"}
{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}
{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"gpu_status","arguments":{}}}
JSONRPC

Catalog and error checks

The frozen tools are ai_run, ai_complete, ai_learn, ai_train, wdbx_query, scheduler_stats, scheduler_info, connector_test, gpu_status, plugin_list, wdbx_stats and plugin_run. scheduler_info is a compatibility alias. Test an unknown tool and a missing required argument separately from successful calls. Catalog presence says that an interface exists; it does not imply credentials, populated storage or production authorization.

Transport selection and adoption

Stdio is the primary transport; use it when configuring a client unless the client needs HTTP. The binary also attempts a loopback HTTP listener at startup; stdio runs either way, and the process stays stdio-only if the listener cannot bind or report its port. The listener binds 127.0.0.1 only, defaults to port 8080 (ABI_MCP_HTTP_PORT) and accepts optional bearer auth via ABI_MCP_HTTP_TOKEN. GET /sse opens a persistent MCP 2024-11-05 HTTP+SSE session whose endpoint event names /message?sessionId=<id>; a POST to that path gets 202 Accepted and its response arrives as a message event on the stream (a notification gets 202 and no event), and an unknown session gets 404. POST /message without a session keeps the original mode: one JSON-RPC request body, one JSON-RPC response over HTTP. The listener lives only while stdio is open: when stdin reaches EOF the process stops it. The listener is not Streamable HTTP (2025-03-26), so a client that speaks only that transport needs a different implementation. Before enabling writes, define data ownership and error recovery for each tool. This guide does not ask you to run learning, training or plugin side effects as a handshake test.