Choosing a surface
Wexa exposes the same set of tools four times over. The four surfaces are at parity by design, so choosing between them is not a choice about capability. It is a choice about where the code that calls Wexa already lives.
The four, and who each one is for
The Wexa MCP server is for an MCP client — a desktop assistant, an editor, anything that speaks the protocol. You configure the client once with an endpoint and a credential, and every Wexa tool shows up as a tool the assistant can reach. Pick this when the caller is a product someone else wrote and you are not writing code at all.
The REST API is for anything that can make an HTTP request. Pick it when you are calling from a language with no Wexa SDK, from a shell script, or from a system where adding a dependency is the hard part.
The TypeScript SDK and the Python SDK are for application code. They give you typed arguments, typed results and typed errors, and they refuse a bad call before it leaves your process rather than after. Pick the one your service is already written in.
What does not change with the surface
The tool you call, the arguments it takes, the policy decision it passes through, the audit record it writes and the result it returns are all the same. So is what you are not allowed to do: a surface is never a way around a rule, because the rules sit underneath all four.
This is why the tool reference is one reference rather than four. Each tool is described once, and each example carries the four call syntaxes side by side.
Answer three questions and you have chosen
If you would rather not weigh four descriptions against each other, this decides it.
- Is the thing calling Wexa a product someone else wrote — an editor, a desktop assistant? Then it is the Wexa MCP server, and you will write no code.
- Otherwise, is Wexa being called from TypeScript or from Python? Then use that SDK. You get typed arguments and typed errors, and some mistakes are refused before the request leaves your process rather than after.
- Otherwise — another language, a shell script, or somewhere a dependency is the hard part — use the REST API. There is nothing to install.
Start your quickstart
Each of the four takes you from nothing to one successful, verifiable call, and each covers getting a credential before it asks you to authenticate anything.
Configure a client, complete the handshake, watch a tool run. No code.
POST /v1/<tool-name> with a bearer token. Nothing to install.
Typed arguments, typed errors, ESM and CommonJS, Node 18 and newer.
One module, standard library only, Python 3.9 and newer.
Changing your mind later
Because the surfaces are at parity, moving between them is a rewrite of syntax and nothing else. A call you prototyped through the Wexa MCP server in an editor becomes the same call in production Python without changing what it does, what it is permitted to do, or what it records.
The one thing that does not travel with you is the credential's shape. An API key is pinned to a single project when it is minted, and the scope never widens — so a second project means a second key, whichever surface you moved to.