Memory Shell Detector MCP

by RuoJi6

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.1.5
Disambiguation5/5
Each tool has a distinct purpose: network check, download, command execution, report export, system info, process listing, scanning, code viewing, and removal. No overlap exists, and descriptions clearly differentiate them.
Naming Consistency4/5
Most tools follow verb_noun pattern (check_network, download_detector_tools, export_report, etc.). One outlier, get_system_info_tool, uses 'get' instead of a consistent verb and adds redundant '_tool', slightly breaking consistency.
Tool Count5/5
With 9 tools, the server covers the full workflow from preparation (check, download) to detection (list, scan, view) to remediation (remove, report). The count is well-scoped and not excessive.
Completeness5/5
The toolset covers the entire memory shell detection lifecycle: network check, tool download, process listing, scanning, code review, removal, and report generation. No obvious gaps for the stated purpose.
Average 4.2/5 across 9 of 9 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on January 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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 are provided, so the description carries full burden. It describes the process (dump bytecode, decompile) and underlying command, but does not disclose potential side effects (e.g., JVM impact), error conditions (class not found, invalid PID), or security requirements. Behavior beyond 'success' is missing.
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 well-structured with sections: purpose, command example, usage context, parameter list, and return value. It is somewhat verbose with redundant technical details, but information is front-loaded and logically organized. Minor conciseness improvements possible.
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 complexity (9 params, optional SSH, remote execution), the description covers the main workflow and parameters. However, it lacks guidance on SSH usage triggers, error handling, and prerequisites. An output schema exists but is not detailed here; the description's mention of 'source_code' 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?
Schema description coverage is 0%, so the description must explain parameters. It provides brief but clear explanations for all 9 parameters, including examples for 'class_name' and 'pid', and context for SSH-related parameters. Could be more detailed (e.g., format constraints), but adequately adds meaning beyond the bare 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 clearly states the tool extracts and decompiles bytecode from JVM memory using a specific jar. It uses a specific verb ('extract and decompile') and specifies the resource (class bytecode). The tool is distinct from siblings like 'execute_command' or 'scan_process', which do not perform decompilation.
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 mentions it's for analyzing memory shells ('内存马') but does not explicitly state when to use this tool versus alternatives like 'execute_command' or 'scan_process'. There is no guidance on prerequisites (e.g., Java Agent availability) or exclusions. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral transparency. It reveals the underlying command and SSH parameters, implying network usage and external execution. However, it does not explicitly state that the tool is read-only or non-destructive, nor does it mention permissions or side effects. The transparency is adequate but incomplete.
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 structured with a first sentence stating the action, followed by the underlying command, bullet-pointed report contents, and a parameter list. It is front-loaded and reasonably concise given the complexity (10 params, SSH support). Minor redundancy (e.g., 'Args' list repeats schema) but overall efficient.
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?
The description covers the tool's purpose, command, report contents, parameters, and return value. Since an output schema exists, the return description is sufficient. It addresses SSH execution context but omits error handling or failure scenarios. It is fairly complete for a tool of this complexity.
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?
Schema description coverage is 0%, so the description must add meaning. It lists all 10 parameters and clarifies their roles (e.g., format accepts json/html/txt, ssh parameters for remote execution). It explains the report contents, which helps contextualize output_file and format. However, it does not provide detailed documentation for each parameter beyond the basic description, so it adds value but could be richer.
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: executing a JAR to generate a memory shell detection report. It specifies the underlying command and details the report contents (scan time, suspicious classes, risk levels, source code). This distinguishes it from siblings like scan_process or remove_memory_shell.
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 explicit guidance on when to use this tool versus alternatives (e.g., scan_process for scanning, view_class_code for viewing code). It does not mention prerequisites (e.g., needing to run scan_process first) or when not to use it. Usage is only implicit.
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 fully disclose behavioral traits. It states the tool lists processes (implying read-only) but does not mention potential side effects like performance impact or Java dependency. The behavior is partially clear but not fully transparent.
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 structured with a brief intro, command explanation, purpose, and parameter list. It is reasonably concise, though the inclusion of both Chinese and English adds some verbosity.
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 complexity of 7 parameters and no required ones, the description covers the tool's purpose, parameters, and return value. It lacks error handling details and dependencies like required Java installation, but is largely complete.
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 has no property descriptions, but the description compensates by listing all 7 parameters with their purpose in an Args section. This adds significant meaning beyond the schema, though some parameter details (e.g., constraints) are missing.
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 executes a specific jar to list all running Java processes, providing a specific verb and resource. It distinguishes from siblings like scan_process by indicating it is a preliminary step for selecting target processes.
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 explains the tool is used before memory shell scanning and provides context for SSH usage. However, it does not explicitly contrast with alternatives or specify 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains what is downloaded and the basic behavior, but lacks details on side effects like file overwriting, disk space needs, or error handling. The description is adequate but not rich on behavioral context.
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 well-structured with a clear purpose up front, followed by parameter details and return value. It is efficient with no wasted sentences.
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 complexity (7 optional parameters) and absence of annotations, the description is quite complete, explaining parameters and return. However, it lacks details on error conditions or failure handling, and the output schema is not described, but since output schema exists, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter descriptions in the Args section cover all 7 parameters, adding meaning beyond the schema, which has 0% description coverage. Each parameter explains its purpose and fallback to environment variables, providing clear guidance.
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 downloads two specific jar files for Java memory shell detection. It uses specific verbs ('下载') and resource names ('detector-agent.jar', 'detector-cli.jar'), and distinguishes itself from sibling tools like scan_process and remove_memory_shell by being a prerequisite step.
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 it is a prerequisite step before scanning and analysis, providing clear context for when to use the tool. However, it does not mention when not to use it or suggest alternatives, which slightly reduces the score.
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 provided, the description carries full burden. It discloses execution behavior, return fields (success, stdout, stderr, return_code), SSH configuration, and timeout. However, it does not mention potential risks (e.g., destructive commands, security implications) or required permissions, leaving important behavioral aspects unclear.
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 front-loaded with purpose and usage guidelines, followed by parameter details. It is well-structured but slightly verbose with the 'Args' section repeating parameter names. Every sentence serves a purpose, but some redundancy could be trimmed.
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 complexity (8 params, local/remote execution, environment variable fallbacks), the description covers core functionality, usage boundaries, and return structure. It lacks security warnings or error handling details, but overall it is sufficiently complete for typical usage scenarios.
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?
Schema description coverage is 0%, so the description must compensate. It provides details for all 8 parameters, including environment variable fallbacks for SSH parameters and default values. This adds significant meaning beyond the schema's raw types and defaults, though the command parameter could have more examples or format guidance.
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 executes system commands locally or via SSH, provides concrete examples (java -version, ps aux), and explicitly distinguishes it from sibling tools like list_java_processes and scan_process for core detection. The verb 'execute' and resource 'system commands' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (checking Java, system processes, auxiliary commands) and when not to use (core memory shell detection should use dedicated tools). It names specific alternatives: list_java_processes and scan_process.
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 provided; description omits behavioral traits like read-only nature. However, lists return fields, which partially compensates.
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?
Front-loaded bilingual description, concise bullet list of return fields, no superfluous words.
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 output schema present, description fully explains return values and purpose; no gaps for a parameterless 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?
No parameters, baseline 4. Description adds meaning by detailing return fields beyond 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?
Specific verb+resource ('获取当前系统环境信息'), clearly distinguishes from siblings like check_network or download_detector_tools.
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?
States use case: compatibility checking and tool storage path determination. Provides clear context but no explicit when-not-to-use or 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?
No annotations are provided, so the description carries the full burden. It explains the technology used (Java Agent injection), what components are scanned, and that results list suspicious class names. It doesn't discuss side effects or safety, but as a diagnostic tool, the description is sufficiently transparent.
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 well-structured: purpose, command, detection targets, then argument list. It's informative without being overly verbose, though some redundancy could be trimmed. Each sentence contributes to understanding.
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 complexity (8 parameters, SSH support, output), the description covers the main aspects: what it does, what it scans, all parameters, and the return format. With an output schema present, the description needn't detail return structure further.
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?
Schema description coverage is 0%, so the description compensates by listing all 8 parameters with brief explanations (e.g., pid, tools_dir, SSH options). It adds meaning beyond the schema's types and defaults, though some details (like valid pid range) are missing.
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 it executes a memory shell detection scan on a Java process, detailing the types of memory shells detected (Servlet, Spring, Agent, etc.). It is distinct from siblings like 'remove_memory_shell' or 'list_java_processes'.
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 explains when to use the tool (to scan a Java process for memory shells) and provides the underlying command. It doesn't explicitly state when not to use or mention alternatives, but the purpose is clear enough for an agent to decide.
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, but the description implies a read-only check. It does not explicitly state that it has no side effects, but the nature of testing connectivity is inherently non-destructive. Returns status without changing state.
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 and well-structured: it states the purpose, usage context, fallback instructions, and return format. Every sentence adds value with no fluff.
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 no parameters and a simple output (available, message), the description fully covers the tool's purpose, use case, and output. It even provides troubleshooting steps, making it contextually complete.
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?
Tool has 0 parameters, so schema coverage is 100%. Baseline 4 applies. Description adds context about what the tool checks, but no parameters to elaborate on.
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 checks network connectivity to a specific server ('工具下载服务器'). It distinguishes from siblings like 'download_detector_tools' or 'execute_command' by specifying it's a network test, not a download or command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions when to use: 'before downloading detection tools'. It also provides guidance on what to do if network is unreachable: manually download jar or check configuration. This suggests not to use it for other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: it uses Java Agent to unload/disable classes, explains removal mechanisms per type (Filter/Servlet/Listener, Spring, Agent), and describes the two-phase safety mechanism. It also states return values for each phase. No contradictions.
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 well-structured with sections for purpose, command, mechanism, security, args, and returns. It is front-loaded with the main purpose. While it is somewhat long, every sentence adds value, and no redundancy is present. A slight further tightening could improve, but it's already effective.
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 has an output schema, but the description covers the two-phase return. It addresses complexity: removal mechanisms, security confirmation, remote execution via SSH. No critical details are missing for an agent to use correctly. It is complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides clear explanations for all 10 parameters in the 'Args' section, including the ai_confirmed workflow and SSH connection parameters. It adds meaning beyond the schema by explaining the roles of tools_dir and the ai_confirmed flag.
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 removes memory shells from JVM processes, using a specific verb ('remove') and resource ('memory shell'). It distinguishes from siblings (e.g., scan_process detects, this removes) and provides the underlying command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description details a two-step usage pattern: first call with ai_confirmed=False to decompile and confirm, then second call with ai_confirmed=True to execute removal. It also clarifies when to use (after detection) and implies when not (without prior confirmation). Siblings like view_class_code or scan_process are for different phases.
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:

[![memory-shell-mcp MCP server](https://glama.ai/mcp/servers/RuoJi6/memory-shell-mcp/badges/card.svg)](https://glama.ai/mcp/servers/RuoJi6/memory-shell-mcp)

Score Badge

Copy to your README.md:

[![memory-shell-mcp MCP server](https://glama.ai/mcp/servers/RuoJi6/memory-shell-mcp/badges/score.svg)](https://glama.ai/mcp/servers/RuoJi6/memory-shell-mcp)

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/RuoJi6/memory-shell-mcp'

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