How do I use MCP X-Platform?

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 X-Platform Analyze ./src for cross-platform compatibility issues" 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 X-Platform

by Atomic-Germ

Overview Schema Related Servers Score Discussions

TypeScript

Local

MCP X-Platform

A Cross-Platform Compatibility Analyzer MCP server that systematically identifies platform-specific code patterns, dependencies, and potential portability issues

License: MIT TypeScript MCP

Overview

MCP X-Platform is a Model Context Protocol (MCP) server designed to analyze codebases for cross-platform compatibility issues. It detects platform-specific APIs, file path problems, line ending inconsistencies, shell command incompatibilities, and dependency issues across Windows, macOS, and Linux.

Key Features

🔍 Platform API Detection - Identify Windows, macOS, Linux, and POSIX-specific APIs
📁 File Path Analysis - Detect separator issues, reserved names, and case sensitivity problems
📝 Line Ending Check - Find CRLF vs LF inconsistencies
🖥️ Shell Command Analysis - Identify platform-specific shell commands and scripts
📦 Dependency Compatibility - Analyze dependencies for platform-specific packages
📊 Comprehensive Reports - Generate detailed cross-platform compatibility reports
🔗 MCP Integration - Seamless integration with other MCP tools
✅ Test-Driven - Built using TDD methodology

Related MCP server: Smart Code Reviewer

Installation

# Install dependencies
npm install

# Build the project
npm run build

# Run tests
npm test

Quick Start

As an MCP Server

Add to your MCP client configuration (e.g., Claude Desktop):

{
  "mcpServers": {
    "x-platform": {
      "command": "node",
      "args": ["/path/to/mcp-x-platform/dist/index.js"]
    }
  }
}

Core Tools

Tool	Purpose
`detect_platform_apis`	Detect platform-specific API calls
`analyze_file_paths`	Analyze file paths for compatibility
`analyze_line_endings`	Check line ending consistency
`analyze_shell_commands`	Analyze shell command compatibility
`generate_compatibility_report`	Generate comprehensive reports

Usage Examples

Detect Platform APIs

{
  "tool": "detect_platform_apis",
  "arguments": {
    "path": "./src",
    "platforms": ["windows", "macos", "linux"]
  }
}

Analyze File Paths

{
  "tool": "analyze_file_paths",
  "arguments": {
    "path": "./src",
    "checkCaseSensitivity": true,
    "checkSeparators": true
  }
}

Best Practices

File Paths

// ✅ GOOD
import * as path from "path";
const filePath = path.join("src", "utils", "helper.js");

// ❌ BAD
const filePath = "src\\utils\\helper.js";

Line Endings

# .gitattributes
* text=auto eol=lf
*.sh text eol=lf
*.{cmd,bat} text eol=crlf

Shell Commands

// ✅ GOOD - Cross-platform
import { rimraf } from "rimraf";
await rimraf("./temp");

// ❌ BAD - Platform-specific
exec("rm -rf ./temp");

Development

# Build
npm run build

# Test
npm test

# Watch mode
npm run build:watch

License

MIT License - see LICENSE file for details

Built for cross-platform compatibility with ❤️

Available Tools

8 tools

analyze_build_systemsC

Analyze build system configurations for cross-platform compatibility

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Project root path
`buildTools`	No	Build tools to analyze
`checkScripts`	No	Check build scripts for platform issues

TDQS

C2.9/5.0

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 fails to disclose whether the tool is read-only, requires permissions, or what the output format is. The brief description gives no behavioral context beyond the core function.

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 concise sentence that efficiently conveys the tool's core purpose. It is front-loaded with the key action and target, but some additional context (e.g., output format) could be added without sacrificing conciseness.

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

Completeness2/5

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

Despite having 3 parameters and no output schema, the description does not explain what the analysis produces, how to interpret results, or any prerequisites. This is insufficient for an agent to fully understand the tool's behavior and outputs.

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?

The input schema descriptions cover all 3 parameters (100% coverage) with clear explanations. The tool description adds no additional parameter meaning beyond the schema, so it meets the baseline expectation but does not exceed it.

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 verb 'Analyze' and the resource 'build system configurations' with the purpose of 'cross-platform compatibility'. It distinguishes this tool from sibling tools like analyze_dependencies and analyze_file_paths by focusing on build systems, though it does not explicitly contrast with siblings.

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. With multiple sibling analysis tools, the agent has no criteria to choose this over others for specific tasks.

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

analyze_dependenciesC

Analyze dependencies for platform-specific packages and compatibility

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Project root path
`platforms`	No	Target platforms to validate against
`checkArchitecture`	No	Check architecture-specific dependencies
`checkNativeModules`	No	Check for native/binary dependencies

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure, yet it only states 'Analyze dependencies...' without revealing whether it modifies state, what output to expect, or any side effects. This is insufficient for a tool with 4 parameters.

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 concise single sentence with no filler. It could be slightly improved by adding more context while remaining succinct, but overall it is efficient.

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 4 parameters and no output schema or annotations, the description is incomplete. It does not explain what the tool returns, error conditions, or the scope of analysis, which is needed for safe 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?

All 4 parameters are described in the input schema (100% coverage), so the description adds no extra meaning. Baseline score of 3 applies as the schema already explains each parameter's purpose.

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 it analyzes dependencies for platform-specific packages and compatibility, using specific verb and resource. However, it does not distinguish it from sibling tools like analyze_build_systems, which also deal with dependencies.

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, nor any context about when not to use it. Usage is only implied by the action 'analyze dependencies'.

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

analyze_file_pathsB

Analyze file system paths for cross-platform compatibility issues

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Directory or file path to analyze
`checkSeparators`	No	Check path separator usage
`checkReservedNames`	No	Check for Windows reserved names
`checkCaseSensitivity`	No	Check for case sensitivity issues

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must detail behavior but only gives a high-level purpose. It does not mention what checks are performed, output format, or side effects.

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?

Description is a single sentence, very concise and front-loaded. However, it could be expanded with usage guidance without losing conciseness.

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?

Tool has 4 parameters, no output schema, and no annotations. Description lacks information about output, typical use cases, and relationship to siblings, making it incomplete.

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 100% with descriptions for all parameters. The tool description adds no additional param semantics 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 verb 'Analyze', resource 'file system paths', and purpose 'for cross-platform compatibility issues'. It is distinct from sibling tools which focus on other aspects like build systems or encoding.

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?

Description provides no guidance on when to use this tool versus alternatives or any context for invocation.

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

analyze_line_endingsC

Detect line ending inconsistencies (CRLF vs LF)

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Directory or file path to analyze
`autoFix`	No	Suggest auto-fix options
`preferredEnding`	No	Preferred line ending style	LF

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description only says 'detect'. It does not disclose whether the tool modifies files, what the output looks like, or any potential side effects. For a tool with three parameters, more behavioral context is needed.

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, concise sentence. It is front-loaded and contains no redundant information. However, it is slightly under-specified for the complexity of the tool.

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 no output schema and minimal description, the tool lacks important context. For a tool with three parameters and no annotations, the description should cover expected output or typical use cases to be complete.

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 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions. It does not explain how 'autoFix' or 'preferredEnding' affect behavior.

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?

Description states 'Detect line ending inconsistencies (CRLF vs LF)', which clearly identifies the tool's purpose as analyzing line endings. However, it does not differentiate from sibling tools like 'detect_encoding_issues', missing a chance to clarify its unique scope.

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 versus alternatives. The description is a single sentence without any context on appropriate usage scenarios or when to avoid it.

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

analyze_shell_commandsB

Analyze shell commands and scripts for cross-platform compatibility

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Directory or file path to analyze
`checkEnvVars`	No	Check environment variable usage
`targetShells`	No	Target shell environments

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are present, so the description carries the full burden. It only states the function without disclosing behavioral traits like whether it is read-only, whether it modifies files, performance implications, or what kind of output is produced.

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, direct sentence with no filler. It is appropriately front-loaded and concise.

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 lack of annotations and no output schema, the description is insufficient. It does not describe what the tool returns (e.g., a report, list of issues) or any side effects, leaving the agent without complete information to understand the tool's full behavior.

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 100%, so the input schema already fully describes each parameter. The description adds no additional meaning beyond what the schema provides, meeting the baseline expectation.

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 identifies the tool's purpose: analyzing shell commands and scripts for cross-platform compatibility. The verb 'analyze' and resource 'shell commands and scripts' are specific, and it distinguishes itself from sibling tools that focus on build systems, dependencies, file paths, etc.

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. Siblings like analyze_build_systems or detect_platform_apis are listed but not differentiated in terms of usage context.

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

detect_encoding_issuesB

Detect file encoding issues that may cause cross-platform problems

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Directory or file path to analyze
`checkBOM`	No	Check for BOM (Byte Order Mark) issues
`preferredEncoding`	No	Preferred file encoding	UTF-8

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It does not mention whether the tool is read-only, requires file access, or has side effects. For a detection tool, assuming read-only is reasonable, but it's not explicitly stated.

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 sentence with no wasted words. However, it is very brief and could include more context without losing conciseness. Still, it is appropriately sized for a simple detection tool.

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 lack of output schema and annotations, the description is insufficient. The agent does not know what the tool returns (e.g., a list of issues, a report, or just boolean). Sibling tools have more specific names, but this one leaves ambiguity.

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 100%; each parameter has a description. The tool description adds no extra semantic meaning beyond what the schema provides. Baseline 3 is appropriate since no value is added but nothing is 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 verb 'detect' and the resource 'file encoding issues' with a specific context 'cross-platform problems'. It distinguishes from sibling tools like 'analyze_line_endings' and 'detect_platform_apis', which address different aspects.

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 siblings or alternatives. It does not mention prerequisites, when not to use, or specific scenarios. The agent has no context to decide between this and similar analysis tools.

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

detect_platform_apisB

Detect platform-specific API calls (Windows, macOS, Linux, POSIX)

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Directory or file path to analyze
`platforms`	No	Platforms to check against
`includeTests`	No	Include test files

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description must cover behavior. 'Detect' implies read-only, but no details on side effects, output format, or permissions. Very limited transparency.

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?

Single, front-loaded sentence efficiently conveys the core purpose. Could be slightly more informative without losing conciseness.

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?

Missing essential context: no output description, no mention of recursion or file filtering behavior, no return format. Incomplete for a scanner tool with multiple parameters.

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 100%, so baseline is 3. Description adds no parameter information beyond the schema, but the schema itself is self-explanatory.

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 the tool's purpose: detect platform-specific API calls, listing the specific platforms (Windows, macOS, Linux, POSIX). This distinguishes it from sibling tools like analyze_build_systems or detect_encoding_issues.

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. The description only states what it does, not when it should be invoked or excluded.

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

generate_compatibility_reportB

Generate comprehensive cross-platform compatibility report

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Project root path
`format`	No	Report format	summary
`severity`	No	Minimum severity to include	medium
`targetPlatforms`	No	Target platforms for analysis

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must carry full behavioral disclosure. However, it only says 'Generate comprehensive cross-platform compatibility report' and gives no insight into side effects, required permissions, performance implications, or what happens on error.

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 sentence with no wasted words, achieving brevity. However, it could benefit from additional structure (e.g., bullet points or examples) without sacrificing conciseness.

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 has 4 parameters, no output schema, and no annotations, the description is too sparse. It does not explain what the report contains, how results are returned, or any limitations, leaving significant gaps for an agent.

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 100%, and the description adds no extra meaning beyond what the schema provides. Parameters like 'format', 'severity', and 'targetPlatforms' are fully defined in the schema with enums and defaults, so baseline score of 3 is appropriate.

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 verb 'Generate' and the resource 'cross-platform compatibility report', specifying a comprehensive scope. It distinguishes from sibling tools like 'analyze_build_systems' or 'analyze_dependencies' which are more focused.

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 use when a broad compatibility overview is needed, but does not explicitly state when to use this tool versus siblings like 'analyze_file_paths' or 'analyze_line_endings'. No exclusion criteria or context provided.

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.

8 tool updatesv0.1.0Jul 13, 2026
- First observedanalyze_build_systems
- First observedanalyze_dependencies
- First observedanalyze_file_paths
- First observedanalyze_line_endings
- First observedanalyze_shell_commands
- First observeddetect_encoding_issues
- First observeddetect_platform_apis
- First observedgenerate_compatibility_report

Install Server

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

TDQS

A3.5/5.0

Disambiguation5/5

Each tool targets a distinct aspect of cross-platform compatibility (build systems, dependencies, file paths, line endings, shell commands, encoding, platform APIs, and report generation) with no overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using 'analyze_', 'detect_', or 'generate_' followed by a specific noun, with no mixing of conventions.

Tool Count5/5

Eight tools is well-scoped for a domain-specific compatibility analysis server, covering all key areas without being too few or too many.

Completeness4/5

The tool set covers major cross-platform issues (build systems, dependencies, paths, line endings, shell commands, encoding, APIs) and includes a comprehensive report generator, though environment variables or permissions are not directly addressed.

Maintenance

ActivityInactive

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

XRay-VisionOAuth
com.emtailabs
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
Code Analysis Developer Tools Autonomous Agents
2
chat-recallOAuth
io.github.munhq
Memory, secret scanning and code findings across every AI coding tool
12
Frogeye Security Scanner A
io.github.frogeye-ai
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security Penetration Testing
2
ArchGraphOAuth
dev.archgraph
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Code Analysis Software Architecture Developer Tools
2

Related MCP Servers

DependencyMCP Server
Code Analysis Developer Tools Code Execution
mkearl
A
license
A
quality
D
maintenance
Analyzes codebases to generate dependency graphs and architectural insights across multiple programming languages, helping developers understand code structure and validate against architectural rules.
Updated 2 years ago (2024-12-14 09:42 UTC)
6
60
20
MIT
Smart Code Reviewer
Code Analysis Developer Tools
renjismzy
A
license
A
quality
D
maintenance
Enables comprehensive code analysis including quality assessment, security vulnerability detection, refactoring suggestions, complexity calculations, and automatic documentation generation for multiple programming languages.
Updated a year ago (2025-08-14 02:42 UTC)
5
14
MIT
QoutaMCP
Developer Tools Code Analysis Software Architecture
QoutaID
A
license
A
quality
D
maintenance
Enables inspection and analysis of project structures to detect languages, frameworks, entry points, and dependencies across multiple programming languages including Node.js, Python, PHP, Go, Java, and Rust.
Updated 9 months ago (2025-12-22 03:25 UTC)
3
18
1
ISC
CodeBase Optimizer
Code Analysis Developer Tools Autonomous Agents
liadgez
A
license
Not graded
quality
D
maintenance
Provides comprehensive codebase analysis including project structure evaluation, cross-language duplicate detection, microservices validation, and configuration optimization with AI-powered pattern learning that generates actionable improvement reports.
Updated a year ago (2025-07-01 12:51 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/Atomic-Germ/mcp-x-platform'

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