MCPGuard-Lab

by Lc517

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a clearly distinct operation: arithmetic, file reading, note searching, URL fetching, security inspection, and note writing. No overlap in purpose.
Naming Consistency4/5
Five tools follow verb_noun pattern (read_file, query_notes, fetch_url, inspect_tool_metadata, write_note). The calculator tool uses a noun only, which is a minor deviation but still readable.
Tool Count5/5
Six tools is well-scoped for a security-focused lab server. Each tool earns its place without bloat or deficiency.
Completeness4/5
Covers core operations for a guarded lab environment: read, write, search notes, fetch URLs, compute, and inspect tool metadata. Missing file write or note deletion, but these are likely intentional safety constraints.
Average 3.2/5 across 6 of 6 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 are provided, so the description carries the full burden. It mentions 'explicit confirmation' but doesn't explain whether the tool checks the 'confirmed' parameter or expects a separate confirmation step. No disclosure of side effects (overwrite? append?), permissions, or error behavior. The description is too sparse for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is short. However, it is not well-structured: 'after explicit confirmation' is awkwardly placed and could be misinterpreted. While concise, it sacrifices clarity and completeness. A slightly longer but clearer description would be more effective.
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?
With 3 required parameters, no output schema, and no annotations, the description should cover input purpose, return value, and error conditions. It only hints at the confirmation requirement. Missing details about what happens on success, whether the note is persisted, and how to handle conflicts or invalid titles. Inadequate for safe agent usage.
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% — the input schema has no descriptions. The description only implies 'content' is Markdown and 'confirmed' relates to a confirmation. It fails to explain the pattern for 'title', the max length for 'content', or the semantics of 'confirmed' (e.g., must be true to proceed). This does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Write a Markdown note' — a specific verb and resource with the format. This distinguishes it from siblings like 'calculator' and 'read_file'. However, 'after explicit confirmation' is ambiguous (does the tool require pre-confirmation or self-confirm?), and it doesn't clarify what a 'note' is (a file? a database entry?).
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 on when to use this tool vs. alternatives like 'query_notes' (searching) or 'read_file' (reading). No when-not-to-use conditions or prerequisites are mentioned. The phrase 'after explicit confirmation' hints at a constraint but is not actionable guidance.
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?
With no annotations, the description must reveal behavioral traits. It warns that returned text is untrusted data, which is a useful behavioral note. However, it does not disclose whether the tool is read-only, requires authentication, or any side effects. The warning adds value but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, consisting of two short sentences. Every sentence adds information, but it could be slightly more structured (e.g., explaining the return format). Overall, it is appropriately concise.
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 low complexity (one parameter, no output schema, no nested objects), the description is minimally adequate. It states the action and a key behavioral note. However, it lacks details on query syntax, result format, and whether the search is full-text or filtered. More context would be helpful.
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 coverage is 0% with no description for the 'query' parameter. The description adds no meaning beyond the parameter name, leaving the agent to guess what constitutes a valid query or how it is interpreted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and the resource ('local Markdown notes'). It is specific and unambiguous. However, it does not differentiate from sibling tools like 'read_file' which might also access notes, but the purpose is still clear.
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?
The description provides no guidance on when to use this tool versus alternatives. The only usage hint is that returned text is untrusted, but it does not specify prerequisites, limitations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It hints at security filtering ('after SSRF policy checks') but omits key behaviors: what happens on failure (timeouts, blocked domains), size limits, caching, authentication (public only), response format, or side effects. This is insufficient for a tool that makes network requests.
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 redundancy. Every word is meaningful. It is optimally concise for the information it conveys.
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?
Given no output schema and minimal schema details, the description should explain return values (e.g., raw content, headers, status), errors, and how SSRF checks affect behavior. It does none of this, leaving critical gaps for an agent to invoke the tool correctly.
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 description coverage is 0%, so the description must compensate. It does add meaning by specifying that the 'url' must be public and support HTTP/HTTPS, which the schema (just a string) does not indicate. However, it doesn't clarify the required nature or expected format (e.g., must include scheme). The added value is moderate.
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 fetch a public HTTP(S) URL after SSRF policy checks. The verb 'Fetch' and resource 'URL' are specific, and the description distinguishes it from sibling tools like calculator, read_file, and write_note by targeting external web resources.
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?
The description provides no guidance on when to use this tool versus alternatives (e.g., read_file for local content, calculator for math). It mentions SSRF policy checks but does not explain prerequisites, limitations, or what URLs are allowed. No explicit when/when-not information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions 'without eval or shell execution' as a safety trait, but omits critical details like supported operations, error handling, precision, or expression syntax. This leaves significant ambiguity.
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 with no redundant words. It efficiently conveys the core purpose and a key behavioral note. Every word earns its place.
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 has only one parameter and no output schema, the description covers the minimal purpose but lacks details about the return value, error behavior, or expression language. It is adequate for a straightforward tool but not fully complete.
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% (the 'expression' property has no description). The tool description hints that the parameter is a numeric arithmetic expression, but does not specify expected syntax, allowed functions, or format rules. This is insufficient compensation for the missing schema 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 clearly states the tool evaluates numeric arithmetic, which is a specific verb-resource pairing. The sibling tools (read_file, query_notes, etc.) are unrelated, so differentiation is inherent.
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 does not provide explicit guidance on when to use this tool versus alternatives. However, the siblings are all different in nature (file/note/URL operations), so the intended use case is implicitly clear. A score of 3 reflects the lack of explicit when/when-not advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states the purpose but does not reveal the output format (e.g., boolean, score, report), side effects (presumably read-only), or what 'high-signal' detection entails. For a security-screening tool, missing these details hampers an agent's understanding.
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?
One sentence that is front-loaded with the action 'Screen.' No wasted words. Every part of the sentence contributes to understanding the tool's purpose.
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?
Given the tool's purpose (prompt injection screening), no output schema, no annotations, and 0% schema coverage, the description is insufficient. It fails to explain what the tool returns or how the agent should interpret the result. An agent would lack key information to use the tool effectively.
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 description coverage is 0%, so the description must compensate. It adds that the inputs come from an 'external tool,' providing context beyond the raw schema constraints (string lengths). However, it does not elaborate on the expected format or validation rules for name or description, offering only minimal additional meaning.
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 function: 'Screen an external tool name and description for high-signal prompt injection.' The verb 'screen' and the resource 'external tool name and description' are specific. This purpose distinguishes it from sibling tools like calculator, read_file, and fetch_url, which perform different operations.
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 the tool should be used when examining external tool metadata for prompt injection. However, it does not specify when not to use it or provide alternatives. Sibling tools such as fetch_url might also involve external content, but no guidance is given. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool reads a UTF-8 text file but does not disclose behavior on missing files, non-UTF-8 content, binary files, size limits, or permissions. This is a significant gap for a file-reading tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. While it could include more detail without becoming verbose, it is appropriately concise for a simple tool.
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 (one parameter, no output schema), the description is adequate for basic use. However, it lacks details on error handling, return format, and behavior for non-text files, leaving gaps for an agent to infer.
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 description coverage is 0%, so the description must compensate. It adds 'inside the configured workspace root,' which clarifies the path scope, but does not explain whether the path is absolute or relative, or how the workspace root is defined. This adds some value but is not comprehensive.
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 (read), resource (text file), encoding (UTF-8), and scope (inside configured workspace root). This distinguishes it from siblings like write_note (write) and fetch_url (URL).
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 implicitly indicates the tool is for reading text files, but it provides no explicit guidance on when to use it versus alternatives (e.g., query_notes, fetch_url). No exclusions or prerequisites are mentioned.
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

Copy to your README.md:

[![mcpguard-lab MCP server](https://glama.ai/mcp/servers/Lc517/mcpguard-lab/badges/card.svg)](https://glama.ai/mcp/servers/Lc517/mcpguard-lab)

Score Badge

Copy to your README.md:

[![mcpguard-lab MCP server](https://glama.ai/mcp/servers/Lc517/mcpguard-lab/badges/score.svg)](https://glama.ai/mcp/servers/Lc517/mcpguard-lab)

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/Lc517/mcpguard-lab'

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