Build1 distinct publisher2 min readUpdated
A developer's four-tool server read as empty on glama, Smithery and mcp.directory, because tools/list arrives without a token. The fix is a four-method allowlist.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The allowlist that repairs this is four method names long: initialize, notifications/initialized, ping, and tools/list [12]. Nothing on that list spends money, which is the test the author of the dev.to writeup applies. Describing what a server offers is not privileged, and calling those tools is [12]. The original wrapper was not sloppy, either. Every tool call in that server spends credits, so every tool call needs an identified user [7], and the docs and examples encourage wrapping the handler [6]. The wrapper simply also caught the one method that costs nothing to answer.
The conditions around the allowlist are the part worth reading twice, because each is a failure someone else will rediscover in production. A request carrying an Authorization header goes down the authenticated path even when its method is public; skip that and a client holding an expired token gets quiet anonymous service instead of the 401 that triggers a refresh [13]. The gate applies only to POST, because in Streamable HTTP a GET opens the SSE stream and a DELETE ends the session, and neither carries a JSON-RPC method you can inspect [14]. And since JSON-RPC permits batching, the check has to hold for every message in the array rather than any of them, or a tools/call rides in beside a tools/list [15].
That last condition has a runtime price: the classifier clones and parses the body of every POST before it knows whether auth applies [19]. Behind it sits a second stop. The public path runs with no caller in context, so a tools/call that slipped through finds no user and the charging function refuses [16]. The author also names the mistake that would cost more than an empty listing: a hand-rolled 401 that stops advertising WWW-Authenticate, which strips compliant clients of the header they rely on for OAuth discovery [17].
Three separate directories published the same empty array for the same server [1], which says the emptiness is not one crawler's bug but the predictable output of an anonymous handshake meeting a blanket 401 [8]. A crawler cannot distinguish "requires auth" from "does nothing" [8], and neither can your logs, where its 401 looks like any other unauthenticated request [18]. Middleware that wraps an exported handler operates at the granularity of the transport, not the method, and MCP's first useful move is anonymous by construction [4]. Auth strength was never in question here. Placement was, and placement is the thing no test suite was watching.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
A developer shipped a remote MCP server behind OAuth 2.1, registered it across directories, and found every directory listing it as having no tools at all.
glama's API returned the server as {"name": "FrameThrower MCP Server", "attributes": ["author:official", "hosting:remote-capable"], "tools": []}.
Smithery's page and mcp.directory rendered the same empty capability list for a server with four working tools.
An MCP client discovers what a server can do by calling tools/list, a normal JSON-RPC method, so a handler wrapped in auth puts tools/list behind auth along with everything else.
The server's handler used withMcpAuth, returned a 401 Unauthorized when no session user id was present, and exported the same authed function as GET, POST and DELETE.
The author states that wrapping the handler in auth is what the docs and every example encourage.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
First-hand artifacts, single unverified author
The mechanism is shown rather than asserted: a quoted glama API response with tools: [], the withMcpAuth handler, before/after Smithery scanner logs, the classifier code and a curl check. But everything comes from one self-published post by the affected server's author, with no directory-side confirmation, specification citation or independent reproduction.
One documented deployment, fix verified once
Adoption evidence covers exactly one server: shipped behind OAuth 2.1, listed empty on three directories, then scanning clean after the patch. Three directories showing the behaviour rules out a single crawler quirk, but no other operator, registry statement or install figure is supplied, so uptake of either the problem or the remedy beyond this deployment is unmeasured.
Sound mechanism, overreaching prevalence claim
The technical narrative is modest and well-supported, but the framing extrapolates from one server to 'almost certainly happening to you too' and to whole-ecosystem invisibility without a second operator, a registry-wide sample or any directory statement. The WWW-Authenticate failure mode is also foregrounded without an observed instance.
Author is the affected server's operator
The post is written by the operator of the named commercial server, whose tool calls spend credits, and published on a developer-marketing platform, so it doubles as visibility for a product whose listings had been empty. That interest favours dramatic framing; the first-person account and verifiable code partially offset it, and there is no editorial review or right-of-reply from the directories.
Mechanism credible, scope uncertain
High confidence the specific mechanism and fix are real — protocol behaviour, code and matched before/after logs cohere internally. Low confidence in scope, because the cluster has one publisher, one deployment, no directory response and no measurement of how many OAuth-gated MCP servers are affected.
build
Rate limit your MCP servers, because a retrying agent turns one error into a billing incident1 distinct publisher
build
The MCP transport your search results teach has been deprecated since March1 distinct publisher
build
Atlas App Connections hands AI clients your whole Atlas role, so fix the roles first1 distinct publisher
build
MCP is a discovery layer, and your exposure list is a governance decision1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 22, 2026