Struct ServerConfig 

pub struct ServerConfig {
    pub server: ServerSection,
    pub metadata: MetadataSection,
    pub database: DatabaseSection,
    pub backend: Option<BackendSection>,
    pub code_mode: Option<CodeModeSection>,
    pub tools: Vec<ToolDecl>,
    pub config_slots: Vec<ConfigSlotDecl>,
    pub prompts: Vec<PromptDecl>,
    pub resources: Vec<ResourceDecl>,
    pub shared_policy_store: Option<SharedPolicyStoreSection>,
}

Top-level pmcp-server-toolkit configuration parsed from a config.toml.

One struct parses the entire file in one shot (per D-13). All sub-sections carry #[serde(deny_unknown_fields)] — a typo anywhere in the file is a hard parse error.

Entry points

Use ServerConfig::from_toml_strict_validated for production callers. ServerConfig::from_toml is the no-validation variant for programmatic merges; ServerConfig::validate runs the semantic checks separately.

Examples

use pmcp_server_toolkit::config::ServerConfig;

let toml = r#"
    [server]
    name = "demo"
    version = "0.1.0"
"#;
let cfg = ServerConfig::from_toml_strict_validated(toml)
    .expect("valid minimum config");
assert_eq!(cfg.server.name, "demo");
assert_eq!(cfg.server.version, "0.1.0");

Fields

server: ServerSection

[server] — identity and version metadata.

metadata: MetadataSection

[metadata] — admin-facing display defaults.

database: DatabaseSection

[database] — backend connection + tables.

backend: Option<BackendSection>

[backend] (optional, http feature) — OpenAPI/REST HTTP backend declaration (base_url + [backend.auth] + [backend.http]).

Additive per the REF-01 superset invariant (D-06): a pure-SQL config omits [backend] and this field parses to None. The whole section is gated behind the http feature — a no-http build has no OpenAPI backend, so exposing an unusable stub type would be misleading. See BackendSection.

code_mode: Option<CodeModeSection>

[code_mode] (optional) — code-mode policy and limits.

tools: Vec<ToolDecl>

[[tools]] — declarative tool surface (TOML-defined handlers).

config_slots: Vec<ConfigSlotDecl>

[[config_slots]] — declared config slots the TARGET environment must fill (PKG-03). Additive per the REF-01 superset invariant: a config omitting the block parses to an empty vec.

Deliberately NOT gated on the http feature — a SQL or workbook Shape A server declares slots too, and gating it would make the field vanish in the toolkit’s own default build.

prompts: Vec<PromptDecl>

[[prompts]] — declarative prompt surface.

resources: Vec<ResourceDecl>

[[resources]] — declarative resource surface.

shared_policy_store: Option<SharedPolicyStoreSection>

[shared_policy_store] (optional) — AVP/Cedar shared-policy-store declaration emitted by the reference SQL server (is_reference = true), which provisions the policy store all sibling SQL servers attach to. Additive per the REF-01 superset invariant (Plan 85-01); parsed verbatim — the toolkit does not provision SSM at parse time.

Implementations

impl ServerConfig

pub fn from_toml(toml_str: &str) -> Result<Self>

Parse ServerConfig from a TOML config string.

Performs strict parsing (#[serde(deny_unknown_fields)] on every section, per D-13). Does not run semantic validation — callers wanting required-field guarantees should use Self::from_toml_strict_validated instead.

Errors

Returns ToolkitError::Parse on syntax error or unknown field. A mis-spelled key (e.g. auto_aprove_levels for auto_approve_levels) produces a parse error here, not a silent default.

Example

use pmcp_server_toolkit::config::ServerConfig;

let toml = r#"
    [server]
    id = "demo"
    name = "Demo"
    version = "0.1.0"
"#;
let cfg = ServerConfig::from_toml(toml).expect("parse");
assert_eq!(cfg.server.name, "Demo");

pub fn from_toml_strict_validated(toml_str: &str) -> Result<Self>

Parse + validate. Per Phase 83 review R8 — guards against the missing-required-value trap that the Default impls on sub-sections would otherwise hide behind silent empty strings (e.g. a typo’d [serever] header makes server.name default to "").

Errors

Returns ToolkitError::Parse on TOML syntax / unknown-field errors, or ToolkitError::Validation (wrapping ConfigValidationError) on missing required values (empty server.name, empty server.version, empty tool name, empty table name).

Example

use pmcp_server_toolkit::config::ServerConfig;
let toml = r#"
    [server]
    name = "demo"
    version = "0.1.0"
"#;
let cfg = ServerConfig::from_toml_strict_validated(toml).expect("valid");

pub fn validate(&self) -> Result<(), ConfigValidationError>

Validate required-field semantics that #[serde(default)] would otherwise mask. Per Phase 83 review R8.

Rules checked, in order:

1. server.name is non-empty (trimmed).
2. server.version is non-empty (trimmed).
3. Every [[tools]] entry has a non-empty name.
4. No [[tools]] entry mixes tool kinds (sql / path+method / script) — D-01 / T-90-02-04.
5. Every [[database.tables]] entry has a non-empty name.
6. Every [[config_slots]] entry has a non-empty key AND name (PKG-03). The entry’s kind needs no rule here — it is the closed ConfigSlotKind enum, so serde rejects an unknown discriminator at parse time, before validate() is called.
7. When a [backend] block is present (http feature), its base_url is non-empty (trimmed) — GAP 3 / WR-02. Absent on no-http builds.
8. Every [[tools.parameters]] declaration is well-formed (Phase 128 D2 / SC-2): no empty pattern, no minimum/maximum outside the exactly-representable f64 integer range, and the tool’s synthesized inputSchema COMPILES as a Draft 2020-12 schema. The compile check requires the input-validation feature; on a build without it the check is skipped and a tracing::warn! says so once, because an enforcement that is off must never read as on.

Errors

Returns a ConfigValidationError variant identifying the first rule violated. Iteration order matches struct field order.

pub fn lint(&self) -> Vec<ConfigWarning>

Non-fatal configuration findings (Phase 128, D-07).

Returns, in [[tools]] then [[tools.parameters]] DECLARATION order:

1. one uncapped-string finding per BODY-position string parameter with no max_length — the residual D-05 accepts, surfaced rather than refused;
2. one declared-max-length-above-placeholder-cap finding per path- or query-position parameter whose declared max_length EXCEEDS pmcp::server::schema_validation::PLACEHOLDER_MAX_LENGTH, because such a parameter publishes a limit in inputSchema that the always-on placeholder floor will not honour — so a refusal would name a rule the client was never told about;

and then one finding per ACTIVE [server.validation] opt-out.

Never returns an error and never refuses anything. A config with zero tools and no active opt-out returns an empty Vec. Consumed by cargo pmcp validate config and by the once-at-startup log.

pub fn lint_against_spec(&self, spec: &OpenApiSchema) -> Vec<ConfigWarning>

The findings that need the operator’s OpenAPI document to be computable (Phase 128, D4(b) / T-128-36a).

Separate from Self::lint rather than folded into it, because lint takes only &self and a config is meaningful with no spec at all — a spec-less deployment is supported and must produce no findings from its own absence.

Returns, in [[tools]] declaration order, one CONFIGURED_TEMPLATE_NOT_IN_SPEC finding per single-call tool whose (method, path) matches no operation the spec declares. Such a tool reaches its endpoint and keeps the unconditional character floor and the always-on length cap, but the spec’s declared pattern/maxLength narrowing for its placeholders is silently not applied — the /users/{alias} versus /users/{id} drift. That is an author error an operator can fix before deploy, which is the whole reason this runs at config time.

An author-written query string on the configured path is stripped before the lookup, because an OpenAPI path template never carries one — so /content/{version}/CUI?string=x is matched as /content/{version}/CUI rather than reported as drift.

The bound on this guard, stated

It covers a template written in the CONFIG. A template a Code Mode script COMPOSES at runtime is not visible here and cannot be, which is why the runtime miss is additionally reported once per (method, template) pair by crate::code_mode’s log_spec_lookup_miss. Neither signal is a refusal: this returns findings, and never an error.

Tools with no path/method pair — SQL tools, script tools — are skipped: they address no single spec operation.

Trait Implementations

impl Clone for ServerConfig

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ServerConfig

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for ServerConfig

fn default() -> Self

Returns the “default value” for a type.

impl<'de> Deserialize<'de> for ServerConfig

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl From<&ServerConfig> for StaticPromptHandler

fn from(cfg: &ServerConfig) -> Self

Build a single StaticPromptHandler from a crate::config::ServerConfig.

Returns a handler for the FIRST [[prompts]] entry, or — if none are declared — a no-op handler named "<no-prompts>" with an empty body. Multi-prompt servers should use prompt_handlers_from_config instead.

Example

use pmcp_server_toolkit::{ServerConfig, StaticPromptHandler};

let cfg = ServerConfig::default();
let _handler = StaticPromptHandler::from(&cfg);

impl From<&ServerConfig> for StaticResourceHandler

fn from(cfg: &ServerConfig) -> Self

Build a StaticResourceHandler from a parsed crate::config::ServerConfig.

Each [[resources]] entry in config becomes one LoadedResource. Resources with no content field default to an empty body — the strict-parse path’s crate::config::ServerConfig::validate does not flag empty resource bodies (operators may use the placeholder form "loaded from path.md" as a stable URI handle), so this construction follows suit. Resources WITH content_file semantics are out of scope for the lifted shape (Lambda runtime constraint, mirroring LoadedResource::from_config).

Insertion order matches the order of [[resources]] declarations, satisfying Pattern D (deterministic list() output).

Example

use pmcp_server_toolkit::{ServerConfig, StaticResourceHandler};

let cfg = ServerConfig::default();
let handler = StaticResourceHandler::from(&cfg);
assert_eq!(handler.len(), 0); // default config has no [[resources]]

impl PartialEq for ServerConfig

fn eq(&self, other: &Self) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl Serialize for ServerConfig

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl StructuralPartialEq for ServerConfig