Enum ConfigValidationError 

#[non_exhaustive]
pub enum ConfigValidationError {
    EmptyServerName,
    EmptyServerVersion,
    EmptyToolName(usize),
    EmptyTableName(usize),
    InlineSecretRejected,
    AmbiguousToolKind(usize),
    EmptyBackendBaseUrl,
}

Semantic-validation errors surfaced by crate::config::ServerConfig::validate.

Per Phase 83 review R8 — the Default impls on ServerConfig and its sub-sections deliberately allow from_toml to succeed even when required fields are missing (so partial configs can be merged programmatically). The crate::config::ServerConfig::validate entry-point catches these gaps at parse time and surfaces them as a typed enum variant per rule.

The enum is #[non_exhaustive] — match callers must include a wildcard arm so additional rules can be added without a breaking change.

Examples

use pmcp_server_toolkit::ConfigValidationError;

// Each variant has a precise `Display` describing the rule violated.
let err = ConfigValidationError::EmptyServerName;
assert_eq!(err.to_string(), "server.name must be non-empty");
let err = ConfigValidationError::EmptyToolName(3);
assert_eq!(err.to_string(), "[[tools]] entry at index 3 has empty name");

Variants (Non-exhaustive)

Non-exhaustive enums could have additional variants added in future. Therefore, when matching against variants of non-exhaustive enums, an extra wildcard arm must be added to account for any future variants.

EmptyServerName

[server] name is missing or whitespace-only.

EmptyServerVersion

[server] version is missing or whitespace-only.

EmptyToolName(usize)

[[tools]] entry at index has an empty / whitespace-only name.

EmptyTableName(usize)

[[database.tables]] entry at index has an empty / whitespace-only name.

InlineSecretRejected

Per Phase 83 Plan 06 review R9: [code_mode].token_secret was given as an inline literal (e.g. token_secret = "raw-string") instead of the env:VAR_NAME reference form, and the dev-only escape hatch allow_inline_token_secret_for_dev was not set. Inline literals in committed configs leak HMAC signing keys; the toolkit defaults to rejecting them.

AmbiguousToolKind(usize)

Per Phase 90 Plan 02 (D-01, T-90-02-04): a [[tools]] entry declares more than one mutually-exclusive tool kind. A tool is EITHER a SQL tool (sql), a single-call HTTP tool (path/method), OR a script tool (script) — never a mixture. The ambiguity is rejected rather than resolved by a silent precedence rule. The usize is the entry index.

EmptyBackendBaseUrl

Per Phase 90 gap-closure (GAP 3 / WR-02): a [backend] block is present but its base_url is empty / whitespace-only (or the base_url key was omitted, defaulting to "" via #[serde(default)]). Without this parse-time check a typo’d or missing base_url would validate cleanly and then surface late as an opaque DispatchError::Connector("invalid base URL") at the first backend request. Rejecting it here turns that late opaque failure into an actionable, field-naming error.

Trait Implementations

impl Debug for ConfigValidationError

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

Formats the value using the given formatter.

impl Display for ConfigValidationError

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

Formats the value using the given formatter.

impl Error for ConfigValidationError

fn source(&self) -> Option<&(dyn Error + 'static)>

Returns the lower-level source of this error, if any.

fn description(&self) -> &str

👎Deprecated since 1.42.0:

use the Display impl or to_string()

fn cause(&self) -> Option<&dyn Error>

👎Deprecated since 1.33.0:

replaced by Error::source, which can support downcasting

fn provide<'a>(&'a self, request: &mut Request<'a>)

🔬This is a nightly-only experimental API. (error_generic_member_access)

Provides type-based access to context intended for error reports.

impl From<ConfigValidationError> for ToolkitError

fn from(source: ConfigValidationError) -> Self

Converts to this type from the input type.