Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

Guard Core

PYPI · GUARD-CORE-MCP

Guard Core security MCP: SecurityConfig validation, docs search, live threat detection.

Available components

+32 this week 67 Trust /100

Last scanned (3 hours ago)

Scores higher than 67% of PyPI servers

Category Security

Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →

Supply Chain Security50
  • Malware scan not yet available for this package.Unverified
  • No known CVEs affecting this package version or its production dependencies.Pass
  • Runs hatchling.build at install time, a recognised build step with no custom scripting around it. View diagnostics → Pass
  • 1 of 28 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency100
  • Source repository is publicly reachable at the declared URL. View diagnostics → Pass
  • Cryptographically verified build provenance (signed, bound to Guard-Core/guard-core-mcp). View diagnostics → Pass
  • Clear OSI-approved license (MIT).Pass
  • Actively maintained (last published 0 days ago).Pass
  • Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability66
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 2588 tokens (~287/item across 9 items; 9 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management17
  • Stability observed for 5 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • We read all 9 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
  • An AI judge read all 10 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a current MCP spec version (2026-07-28).Pass
Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 19 Oct 26 −15
    • Malware scan: pass → unverified ▼ security
    • Package version: 1.6.0 → 1.7.0 functional
  • 18 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 10 to 13. That category is still filling its 30-day observation window: 3 days of observed history at the previous scan, 4 at this one. The score rises as the window fills, whether or not the server changes.

  • 17 Oct 26 +15
    • Malware scan: unverified → pass ▲ security
  • 16 Oct 26 −14
    • Malware scan: pass → unverified ▼ security
    • Schema quality: 217 → 287 ▼ functional
    • Stability: unverified → 0.07 ▲ functional
    • Package version: 1.4.5 → 1.6.0 functional
  • 15 Oct 26 +15
    • Malware scan: unverified → pass ▲ security
  • 14 Oct 26 +15
    • Malware scan: pass → unverified ▼ security
    • Injection markers: unverified → pass ▲ security
    • First check of Judged manipulation: pass security
    • Stability: Stability not yet verified: not enough scan history yet (needs a 30-day window). security
    • Tool coverage: unverified → 100 ▲ functional
    • MCP protocol: unverified → pass ▲ functional
    • First check of Schema quality: fail functional
    • First check of Schema quality: excellent functional
    • First check of Destructive annotations: pass functional
    • First check of Schema quality: fail functional
    • First check of Tool coverage: 100 functional
    • First check of Tool coverage: 100 functional
  • 13 Oct 26 +15
    • Malware scan: unverified → pass ▲ security
  • 12 Oct 26 35

    First indexed and scored.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 19 Oct 2026 · Analysed pypi/guard-core-mcp@1.7.0

Provenance Verified

A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.

Result Verified
Ecosystem pypi
Reason Verified
Discovered via Registry attestation endpoint
Source repo Guard-Core/guard-core-mcp
Certificate issuer https://token.actions.githubusercontent.com
Certificate SAN https://github.com/Guard-Core/guard-core-mcp/.github/workflows/release.yml@refs/tags/v1.7.0
Rekor log index 3314745330
Predicate type PyPI publish attestation https://docs.pypi.org/attestations/publish/v1
Subject digest sha256:51db409fc131536c71ccb3050d8846c3444fb190483f7d136a79e270a1b3c3d2

Background: How many MCP packages publish verified provenance →

Install scripts 1 script
Hook Tier Command
build_backend allowlisted hatchling.build

Background: Why install scripts are a supply-chain risk →

Dependencies 28 packages
Packages resolved 28
No linked repository 1
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 9 exposed · ~2,396 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
adapter_setup ~236

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.

NameTypeReqDescription
frameworkstringyesThe adapter slug for that language, or the adapter package name. An unknown slug returns an error object listing the valid ones
languagestringyesThe language of the adapter. One of python, go, typescript, php or rust. Any other value returns an error object

Structured output declared, but exposes no named fields.

No examples provided.

check_payload ~486

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.

NameTypeReqDescription
body––Request body as a raw string, or a JSON object or array, which is serialized for you. Omit for a bodyless request
config––SecurityConfig fields to override guard-core's defaults, as a JSON object, to see how a setting changes the verdict. enable_redis is always forced off
headers––Request headers as a JSON object of names to values. Names are matched case-insensitively
methodstring–HTTP method of the request to test
pathstring–Request path of the request to test
query––Query-string parameters as a JSON object of names to string values

Structured output declared, but exposes no named fields.

No examples provided.

config_fields ~250

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.

NameTypeReqDescription
packagestring–Which Guard library's installed model to search. One of fastapi-guard, guard-core or guard-agent. Any other value returns an error object
querystringyesEither an exact config field name or plain words describing the behaviour. Matching is case-insensitive and word order does not matter

Structured output declared, but exposes no named fields.

No examples provided.

ecosystem ~256

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.

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

get_doc ~182

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.

NameTypeReqDescription
packagestringyesThe library the page belongs to, copied from a search_docs result or from the keys versions reports under docs_bundled_for and knowledge_bundled_for
pathstringyesThe page path relative to the library's bundled docs, copied from a search_docs result. Paths outside the bundled docs are rejected

Structured output declared, but exposes no named fields.

No examples provided.

search_docs ~269

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.

NameTypeReqDescription
limitinteger–Maximum number of results to return, highest score first
package––Restrict the search to one library, for example fastapi-guard, guard-core or guard-agent. Omit to search every bundled library. An unrecognized name silently matches nothing
querystringyesWords to look for in the bundled documentation. Pages are ranked by how often the words occur, so use specific terms

Structured output declared, but exposes no named fields.

No examples provided.

validate_config ~315

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.

NameTypeReqDescription
configobjectyesThe config as a JSON object of field names to values, exactly as you would pass it to the model's constructor
packagestring–Which Guard library's installed model to validate against. One of fastapi-guard (SecurityConfig), guard-core (SecurityConfig) or guard-agent (AgentConfig). Any other value returns an error object

Structured output declared, but exposes no named fields.

No examples provided.

versions ~165

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.

Input schema present but exposes no named parameters.

Structured output declared, but exposes no named fields.

No examples provided.

wire_agent ~237

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.

NameTypeReqDescription
framework––Optional adapter slug of that language, to add a note on how the agent hooks into that adapter. Omit for the agent alone
languagestringyesThe language whose telemetry agent to set up. One of python, go, typescript, php or rust. Any other value returns an error object

Structured output declared, but exposes no named fields.

No examples provided.

Install

How do I install the Guard Core MCP server?

Guard Core runs locally as a PyPI package, launched with uvx guard-core-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

pypi · guard-core-mcp

# add to Claude Code
claude mcp add guard-core-guard-core-mcp -- uvx guard-core-mcp
Common questions

What is the Guard Core MCP server?

Guard Core is an MCP server listed in the public MCP registry as io.github.Guard-Core/guard-core-mcp. Guard Core security MCP: SecurityConfig validation, docs search, live threat detection. This page covers its PyPI package (guard-core-mcp).

Is the Guard Core MCP server safe to use?

Guard Core scores 67 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 19 October 2026. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the Guard Core MCP server expose?

Guard Core exposes 9 tools: versions, validate_config, config_fields, search_docs, get_doc, and 4 more. Their descriptions and schemas cost roughly 2,396 tokens of context every time the server is loaded.

Is the Guard Core MCP server still maintained?

Guard Core is still listed as active in the MCP registry. We last reached this channel on 19 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

What licence is the Guard Core MCP server under?

Guard Core declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.