Scope question: does Skills Over MCP cover dynamic, server-contributed context (memory / state)?

Read docs/open-questions.md, problem-statement.md, approaches.md, why-and-when.md, and use-cases.md to compare the existing scope and dynamic-context framing. Then review the referenced SEP-2260, SEP-2577, and SEP-2133 material. Done means the group records whether server-contributed memory/state is in scope, identifies the appropriate home or mechanism, and captures the use case if useful.

I run a memory/state server locally over MCP, and a host that also has a private memory-provider interface. The difference between the two shows up in behaviour, not in packaging, and I can't tell whether the gap it exposes is something this working group intends to cover — or whether it's deliberately out of scope. I read docs/open-questions.md, problem-statement.md and approaches.md first and didn't find it, so apologies if I missed a thread.

(Venue note: I couldn't open a Discussion in the main repo — my account lacks that permission — so I'm posting here. Happy to move it wherever you'd rather it live.)

What I observe. All three MCP primitives are host-initiated: a tool call, a resource read, a prompt fetch only happen when the host (or the model) asks. On the server side, the channels that could push something in are being narrowed on purpose — SEP-2260 ties server-initiated requests to an in-flight client request, and SEP-2577 deprecates roots, sampling and logging. So a memory server can serve data perfectly well, but it cannot contribute context proactively; recall is entirely a host/model decision. In practice I end up relying on the model choosing to call the search tool.

Why I'm asking this working group. Your problem statement already names "server instructions load only at initialization" and the missing discovery mechanism, and the framing "skills are context, and MCP is a context protocol" is exactly the property I'm missing. But skills look like static how-to: workflow instructions that are pulled and then stay put. Memory is dynamic per-turn context: it changes as the conversation goes, and its value depends on it arriving without anyone asking. Your "dynamic" axis in why-and-when.md and use-cases.md is about content that updates server-side, not about context that arrives unprompted — which is why I think this is a distinct question rather than a duplicate.

Questions.

1. Is dynamic, server-contributed context (memory / state, as opposed to static skills) considered in scope for this working group, or deliberately separate?
2. If separate — where would that belong: another IG/WG, or an extension under the SEP-2133 extension framework?
3. Is there a primitive or convention I've missed that a memory server is supposed to use here? I'd rather use the intended mechanism than work around it.

What I can contribute. A working local implementation (memory server + host) that I can write up as a use case: what is host-driven vs model-driven today, and what would have to change for recall to stop depending on the model's choice. If that is useful, I'm happy to turn it into an issue-adjacent doc, a use-case entry, or a discussion thread.