MCP Server

The server proxies the Moneyline API. Anything an agent does through it is scoped to the API key it authenticates with, so it sees exactly what that tenant sees.

Tool paths are verified against the OpenAPI spec in CI, so they cannot silently drift from the API. Run tools/list against a running server for the live, authoritative catalog — the tables below are a guide, not the source of truth.

Install

Build from source:

cd apps/mcp && bun install && bun run build

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "moneyline": {
      "command": "npx",
      "args": ["-y", "@moneyline/mcp-server"],
      "env": {
        "MONEYLINE_API_KEY": "ml_live_xxxxx",
        "MONEYLINE_API_URL": "https://api.moneyline.co"
      }
    }
  }
}

Pointing at a local build instead:

{
  "mcpServers": {
    "moneyline": {
      "command": "node",
      "args": ["/path/to/moneyline/apps/mcp/dist/index.js"],
      "env": {
        "MONEYLINE_API_KEY": "ml_test_xxxxx",
        "MONEYLINE_API_URL": "http://localhost:3000"
      }
    }
  }
}

Claude Code

claude mcp add moneyline \
  --env MONEYLINE_API_KEY=ml_live_xxxxx \
  --env MONEYLINE_API_URL=https://api.moneyline.co \
  -- npx -y @moneyline/mcp-server

Transports

Selected by MCP_TRANSPORT.

Nothing needs to be hosted to use the server: stdio runs it as a subprocess of your MCP client, and is the right choice for a single user on one machine.

Run the HTTP transport when you want one deployment to serve several people or a remote agent:

MCP_TRANSPORT=http MCP_PORT=3333 MONEYLINE_API_URL=https://api.moneyline.co \
  npx -y @moneyline/mcp-server

It is stateless — each POST /mcp is handled by a fresh server bound to the caller's key from the Authorization header, so one deployment serves many tenants and holds no cross-request state. GET /health is an unauthenticated liveness probe. A request without a key gets 401.

Connecting with OAuth

An API key identifies a tenant and never expires, which is right for a server you control and wrong for someone connecting their own account to an agent they installed. For that, the Moneyline API is also an OAuth 2.1 authorization server, so a client can be authorized by a user instead of configured with a shared secret — and that grant can be revoked without rotating a key everything else depends on.

The hosted MCP server advertises where to go:

curl https://mcp.moneyline.co/.well-known/oauth-protected-resource

{
  "resource": "https://api.moneyline.co",
  "authorization_servers": ["https://api.moneyline.co"],
  "bearer_methods_supported": ["header"]
}

A request without credentials also answers with the same pointer, so a client can begin the flow from the failure rather than needing to be told about it:

WWW-Authenticate: Bearer resource_metadata="https://mcp.moneyline.co/.well-known/oauth-protected-resource"

From there the standard endpoints are discoverable at the authorization server:

curl https://api.moneyline.co/.well-known/oauth-authorization-server

Dynamic client registration (RFC 7591) is supported, so a client can register itself rather than the operator provisioning one by hand, and PKCE (S256) is required. The user signs in on the dashboard and approves the request; the token that comes back is bound to that user, carries an expiry, and is accepted by the API anywhere an API key is.

Environment variables

Leave MONEYLINE_API_KEY unset under http — the key comes from the request.

Tools

Workflows (14)

The workflow builder, exposed so an agent can do what the studio UI does.

Call moneyline_list_node_types before authoring. Activation refuses any node type the engine cannot run, so an agent that guesses type strings writes a graph it cannot activate — and the catalog is the difference between composing a workflow and guessing at one.

Node positions and edges are optional. The API requires an x/y per node because the canvas needs one, but an agent composing a pipeline has no opinion about layout: omitted nodes are laid out in a readable column, and omitted edges wire the trigger through the nodes in the order given. The result still opens in the builder.

Submissions (8)

Documents (5)

Analytics (9)

Policies (4)

Transactions (3)

Integrations (2)

Resources

Read-only access over moneyline:// URIs.

Examples

Once configured, ask Claude:

"What workflow node types are available? Build me a pipeline that classifies an uploaded document, parses it, and raises a task if the risk score is over 700."

"Clone the MCA application template, activate it, and run it against submission sub_abc123."

"Show me the last five runs of my invoice workflow and tell me which node the failed ones stopped on."

"Create a submission for Acme Corp with external ID acme-001, upload this bank statement, and generate a scorecard."

Verifying a local setup

With the server built, a handshake and tools/list over stdio needs no API:

printf '%s\n' \
  '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"t","version":"1"}}}' \
  '{"jsonrpc":"2.0","method":"notifications/initialized"}' \
  '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
  | MONEYLINE_API_KEY=ml_test_xxxxx node dist/index.js

A tool that reaches the API needs MONEYLINE_API_URL pointing at a running one.

Develop

bun run dev    # stdio, watch mode
bun run test   # vitest
bun run build  # -> dist/