pub enum PrimitiveKind {
Tool,
Resource,
ResourceTemplate,
Prompt,
}Expand description
Which list a primitive belongs to.
The four lists are separate on the wire (tools/list, resources/list,
resources/templates/list, prompts/list) and they are notified on
separately, so the distinction is load-bearing rather than cosmetic: a tool
being added must not make a session’s prompt list appear to have changed.
Ord and PartialOrd are derived from the same declaration order, and
PrimitiveKind::ORDERING_AGREES is the test that says so. The
declaration order is a display order chosen once — tools, then resources,
then templates, then prompts, matching the order the specification
introduces them — and it is not the order any peer observes, because
Snapshot keeps each list in registration order and this only orders the
kinds when a change set is rendered.
Variants§
Tool
tools/list, tools/call.
Resource
resources/list, resources/read.
ResourceTemplate
resources/templates/list.
Prompt
prompts/list, prompts/get.
Implementations§
Source§impl PrimitiveKind
impl PrimitiveKind
Sourcepub const fn feature(self) -> Feature
pub const fn feature(self) -> Feature
The feature a session needs before it may list this kind.
So the listing methods’ gates are written once. A table here rather than
at each call site is the point: resources/list and
resources/templates/list are separate methods in the spec, and a
second place naming which requires which feature is a second place to
forget it.
ResourceTemplate maps to Feature::Resources, not to a feature of
its own, because the specification’s resources capability covers
templates too. A peer that can list resources can list their templates;
a separate feature would gate the two independently and let a session
hold the odd combination the spec has no way to express.