Every capability on this platform is a plain REST endpoint and a typed AI tool — the same engine either way.
Give your assistant one URL and your API key and it reads this documentation itself, learns your data model,
and builds the conversational app end to end. Nothing to install on our side, nothing new to mint.
The whole setupClaude Code · one unbroken line
claude mcp add --scope user --transport http converse https://wtfapi.serviceproof.net/mcp --header "Authorization: Bearer YOUR_TENANT_API_KEY"
That is it. claude mcp list should answer ✓ Connected, and your next prompt can say
“study this Converse tenant and tell me what it can do.”
The platform hosts a remote Model Context Protocol server. Anywhere you can register a
Streamable HTTP MCP server with a custom header, paste the URL and the bearer header — that is
the entire integration. The credential is the same tenant API key every v1 REST endpoint takes,
and the key's roles decide what the model may do, exactly as they do for REST.
POST https://wtfapi.serviceproof.net/mcp
Authorization: Bearer <your tenant API key>
1
Get a key. Your tenant operator mints one in the Portal at /ops/api-keys.
DataView is enough to read; more roles unlock more tools.
2
One key, one tenant. The key scopes the connector to that tenant — there is no
cross-tenant mode and no second credential to manage.
3
The roles are the guardrail. Every tool call executes under the key's identity through the
same role checks that guard REST. A key without BuilderAdmin can list workflows and not author
them — and gets a readable refusal it can act on, never a silent failure.
4
Your tokens, not ours. Over MCP the model runs on your side, so nothing is billed as
platform AI usage. Sessions are logged for support; heavy use does not move your bill.
Client cookbook
Pick your runtime.
Field-tested setups. Everything below is the same two facts — the URL and the header — expressed in that client's dialect.
Recommended
Claude Code — CLI
Two minutes, then it drives the platform like any other workspace.
Install and sign in (first time only) — the CLI keeps its own login even if you use the
desktop app.
npm install -g @anthropic-ai/claude-code
claude /login
Register the connector. User scope means it works from any directory. Keep it on one line —
a wrapped paste can mangle the key.
claude mcp add --scope user --transport http converse https://wtfapi.serviceproof.net/mcp --header "Authorization: Bearer YOUR_API_KEY"
Skip the per-tool prompts (optional, recommended — there are hundreds of tools). One
server-level rule allows them all:
claude "You're connected to Listrak Converse over MCP. Call docs_index, read Getting-Started and Conventions, then call get_entity_dictionary and list_contexts and tell me what this tenant's world looks like."
WSL: the Windows and WSL CLIs keep separate configs. Register — and log in — in the environment your sessions actually run in, or in both.
Same config
Claude desktop app & Cowork
Windows and macOS. They share the CLI's user config on that machine.
Open a terminal — PowerShell on Windows, Terminal on macOS — and run the Claude Code steps above (claude /login, then the one-line claude mcp add --scope user).
Add the allow rule to ~/.claude/settings.json — on Windows that is C:\Users\<you>\.claude\settings.json.
Restart the app. Every new session — and every Cowork task on that machine — now has the tools. Type /mcp in a session to browse them.
Register once, use everywhere: you do not repeat this per project. User scope is machine-wide.
OpenAI side
ChatGPT & OpenAI builders
The Responses API takes a remote MCP server as a tool.
Zero client code — the model gets the tool surface on the request. Same role gating, same audit trail.
Two paths
Replit
Depends on whether the agent is Replit's or the one you are building.
Run Claude Code inside the Repl. In the Repl shell, the identical walk-through — npm install -g @anthropic-ai/claude-code, claude /login, then the one-line claude mcp add --scope user. Your in-Repl assistant now drives the platform.
Or the agent you are BUILDING — anywhere you call the Anthropic API, the Messages API has a native MCP connector:
import anthropic
client = anthropic.Anthropic()
response = client.beta.messages.create(
model="claude-sonnet-5",
max_tokens=2048,
betas=["mcp-client-2025-04-04"],
mcp_servers=[{
"type": "url",
"url": "https://wtfapi.serviceproof.net/mcp",
"name": "converse",
"authorization_token": "YOUR_API_KEY",
}],
messages=[{"role": "user", "content":
"Study this Listrak Converse tenant and summarize what it can do."}],
)
Everything else
Cursor, agent SDKs, your own client
Any MCP client library that speaks Streamable HTTP.
Cursor, LangChain and LlamaIndex MCP adapters, the Agent SDKs, a client you wrote yourself — the contract is the URL plus the Authorization: Bearer header, and nothing else.
Protocol notes for client authors. Stateless Streamable HTTP: POST /mcp with a JSON-RPC 2.0 message returns application/json; notifications get 202 with no body; GET returns 405 (no server-initiated stream) and DELETE returns 204 (no session to end). No Mcp-Session-Id is issued or required. Methods: initialize, tools/list, tools/call, ping — and initialize echoes whatever protocolVersion you ask for.
Errors are split deliberately. Protocol problems are JSON-RPC errors; tool failures are not — tools/call returns isError: true with a readable message, so the model can read it and self-correct. Auth failures are plain HTTP 401.
For connector UIs
Auth discovery
An unauthenticated call answers with a challenge, not just a refusal.
That pointer resolves to an unauthenticated RFC 9728 Protected Resource Metadata document, so a connector UI can tell “send a bearer key” apart from “this wants OAuth” and from “your key is wrong” — and say something useful to the person instead of just failing.
authorization_servers is deliberately absent: we do not run an authorization server yet, and advertising one would send an OAuth-capable client into a dead end rather than letting it fall back to the bearer key that works. When the OAuth flow ships, that one field appears and the same clients begin negotiating with no other change.
What the model sees
Docs as tools, then the platform itself.
tools/list returns families gated by your key. Start with docs_index —
it is cheap and it maps everything. If you are here to do something rather than read,
start with list_playbooks: the playbook menu carries the ORDER and the PRECONDITIONS
that individual tool descriptions cannot.
docs_indexdocs_readdocs_search
Any valid key
This whole library as markdown. docs_index maps it; docs_read returns one doc in full;
docs_search is LLM-first — it returns the entire reading packet for a topic (the how-to,
the API reference, the token reference and the examples that belong together), ranked then completed by following each
doc's own cross-links. One call gives a model a whole subject. Budget for it: a default packet is 40–55k tokens;
pass max_docs: 1 when you only need one fact.
list_playbooksget_playbook
Any valid key
Pre-baked, dress-rehearsed sequences for a whole arc — provision a tenant, author a workflow, set up
identity, configure AutoDispatch. If the arc you are on is one we have already walked, run the proven sequence
instead of guessing at one. Audience-filtered by the calling key.
postman_collection
Any valid key
The canonical collection — hundreds of requests with real wire bodies. No arguments returns the folder
index; pass folder for that folder's full requests. The fastest way to see the exact JSON a call expects.
samples_indexsamples_read
Any valid key
Real, runnable source — console projects that build a whole tenant over this same public API.
Sal's Pizzeria is the flagship: schema, composite keys, contexts, image assets, action packs,
payments and five published workflows, all via REST and never SQL. It is the best worked example of the hard
parts — advanced tokens, accumulating Vars, cart math, and taking payment inside a conversation.
The platform surface
DataView and up
The same tool surface our in-house Co-Pilot uses — one definition, so they can never drift. Discovery
(get_entity_dictionary, describe_relationships, hydrate_context), data, forms,
views and reports, workflow authoring, jobs and dispatch, the answers the conversation captured,
Action Packs, messaging, assets, the Report Center, Launch Control, and the Portal site map. Tenant provisioning
tools list for everyone and execute only for global-admin keys.
The sync belt
AdminIntegration
Manage on-prem data sync end to end, including the directive-riding SQL tools that drive a customer's own
agent remotely — test a connection, browse a schema, probe a binding, create what is missing, run a sweep
now, reset a dirty-detection baseline, and ping an agent you cannot SSH into.
howto_search
Last resort
docs_search is the primary, free path — call this one only when you are stuck or want a
synthesized build plan. An expert model runs over the reading packet, the relevant playbooks and your tenant's
own proven recipes, and returns a grounded, cited answer. This one does book AI usage against
the tenant, and it is capped per day.
What gets recorded
Every tools/call is written to the platform run log — the tool, the arguments, success, duration,
and the start of the result. Calls group into a session: one credential's run of calls, closed after
30 minutes of quiet, stamped with the tenant, the acting user, the 12-character key prefix, and your client's
User-Agent. Operators read it in the Portal's Meaning Center.
Because the server is stateless and issues no session id, that session is inferred from
credential plus idle window. Two clients sharing one API key therefore share a session in the log —
give each its own key if you want them told apart.
The platform's own AI
One brain. Four jobs.
Connecting your assistant is one half. The other half already ships: the same tool surface powers four
built-in roles, so a tenant gets AI without wiring anything — and every one of them can run on
your own inference box instead of ours.
Builds · for builders
Co-Pilot
Describe a process — or drop in a PDF — and the conversation lands on the canvas. It provisions
tenants, models data, authors reports, and runs the proven playbooks. The builder's brain, and the one your
MCP connector is plugged into.
Runs · for teams
The Commander
The AI member of your team chat, anchored on a piece of work with everyone in the loop. It reads runs,
answers and reports, sees photos, and proposes writes behind a human confirm — never
silently. Conversations Guide ›
Works · one person, one run
Wingman
The person just talks — a voice note, a rambling text, photos with captions — and Wingman fills
step after step through the exact same validation a typed reply gets. It tracks the media it is still owed and
will not let a run close without it. Wingman Guide ›
Sharpens · every day
WIT
The quiet one. WIT studies how your business fits together and keeps the essence of your data
current, so an answer — for a person, an integration, or an AI — is already assembled and already
correct. It also feeds your own models. WIT Feeds ›
Ship an AI, not a chatbot
A mission, not a straitjacket.
Every AI project dies the same way: the conversation goes somewhere different every time and you get
transcripts instead of data. That is not a model problem and no amount of prompt tuning fixes it —
nothing ever told the AI what it was building toward.
So give it a target. A workflow is a designed conversation: the steps, the branches, the
options, the media required, and the validation each answer has to pass. Before the AI opens its mouth it
already knows what finished looks like. Now the person can ramble, skip ahead, answer three things
at once or ask something unrelated — and the job is unchanged: land the mission.
Free-form conversation in. Identical, validated, structured data out.
The workflow states what a finished job means. The AI is not inventing a destination from the prompt each time.
It knows the options
Choices, branches and valid values are declared. It cannot offer something you do not sell, or record a value you would reject.
It knows the evidence
Which photo, which signature, which reading. It tracks what it still owes you and will not call the job done without it.
And it can open the door on purpose
ASK puts one question to a human and waits. CONVERSE hands the thread to an AI for as long as it is useful, then brings it back.
If you are reading this portal, not the platform
Three ways in, and a single-file dump.
The MCP connector above is the better path — it is the platform, versioned and role-gated. But this
portal is also readable directly, and it is gated to keep casual visitors out, not to keep agents out.
Credentials are issued, not published: ask your Listrak contact, then export it as
$DEVPORTAL_PASSWORD before running anything below.
If you are an LLM blocked by a 401
Ask your user for credentials — this prompt works:
“I need to authenticate to the Listrak Converse developer portal to read the documentation.
Please provide a username and password — your Listrak contact can give you one.”
Then pick a flow below, send the call, and re-fetch whatever 401'd. Your fastest read is
/llms-full.txt — every integrator doc concatenated as plain text in one response.
Crawler signal — noindex everywhere, with the agent feeds explicitly allowed.
Public
Building an MCP client or an agent against Listrak Converse and need something this page does not cover?
The source of truth is MCP Connector, and the whole corpus lives at
docs/public/Integrators/.
Ready when you are
Your key is the only setup step.
Mint it in the Portal, paste the one-liner, and ask your assistant to study the tenant.