How do I use SSH MCP?

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., "@SSH MCP check disk space on db-server-01" 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.

SSH MCP

by sondt2709

Overview Schema Related Servers Score Discussions

Python

Local

SSH MCP: Model Context Protocol tool for Virtual Machine Management over SSH

SSH MCP is a Model Context Protocol tool written in Python for managing and interacting with multiple virtual machines (VMs) over SSH. It simplifies executing commands on remote servers by using the standard SSH config file format and leverages the robust paramiko library to handle SSH connections and command execution securely and efficiently.

Usage Guide 📖

SSH MCP can be used in two ways: as an MCP server or as a direct command-line tool.

MCP Server Usage

SSH MCP can also run as an MCP server, providing tools that can be used by AI assistants and other MCP clients:

uv run ssh-mcp-py

Available MCP Tools:

execute_ssh_command: Execute a command on a remote host
- Parameters: hostname (string), command (string)
list_ssh_hosts: List all configured SSH hosts
- Parameters: None
get_host_info: Get detailed information about a specific host
- Parameters: hostname (string)
test_ssh_connection: Test SSH connection to a host
- Parameters: hostname (string)

Integration with Claude Desktop

To use SSH MCP with Claude Desktop, add the following configuration to your claude_desktop_config.json:

{
  "mcpServers": {
    "ssh": {
      "command": "uvx",
      "args": [
        "ssh-mcp-py"
      ],
      "env": {
        "MCP_TRANSPORT": "stdio",
        "SSH_CONFIG_PATH": "/Users/your_username/.ssh/config"
      }
    }
  }
}

Configuration File Location:

macOS: /Users/your_username/Library/Application Support/Claude/claude_desktop_config.json

Replace your_username with your actual username

Direct Command-Line Usage

You can execute commands directly using the command line interface:

Basic Command Execution:

uv run cli.py <host> "<command_to_execute>"

Examples:

To list the files in the home directory of web-server-01:

uv run cli.py web-server-01 "ls -la ~"

To check the disk space on db-server-01:

uv run cli.py db-server-01 "df -h"

MCP Inspector

You can inspect and test the MCP server using the MCP Inspector:

npx @modelcontextprotocol/inspector uv run ssh-mcp-py -e SSH_CONFIG_PATH=/Users/your_username/.ssh/config -e PROXY_CONFIG_PATH=/config/proxy.json

This will open a web interface where you can test the available MCP tools interactively.

Related MCP server: MCP SSH Manager

Key Features 🚀

Standard SSH Config: Uses the familiar ~/.ssh/config file format for managing VM connection details
Automatic Key Management: Uses SSH keys specified in the config file for each host
Remote Command Execution: Execute terminal commands on any configured VM directly from your local machine
MCP Integration: Provides tools for AI assistants through the Model Context Protocol
Simplified Workflow: Streamline your server administration tasks using standard SSH configuration

Requirements 📋

To use SSH MCP, you'll need the following on your system:

Python 3.10 or higher: Ensure you have a recent version of Python installed.
paramiko: The core Python library for the SSHv2 protocol.
fastmcp: For MCP server functionality.

Configuration ⚙️

SSH MCP uses the standard SSH configuration file format. By default, it looks for ~/.ssh/config, but you can specify a custom path using the SSH_CONFIG_PATH environment variable.

SSH Config File Setup

Create or update your ~/.ssh/config file with your server details:

Example ~/.ssh/config:

Host web-server-01
    HostName 192.168.1.101
    Port 22
    User admin
    IdentityFile ~/.ssh/id_rsa

Host db-server-01
    HostName 192.168.1.102
    Port 22
    User dba
    IdentityFile ~/.ssh/id_rsa

Host app-server-01
    HostName 192.168.1.103
    Port 2222
    User deployer
    IdentityFile ~/.ssh/id_ed25519

Proxy Configuration (Optional)

SSH MCP supports SOCKS5 proxy connections with authentication. Create a JSON file with proxy configurations and set the PROXY_CONFIG_PATH environment variable:

Example proxy_config.json:

{
  "vm-a": {
    "host": "proxy.example.com",
    "port": 1080,
    "username": "proxy_user",
    "password": "proxy_pass"
  },
  "vm-b": {
    "host": "another-proxy.example.com",
    "port": 1080,
    "username": "another_user",
    "password": "another_pass"
  }
}

When a host is configured in both SSH config and proxy config, SSH MCP will automatically use the SOCKS5 proxy for that connection.

Command Logging

Every execute_ssh_command call writes a log file containing the command and its full, untruncated stdout/stderr (plus host, exit code, and duration). The response includes the path to that log file, so even when the response output is truncated to max_length, the complete output is preserved on disk.

The log directory is controlled by the SSH_MCP_LOG_DIR environment variable. When unset, an OS-appropriate default is used:

OS	Default log directory
macOS	`~/Library/Logs/ssh-mcp/`
Linux	`${XDG_STATE_HOME:-~/.local/state}/ssh-mcp/logs/`
Windows	`%LOCALAPPDATA%\ssh-mcp\logs\`

Set SSH_MCP_LOG_DIR to a directory path to use a custom location.
Set SSH_MCP_LOG_DIR=false to disable logging entirely (no log file is written and no log path is returned).
If the log directory cannot be created or written, the command still runs and returns its output; the response notes that logging was skipped.
One log file is created per command. Cleanup is up to you — SSH MCP does not rotate or delete old logs.

Environment Variables (Optional)

MCP_TRANSPORT: stdio, sse, streamable-http (defaults to stdio)
SSH_CONFIG_PATH: Path to SSH config file (defaults to ~/.ssh/config)
PROXY_CONFIG_PATH: Path to JSON file containing SOCKS5 proxy configurations (optional)
SSH_MCP_LOG_DIR: Directory for per-command log files (defaults to an OS-specific path; set to false to disable logging)

Architecture & Workflow 🏗️

SSH MCP follows a clean architecture with clear separation between configuration management, SSH operations, and MCP integration.

Class Structure

classDiagram
    class SSHConfig {
        +config_file_path: str
        +ssh_config: paramiko.SSHConfig
        +__init__()
        +_load_ssh_config() paramiko.SSHConfig
        +get_host_config(hostname) Dict
        +list_hosts() List[str]
    }
    
    class SSHClient {
        +config: SSHConfig
        +__init__(config)
        +execute_command(hostname, command) Dict
        +list_hosts() List[str]
    }
    
    class MCPTools {
        +execute_ssh_command(hostname, command) str
        +list_ssh_hosts() str
        +get_host_info(hostname) str
        +test_ssh_connection(hostname) str
    }
    
    SSHClient --> SSHConfig : uses
    MCPTools --> SSHClient : uses
    SSHConfig --> paramiko.SSHConfig : wraps

Workflow Diagram

graph TD
    A[MCP Client Request] --> B{Tool Type}
    B -->|execute_ssh_command| C[execute_ssh_command]
    B -->|list_ssh_hosts| D[list_ssh_hosts]
    B -->|get_host_info| E[get_host_info]
    B -->|test_ssh_connection| F[test_ssh_connection]
    
    C --> G[get_ssh_client]
    D --> G
    E --> G
    F --> G
    
    G --> H[SSHClient.__init__]
    H --> I[SSHConfig.__init__]
    I --> J[_load_ssh_config]
    J --> K[paramiko.SSHConfig.parse]
    
    C --> L[SSHClient.execute_command]
    L --> M[get_host_config]
    M --> N[paramiko.SSHConfig.lookup]
    N --> O[paramiko.SSHClient.connect]
    O --> P[paramiko.SSHClient.exec_command]
    
    D --> Q[SSHConfig.list_hosts]
    Q --> R[paramiko.SSHConfig.get_hostnames]
    
    E --> M
    F --> M
    F --> S[paramiko.SSHClient.connect]

Development & Testing 🧪

Clone code and setup 💻

Clone the Repository: Start by cloning the SSH MCP repository to your local machine
Install Dependencies: Install the necessary Python libraries uv sync
Setup Pre-commit: Run uv run pre-commit install. This will automatically run code quality checks before each commit, catching issues early and maintaining consistent code standards.

Test Structure

SSH MCP uses a focused testing approach that emphasizes real integration tests over complex mocked unit tests.

tests/test_ssh_client.py: Basic unit tests for core functionality
tests/test_mcp.py: Minimal MCP tool tests with simple mocking
tests/test_integration.py: Real integration tests that connect to actual SSH hosts

Integration Testing Setup

The integration tests require a host named test in your SSH config. Add a host like this to ~/.ssh/config:

Host test
    HostName your-test-server.com
    User your-username
    IdentityFile ~/.ssh/your-key

The integration tests will:

Connect to the real SSH host
Execute actual Linux commands
Test the full MCP workflow end-to-end

Running Tests

# Run all tests
uv run pytest tests/ -v

# Run only integration tests (requires 'test' host)
uv run pytest tests/test_integration.py -v

# Run only unit tests
uv run pytest tests/test_ssh_client.py tests/test_mcp.py -v

# Run with coverage
uv run pytest tests/ --cov=ssh_mcp --cov-report=html

Code Quality

The project uses ruff for linting and formatting:

uv run ruff check .
uv run ruff format .

Publishing to PyPI

To publish this package to PyPI, bump the version in pyproject.toml and run:

rm -rf dist
uv build
uv publish --username __token__ --password YOUR_PYPI_API_KEY

Replace YOUR_PYPI_API_KEY with your actual PyPI API token.

Available Tools

4 tools

execute_ssh_commandA

Run a shell command on a remote host over SSH.

Args:
    hostname: Host alias from SSH config.
    command: Shell command to run.
    timeout: Connection/command timeout, seconds (default 30, max 300).
    max_length: Max stdout/stderr length in the response (default 1000, max 10,000,000); full output is in the log file.

Returns:
    Command output (markdown), with exit code and the log file path.

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes
`timeout`	No
`hostname`	Yes
`max_length`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully discloses timeout bounds, output truncation via max_length, the fact that full output goes to a log file, and the return format. However, it does not mention authentication requirements, potential side effects of running arbitrary commands, or safety/security caveats.

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 front-loaded with a clear one-sentence purpose, followed by a compact Args list and Returns section. Every sentence adds useful information, with no filler or redundant content.

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 provides strong coverage of parameters, defaults, return values, and truncation behavior. However, it omits any guidance about long-running or destructive commands, authentication assumptions, or remote-host impact, which would be helpful for a tool that executes arbitrary commands with no annotation safeguards.

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?

The input schema has no parameter descriptions (0% coverage), so the description fully compensates by explaining each parameter: hostname as an SSH config alias, command as the shell command, timeout with defaults/max, and max_length with truncation and log-file behavior. This is exactly what the agent needs to invoke the tool correctly.

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: 'Run a shell command on a remote host over SSH.' The verb 'Run' and resource 'shell command on a remote host' are specific, and the description distinguishes this from sibling tools that list hosts, get host info, or test connections.

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 one-line summary provides clear context for when to use the tool: when you need to execute a shell command on a remote host. It does not explicitly mention alternatives or exclusions, but the purpose is distinct enough that no confusion with sibling tools arises.

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

get_host_infoA

Get config details (hostname, port, user, key) for a host alias.

Args:
    hostname: Host alias from SSH config.

Returns:
    Host configuration details.

ParametersJSON Schema

Name	Required	Description	Default
`hostname`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the source ('SSH config') and the returned fields, indicating a read-only operation. However, it does not mention error behavior (e.g., what happens if the alias is not found), potential side effects, or any prerequisites. It adds some useful context but leaves gaps.

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, with a clear one-line summary followed by Args and Returns sections. Every sentence earns its place, and there is no redundant 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?

For a simple tool with one parameter and an output schema, the description covers the purpose, parameter semantics, and returns adequately. It lacks mention of error handling or related tools, but given the low complexity, it is sufficiently complete overall.

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 only defines 'hostname' as a string with no description (0% coverage). The description compensates by explaining that the parameter is a 'Host alias from SSH config,' which gives crucial semantic meaning beyond the schema. It also lists the return fields, further clarifying the parameter's role.

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 ('Get config details') and the resource (a host alias), and lists the specific fields returned (hostname, port, user, key). This distinguishes it from sibling tools like list_ssh_hosts, execute_ssh_command, and test_ssh_connection, 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context: 'for a host alias' suggests you use this when you need connection details for a known SSH alias. However, it provides no explicit guidance on when not to use it or how it compares to sibling tools like list_ssh_hosts or test_ssh_connection. The usage is implied rather than stated.

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

list_ssh_hostsA

List all host aliases from the SSH config.

Returns:
    Newline-separated list of configured hosts.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses that this is a read-only listing operation and specifies the return format as a newline-separated list. It does not mention edge cases (e.g., missing config file) or config path, but for a simple list operation this is reasonably transparent.

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 appropriately concise, with a clear front-loaded action statement and a separate return-format section. Every sentence adds value and there is no filler.

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 (zero parameters, no annotations, simple return), the description covers operation and output adequately. It could mention behavior when no hosts are configured or when the SSH config is missing, but this is not critical given the low 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?

The tool has zero parameters, so the baseline is 4. The description adds meaning by specifying the data source ('SSH config') and the output format, which is sufficient for a parameterless tool.

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 resource ('host aliases from the SSH config'), making the action and scope unambiguous. It clearly distinguishes from siblings like execute_ssh_command, get_host_info, and test_ssh_connection.

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 usage for discovering available host aliases, but gives no explicit when-to-use or when-not-to-use guidance, nor any reference to alternatives. Sibling tool names provide context, but the description itself leaves this to inference.

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

test_ssh_connectionA

Test SSH connectivity to a host without running a command.

Args:
    hostname: Host alias from SSH config.
    timeout: Connection timeout, seconds (default 30, max 300).

Returns:
    Whether the connection succeeded or failed.

ParametersJSON Schema

Name	Required	Description	Default
`timeout`	No
`hostname`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the key behavioral trait that no command is run and that the return value indicates success/failure, but it omits details about error behavior (e.g., unknown host alias, unreachable host) and whether any side effects exist.

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 compact and well-structured with a one-sentence summary, clearly labeled Args, and Returns. Every line earns its place without fluff or repetition.

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 tool is simple with only two parameters, and the description covers purpose, parameters, and return behavior. It is complete enough for an agent to invoke correctly, though it could mention behavior on failure (e.g., exception vs. false return) for even stronger guidance.

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 description coverage is 0%, so the description fully compensates. It explains that hostname is an 'alias from SSH config' and timeout is 'connection timeout, seconds (default 30, max 300)', adding crucial meaning not present in 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?

The description clearly states the tool's purpose with a specific verb ('Test') and resource ('SSH connectivity to a host'). It also distinguishes itself from the sibling tool execute_ssh_command by adding 'without running a command'.

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 phrase 'without running a command' provides clear context for when to use this tool versus execute_ssh_command. It does not explicitly mention alternatives like list_ssh_hosts or get_host_info, but the core use case is well implied.

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.

4 tool updatesv0.1.3Aug 1, 2026
- First observedexecute_ssh_command
- First observedget_host_info
- First observedlist_ssh_hosts
- First observedtest_ssh_connection

Install Server

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

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing hosts, fetching host details, testing connectivity, and executing commands. There is no overlap between them.

Naming Consistency5/5

All tool names follow the consistent verb_noun pattern with underscores: execute_ssh_command, list_ssh_hosts, get_host_info, test_ssh_connection. The naming is uniform and predictable.

Tool Count5/5

Four tools is a well-scoped set for an SSH server, covering the essential operations without unnecessary bloat. Each tool earns its place.

Completeness4/5

Core SSH workflows are covered: discover hosts, inspect config, test connectivity, and run commands. Minor gaps exist such as file transfer or session management, but the set is functional for its stated purpose.

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

termalin-web A
in.termal
Run commands and read/write files on your servers over Termalin's keyless tunnels (hosted MCP).
Shell Access File Systems
81
Google GKE A
com.googleapis.container
The Google GKE MCP server is a managed Model Context Protocol server that provides AI applications with tools to manage Google Kubernetes Engine (GKE) clusters and Kubernetes resources. It exposes a structured, discoverable interface that allows AI agents to interact with GKE and Kubernetes APIs, enabling them to inspect cluster configurations, retrieve Kubernetes resource YAMLs, monitor operations like cluster upgrades, diagnose issues, and optimize costs—all without needing to parse text output or use complex kubectl commands.
Cloud Platforms Virtualization Observability
232
mcp AOAuth
io.github.Massed-Compute
Massed Compute MCP — GPU inventory, VM lifecycle, billing, SSH keys, and setup recipes.
Cloud Platforms Virtualization
2
Google Compute Engine A
com.googleapis.compute
The Google Compute Engine MCP server is a fully-managed Model Context Protocol server that provides tools to manage Google Compute Engine resources through AI agents. It enables capabilities including instance management (creating, starting, stopping, resetting, listing), disk management, handling instance templates and group managers, viewing machine and accelerator types, managing images, and accessing reservation and commitment information. The server operates as a zero-deployment, enterprise-grade endpoint at https://compute.googleapis.com/mcp with built-in IAM-based security.
Cloud Platforms Virtualization Agent Orchestration
292

Related MCP Servers

acp-mcp
Shell Access Command Line
prmichaelsen
A
license
Not graded
quality
D
maintenance
MCP server for remote machine operations via SSH, providing a single tool to execute any shell command on remote machines with real-time progress streaming.
Updated 6 months ago (2026-02-24 01:01 UTC)
22
MIT
MCP SSH Manager
Shell Access Command Line Networking & Infrastructure
bysonte
A
license
A
quality
B
maintenance
MCP server for managing remote servers via SSH, enabling command execution, file transfer, rsync, tunnels, health checks, backups, and database operations.
Updated 2 months ago (2026-07-14 00:42 UTC)
17
2,117
1
MIT
ssh-mcp-pro
Shell Access Command Line
oaslananka
A
license
B
quality
A
maintenance
ssh-mcp-pro is a secure Model Context Protocol (MCP) server for SSH automation, enabling clients to open SSH sessions, run commands, manage files, transfer artifacts, create tunnels, and perform package/service operations under policy control.
Updated a month ago (2026-07-24 18:24 UTC)
46
61
2
MIT
open-ssh-mcp
Shell Access Command Line
cjp1016
A
license
Not graded
quality
C
maintenance
An MCP server for managing remote SSH servers, enabling AI agents to execute commands, transfer files, and perform deployment operations securely.
Updated a month ago (2026-07-24 14:33 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/sondt2709/ssh-mcp-py'

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