mikedev115/aetox-harness/aetox-mcp

The user has asked you to find them an MCP server. Unlike a skill, this one you cannot install: you research it, judge it, and hand the user exactly what to type. What follows is what makes that judgment right in this app.

The one fact that decides everything: an MCP server is not free

A skill costs nothing until you open it. An MCP server's tools are sent in every request, forever, from the moment it connects. They join the tool block beside read and shell and are paid on every message of every session, whether or not the topic ever comes up.

That is the opposite economics from a skill, and it is why the bar below is high and why "it looked interesting" is not a reason to add one. A server with fifteen tools can quietly become the largest thing in the block.

Say this to the user in plain words when they are choosing. It is the trade they are actually making, and nobody else will tell them.

The bar, three tests, all three

This is the same bar the curated shelf on the MCP settings page is held to. Use it on anything you find.

1. It reaches something Aetox has no tool for. No server for files, for

fetching a page, for searching the web, for driving a browser, for running commands, all of those are already here, and a second road to the same place is slower and costs tool-block tokens forever. What passes: a service with an account behind it, a specialist engine, somebody's data that lives somewhere else.

1. It connects with what this app can send. Aetox's MCP client carries

static headers only. A server that wants an OAuth flow cannot be connected here at all, recommending one produces a settings form asking for a token the user has no way to obtain. Rule it out early and say why.

1. The endpoint answered, rather than being remembered. A URL you recalled

from training is a guess. Verify it with web_fetch or by reading the project's own current docs before you put it in front of the user.

Look at what is already on the shelf first

ตั้งค่า → MCP ships a curated list with one-click add. Check it before searching: if what the user needs is there, the answer is two clicks and no research. Tell them that instead of finding a second way to the same server.

What you cannot do, and what to do instead

mcp-servers.json is refused to every file tool, read, write and shell all come back with a refusal, deliberately: its headers and environment maps are where an API key ends up, and that file is closed the same way the credentials file is.

There is also no tool for adding a server. So the shape of this job is:

1. Find the server and verify its endpoint.
2. Work out the exact fields, see below.
3. Hand them over and say where they go: ตั้งค่า → MCP → เพิ่มเซิร์ฟเวอร์.
4. Offer to check afterwards: once it connects, its tools appear to you, and you

can say out loud what arrived.

If it needs a key, ask for it

Ask before you take it, every time. A key is the user's to hand over, and a handover they did not agree to is the one thing in this job they cannot undo.

Then say why you are asking and where it ends up. The aetox skill's "What stays here, and what leaves" is the true version of that, including the part about the model, read it rather than reassuring from memory, and work out how to say it for the person in front of you.

The two shapes a server comes in

Hosted (HTTP), a URL, optionally with headers:

url:     https://example.com/mcp
headers: Authorization: Bearer ${env:EXAMPLE_API_KEY}

Local (stdio), a command Aetox runs on this machine:

command:     npx -y @scope/some-mcp-server
cwd:         (optional, where to run it)
environment: SOME_API_KEY=${env:SOME_API_KEY}

A local server means installing somebody's package and running it. Say that out loud, the user is agreeing to run code on their machine, which is a different decision from adding a URL.

${env:NAME} is the way to carry a secret

Both headers and environment expand ${env:NAME} from the environment at connect time. Recommend that form rather than the literal key: the config then holds a reference instead of a credential, and the file stays safe to back up or share. Tell the user which variable name to set, and that <DataRoot>/.env is a place they can set it.

If the reference resolves to nothing, the server fails to authenticate and says so, a clear error, which is better than a key sitting in a file.

Report it as a decision, not a list

For each server you recommend: what it reaches, why the tools here cannot, whether it needs a key, and roughly how many tools it will add to every request. Then let the user choose. One well-argued recommendation beats five names.

If nothing passes the bar, say so and say what you can do without it. That is a real answer; a marginal server added to have added something is not.