mcp-shield

by sanjibani

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 4.2/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

mcp-shield MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![mcp-shield MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/sanjibani/mcp-shield/badges/card.svg)](https://glama.ai/mcp/servers/sanjibani/mcp-shield)

Score Badge

Copy to your README.md:

[![mcp-shield MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/sanjibani/mcp-shield/badges/score.svg)](https://glama.ai/mcp/servers/sanjibani/mcp-shield)

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