Struct ClientFilters 

pub struct ClientFilters { /* private fields */ }

Per-client filter combining tool-visibility (name-level) and tool-callability (argument-level) rules. Driven by request headers (HTTP/WS) or environment variables (stdio).

Implementations

impl ClientFilters

pub fn allow_all() -> Self

A filter that permits everything (no headers / no env vars set).

pub fn from_strings( visibility_allow: Option<&str>, visibility_deny: Option<&str>, callable_allow_json: Option<&str>, callable_deny_json: Option<&str>, ) -> Self

Build from raw strings. Callability inputs are JSON; malformed JSON is treated as no constraints (logged at WARN) — bricking a request on bad filter config would be a footgun for ops.

pub fn tool_visible(&self, name: &str) -> bool

true if the tool name is visible to this client.

A false return means a tools/call against this name produces an MCP Protocol Error (-32602, “Unknown tool: …”) and the tool is omitted from tools/list / resources/list. Deny wins; an empty allow list means “visible unless explicitly denied”.

pub fn meta_tool_visible(&self, name: &str) -> bool

true if the top-level search/execute/connection_status tools are visible to this client — unlike tool_visible, only deny applies; a non-empty allow list does not hide these.

These three are entry points, not operations: an operator’s allow list is written in terms of operation names (report:Foo, command:Bar) to scope which operations a client can reach — that scoping is enforced separately, per call, inside search’s index filtering and execute’s sandbox (both still call tool_visible on the operation’s own {kind}_{id} name). If search/execute themselves were gated by the same allow list, an operation-scoped allow list with no explicit search/execute entry would hide both tools entirely — making the server unreachable despite the operator’s intent being to scope operations, not remove entry points. Explicit deny still works normally for operators who want to lock a client out of a tool entirely.

pub fn tool_callable( &self, tool_name: &str, arguments: &Value, ) -> Result<(), String>

Check whether a tools/call is callable for this client given its JSON arguments.

Ok(()) if no callability constraints apply or every constraint passes. Err(message) surfaces as an MCP Tool Execution Error (isError: true content with the message), the spec’s “Invalid input data” category.

Visibility is not re-checked here; callers run tool_visible first.

Trait Implementations

impl Clone for ClientFilters

fn clone(&self) -> ClientFilters

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for ClientFilters

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

Formats the value using the given formatter.

impl Default for ClientFilters

fn default() -> ClientFilters

Returns the “default value” for a type.