Tetrees' MCP server is a versioned tarball, and every spend needs a flag

The server arrives as a tarball from the vendor's domain

The quick start does not tell you to install a package from a registry. It tells you to point your MCP client at npx with a tarball URL served from the vendor's own domain.

{
  "mcpServers": {
    "tetrees-ai": {
      "command": "npx",
      "args": ["-y", "https://ex.tetrees.ai/pkg/tetrees-mcp.tgz?v=2.2.1"],
      "env": {
        "TETREES_API_URL": "https://ex.tetrees.ai/api",
        "TETREES_TOKEN": "<revocable-account-token>"
      }
    }
  }
}

The query string is the interesting part and the readme explains it rather than leaving you to guess. The version suffix prevents the package runner from reusing an older tarball cached under the same URL, and the instruction is to change it only when a newer MCP contract is published. The same code is also on the public registry under a scoped name at the matching version, so the tarball route is a deliberate choice about pinning rather than a hosting constraint. Two things to notice about the invocation itself: the package runner is told not to prompt before installing, and the only credential in the environment is a revocable account token, not a model provider key.

Every spend needs a quote first and a flag second

The client interface is written as an instruction with a budget in it, and the guard rails are literal rather than advisory. The example asks the agent to search for a suitable pack, show its public report and runtime profile, quote an eight-thousand input and two-thousand output point-funded run, and then explicitly not run it until the quoted maximum is approved. On the command line the same rule appears as two separate verbs.

# Quote first. This never starts a model request.
npm run tetrees -- quote <pack-id> <model-id>

# A Point-spending run needs the exact confirmation flag.
npm run tetrees -- run <pack-id> <model-id> "Your task" --confirm-spend

The buyer flow then adds two more properties that make the model tolerable. A preview run is stateless and unused reserved points return rather than being consumed. And ownership is the gate for everything local: download, your own provider key, saved growth and client extensions become available only after you acquire the pack. So the cost model is pay-per-run with a refund on unused reservation, and the durable cost is ownership rather than usage.

The CLI refuses to read a secret file for you

One instruction in the client section is short and load-bearing: copy the values from the example environment file into your shell yourself, because this project deliberately does not auto-load secret files. That is unusual, because most command-line tools in this space will read a dotenv file if one is present, and it removes an entire class of surprise where a tool silently picks up credentials from a directory you forgot about. The rest of the client's behaviour is equally conservative. It redacts secret-shaped response fields before printing them, it reports the vendor's error codes alongside the HTTP status and any retry-after header, and it does not retry a mutation automatically. That last one is the correct default for anything that can spend money, and the read-only commands are separated from the two that act, so you can inspect a pack's runtime profile, readiness report and skill list without touching a balance.

Local bindings never leave the machine and need a literal phrase

The builder path is where the security design is most specific. A published pack may declare client extensions, but only ones that passed the vendor's evaluation, and the binding itself and its credentials stay on the user's machine. Three patterns are supported and each is constrained in a named way: an HTTPS base URL with fixed declared methods and environment-backed headers; a nested MCP server started without a shell and mapped to declared tool names; and a local skill implemented as a no-shell child process that receives one JSON request and returns one JSON result. The no-shell constraint appears twice, which is the point, since a shell is where an extension stops being a declared capability. Then the sentence that matters most: hosting never inherits those local permissions. And a write method requires the exact per-call phrase naming the extension and the method, so an agent cannot silently invoke a mutating capability.

A check script enforces the boundary the README claims

The repository makes a long claim about what it does not contain: no agent implementation, no private pack contents, no memory representation, no growth logic, no scoring rules, no internal evaluation fixtures, no service prompts, no moderation logic, no provider credentials, no pricing margins, no signing keys, no storage details. A claim like that is only worth as much as the mechanism behind it, and here there is one. The package scripts include a command that runs a public-boundary check, and the aggregate check command runs the tests and that boundary check together. So the assertion is executable rather than aspirational, and it is wired into whatever the maintainer treats as the gate. The published file list reinforces the discipline from the other side: it ships the compiled server, the client sources, the examples, the docs and the agent instruction file, and it does not ship the tests or the scripts directory.

One runtime dependency, pinned exactly, with the build output committed

The dependency list is a single entry: the Model Context Protocol SDK at an exact version, no range. Everything else the client needs is in the standard library of the runtime, which is why the engines field only has to demand one runtime version of twenty or newer. The published file list is where the next detail sits. It ships a distribution directory under the server package rather than a source tree and a build step, so what npm delivers is compiled output, and the tests that would have validated a fresh build are not in the package at all. Two binaries are published: the server itself and the client, pointed at two different paths, one of them inside the built distribution and the other in the source tree. That is a normal split for a package that ships a protocol server alongside a command-line tool, and it is worth knowing which of the two you are invoking when you read a quick start that only mentions one.

The publisher is a different company from the product

The manifest metadata does not quite line up with the branding, and it is the kind of thing that matters when you are deciding who you are trusting with a token. The package name, the MCP server name, the repository, the homepage and the bug tracker all point at the Tetrees domain and repository. The author field and the contact address on the issue tracker point at a different organisation, with a distinct name and an address on an unrelated domain. There is also no GitHub release history at all, so the version lives only in the package manifest, which means the version you depend on is a number in a file rather than a tag you can audit. The repository's last push was 2026-09-07. None of this is damning, and an operating company behind a product brand is ordinary, but if you are writing a procurement note about a tool that will hold a spending token, the difference is the kind of detail you want on the record rather than discovering later.

A contract check you can run before you spend anything

There is one command in this repository designed purely for trust, and it is worth knowing about. After installing dependencies and exporting a token, the inspector launches the official hosted package, lists its public tools and resources, checks that the expected buyer, builder and seller surface is present, and exits. Two properties make it safe to run. It spends no points, and it changes no account state. So it answers the question a cautious adopter actually has, which is whether the thing behind that tarball URL is the contract the documentation describes, before you point a real agent at it and before you approve a quote. The stable public references reinforce the same posture: an API reference, an OpenAPI description, a Postman collection and a product catalogue are all published, so you can read the protocol from another angle instead of taking the MCP surface on faith. The client examples are similarly runnable, with a read-only discovery and quote script for buyers and a readiness check for sellers.

Editorial conclusion

Tetrees Agent EX fits someone building an agent that needs a capability they have not written, and who is willing to pay a metered price per run with the quote visible before execution. It does not fit someone who wants to read how a pack is judged, because the scoring rules are deliberately absent, and it does not fit anyone who needs the local bindings to be reproducible on the vendor's side, because credentials never leave the machine and hosting never inherits those permissions. Before you connect a client, pin the contract version in the tarball query string yourself rather than copying the readme, check the public boundary script if you fork the repository, and read the quote output carefully, because it is the only place the model, token ceiling and hosted skills behind a run are stated before you pay for it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. TetreesEX/TetreesAgent_EX on GitHub