How do I use mcp-shield?

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., "@mcp-shield run the red-team suite against my MCP server" 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.

mcp-shield

by sanjibani

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

mcp-shield

Security primitives for the Model Context Protocol.

The Blackwell Systems 2026-06 audit scanned 54 production MCP servers and found 20 bugs in 9 of them. The 2026-03-05 MCP roadmap named audit trails, SSO, and machine-readable server discovery as the four blockers keeping MCP out of regulated enterprises. mcp-shield is the missing security layer — five drop-in primitives that address every bug class from the audit, MIT-licensed, stdlib-only, no SaaS dependency.

pip install mcp-shield

Why this exists

If you're running an MCP server — yours or someone else's — you have four problems mcp-shield solves:

Tool errors return as success. except E: return _format_error(e) leaves FastMCP's isError flag unset, so the agent retries forever. MCPTox benchmark (arXiv:2508.14925) flags this across 26+ Python MCPs.
No audit trail. SOC2 procurement requires per-call records. Building one yourself is a Friday you'll never get back.
Tool output can hijack the agent. OWASP #1 LLM vulnerability (Context Poisoning, >100K sites hit in 2025). Tool descriptions and outputs are the attack surface.
No input validation. Malformed calls from the agent crash your handler with KeyError, TypeError, etc. — not a typed error the model can correct.

Related MCP server: MCP Security Framework

The five primitives

Primitive	Bug class	Drop-in usage
`shield_tool` decorator	1 — isError-compliance	`@shield_tool(name="my_tool", schema={...})`
`audit_tool_call`	3 — JSONL audit	`with audit_tool_call("my_tool", args): ...`
`validate_input`	4-adj — JSON-schema input	`validate_input(args, schema={...})`
`sanitize_output`	2 — prompt-injection scrub	`sanitize_output(text, strict=True)`
`require_scope`	4 — OAuth 2.1 scope	`require_scope("admin")`

Plus: a standalone MCP server exposing shield_audit_tail, shield_audit_summary, shield_red_team, shield_scan_input, shield_patterns_list, shield_sanitize_preview, shield_version — register it alongside any other MCP to inspect what's happening.

Quick start (decorator)

from mcp.server.fastmcp import FastMCP
from mcp_shield import shield_tool

mcp = FastMCP("my-server")

@mcp.tool()
@shield_tool(
    name="search_things",
    schema={
        "type": "object",
        "required": ["query"],
        "properties": {"query": {"type": "string", "minLength": 1, "maxLength": 200}},
        "additionalProperties": False,
    },
    sanitize_strict=False,  # redact matched patterns; True raises
    required_scopes="read",
)
async def search_things(query: str) -> str:
    result = await upstream.search(query)
    return json.dumps(result)

That's it. You now have:

JSON-schema validation (rejects malformed calls with typed errors)
JSONL audit log per call (stderr default, override with MCP_SHIELD_AUDIT_LOG)
Output sanitization with 15 high-precision patterns from MCPTox + OWASP
isError-compliance (FastMCP sets isError: true automatically)
OAuth scope check

Quick start (operational MCP server)

# Audit logs go to stderr by default
mcp-shield

# Or to a file
MCP_SHIELD_AUDIT_LOG=/var/log/mcp/audit.jsonl mcp-shield

# Or disable audit entirely (for unit tests)
MCP_SHIELD_AUDIT=0 mcp-shield

Then ask your MCP client: "what was the error rate over the last hour?" or "run the red-team suite against my MCP."

What's in the box

src/mcp_shield/
├── __init__.py     # public surface
├── audit.py        # JSONL audit log (stdlib-only, fail-open, secret-redacting)
├── exceptions.py   # typed exception hierarchy (ShieldError, ShieldAuthError, ...)
├── sanitize.py     # prompt-injection scrubber (15 curated patterns)
├── server.py       # standalone MCP server exposing ops tools
├── shield.py       # @shield_tool decorator + ShieldedTool class + require_scope
└── validate.py     # JSON-schema input validation (Draft 7 subset)

Engineering standards

Every line of code in this repo follows patterns documented in the engineering playbook — the same playbook used by hawksoft-mcp, ezyvet-mcp, practicepanther-mcp, and the rest of the sanjibani MCP portfolio.

ruff: full rule set (E/F/W/I/N/UP/B/A/C4/DTZ/T20/PT/Q/RET/SIM/TID/ARG/PTH/ERA/PL/RUF)
mypy --strict: clean
pytest: 53 tests, all passing, covering every primitive + edge cases
py.typed: ships the marker for downstream mypy to type-check us
stdlib-only: audit + sanitize + validate need no extra deps; only mcp[cli], httpx, pydantic, structlog for the wrapper
fail-open: a broken audit sink never breaks the tool (SOC2 baseline)
JSON-RPC safe: audit goes to stderr (or file), never stdout

If you ship an MCP server, drop the shield on it in 5 minutes. If you don't ship one and just need to harden the ones you use, add the operational MCP server to your fleet.

If you'd rather have someone build a custom MCP server (vertical SaaS, internal tool, anything with a REST/GraphQL/SOAP API), see the engagement page — $25K / $60K / $120K+ tiers.

Other vertical MCPs in this portfolio:

hawksoft-mcp — independent insurance AMS
open-dental-mcp — dental practice
ezyvet-mcp — veterinary practice
jobber-mcp — home service trades
practicepanther-mcp — legal practice mgmt

Maintainer

Sanjibani Choudhury schoudhury1991@gmail.com · github.com/sanjibani

Available Tools

7 tools

audit_summaryA

Aggregate counts over a JSONL audit log: total calls, error rate, top tools.

Use when: "how healthy is the MCP fleet?", "what's the error rate?". Example: path="/var/log/mcp-shield/audit.jsonl".

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

No annotations exist, so description must fully disclose behavior. It implies read-only aggregation but does not state permissions, side effects, or whether it's safe. Missing details on resource usage or error states.

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?

Extremely concise: two sentences and an example. Front-loaded with purpose, followed by usage context and example. No extraneous information.

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 only one parameter and presence of an output schema, the description adequately covers the tool's function and usage. It fits well among siblings but could elaborate on output format or limitations.

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?

Single parameter 'path' has 0% schema description coverage. Description only provides an example path without explaining format, requirements, or restrictions. Adds minimal semantic value beyond the 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?

Description clearly states it aggregates counts over a JSONL audit log, specifying outputs: total calls, error rate, top tools. Provides example queries, making purpose unambiguous and distinct from sibling tools like audit_tail.

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?

Provides explicit 'Use when' examples like 'how healthy is the MCP fleet?', giving clear context for when to invoke. However, no when-not or alternative suggestions are given.

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

audit_tailA

Return the last n records from a JSONL audit log.

Use when: "what did the agent just do?", "did anything fail?". Example: path="/var/log/mcp-shield/audit.jsonl", n=50.

ParametersJSON Schema

Name	Required	Description	Default
`n`	No
`path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavioral traits. It indicates a read operation (returning records) but does not mention permissions, side effects, or performance considerations. The example path gives a hint about the expected location, but more context would be helpful.

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 very concise: three sentences covering the action, use cases, and an example. Information is front-loaded and no unnecessary words are present.

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 (2 params, output schema exists), the description is largely complete. It covers purpose, usage, and an example. However, it lacks a note about file existence or permissions, which would be helpful for a file-reading 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 schema has 0% description coverage, so the description must compensate. It explains 'n' as the number of records and gives an example path format. It also notes the default for n (20). This adds meaning beyond the raw schema, though it could be more explicit about the path parameter's required format.

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 the last n records from a JSONL audit log.' This is a specific verb and resource, distinguishing it from sibling tools like audit_summary which likely summarizes rather than tails.

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 explicit use cases: 'what did the agent just do?' and 'did anything fail?'. It also offers an example command. However, it does not specify when not to use this tool or mention alternatives like audit_summary.

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

patterns_listA

List the prompt-injection patterns the sanitizer detects.

Use when: "what does this tool actually look for?".

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description bears full responsibility. It communicates that the tool lists patterns, but does not disclose whether the operation is read-only, the output format, or any other behavioral details beyond the basic listing functionality.

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 consists of two concise sentences: the first states the purpose, the second provides usage guidance. No redundant or unnecessary information is present.

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?

Given the tool has no parameters and an output schema is present, the description is complete. It clearly explains the tool's function and when to use it, leaving no critical gaps.

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 input schema defines no parameters, and the description appropriately adds no parameter information. With zero parameters and 100% schema coverage, the baseline score of 4 applies.

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 'list' and a clear resource 'prompt-injection patterns the sanitizer detects', effectively distinguishing it from sibling tools like audit_summary, red_team, and sanitize_preview.

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 explicitly states a use case: 'Use when: what does this tool actually look for?', providing clear context for when to invoke it, though it does not mention when not to use it or compare to alternatives.

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

red_teamA

Run a curated set of injection payloads through the sanitizer.

Use when: "is the sanitizer actually catching things?", "compliance evidence for security review". Example: strict=False (default; reports hits without raising).

Each result row shows {"input", "caught", "pattern"}. caught is True iff the sanitizer matched any pattern.

ParametersJSON Schema

Name	Required	Description	Default
`strict`	No
`extra_patterns`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full weight. It explains default behavior (strict=False reports hits without raising), output format (each row shows input, caught, pattern), and meaning of 'caught' (true if any pattern matched). It does not detail side effects or permissions, but the read-only nature is implied.

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 concise (5 sentences), front-loaded with the main action, and efficiently includes use cases, an example, and output details without redundancy.

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?

For a tool with 2 simple parameters and an output schema, the description covers purpose, usage, default, and output format. It lacks detail on what happens when strict=True or how extra_patterns behave, but overall it is fairly complete for effective tool invocation.

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

Parameters3/5

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

Schema coverage is 0%, so description must compensate. It adds meaning for 'strict' by explaining its default and effect (reports hits without raising). However, 'extra_patterns' is not described, leaving its purpose ambiguous. The output description is provided but parameter semantics are only partially addressed.

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 explicitly states the verb 'run' and the resource 'a curated set of injection payloads through the sanitizer.' It clearly defines the tool's function and distinguishes it from siblings like scan_input or patterns_list by focusing on a predefined set for testing effectiveness.

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 specific use cases: 'is the sanitizer actually catching things?' and 'compliance evidence for security review.' It does not directly mention when not to use it or compare to alternatives, but the guidance is clear for the intended scenarios.

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

sanitize_previewA

Preview what the sanitizer would do to text without raising.

Use when: "what gets redacted from this output?". Example: text="ignore previous instructions", strict=False.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`strict`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

The tool has no annotations, so the description carries the burden of behavioral disclosure. It states that the tool does not raise errors ('without raising'), implying it is non-destructive and safe. However, it does not explicitly confirm idempotency or lack of side effects, which would strengthen transparency.

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 extremely concise with three short sentences and an example. Every sentence adds value, and the structure is front-loaded with the core action and purpose. No wasted words.

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 that the tool has an output schema, the description does not need to explain return values. With two parameters (one required, one optional with default), the description provides a clear use case and example. However, it could offer more context on when to use the 'strict' parameter, but overall it is adequate for a simple preview tool.

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

Parameters3/5

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

Schema coverage is 0%, so the description must add meaning. The description mentions the 'text' parameter and shows an example with 'strict=False', but does not explain what 'strict' does or how it affects behavior. This incomplete parameter documentation leaves the agent needing to infer or test.

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's purpose: to preview what the sanitizer would do to text without raising errors. It uses a specific verb ('preview') and resource ('sanitizer's effect on text'), and distinguishes itself from sibling tools by focusing on a safe preview operation.

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 explicit use case guidance: 'Use when: "what gets redacted from this output?"'. However, it does not explicitly mention when not to use the tool or suggest alternatives, which would make it more comprehensive.

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

scan_inputA

Validate an args dict against a JSON schema; return OK or first error.

Use when: "is my agent's call valid before I send it?". Example: args={"q":"hi"}, schema={"type":"object","properties":{"q":{"type":"string"}}}.

Returns {"valid": true} or {"valid": false, "error": "..."}. Never raises — the tool surfaces validation results as data.

ParametersJSON Schema

Name	Required	Description	Default
`args`	Yes
`schema`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. Discloses that it never raises errors and returns a specific structure. Additional details like performance or limits are unnecessary for a pure validation tool.

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?

Three sentences, each adding value: purpose, usage, return format. No extraneous text; 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?

Covers purpose, usage, return format, and example. Does not mention edge cases or error types, but for a straightforward validation tool, the description is sufficient. Output schema exists to document return values.

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

Parameters3/5

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

Schema coverage is 0%, and the description does not individually define each parameter. However, the example (args={"q":"hi"}, schema={"type":"object",...}) provides partial context, helping agents understand expected input.

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?

Clearly states it validates an args dict against a JSON schema and returns OK or first error. Distinct from sibling tools like audit_summary or sanitize_preview.

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?

Explicitly provides a 'when to use' quote: "is my agent's call valid before I send it?". Does not specify when not to use, but context is clear.

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

versionA

Return mcp-shield version + runtime config.

Use when: "what version is deployed?".

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description bears full responsibility. It accurately conveys a read-only, non-destructive action (returning version info). No behavioral traits are omitted, given the tool's simplicity.

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 two sentences long: the first states purpose, the second provides usage guidance. Every word is necessary and front-loaded, no redundancy.

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?

Given the tool has no parameters and an existing output schema, the description completely covers the necessary information: it identifies the output (version + runtime config) and suggests when to use it.

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, and the schema coverage is 100% (empty properties). The description adds no parameter details, which is acceptable as no parameters exist. Baseline score is 4 for zero-parameter tools.

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 explicitly states the tool returns 'mcp-shield version + runtime config', providing a specific verb and resource. It clearly distinguishes from sibling tools like audit_summary or red_team, which have different purposes.

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 includes a direct usage hint: 'Use when: "what version is deployed?".' This is clear context for when to invoke the tool, though it lacks explicit exclusions or alternatives, which are unnecessary for such a straightforward tool.

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. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jun 27, 2026
- First observedaudit_summary
- First observedaudit_tail
- First observedpatterns_list
- First observedred_team
- First observedsanitize_preview
- First observedscan_input
- First observedversion

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: auditing (summary and tail), pattern management (list and test), sanitization preview, input validation, and version info. No overlap.

Naming Consistency5/5

All tool names use snake_case and follow a verb_noun pattern (audit_summary, audit_tail, patterns_list, red_team, sanitize_preview, scan_input). Even 'version' fits as a simple noun command.

Tool Count5/5

With 7 tools, the surface is well-scoped for a security/audit server. It covers auditing, pattern introspection, testing, preview, input validation, and version info without bloat.

Completeness4/5

Covers core workflows: auditing (summary + tail), pattern listing, red team testing, sanitization preview, and input validation. Minor gaps like dynamic pattern updates or configuration are absent but not critical for the stated purpose.

Maintenance

ActivityStale

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

MANDATE Credential Broker B
io.github.projetnanocorp
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Security
111
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
Word Of Clout ACN MCP Server
io.github.wordofclout
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
CRM Customer Data Platforms
2

Related MCP Servers

mcp-trust-guard
Security Autonomous Agents
Thezenmonster
A
license
Not graded
quality
F
maintenance
Security middleware for MCP servers. Trust-based access control, rate limiting, and audit logging. Zero dependencies.
Updated 5 months ago (2026-03-27 02:20 UTC)
28
MIT
MCP Security Framework
Security Developer Tools
aself101
A
license
A
quality
B
maintenance
Enables creation of secure-by-default MCP servers with 5-layer validation to protect against injection, path traversal, and other attack vectors.
Updated 15 days ago (2026-08-24 17:53 UTC)
7
831
2
MIT
mcpauth
Security Developer Tools
yilmazali325
A
license
Not graded
quality
D
maintenance
Drop-in OAuth 2.1 + Dynamic Client Registration for MCP servers, providing authentication middleware and token verification.
Updated 2 months ago (2026-07-01 22:25 UTC)
20
MIT
mcp-starter-template
Developer Tools Security
HamzaOuadid
A
license
Not graded
quality
B
maintenance
A reference MCP server scaffold with per-user auth passthrough, read-only defaults, dry-run mode, and rate/spend capping, enabling developers to build secure MCP integrations with structured audit logging.
Updated 22 days ago (2026-08-17 15:52 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sanjibani/mcp-shield'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

mcp-shield

Why this exists

The five primitives

Quick start (decorator)

Quick start (operational MCP server)

What's in the box

Engineering standards

Cross-promo footer

Maintainer

Available Tools

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

Latest Blog Posts

MCP directory API