Give your agent the endpoint.

Use InvokeWorks from an MCP client that supports Streamable HTTP and authorization headers.

https://mcp.invokeworks.dev/mcp

1. Authenticate with LiveAuth

Obtain an active MCP session token for the InvokeWorks project through the LiveAuth start/confirm flow. The proof-of-work path needs no agent account, subscription, or human payment step. Session budgets and expiry still apply.

Supply the token as Authorization: Bearer <liveauth-jwt>. Keep tokens out of source control. Discovery is public; tool invocations require authorization.

2. Use InvokeWorks from an MCP client

This JavaScript example uses the same MCP client package and Streamable HTTP transport as the repository's integration tests. Set LIVEAUTH_JWT to your active InvokeWorks session token.

npm install @modelcontextprotocol/client@^2.0.0

import { Client, StreamableHTTPClientTransport } from '@modelcontextprotocol/client';

const jwt = process.env.LIVEAUTH_JWT;
if (!jwt) throw new Error('Set LIVEAUTH_JWT to an active InvokeWorks MCP session token');

// One ID per logical call. Keep this ID and the arguments unchanged on a retry.
const requestId = crypto.randomUUID();
const client = new Client({ name: 'site-audit-client', version: '1.0.0' });
const transport = new StreamableHTTPClientTransport(
  new URL('https://mcp.invokeworks.dev/mcp'),
  { requestInit: { headers: {
    Authorization: `Bearer ${jwt}`,
    'X-Request-Id': requestId,
  } } },
);

try {
  await client.connect(transport);
  const result = await client.callTool({
    name: 'site_audit',
    arguments: { target: 'https://example.com' },
  });
  console.log(result); // Audit result plus _meta.liveauth billing metadata / receipt.
} finally {
  await client.close();
}

3. Give your agent a task

Audit https://example.com and tell me the most important issues.

The agent can invoke site_audit with { "target": "https://example.com" }. LiveAuth meters the accepted execution at 5 sats, and the audit result comes back with billing metadata and a receipt.

X-Request-Id becomes the billing idempotency key. Preserve it and the arguments for retries of the same call; generate a new ID for a new task. A retry can run the audit again without creating a duplicate charge. Execution failures after charging remain billable.