What leaves your machine

Your query text goes to Edge, is logged there, and reaches at least one third party beyond Edge. This page says exactly which parties, what each one receives, and what comes back into your agent's context.

The short version

Edge sends your query text off your machine. Treat a query the way you would treat a public search box.
Edge logs every query it receives, verbatim.
The catalog tool Edge runs on its server has its own analytics beacon to a third party, and your query text is in it.
On Pro, your query and the candidate descriptions also go to an external ranking service.
use_skill pulls text written by strangers straight into your agent's context. Edge does not review it.
Nothing is installed or written on your machine, and nothing else about your project is read or sent.

What the connector sends

The package that runs on your machine is a protocol connector. Per call it sends one HTTPS POST to https://getedge.cc/api/mcp with a JSON body and a @getedge/mcp user agent. That body is the entire payload:

find_skillquery, the text your agent wrote, 3 to 500 characters. Plus key if you configured EDGE_KEY.

use_skillsource and skill, the identifiers you picked, plus request_id when the agent passes one back, plus key if set.

There is nothing else in it. No file contents, no paths, no repository name, no directory listing, no machine or user identifier, no conversation history. The connector reads two things from its environment and nothing at all from your filesystem: EDGE_KEY, and EDGE_MCP_API_URL, which points it at a different backend and exists for development. The backend rejects any request body over 8 KB.

What ends up in the query is chosen by your agent, though, and an agent writes queries out of the task in front of it. A query like review our billing reconciliation cron for race conditions tells Edge and everyone downstream that such a thing exists.

Where the query goes after that

Edge, getedge.ccReceives the query and the key. Passes the query as a command-line argument to the catalog CLI, as an argument array rather than a shell string, so nothing in your text is interpreted as a command. Writes a log line, described below.
skills.shThe catalog itself. The CLI queries its search API for 20 results. The request originates from Edge's server.
add-skill.vercel.sh, a third partyThe catalog CLI's own analytics beacon. On every search it sends a request to https://add-skill.vercel.sh/t carrying event=find, your query text as the query parameter, the number of results, and the CLI version. This is the CLI's behaviour, not Edge's code, and Edge does not switch it off.
skills.sh, again, during enrichmentEdge's server fetches each candidate's public catalog page to read its description. These requests carry no part of your query, and they come from Edge's server, never from your machine.
api.typesafe.ai, Pro onlyThe ranking service. Receives your query text and, for each of up to 20 candidates, its identifier and the description Edge read from the catalog page. One request per search, authorized with Edge's own service key, not yours. On Free this call never happens.

About that beacon

The catalog CLI turns its telemetry off when either DISABLE_TELEMETRY or DO_NOT_TRACK is set in its environment. Edge starts the CLI with an explicit, short environment allowlist, PATH, HOME, NO_COLOR, FORCE_COLOR and GIT_TERMINAL_PROMPT, and neither of those two variables is in it. So the beacon is on, and your query text reaches that third party on every find_skill call. The allowlist exists for a different reason: it keeps Edge's own service credentials out of the CLI and out of the git processes the CLI spawns.

The same CLI reports install, find, remove, update and experimental_sync events. It has no event for the command Edge uses to load a skill, so use_skill sends nothing to that beacon. What a load does reach is wherever the skill is published, usually GitHub, whose server sees a download request from Edge's machine.

What Edge logs

Edge appends one line per call to its own event log. For a search that line holds the timestamp, the event type, a random request id, whether it succeeded, how long it took, your query text verbatim, how many candidates were retrieved and presented, how many were enriched, whether the call was Pro, a short label for the key, which ranker ran, how long ranking took, why ranking degraded if it did, and the before and after fit counts. For a load it holds the source, the skill, the request id and whether the skill was published by Edge itself.

That key label is a short identifier recorded when the key was issued, never the key itself. Keys are stored as SHA-256 hashes, so the key file on the service is not itself a set of credentials, and your key is never written to the log in usable form.

Those records contain no IP address and no account identifier, because there are no accounts. Edge's service does sit behind a web server, which by nature sees the address your request came from and keeps its own access log.

The search request id is also printed in the result, and your agent is asked to pass it back on use_skill. Its purpose is to connect a load to the search that produced it, which is how Edge counts loads of its own skills at all, since the catalog never counts them.

What comes back in

use_skill returns a document written by whoever published that skill, and it lands in your agent's context as instructions. This is the part worth being deliberate about.

Edge does not review these skills. The catalog is a public, third-party ecosystem. Anyone can publish to it. Every load carries an advisory saying so, but an advisory is a warning, not a filter, and Edge applies no content check of any kind.
The text is written to be followed. Skills are instructions for an agent, and they can name commands, scripts and tools. Read what came back before acting on it, and do not let an agent run a skill's scripts unexamined.
Loading is temporary. The retrieval happens on Edge's server, the text is returned over the same HTTPS call, and nothing is written to your disk. Edge never runs the catalog's install command, so no skill ends up permanently in your agent's skill directory through Edge.
The credit line is a request, not a claim. The result asks the host model to emit one short callout the first time it acts on the skill. Edge cannot render anything in your transcript itself, and whether that callout appears is up to the model.

Output is stripped of terminal control codes and capped at 2 MB, beyond which it is cut and marked truncated.

What Edge never does

Install a skill, or call the catalog's installer, on your machine or on its own.
Read, list or send any part of your project.
Write anything to your filesystem. The connector speaks stdio to your agent and HTTPS to Edge, and that is all it does. Launching it with npx does put the package itself in your npm cache, the same as any npm package.
Require an account. There is no login, no session and no password to reset, on either plan.

The practical rule

Keep confidential detail out of the query. A query naming a client, an internal system, an unannounced product or a specific vulnerability is a query you have handed to Edge's log, to a third-party analytics endpoint, and on Pro to a ranking service as well. Describing the kind of work rather than the subject of it gets the same candidates back: review a pull request for correctness bugs finds exactly what review the Acme billing PR would.

Edge MCP