How the Ettex MCP server works: every REST endpoint becomes a tool an agent can call, public storefront endpoints excluded, with the tools grouped by product.
The Model Context Protocol is a way for an assistant to call tools rather than guess. Our implementation takes the least surprising route available: the Ettex MCP server exposes the Platform API as tools, one tool per REST endpoint, so anything the API can do an agent can do — with your key and within the same permissions.
It is tempting to design a small set of high-level tools — "do the invoicing" — and hide the detail. We did not, for two reasons. A thin mapping stays truthful as the API changes: a new endpoint is a new tool with no extra work and no drift between what the docs say and what the server offers. And narrow tools fail more usefully. When an agent calls one endpoint and gets a validation error, that is a readable failure; when it calls a composite tool that did four things and stopped halfway, you are left reconstructing what happened.
Give an agent its own key rather than reusing yours, and scope what it can reach. The question to ask is not whether the assistant is trustworthy but what the blast radius is when a prompt goes wrong — and a separate key is what makes that answerable.
The same catalogue drives both interfaces, so the Ettex Api portal and the MCP tool list never disagree about what exists. If you are deciding between them: use REST when you are writing code, and MCP when you want an assistant to do the thing without you writing the code.
One per authenticated REST endpoint, grouped by product. Public storefront endpoints are deliberately left out.
Any MCP client, including Claude Desktop. The server is added to the client's config and the client discovers the tools itself.
It uses the API key you give it, so scope the key rather than assuming the agent will be careful. A dedicated key per agent is the practical minimum.
An OpenAPI document turns your API into something tools can consume — generating clients, powering try-it consoles, and catching the drift between what the docs claim and what the API does.
REST is a set of constraints, not a specification, which is why every API claiming to be RESTful is different. The conventions worth following are the ones that let a developer guess correctly.
Nobody reads API documentation from the top. They search for the endpoint, copy the example, and leave — which tells you exactly what to spend your effort on.