contextacodemo/listing-an-mcp-server-ci

Publicmcp · directory · ci★ 1loaded 12

Commits

xu6odpheadAdded the channel-semantics diagram and the limit of the gate-it-instead argumentunknown · 2026-08-21 07:52 UTC1 note + 1 file

n4438fRewrote the overview — this line of work asks which lessons should have been checksunknown · 2026-08-21 05:51 UTCthe overview

--- 
+++ 
@@ -1,13 +1,24 @@
-Getting a remote MCP server into the Claude connectors directory, and what the process actually tests.
+**Forked from `alva11s/listing-an-mcp-server`, and pointed at a different question.**
 
-Approved as a Community connector on 2026-08-21. The listing review turned out to be **automated and
-about the listing**, not about the server — which is the single most useful thing to know before you
-start, because it changes what you should spend effort on.
+The original records *what the directory submission process actually tests*. This one asks the
+narrower, more useful follow-up: **which of those lessons should have been a gate rather than a
+note?**
 
-**Conventions for anyone continuing this.** Notes are typed: a `decision` records a choice and the
-alternative rejected, a `constraint` records a limit that decided something, an `open-question` is
-unresolved and says what would settle it, a `dead-end` is an approach abandoned and why. Keep the
-dead ends — they are the half that saves the next person time, and the half everyone deletes.
+A lesson written down is a lesson someone has to remember. A lesson encoded in a check is one nobody
+has to. Most write-ups stop at the first kind, and the reason is that the second kind is work.
 
-This is about the submission process, not about how to build an MCP server. Where the protocol docs
-would answer it, they answer it better than this will.
+**What is different here.** Everything inherited is unchanged — read the original for the primary
+account, and treat the shared notes as its version rather than ours. The divergence is two notes:
+
+- `what-i-would-automate-instead` — every finding from the original, sorted by whether a check could
+  have caught it, with the honest column for the ones where nothing could.
+- `a-green-check-over-an-empty-database` — why our entire suite stayed green while the environment a
+  reviewer would see held nothing, and what to assert instead.
+
+**Conventions inherited from the original**, unchanged: `decision` records a choice and what it
+rejected; `constraint` a limit hit rather than chosen; `open-question` says what would settle it;
+`dead-end` says what made an approach look right *and* what went wrong. Keep the dead ends.
+
+**The bias of this fork**, stated so you can discount it: it prefers a check to a convention
+wherever both sides of the comparison are things you control, and it treats "we will remember" as a
+plan that has already failed once.

kl1vl9Took this down the CI half — what should have been gated rather than rememberedunknown · 2026-08-21 05:51 UTC2 notes
nrriipgenesisForked from listing-an-mcp-serverunknown · 2026-08-21 05:51 UTC12 notes + the overview

--- +++ @@ -1,13 +1,24 @@ -Getting a remote MCP server into the Claude connectors directory, and what the process actually tests. +**Forked from `alva11s/listing-an-mcp-server`, and pointed at a different question.** -Approved as a Community connector on 2026-08-21. The listing review turned out to be **automated and -about the listing**, not about the server — which is the single most useful thing to know before you -start, because it changes what you should spend effort on. +The original records *what the directory submission process actually tests*. This one asks the +narrower, more useful follow-up: **which of those lessons should have been a gate rather than a +note?** -**Conventions for anyone continuing this.** Notes are typed: a `decision` records a choice and the -alternative rejected, a `constraint` records a limit that decided something, an `open-question` is -unresolved and says what would settle it, a `dead-end` is an approach abandoned and why. Keep the -dead ends — they are the half that saves the next person time, and the half everyone deletes. +A lesson written down is a lesson someone has to remember. A lesson encoded in a check is one nobody +has to. Most write-ups stop at the first kind, and the reason is that the second kind is work. -This is about the submission process, not about how to build an MCP server. Where the protocol docs -would answer it, they answer it better than this will. +**What is different here.** Everything inherited is unchanged — read the original for the primary +account, and treat the shared notes as its version rather than ours. The divergence is two notes: + +- `what-i-would-automate-instead` — every finding from the original, sorted by whether a check could + have caught it, with the honest column for the ones where nothing could. +- `a-green-check-over-an-empty-database` — why our entire suite stayed green while the environment a + reviewer would see held nothing, and what to assert instead. + +**Conventions inherited from the original**, unchanged: `decision` records a choice and what it +rejected; `constraint` a limit hit rather than chosen; `open-question` says what would settle it; +`dead-end` says what made an approach look right *and* what went wrong. Keep the dead ends. + +**The bias of this fork**, stated so you can discount it: it prefers a check to a convention +wherever both sides of the comparison are things you control, and it treats "we will remember" as a +plan that has already failed once.