What can you do with this server?

ScopeGuard MCP is a policy-first defensive security server that enables AI clients to perform secure, bounded assessments, analyze web security headers, and scan authorized local repositories through a controlled interface, ensuring strong security guarantees and auditability. * Health Check: Report server safety settings, capabilities, and audit-chain health (health). * Create Dry-Run Engagement: Create a bounded, non-executing engagement scope with expiry (create_dry_run_engagement). * Revoke Engagement: Immediately revoke an engagement to prevent further operations (revoke_engagement). * Scope Validation: Normalize and verify targets are within allowed scope (check_scope). * Assessment Planning: Generate bounded web or repository assessment plans without executing network actions (plan_assessment). * Header Analysis: Analyze caller-supplied HTTP response headers offline (analyze_headers). * Repository Scanning: Run read-only Python and secret pattern scans on authorized local repos (scan_repository). * Audit Trail: List engagement-specific audit events (list_audit_events) and verify the tamper-evident audit chain (verify_audit_chain).

How do I use scopeguard-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@scopeguard-mcp Check if https://example.com is in scope for an assessment." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

scopeguard-mcp

by mzatylny

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

ScopeGuard MCP

CodeQL Python MCP License

ScopeGuard is a policy-first defensive security server for MCP. It lets AI clients plan assessments, evaluate web security headers, and scan explicitly authorized local source trees without exposing a general shell, network scanner, exploit generator, or credential tool.

The project demonstrates senior security-engineering concerns beyond rule detection: authorization boundaries, canonical scope evaluation, dual execution gates, bounded resource use, evidence integrity, secure file access, durable audit history, threat modeling, supply-chain controls, and negative testing.

Security guarantees

MCP clients can create only short-lived dry-run engagements.
Execute engagements are created and revoked only through the local operator CLI.
Every target operation requires an active engagement, an explicit capability, and a canonical target that matches scope.
Repository scans require both an execute engagement and the operator-controlled SCOPEGUARD_EXECUTION_ENABLED gate.
Production execution can require an HMAC-sealed audit checkpoint. A missing or invalid seal fails closed.
File traversal is bounded by file count, file size, total bytes, and finding count.
Repository files are opened as regular files without following symlink components on supported POSIX platforms, reducing path-race exposure.
Secret matches are never returned. Correlation fingerprints use keyed HMAC rather than a guessable unsalted digest.
Completed scans persist a manifest digest, ruleset digest, timestamps, outcome, and summary so evidence can be correlated with the audit chain.
The server uses local stdio only. It does not expose an unauthenticated network port.

These controls do not prove that a ticket represents legal authorization. The operator is still responsible for validating permission and exporting signed audit heads to a separate trust domain.

Related MCP server: mcp-security-scanner

Architecture

flowchart LR
    A["Untrusted MCP client"] --> B["Typed stdio tools"]
    O["Operator CLI + environment"] --> C["Policy engine"]
    B --> C
    C --> D["Canonical scope matcher"]
    C --> E["Capability + expiry gate"]
    C --> F["Dual execution gate"]
    F --> G["Bounded repository analyzer"]
    C --> H["Offline header analyzer"]
    C --> I[("SQLite engagements")]
    G --> J[("Durable scan evidence")]
    C --> K[("Hash-chained audit events")]
    K --> L["HMAC-sealed checkpoint"]

See ARCHITECTURE.md, the threat model, and the operations runbook for the detailed design.

MCP tools

Tool	Purpose	Boundary
`health`	Report safety posture and audit integrity	No target access
`create_dry_run_engagement`	Create a bounded non-executing scope	Execute mode is unavailable
`revoke_engagement`	Revoke an MCP-created dry-run engagement	Cannot revoke operator execute grants
`check_scope`	Normalize and evaluate a target	Active engagement required
`plan_assessment`	Produce a bounded web or repository plan	No network or process execution
`analyze_headers`	Inspect caller-supplied response headers	Offline and input-bounded
`scan_repository`	Run read-only Python and secret checks	Requires both execution gates
`list_audit_events`	Read engagement-specific evidence	Requires `audit:read`
`list_scan_runs`	Read durable scan manifests and outcomes	Requires `audit:read`
`verify_audit_chain`	Verify event order and the signed head	Does not reveal signing material

Quick start

Python 3.11 or newer is required.

python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
pip install -e .

scopeguard doctor
scopeguard-mcp

Example MCP client configuration:

{
  "mcpServers": {
    "scopeguard": {
      "command": "/absolute/path/to/scopeguard-mcp/.venv/bin/scopeguard-mcp",
      "env": {
        "SCOPEGUARD_STATE_DIR": "/absolute/path/to/scopeguard-state"
      }
    }
  }
}

Authorized execution workflow

Generate and store a random audit key in your secret manager. Do not commit it or place it in shell history. Then configure a dedicated state directory and the smallest possible repository root:

export SCOPEGUARD_STATE_DIR=/absolute/path/to/scopeguard-state
export SCOPEGUARD_ALLOWED_ROOTS=/absolute/path/to/authorized-repositories
export SCOPEGUARD_EXECUTION_ENABLED=true
export SCOPEGUARD_REQUIRE_SEALED_AUDIT=true
export SCOPEGUARD_AUDIT_HMAC_KEY='value-loaded-from-your-secret-manager'
export SCOPEGUARD_AUDIT_KEY_ID='primary-2026'

scopeguard create-engagement \
  --title "Repository security baseline" \
  --ticket SEC-1234 \
  --target file:/absolute/path/to/authorized-repositories/example \
  --capability scan:repository \
  --capability audit:read \
  --mode execute \
  --expires-in-minutes 60

scopeguard-mcp

Export the signed audit head after an assessment and anchor it in an append-only external system:

scopeguard verify-audit
scopeguard export-audit-checkpoint > scopeguard-audit-head.json

The checkpoint contains only the event count, chain head, key identifier, and HMAC signature. It never includes the signing key.

Capabilities

Capability	Allows
`plan:assessment`	Bounded web or repository planning for an in-scope target
`analyze:headers`	Offline analysis of supplied HTTP headers
`scan:repository`	Built-in read-only scanning under both execution gates
`audit:read`	Engagement audit events and durable scan-run evidence

Configuration

Variable	Default	Purpose
`SCOPEGUARD_STATE_DIR`	`<cwd>/.scopeguard`	Private SQLite state directory
`SCOPEGUARD_ALLOWED_ROOTS`	current directory	Path-separated operator allowlist
`SCOPEGUARD_EXECUTION_ENABLED`	`false`	Enables operator-created execute engagements
`SCOPEGUARD_REQUIRE_SEALED_AUDIT`	`true` in execute mode	Fails execution closed without a verified audit seal
`SCOPEGUARD_AUDIT_HMAC_KEY`	unset	At least 32 bytes; signs the durable audit checkpoint
`SCOPEGUARD_AUDIT_KEY_ID`	key fingerprint	Non-secret identifier used for rotation tracking
`SCOPEGUARD_MAX_TARGETS`	`25`	Engagement target ceiling
`SCOPEGUARD_MAX_HEADERS`	`100`	Offline header count ceiling
`SCOPEGUARD_MAX_HEADER_BYTES`	`32768`	Total header input ceiling
`SCOPEGUARD_MAX_FILES`	`5000`	Repository file ceiling
`SCOPEGUARD_MAX_FILE_BYTES`	`1000000`	Per-file read ceiling
`SCOPEGUARD_MAX_TOTAL_BYTES`	`50000000`	Total repository read ceiling
`SCOPEGUARD_MAX_FINDINGS`	`2000`	Returned finding ceiling

Repository analysis

The dependency-free analyzer detects focused high-signal patterns:

Python eval and exec
os.system and os.popen
subprocess calls with shell=True
unsafe Pickle deserialization
yaml.load without a safe loader
private-key blocks, AWS access keys, GitHub tokens, and likely hard-coded secrets

Results include a deterministic file-manifest SHA-256 and ruleset SHA-256. Secret values are excluded from results, audit events, and scan records. This scanner is a bounded baseline, not a replacement for CodeQL, Semgrep, Gitleaks, dependency auditing, or expert review.

Engineering quality

The repository includes:

Python 3.11–3.13 tests with a 90% coverage floor
Ruff lint and format verification
static type analysis with complete function signatures
Bandit and dependency vulnerability scanning
CodeQL analysis on pushes, pull requests, and a weekly schedule
package build and metadata verification
tagged release artifacts with an SBOM and GitHub build-provenance attestation
Dependabot for Python and GitHub Actions dependencies
architecture, threat-model, ADR, operations, contribution, and security documents

Local verification:

pip install -e ".[dev]"
ruff check .
ruff format --check .
mypy src/scopeguard_mcp
bandit -q -r src
pytest
python -m build
twine check dist/*

Responsible use

Use ScopeGuard only on repositories and systems you own or are explicitly authorized to assess. The project intentionally excludes exploit generation, password attacks, credential collection, payload generation, persistence, evasion, denial of service, internet-scale scanning, and autonomous attack chains.

Available Tools

9 tools

analyze_headersAnalyze HTTP security headersA

Read-onlyIdempotent

Analyze caller-supplied response headers offline; no HTTP request is performed.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`headers`	Yes
`engagement_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive behavior, but the description adds the crucial constraint that no HTTP request is performed, which is not captured by annotations. This provides valuable context beyond the structured metadata.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler words. Every word adds meaning, and it perfectly integrates the core purpose with the key behavioral nuance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and the presence of an output schema, the description covers the high-level behavior well. However, with three required parameters and zero schema descriptions, the missing parameter semantics create a notable gap. An agent would struggle to correctly populate 'target' and 'engagement_id' without additional information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the parameters 'engagement_id', 'target', or 'headers'. While 'headers' is implied by the description, 'target' and 'engagement_id' are completely undocumented, leaving the agent to guess their purpose. The description fails to compensate for the lack of schema-level descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Analyze') with a clear resource ('caller-supplied response headers') and adds the key differentiator 'offline; no HTTP request is performed.' This distinguishes it from sibling tools like scan_repository, which likely performs live requests.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies use cases by emphasizing that analysis is performed offline with caller-supplied data, so an agent understands this is for inspecting existing headers rather than fetching them. However, it does not explicitly name alternatives or provide exclusion criteria, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_scopeCheck target scopeA

Read-onlyIdempotent

Normalize a target and report whether it is inside the engagement scope.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`engagement_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the 'normalize' behavior, which is useful, but does not disclose edge cases such as invalid targets or missing engagement IDs. This is adequate given the annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the action ('Normalize a target') and states the outcome ('report whether it is inside the engagement scope'). No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the presence of an output schema, and annotations covering safety, the description is sufficient for basic understanding. It does not describe normalization specifics or error handling, but these are not essential for a simple scope-check operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate for parameter meaning. It does so by explaining that 'target' is normalized and checked against 'engagement scope', implicitly assigning roles to both parameters. This adds value beyond the raw schema fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool normalizes a target and checks if it is inside an engagement scope. The verb 'normalize' and the specific resource ('engagement scope') make the purpose unambiguous, distinguishing it from sibling tools like analyze_headers or scan_repository.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for verifying whether a target falls within a defined scope, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. Context suggests it is a precondition check, but no explicit guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_dry_run_engagementCreate dry-run engagementA

Create a non-executing assessment scope; execute mode is operator-CLI only.

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes
`ticket`	Yes
`targets`	Yes
`capabilities`	Yes
`expires_in_minutes`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are all false (not read-only, not idempotent, etc.), but the description adds meaningful context: the engagement is non-executing and execution is operator-CLI only. This goes beyond annotations and clarifies the tool's behavior, though it doesn't detail side effects like persistence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states purpose immediately and adds a useful nuance in the second clause. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema, the tool is incomplete for confident use: it lacks parameter semantics, usage guidance, and any mention of preconditions or side effects. The description is too brief given 5 parameters and no schema descriptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description provides no parameter meaning. Terms like 'targets' and 'capabilities' are left undefined, offering no value beyond the raw schema names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a 'non-executing assessment scope' (a dry-run engagement), using a specific verb and resource. It distinguishes from siblings by being the only creation tool and clarifies that this is not an execution tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage: this is for setting up a scope that will not execute, with actual execution limited to operator CLI. However, it does not explicitly contrast with alternatives like plan_assessment or explicitly state when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

healthScopeGuard healthA

Read-onlyIdempotent

Return server safety settings, capabilities, and audit-chain health.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by specifying the returned content (safety settings, capabilities, audit-chain health), but does not go further into operational behavior such as authentication or failure modes. This is adequate given strong annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose and return scope. This is appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters, an output schema present, and annotations covering safety, the description needs only to state what the tool returns. It lists three concrete areas (safety settings, capabilities, audit-chain health), which is complete for a simple health-check tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is trivially 100%. The baseline for 0 parameters is 4, and the description does not need to add parameter details. It could potentially clarify that no arguments are required, but this is obvious from the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Return' and names concrete resources: server safety settings, capabilities, and audit-chain health. This clearly states what the tool does and distinguishes it as a general health/inspection endpoint rather than a mutation or specific audit operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives like verify_audit_chain or check_scope. The description does not mention exclusions or preferred contexts, leaving the agent to infer usage from the name and sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_audit_eventsRead engagement audit eventsA

Read-onlyIdempotent

Return recent audit events when the engagement includes audit:read.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`engagement_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the permission requirement (audit:read) and the recency of events, which is useful context, but does not elaborate on pagination or ordering. It contributes some value beyond annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that immediately conveys the action and key condition, with no superfluous content. It is appropriately sized for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, simple parameter set (2 params, 1 required), and annotations covering safety, the description provides the essential condition and scope. It lacks explicit parameter clarification but is otherwise sufficient for a straightforward read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, and the description does not explain the engagement_id or limit parameters. Engagement_id is implied by 'when the engagement' but not explicitly described, and limit is entirely unmentioned. The description fails to compensate for the low schema coverage, leaving parameter semantics weak.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Return recent audit events') and the resource ('audit events'), and the condition 'when the engagement includes audit:read' distinguishes it from siblings like verify_audit_chain. This is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear usage condition: use the tool when the engagement has audit:read permission. It does not explicitly name alternatives or exclusions, but the conditional context is strong, and sibling differentiation is implicit in the distinctive action/resource.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

plan_assessmentPlan defensive assessmentA

Read-onlyIdempotent

Create a bounded web or repository assessment plan without running network tools.

ParametersJSON Schema

Name	Required	Default
`target`	Yes
`profile`	No	baseline
`engagement_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the crucial behavioral trait that the tool does not execute network tools, which goes beyond the annotations. It does not describe return format, but an output schema is present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one sentence of about 12 words, front-loaded with the action verb 'Create' and free of any filler. Every word contributes to understanding the tool's purpose and boundary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, has an output schema, and rich annotations that cover safety and execution semantics. The description fully captures the planning-only scope and distinguishes it from execution tools. No additional detail is necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate for parameter meaning, but it does not. 'target' and 'engagement_id' are self-explanatory by name, but 'profile' is ambiguous and no constraints or formats are given. The description adds zero parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Create' with the resource 'assessment plan' and specifies scoping ('bounded web or repository') and the key constraint ('without running network tools'). This clearly distinguishes it from execution-focused siblings like scan_repository.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'without running network tools' gives clear context that this is for planning only, not execution. It implies use before an actual scan, but it does not explicitly name alternatives or state when not to use it, leaving some room for interpretation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

revoke_engagementRevoke engagementB

Destructive

Immediately revoke an engagement and prevent further target operations.

ParametersJSON Schema

Name	Required	Description	Default
`engagement_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds 'Immediately' and 'prevent further target operations' beyond the annotations (destructiveHint=true, readOnlyHint=false), giving useful behavioral context about the effect and timing. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It efficiently states the action and a key consequence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation tool with one required parameter, the description is minimal. It does not explain how to obtain or format engagement_id, mention prerequisites, reversibility, or error conditions. The output schema exists, so return details are not required, but other operational context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has zero description coverage for engagement_id, and the tool description does not mention the parameter at all. With 0% coverage, the description must compensate but fails to provide any meaning for the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Immediately revoke an engagement and prevent further target operations.' It clearly distinguishes from sibling tools like create_dry_run_engagement, which creates rather than revokes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives, nor any conditions or exclusions. The description states what the tool does but not the context in which it should be invoked.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

scan_repositoryScan authorized local repositoryA

Read-onlyIdempotent

Run built-in read-only Python and secret checks under operator-allowed roots.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`engagement_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value by specifying the nature of checks (Python and secret) and the constraint 'under operator-allowed roots', which goes beyond the annotations. No contradiction exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every word contributes to explaining the tool's core action and constraints, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the output schema exists and annotations cover safety, the description lacks explicit usage guidance relative to siblings and provides no parameter clarification. It is adequate for a simple read-only tool but leaves gaps in operational decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 2 required parameters with 0% description coverage, so the description must compensate. It does not explain 'path' or 'engagement_id', and only vaguely hints at 'operator-allowed roots'. This is insufficient for understanding what values to pass.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Run' with a clear resource 'built-in read-only Python and secret checks' and a scope 'under operator-allowed roots'. This clearly differentiates it from sibling tools like analyze_headers or health, which address different concerns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for scanning an authorized local repository, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The 'operator-allowed roots' hint provides some context but not enough for clear decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_audit_chainVerify audit chainA

Read-onlyIdempotent

Verify every persisted event against the tamper-evident hash chain.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds useful scope information ('every persisted event'), but does not disclose potential performance costs or behavior when tampering is detected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the action and context without any wasted words or irrelevant detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of thorough annotations, a clear output schema, and zero parameters, the description provides adequate context for a verification tool. It could be improved by noting when to run it, but overall it is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no schema burden. Per the baseline for 0-parameter tools, the description does not need to explain parameter semantics, and it does not omit anything necessary.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('verify') and resource ('every persisted event') with a clear mechanism ('tamper-evident hash chain'), making the tool's purpose unambiguous and distinct from sibling tools like list_audit_events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The context implies the tool is for verifying audit log integrity, but there is no explicit guidance on when to use it versus alternatives such as list_audit_events, nor any mention of exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

9 tool updatesv0.1.0Aug 10, 2026
- First observedanalyze_headers
- First observedcheck_scope
- First observedcreate_dry_run_engagement
- First observedhealth
- First observedlist_audit_events
- First observedplan_assessment
- First observedrevoke_engagement
- First observedscan_repository
- First observedverify_audit_chain

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Scored 2026-08-10 16:55 across 9 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: health for status, engagement lifecycle (create/revoke), scope checking, planning, header analysis, repository scanning, and audit operations (list/verify). Even the two audit tools are distinct in intent—listing versus verifying integrity. There is no meaningful overlap that would cause an agent to select the wrong tool.

Naming Consistency4/5

Most tools follow a consistent verb_noun snake_case pattern (create_dry_run_engagement, revoke_engagement, check_scope, plan_assessment, analyze_headers, scan_repository, list_audit_events, verify_audit_chain). The only deviation is 'health', which is a noun instead of a verb_noun form, but this is a common exception for status endpoints and does not detract from overall readability.

Tool Count5/5

With 9 tools, this server is well-scoped for its domain of security assessment scope management. Each tool addresses a distinct operation without redundancy, and the count feels neither thin nor bloated.

Completeness3/5

The tool surface covers engagement creation and revocation, scope checking, planning, analysis, scanning, and audit verification. However, there is no way to list existing engagements or retrieve engagement details, which creates a gap in the engagement lifecycle. An agent cannot easily determine what engagements are active or inspect a specific engagement's configuration, limiting practical management.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ClearPolicyOAuth
app.clearpolicy
Authenticated MCP server for ClearPolicy policy and compliance workflows.
Legal & Compliance Security
2
OneDroid SynapseOAuth
ai.onedroid
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
Security Observability
1
Occludra — MCP Gateway (AI Security Gateway)
ai.occludra
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
Security Agent Orchestration
1
MANDATE Credential Broker B
io.github.projetnanocorp
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Security
111

Related MCP Servers

Symbiotic MCP Serverofficial
Penetration Testing Security Code Analysis
SymbioticSec
A
license
A
quality
D
maintenance
Enables security analysis of code and infrastructure files via MCP, using Symbiotic CLI for scanning vulnerabilities.
Updated 9 months ago (2025-12-15 13:46 UTC)
4
MIT
mcp-security-scanner
Penetration Testing Code Analysis
badchars
A
license
A
quality
A
maintenance
Security scanning for MCP servers from the inside out. Provides runtime inspection, AST-based static analysis, config audit, dependency analysis, and OWASP MCP Top 10 compliance in a single MCP server.
Updated 9 days ago (2026-09-02 03:23 UTC)
55
87
5
MIT
repo-guardian
Code Analysis Security Legal & Compliance
prem-the-dev
A
license
A
quality
C
maintenance
Enables agents to audit and safeguard repositories by detecting dependency pinning issues, license compliance problems, hardcoded secrets, and dead code through MCP tools.
Updated 19 days ago (2026-08-23 07:58 UTC)
4
MIT
hachiman
Security Penetration Testing
nidhish28guhan-netizen
A
license
Not graded
quality
B
maintenance
Enables AI agents and MCP servers to operate under autonomous security enforcement, including pre-deployment scanning, per-call authorization, runtime monitoring, incident containment, and comprehensive auditing.
Updated 18 days ago (2026-08-24 11:59 UTC)
1
MIT

ScopeGuard MCP

Security guarantees

Architecture

MCP tools

Quick start

Authorized execution workflow

Capabilities

Configuration

Repository analysis

Engineering quality

Responsible use

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Symbiotic MCP Serverofficial