coilyco-flight-deck/mcp-beaver

Watch

docs/FEATURES.md still describes resources and prompts as future work, three sections after documenting them as shipped #62

New issue

Closed

opened 2026-08-14 04:49:26 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-14 04:49:26 +00:00

Member

🤖 Filed by Claude Code on Kai's behalf.

Filed by Olaf (OPS). Small, but it is the file whose whole job is being the accurate inventory.

The drift

docs/FEATURES.md:227-231 closes the transport section with:

Supported MCP methods: initialize, notifications/initialized, notifications/cancelled, ping, tools/list, tools/call. Any future resource or prompt support must stay on the generic MCP surface (resources/list, resources/read, prompts/list, prompts/get) and must not grow Ward-specific admin, lifecycle, reload, or control verbs.

Resources and prompts shipped. The same document already says so, roughly a hundred lines earlier, under "Guardfile siblings: resources, prompts, server-info, confirmations."

Verified in source rather than inferred from the docs:

internal/mcpserver/resource.go:96 — s.sdk.AddResource(...) with a ReadResourceRequest handler
internal/mcpserver/prompt.go:125 — s.sdk.AddPrompt(...) with a GetPromptRequest handler
internal/mcpserver/resource_prompt_test.go — live resources/read and prompts/get round trips, including the missing-required-argument rejection
internal/mcpserver/telemetry.go:226-227 — prompts/list, prompts/get, resources/list, resources/read, and resources/templates/list are all in the bounded method label set

So the constraint that paragraph states was met, and the method list beneath it is three revisions behind the runtime.

Why it is worth a fix rather than a shrug

FEATURES.md is described in its own header as "the living inventory of what ships today" and it completes the README / AGENTS / FEATURES trifecta. It is the file an agent or a consumer reads to find out what exists.

The concrete cost: reading that line, I nearly did not file coilyco-bridge/deploy#499 — a child issue whose entire premise is that resource works today — because the authoritative inventory said resource support was hypothetical. I only proceeded after reading the source. A consumer without a checkout would have taken the document at its word.

Requested

Update the method list to what the runtime serves, and reframe the sentence so the architectural constraint it carries — resources and prompts stay on the generic MCP surface, no Ward-specific control verbs — survives as a statement about what shipped rather than a condition on future work. That constraint is worth keeping; only its tense is wrong.

Acceptance

The listed methods match the runtime's actual dispatch, including the resource and prompt methods already in the telemetry label set.
The no-Ward-specific-verbs constraint is retained.
The "Not yet built" section is checked in the same pass for anything else that has since landed — I did not audit it.

> 🤖 Filed by Claude Code on Kai's behalf. **Filed by Olaf (OPS).** Small, but it is the file whose whole job is being the accurate inventory. ## The drift `docs/FEATURES.md:227-231` closes the transport section with: > Supported MCP methods: `initialize`, `notifications/initialized`, `notifications/cancelled`, `ping`, `tools/list`, `tools/call`. **Any future resource or prompt support** must stay on the generic MCP surface (`resources/list`, `resources/read`, `prompts/list`, `prompts/get`) and must not grow Ward-specific admin, lifecycle, reload, or control verbs. Resources and prompts shipped. The same document already says so, roughly a hundred lines earlier, under "Guardfile siblings: resources, prompts, server-info, confirmations." Verified in source rather than inferred from the docs: - `internal/mcpserver/resource.go:96` — `s.sdk.AddResource(...)` with a `ReadResourceRequest` handler - `internal/mcpserver/prompt.go:125` — `s.sdk.AddPrompt(...)` with a `GetPromptRequest` handler - `internal/mcpserver/resource_prompt_test.go` — live `resources/read` and `prompts/get` round trips, including the missing-required-argument rejection - `internal/mcpserver/telemetry.go:226-227` — `prompts/list`, `prompts/get`, `resources/list`, `resources/read`, and `resources/templates/list` are all in the bounded method label set So the constraint that paragraph states was met, and the method list beneath it is three revisions behind the runtime. ## Why it is worth a fix rather than a shrug `FEATURES.md` is described in its own header as *"the living inventory of what ships today"* and it completes the README / AGENTS / FEATURES trifecta. It is the file an agent or a consumer reads to find out what exists. The concrete cost: reading that line, I nearly did not file https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/499 — a child issue whose entire premise is that `resource` works today — because the authoritative inventory said resource support was hypothetical. I only proceeded after reading the source. A consumer without a checkout would have taken the document at its word. ## Requested Update the method list to what the runtime serves, and reframe the sentence so the architectural constraint it carries — resources and prompts stay on the generic MCP surface, no Ward-specific control verbs — survives as a statement about what shipped rather than a condition on future work. That constraint is worth keeping; only its tense is wrong. ## Acceptance - The listed methods match the runtime's actual dispatch, including the resource and prompt methods already in the telemetry label set. - The no-Ward-specific-verbs constraint is retained. - The "Not yet built" section is checked in the same pass for anything else that has since landed — I did not audit it.

coilyco-ops referenced this issue from a commit

2026-08-14 05:05:42 +00:00

feat: default server-info on, correct the docs it contradicts

coilyco-ops closed this issue

2026-08-14 05:05:42 +00:00

coilyco-ops commented

2026-08-14 05:37:29 +00:00

Author

Member

Fixed in 115c02f.

The method list now matches the runtime's actual dispatch, taken from boundedMCPMethod in internal/mcpserver/telemetry.go rather than from the docs: initialize, notifications/initialized, notifications/cancelled, ping, tools/list, tools/call, prompts/list, prompts/get, resources/list, resources/read, resources/templates/list, plus the 2026-07-28 server/discover and subscriptions/listen. Six listed, thirteen served.

The architectural constraint is kept, retensed to describe what shipped rather than to condition future work, and sharpened to name what it actually protects: operator control stays on the /admin endpoints, off the protocol.

"Not yet built" audited, as asked. Both entries still hold:

action composition - no composed chain in opcore at umbra v0.139.0. Nothing named collect, Compose, or a chain type in http/opcore/.
Tool-name disambiguation - toolName is still d.Leaf + "_" + d.Group (server.go).

Nothing else in that section had landed.

One related correction went in alongside: the server-info bullet three sections above described it as opt-in, which #61 changed in the same commit.

Fixed in 115c02f. The method list now matches the runtime's actual dispatch, taken from `boundedMCPMethod` in `internal/mcpserver/telemetry.go` rather than from the docs: `initialize`, `notifications/initialized`, `notifications/cancelled`, `ping`, `tools/list`, `tools/call`, `prompts/list`, `prompts/get`, `resources/list`, `resources/read`, `resources/templates/list`, plus the 2026-07-28 `server/discover` and `subscriptions/listen`. Six listed, thirteen served. The architectural constraint is kept, retensed to describe what shipped rather than to condition future work, and sharpened to name what it actually protects: operator control stays on the `/admin` endpoints, off the protocol. **"Not yet built" audited, as asked.** Both entries still hold: * `action` composition - no composed chain in opcore at umbra v0.139.0. Nothing named `collect`, `Compose`, or a chain type in `http/opcore/`. * Tool-name disambiguation - `toolName` is still `d.Leaf + "_" + d.Group` (`server.go`). Nothing else in that section had landed. One related correction went in alongside: the `server-info` bullet three sections above described it as opt-in, which #61 changed in the same commit.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-flight-deck/mcp-beaver#62

No description provided.

Rows
Columns