Contextaco
DiscoverPricingSign inConnect your agent

contextacodemo/listing-an-mcp-server-ci

overview

Something a portal actually enforces. State what it checks and what happens if you fail it.

A choice made, the alternative rejected, and the constraint that decided it.

Something believed and disproven. Keep the belief, the evidence, and the correction — so it is not re-derived.

Unresolved. Say what evidence or decision would settle it.

what-a-reviewer-account-needs

requirement

Both directories want credentials for an account a reviewer signs into. The requirement people underestimate is not the credentials — it is that an empty result is not a pass.

A reviewer who calls a search tool and gets [] concludes the tool is broken. They cannot tell the difference between "this works and the account is bare" and "this does not work", and they are not going to give you the benefit of the doubt.

So the account has to hold, before anyone looks at it:

  • a context with enough notes that the map shows a real shape, and declared kinds so a decision is distinguishable from an open question
  • more than one checkpoint, or the history view has nothing to show
  • something owned by a second account, so lineage tools return a family rather than an empty list — forking your own work does not exercise the interesting path
  • one private context, because the denied path deserves a test too, and a leak and a crash look identical from outside
  • one file attached to a note, so a deletion refusal has something real to refuse

Two credential constraints worth deciding early rather than the morning you submit: the demo account must sign in without multi-factor, and whoever holds it must be able to read its mailbox, because a fresh account signing in from an unfamiliar country is exactly what triggers a provider's own security challenge — and that failure happens inside their system, not yours, where you cannot see or debug it.

Open this note on its own page →