Edge
Edge MCP documentation

Free and Pro

One thing differs: the order the five candidates come back in, and whether Edge tells you how many of them actually fit your task.

Free

The catalog's own order, kept exactly as it came. Descriptions are fetched for the five candidates about to be shown. The result says in skills.sh relevance order.

Pro

All 20 retrieved candidates get descriptions, then the whole pool is reordered by how well each one fits the task you described. The result says ranked by Edge for this task and counts the fits.

What Free actually returns

The catalog search returns 20 results in its own relevance order, and Edge presents the first five of them untouched. That order is a popularity sort: the comment in Edge's ranking code records that in the benchmark behind this feature, the catalog's order was monotonically non-increasing in install count in 50 of 50 queries. You can see it in any Free result, where the Installs line descends from top to bottom.

Popularity is a real signal and often the right answer. Its failure mode is specific: an exact-fit skill that happens to be unpopular sits below a broadly popular one that only shares vocabulary with your task, and with five slots it may not appear at all.

What Pro changes

Pro reranks the full pool of 20, not the five. That distinction is the whole feature. A reranker handed the already-cut top five can only permute a list whose contents were chosen by install count, so the win, if there is one, lives in candidates 6 to 20.

Three things follow from it:

Two lines only Pro produces

A good fit for this task: 3 of the top 5. In skills.sh's own order it was 1 of 5.

The headline. It counts how many of the presented five cleared the ranker's fit threshold, against how many of the catalog's own top five did, using the same scores that produced the order. When ranking did not improve the count the line is honest about it and reads 3 of the top 5, the same as skills.sh's own order for this query. On many queries the popular skill is also the right one.

   Edge moved this up from #14, where skills.sh ranked it by installs.

Attached to a candidate that was promoted, naming the position it held before. Candidates that did not move say nothing, so the line only appears where ranking changed the answer.

The key

A Pro key looks like edge_ followed by 18 hexadecimal characters. There is no account, no login and no session behind it. The key in your MCP config is the whole identity, which is enough because all it does is switch on a feature.

It goes in the env block of the Edge entry in your MCP config, exactly like any other environment variable:

claude mcp add -s user edge -e EDGE_KEY=your_key -- npx -y @getedge/mcp
{
  "mcpServers": {
    "edge": {
      "command": "npx",
      "args": ["-y", "@getedge/mcp"],
      "env": { "EDGE_KEY": "your_key" }
    }
  }
}

The connector reads EDGE_KEY once when the server starts, so a key added, changed or removed mid-session does nothing until the next session. When it is set, it travels in the body of each request to Edge. On the service it is compared against stored SHA-256 hashes; keys are never stored in plain form, and the only trace of yours in Edge's own logs is a short label recorded when the key was issued.

A key that does not work is silent

There is no error for a missing, malformed or unrecognised key. Edge returns the Free ordering and the call succeeds. This is deliberate: Free is a working product, so there is nothing to fail. It does mean a typo in your key looks exactly like not having one.

The same silence covers every way ranking can fall through. In all of these cases you get the catalog's order and a result that says so:

key absent, shorter than 8 or longer than 128 charactersNot treated as Pro at all.
key not recognisedNot treated as Pro at all.
ranking service unreachable, refusing, or slower than 2.5 secondsPool returned in the catalog's order.
ranking service answers in a shape Edge does not recognisePool returned in the catalog's order.
ranking service scores only some of the poolRejected outright. A partial answer set would sink the unscored candidates on a default score rather than on evidence, which is worse than no reranking.
fewer than 2 candidates came backNothing to reorder.

Because the header line is generated from what actually happened rather than from what was requested, a degraded Pro call reads in skills.sh relevance order, just like Free. That line is the only reliable way to tell which you got.

A newly issued key can take up to 30 seconds to be recognised, because the service caches its key set for that long.

What does not change

Pro does add one thing to what leaves Edge's service: your query and the candidate descriptions go to an external ranking service. That is covered on what leaves your machine.