close the gaps the registries ask for - #13
Merged
Conversation
The official MCP Registry was unreachable: it proves ownership by fetching the published package and matching an `mcpName` field against the server name, and neither that field nor server.json existed. Both are here now, and server.json validates against the registry schema rather than against my reading of it. server.json repeats the version twice, which is the same problem the plugin manifests had. Both copies are placeholders and the release workflow stamps them from the tag alongside package.json, so there is still no version written down anywhere and still no release commit. A test pins both placeholders and checks that `mcpName`, the server name and the package identifier agree, since a mismatch only surfaces at publish time, after npm has already accepted the release. Publishing to the registry now hangs off the same tag as the npm publish, authenticated by the same OIDC token, so no secret is added. It retries: npm accepts a publish before the package is queryable, and the registry validates by fetching it. `--version` did not exist. It is the first thing a bug report needs, so the issue template asked for something that could not be produced. It answers before the configuration is read, which is the state a machine reporting a bug is usually in. SECURITY.md, CONTRIBUTING.md and an issue template, because people arriving from a directory land on a repository that can reconfigure their network and should be able to see how the password is stored and what happens to it. The issue template asks for model and firmware first: nearly every difference in this project comes down to one of those two. CONTRIBUTING says the thing that actually matters here rather than the usual formalities: verify against the router, not against your model of it, and name the model and version you checked on. It also answers the vendor-adapter question ahead of time, so nobody writes one before asking.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the gaps that stood between this repo and the places it should be listed.
The MCP Registry was unreachable
It proves ownership by fetching the published npm package and matching an
mcpNamefield against the server name. Neither that field norserver.jsonexisted, so publishing would have failed at the last step.Both are here now.
server.jsonwas generated with the officialmcp-publisherand checks out against the registry schema rather than against my reading of the docs:It repeats the version twice, which is the same problem the plugin manifests had. Both copies are placeholders and the release workflow stamps them from the tag alongside
package.json, so there is still no version written down anywhere and still no release commit. Simulated the stamp before trusting it:0.0.0-devbecomes0.3.1in all three places and still validates.A test pins both placeholders and checks that
mcpName, the server name and the package identifier agree. A mismatch there only surfaces at publish time, which is after npm has already accepted the release.Publishing hangs off the same tag as the npm publish and uses the same OIDC token, so no secret is added. It retries, because npm accepts a publish before the package is queryable and the registry validates by fetching it.
This only takes effect from the next release. The published 0.3.0 has no
mcpName, so the registry cannot validate it.--versiondid not existThe first thing a bug report needs. The issue template was asking for something that could not be produced. It answers before the configuration is read, which is the state a machine reporting a bug is usually in.
For people arriving from a directory
SECURITY.mdbecause they land on a repository that authenticates as router administrator and can reconfigure their network. It says where the password goes on each platform, what happens when there is no keychain, and where to report privately.CONTRIBUTING.mdsays the thing that actually matters here rather than the usual formalities: verify against the router and not against your model of it, and name the model and firmware you checked on. Two real bugs in this repo passed every unit test and only surfaced against live hardware. It also answers the vendor-adapter question ahead of time, so nobody writes one before asking.An issue template that asks for model and KeeneticOS version first, because nearly every difference in this project comes down to one of those two. Blank issues stay enabled: the best issue this repo has had so far was a design question, and a bug form would have been in its way.
248 tests, typecheck and build clean. All four workflow and template YAML files parse.
Still manual, after this merges
Submitting to the directories themselves needs an account and a form, so it is not something a PR can do: the Anthropic plugin directory, mcpservers.org, and mcp.so. The official MCP Registry is automatic from the next tag.