diff --git a/docs/source/concepts/filter_chain.rst b/docs/source/concepts/filter_chain.rst index 3bcae318..5f09cdad 100644 --- a/docs/source/concepts/filter_chain.rst +++ b/docs/source/concepts/filter_chain.rst @@ -52,9 +52,10 @@ Filter Chain Programming Model (HTTP and MCP) Filters are implemented as simple RESTful endpoints reachable via HTTP. If you want to use the `Model Context Protocol (MCP) `_, you can configure that as well, which makes it easy to write filters in any language. However, you can also write a filter as a plain HTTP service. + When defining a filter in Plano configuration, the following fields are optional: -* ``type``: Controls the filter runtime (defaults to ``mcp``). You can also set this to ``rest`` for plain HTTP filters. +* ``type``: Controls the filter runtime. Use ``mcp`` for Model Context Protocol filters, or ``http`` for plain HTTP filters. Defaults to ``mcp``. * ``transport``: Controls how Plano talks to the filter (defaults to ``streamable-http`` for efficient streaming interactions over HTTP). You can omit this for standard HTTP transport. * ``tool``: Names the MCP tool Plano will invoke (by default, the filter ``id``). You can omit this if the tool name matches your filter id. diff --git a/docs/source/guides/prompt_guard.rst b/docs/source/guides/prompt_guard.rst index 81545a91..aacef20b 100644 --- a/docs/source/guides/prompt_guard.rst +++ b/docs/source/guides/prompt_guard.rst @@ -21,11 +21,13 @@ more reliable, and easier to reason about. - **Domain and Topicality Enforcement**: Ensure that agents only respond to prompts within an approved domain (for example, finance-only or healthcare-only use cases) and reject unrelated queries. - **Dynamic Error Handling**: Provide clear error messages when requests violate policy, helping users correct their inputs. + How Guardrails Work ------------------- -In Plano, guardrails are implemented as MCP filters that validate incoming requests. Each filter receives the chat messages, evaluates them -against policy, and either lets the request continue or raises a ``ToolError`` to reject it with a helpful error message. +Guardrails can be implemented as either in-process MCP filters or as HTTP-based filters. HTTP filters are external services that receive the request over HTTP, validate it, and return a response to allow or reject the request. This makes it easy to use filters written in any language or run them as independent services. + +Each filter receives the chat messages, evaluates them against policy, and either lets the request continue or raises a ``ToolError`` (or returns an error response) to reject it with a helpful error message. The example below shows an input guard for TechCorp's customer support system that validates queries are within the company's domain: