Report which Guard libraries this server can introspect, and at which version.

Call this first, before trusting any answer about a version-specific feature. It takes no arguments.

Returns guard_core_mcp (this server's version), installed (the guard-core, fastapi-guard and guard-agent versions live in this interpreter), and docs_bundled_for and knowledge_bundled_for (the versions the bundled docs and the hand-written ecosystem notes describe).

A null installed version means that library is absent from the interpreter running this server, so validate_config, config_fields and check_payload cannot answer for it and any answer would be a guess. An installed version that differs from docs_bundled_for is normal and only means the docs may lag or lead the install.

Check a Guard config dict against the installed library's real pydantic model.

Use this to confirm a config is valid, or to find out why a setting seems to have no effect. Use config_fields instead when you do not yet know the setting's name.

Returns valid (bool), package, version, model, errors (type errors, each with field, message and input), unknown_fields (each with name and did_you_mean suggestions), deprecated (field and message) and construction_warnings. Unknown keys matter: pydantic silently ignores them, so a misspelled setting does nothing at runtime and raises no error anywhere else. construction_warnings carries guard-core's own logged-not-raised misconfiguration warnings: an unknown constructor keyword, a trusted_proxies or whitelist /0 network, and enabled_detection_categories empty while penetration detection is enabled.

Read-only: the config is validated in memory and never applied. If the library is not installed, or package is not recognized, returns an object with an error key (plus a hint when the cause is a missing install) instead of raising.

Find a Guard config setting by name or by what it does, with type and default.

Use this to learn what a setting means, or whether a setting for some behaviour exists at all. Use validate_config instead to check a whole config you already wrote, and search_docs for prose explanations rather than field metadata.

Returns package, version, query, exact and matches. An exact field name fills exact with that field's name, type, default, required flag and description (otherwise exact is null). Every query also fills matches with each other field whose name or description contains every word of the query; if nothing matches at all, matches falls back to the closest field names by spelling.

Read-only, in-memory lookup. If the library is not installed, or package is not recognized, returns an object with an error key instead of raising.

Search the bundled Guard documentation and return ranked, citable pages.

Use this to answer how or why questions from documentation, and to find the page to read in full with get_doc. Use config_fields instead for a setting's type and default, and adapter_setup or wire_agent for install and wiring steps.

Returns query and results. Each result has package, path, heading, snippet, url (the live documentation page to cite) and score. Pass a result's package and path straight to get_doc to read the whole page.

Read-only and offline: it searches the docs shipped inside this package. Unlike validate_config, an unrecognized package is not an error, it silently matches nothing, so an empty results list means either a real gap in the docs or a mistyped package name; retry with package omitted before concluding the former.

Return the full text of one bundled Guard documentation page.

Use this after search_docs when a snippet is not enough; it does not search. The package and path come from a search_docs result.

Returns package, path, url (the live page to cite) and content (the full markdown). An unknown package or a path that does not exist returns {"error": "unknown doc path"}; the two cases are not distinguished. Read-only and offline, and it cannot read files outside the bundled documentation.

Run one synthetic request through guard-core's real penetration-detection engine.

Use this to confirm that an attack payload is caught, or to explain why a benign request was flagged. Use validate_config instead to check a config, not a request.

Returns is_threat (bool), trigger_info (the matched parameter and pattern, empty when clean), threat_categories (for example sqli or xss), threat_scores (a score per category) and elapsed_ms. Verdicts come from the same detection path a live adapter runs. Read-only and sandboxed: the request is never sent anywhere and enable_redis is forced off so Redis is never touched. If guard-core is not installed, returns an object with an error key and a hint instead of raising.

This is the detection stage alone, not the whole middleware pipeline. A real request also passes IP rules, rate limiting, user-agent and cloud-provider checks, any of which can block it before detection runs, and a whitelisted IP skips detection entirely. A clean verdict here does not promise the request reaches the route, and a threat verdict does not promise a running app would block it.

The scan is bounded, so a payload past a cap is judged on the scanned prefix only: detection_max_scan_values caps values inspected (default 512), detection_max_scan_chars caps total characters scanned (default 65536), and detection_max_json_depth (default 32) caps how deep a JSON body is walked before the rest is scanned as one serialized value. These caps and the enhanced detection path apply from guard-core 3.15.0; versions reports what is installed.

Survey the whole Guard ecosystem: every language, engine, adapter and agent.

Use this to resolve a package name or compare languages. It takes no arguments. When you already know the language and framework, use adapter_setup for one adapter or wire_agent for the telemetry agent instead, which return less.

Returns the full registry for five languages (python, go, typescript, php, rust). Each language entry holds its engine (name, install command, version, release_status, conformance status), every framework adapter with a verified quick-start snippet and the Python adapter it maps to, and its telemetry agent with delivery semantics. A conformance block describes the frozen spec-4.0.2 corpus every engine is tested against, and a saas block documents the guard-core-app ingestion contract all agents share.

release_status is published (live on a package registry), tagged (a git tag exists, registry presence may lag) or untagged (install from source, main or a path dependency). Read it together with notes: several Go, PHP and Rust packages carry tags or version constants that registry publishing has not caught up with. Read-only static data that works with or without the Guard libraries installed.

Get the install command and a verified minimal integration for one Guard adapter.

Use this when you know the language and web framework and want working setup code. Use ecosystem instead to survey every adapter, and wire_agent to set up telemetry.

Returns language, engine (package, install command, release_status and conformance status of the engine the adapter depends on) and adapter (install command, release_status, its role in the framework, the Python adapter it mirrors, and a quick-start snippet taken verbatim from the adapter's README). Snippets reflect the README at the time this server was built; when release_status is untagged, re-check the repository. An unknown language or framework returns an object with an error key instead of raising. Read-only static data, works without the Guard libraries installed.

Get how to set up the Guard telemetry agent for one language.

Use this to ship security events and metrics to the guard-core-app backend. Use adapter_setup instead for the request-blocking middleware itself.

Returns language, agent (package, install command, release_status, quick-start snippet, and a summary of its buffer, flush, overflow and retry semantics), ingestion (the guard-core-app contract the agent ships against: endpoints, headers, HMAC signing, size limits and response semantics) and framework_note. For python the note points at the bundled guard-agent doc page for the adapter; for other languages the agent is standalone and the note says so. An unknown language or framework returns an object with an error key instead of raising. Read-only static data, works without the Guard libraries installed.