MCP

{
  "mcpServers": {
    "general-liquidity": {
      "command": "bunx",
      "args": ["github:general-liquidity/general-liquidity-mcp"],
      "env": {
        "GL_BASE_URL": "https://sandbox.api.generalliquidity.com/",
        "GL_SIGNER_PRIVATE_KEY": "…"
      }
    }
  }
}

Started without a signing seed it still resolves, verifies and discloses, and refuses to sign a payment. There is no reason to put a key somewhere that will not use one.

The tools

resolve

Normalise a counterparty reference into one identity with its accepted ways to be paid.

pay

Submit a signed instruction. We decide; on yes it settles and returns a receipt.

verify

Check a counterparty's signed claim against policy.

disclose

Produce this agent's own signed claim.

What the agent cannot do

It can ask to pay. That is the point of the integration. What it cannot do is approve its own payment, change its own limits, or hold the thing that actually moves money. Those need the operator credential, which is not part of this server's surface at all.

Embedding it instead

Where the host already holds a client, skip the binary and construct the server directly.

import { createClient } from "@general-liquidity/sdk";
import { createMcpServer } from "@general-liquidity/mcp";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = createMcpServer(createClient({ baseUrl, signer }), {
  name: "general-liquidity",
  version: "0.1.0",
});

await server.connect(new StdioServerTransport());

Configuration then comes from the client you inject rather than from the environment. Either way, tool inputs are snake_case on the wire, so a pay call carries idempotency_key, capital_source and mandate_id.

Point it at the sandbox first. The tools behave identically, and a refusal in the sandbox reads exactly like a refusal in production, which is what you want to test against.