From 88c087e9c43303c59e551084098f9ad8a8608719 Mon Sep 17 00:00:00 2001 From: Paul Carleton Date: Fri, 24 Apr 2026 11:51:24 +0100 Subject: [PATCH] docs: add SEP scenario review guidance to AGENTS.md (#247) --- AGENTS.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 35e854f..7a230da 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -53,6 +53,7 @@ Keep scenarios separate when they're genuinely independent features or when they - **Optimize for Ctrl+F on the slug.** Repetitive check blocks are fine — easier to find the failing one than to unwind a clever helper. - Reuse `ConformanceCheck` and other types from `src/types.ts` rather than defining parallel shapes. - Include `specReferences` pointing to the relevant spec section. +- **Severity follows the spec keyword:** MUST / MUST NOT → `FAILURE`; SHOULD / SHOULD NOT → `WARNING`. (CI treats WARNING as a failure, so Tier-1 SDKs still need to satisfy SHOULDs — see #245.) ## Descriptions and wording @@ -60,6 +61,16 @@ Be precise about what's **required** vs **optional**. A scenario description tha When in doubt about spec details (OAuth parameters, audiences, grant types), check the actual spec in `modelcontextprotocol` rather than guessing. +## Reviewing PRs + +### SEP scenarios + +Verify requirement levels against the SEP's **spec diff** — the change to `docs/specification/draft/` in the SEP's PR — not the SEP markdown summary or the conformance PR's description. The keyword that governs check severity is the one in the spec text; a bullet under a "Servers SHOULD…" sentence is SHOULD-level even if the SEP's title says "standardize." + +```sh +gh api "repos/modelcontextprotocol/modelcontextprotocol/contents/docs/specification/draft/?ref=" --jq '.content' | base64 -d +``` + ## Examples: prove it passes and fails A new scenario should come with: