How do I use ghostty-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., "@ghostty-mcp change theme to dracula" 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.

ghostty-mcp

by GitJuhb

Overview Schema Related Servers Score Discussions

JavaScript

Local

Ghostty MCP Server

A Model Context Protocol (MCP) server for Ghostty, the fast, native, feature-rich terminal emulator. This server enables AI assistants like Claude to interact with and control Ghostty through a standardized interface.

Features

Configuration Management: Get and set Ghostty configuration values
Theme Control: Switch between themes and manage light/dark modes
Keybinding Management: Add, modify, or remove custom keybindings
Command Execution: Run commands directly in Ghostty
Window Management: Create, split, and manage Ghostty windows
Live Reload: Reload configuration without restarting
Discovery: List available themes, keybindings, and configurations

Related MCP server: Ryan's Tmux MCP Server

Installation

Clone this repository:

git clone https://github.com/yourusername/ghostty-mcp.git
cd ghostty-mcp

Install dependencies:

npm install

Build the project:

npm run build

Configuration

Claude Desktop Configuration

Add the following to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Linux: ~/.config/claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

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

Replace /path/to/ghostty-mcp with the actual path to your cloned repository.

Available Tools

`ghostty_config`

Get or set Ghostty configuration values.

Parameters:

key (string, required): Configuration key (e.g., "font-size", "theme", "window-decoration")
value (string, optional): Configuration value. If not provided, returns current value

Examples:

// Get current font size
ghostty_config(key: "font-size")

// Set font size to 14
ghostty_config(key: "font-size", value: "14")

`ghostty_theme`

Change Ghostty theme.

Parameters:

theme (string, required): Theme name to apply
mode (string, optional): Theme mode - "light", "dark", or "auto"

Examples:

// Apply dracula theme
ghostty_theme(theme: "dracula")

// Set github_light for light mode
ghostty_theme(theme: "github_light", mode: "light")

`ghostty_keybind`

Manage Ghostty keybindings.

Parameters:

action (string, required): Action to bind (e.g., "copy", "paste", "new_tab")
key (string, required): Key combination (e.g., "cmd+c", "ctrl+shift+t")
remove (boolean, optional): If true, removes the keybinding

Examples:

// Add keybinding for new tab
ghostty_keybind(action: "new_tab", key: "cmd+t")

// Remove keybinding
ghostty_keybind(action: "new_tab", remove: true)

`ghostty_command`

Execute commands in Ghostty.

Parameters:

command (string, required): Command to execute
wait (boolean, optional): Whether to wait for command completion

Examples:

// Run a command
ghostty_command(command: "ls -la")

// Run and wait for completion
ghostty_command(command: "npm install", wait: true)

`ghostty_window`

Manage Ghostty windows and splits.

Parameters:

action (string, required): One of:
- "new": Create new window
- "close": Close current window
- "split-horizontal": Split horizontally
- "split-vertical": Split vertically
- "focus-next": Focus next pane
- "focus-previous": Focus previous pane
config (object, optional): Additional window configuration

Examples:

// Create new window
ghostty_window(action: "new")

// Split vertically
ghostty_window(action: "split-vertical")

`ghostty_reload`

Reload Ghostty configuration.

Parameters:

scope (string, optional): What to reload - "config", "theme", or "all" (default: "all")

Examples:

// Reload all configuration
ghostty_reload()

// Reload only theme
ghostty_reload(scope: "theme")

`ghostty_list`

List available themes, keybindings, or configuration.

Parameters:

type (string, required): What to list - "themes", "keybindings", or "config"
filter (string, optional): Optional filter for results

Examples:

// List all themes
ghostty_list(type: "themes")

// List keybindings containing "tab"
ghostty_list(type: "keybindings", filter: "tab")

Development

Running in Development Mode

npm run dev

Building

npm run build

Testing with MCP Inspector

You can test this server using the MCP Inspector:

npx @modelcontextprotocol/inspector node dist/index.js

Requirements

Node.js 18 or later
Ghostty terminal emulator installed
Access to Ghostty CLI commands

Platform Support

This MCP server supports:

macOS
Linux
Windows (with appropriate path adjustments)

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

License

MIT License - see LICENSE file for details

Acknowledgments

Ghostty by Mitchell Hashimoto
Model Context Protocol by Anthropic

Available Tools

7 tools

ghostty_commandC

Execute commands in Ghostty

ParametersJSON Schema

Name	Required	Description	Default
`wait`	No	Whether to wait for command completion
`command`	Yes	Command to execute in Ghostty

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 must disclose behavioral traits. It merely says 'Execute commands' without specifying whether commands are blocking, require authentication, or have side effects. This is insufficient for safe invocation.

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 extremely concise at three words, front-loading the core action. While efficient, it slightly underspecifies the scope (e.g., what commands are supported), but remains clear.

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 two parameters and no output schema, the description should explain return values, error behavior, or effect. It does none, leaving the agent guessing about 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 description does not need to add param details. However, the description does not elaborate on the 'wait' parameter's purpose beyond the schema. Baseline 3 is appropriate.

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 'Execute' and the resource 'commands in Ghostty', which unambiguously indicates the tool's function. It distinguishes itself from siblings like ghostty_config or ghostty_theme by focusing on executing commands.

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. It does not mention any prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.

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

ghostty_configC

Get or set Ghostty configuration values

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes	Configuration key (e.g., "font-size", "theme", "window-decoration")
`value`	No	Configuration value. If not provided, returns current value

TDQS

C2.9/5.0

Behavior2/5

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

The description only says 'get or set' with no disclosure of side effects, whether changes persist, what triggers a reload, or any permissions needed. Since no annotations are provided, the description carries the full burden.

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 sentence, no fluff, directly states purpose. Could include more detail but is not verbose.

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 return value description (no output schema), no behavioral context for a mutation tool, and no integration with sibling tools. Incomplete for an agent to use effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters have descriptions in the schema. The description adds no extra meaning beyond what the schema provides, so baseline of 3 is appropriate.

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 tool gets or sets Ghostty configuration values. The verb-resource pair is specific, but it does not distinguish from sibling tools like ghostty_list or ghostty_command.

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 siblings. There is no mention of prerequisites, when to get vs set, or how it relates to ghostty_reload or ghostty_list.

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

ghostty_keybindC

Manage Ghostty keybindings

ParametersJSON Schema

Name	Required	Description
`key`	Yes	Key combination (e.g., "cmd+c", "ctrl+shift+t")
`action`	Yes	Action to bind (e.g., "copy", "paste", "new_tab")
`remove`	No	If true, removes the keybinding

TDQS

C2.4/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 the full burden. It does not disclose behavioral traits such as whether adding a keybinding overwrites existing ones, requires reloading config, or any side effects. The word 'manage' implies mutation but lacks specifics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single phrase, which is concise but under-specified. It does not effectively convey the tool's functionality in a structured manner.

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

Completeness2/5

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

Given no output schema and simple parameters, the description should include more behavioral context such as success/error outcomes or relationship to ghostty_reload. It is incomplete for effective tool selection.

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%; all parameters have descriptions. The description adds no additional meaning beyond what the schema already provides. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states 'Manage Ghostty keybindings', which is a verb+resource combination. However, 'manage' is generic and doesn't specify create, modify, or delete operations. It is distinguishable from sibling tools like ghostty_command by context, but the description itself is vague.

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 like ghostty_config or ghostty_command. No when-to-use or when-not-to-use information is provided.

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

ghostty_listB

List available themes, keybindings, or configuration

ParametersJSON Schema

Name	Required	Description	Default
`type`	Yes	What to list
`filter`	No	Optional filter for results

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states what it lists but does not reveal that it is read-only, what the output format is, or any other behavioral constraints.

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 extremely concise with no waste. However, it could be slightly expanded to include usage context 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?

Given the simplicity of the tool and absence of output schema, the description is minimal. It does not explain the return format, pagination, or how it integrates with sibling tools like ghostty_theme or ghostty_config, leaving the agent underinformed.

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 baseline is 3. The description 'List available themes, keybindings, or configuration' adds no semantic value beyond the schema's type enum and filter description.

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 lists 'available themes, keybindings, or configuration', which is a specific verb+resource combination. This distinguishes it from sibling tools like ghostty_theme or ghostty_config that likely handle setting or getting individual items.

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 is provided on when to use this tool vs alternatives, nor any exclusions or prerequisites. For example, it could mention that this is useful for discovering available options before using ghostty_theme or ghostty_config.

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

ghostty_reloadC

Reload Ghostty configuration

ParametersJSON Schema

Name	Required	Description	Default
`scope`	No	What to reload (defaults to "all")

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so the description must disclose behavioral traits. It fails to mention that this is a mutation operation that may reset terminal state, require certain permissions, or that it is safe (reloads without restart). The bare description provides minimal insight.

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 sentence, front-loaded with the action. It is efficient but at the expense of completeness. Could include more useful information like scope options in the same space 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?

Given the simple tool with one optional param and no output schema, the description lacks completeness. It does not state return values, side effects, or prerequisites (e.g., configuration must exist). A reload tool typically provides feedback, but nothing is mentioned.

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 a description for the single parameter, so baseline is 3. The description adds no extra meaning beyond the schema; it does not elaborate on the effective difference between 'config', 'theme', and 'all'.

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 uses specific verb+resource 'Reload Ghostty configuration', clearly indicating the tool's action. However, it does not distinguish from siblings like ghostty_config or ghostty_command, missing context on what exactly is reloaded (e.g., from disk vs memory).

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. For example, it does not explain that this should be used after modifying configuration files to apply changes, or when ghostty_config might be preferred for viewing current settings.

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

ghostty_themeB

Change Ghostty theme

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	Theme mode (light/dark/auto)
`theme`	Yes	Theme name to apply

TDQS

B3.2/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 disclose behavioral traits. It only states 'change' but doesn't mention persistence, restart requirements, or side effects. The description adds minimal behavioral context beyond what the schema implies.

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?

A single, concise sentence that is front-loaded and clear. It could be slightly more informative without becoming verbose, but it wastes no words.

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?

For a simple tool with full schema coverage but no annotations or output schema, the description is adequate but lacks behavioral details and usage context. It meets minimal viability.

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 both parameters (theme, mode). The tool description does not add additional meaning beyond the schema, so a baseline 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 'Change Ghostty theme' uses a specific verb and resource, clearly stating the tool's function. It distinguishes from sibling tools like ghostty_config (broader config changes) and ghostty_window (window management).

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 provided on when to use this tool versus alternatives. No mention of prerequisites, when-not-to-use, or related tools like ghostty_config for other settings.

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

ghostty_windowB

Manage Ghostty windows and splits

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes	Window management action
`config`	No	Additional window configuration

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided; description only states 'Manage...' without detailing behavioral traits like side effects, prerequisites, or limits. Fails to carry the burden for a tool with no extra metadata.

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 sentence is concise and front-loaded, but slightly vague. No unnecessary content, though it could be more informative without losing brevity.

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?

For a tool with 6 actions, a nested config object (open-ended), and no output schema, the description is too minimal. It does not explain scope, return values, or config usage, leaving 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 descriptions cover both parameters (action and config) with baseline clarity. The description adds no extra meaning, such as allowed config keys or action specifics, so it meets the baseline for 100% schema coverage.

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 'Manage Ghostty windows and splits' clearly indicates the tool's domain but does not distinguish it from siblings like ghostty_list (which may also list windows) or ghostty_command. The schema's action enum adds specificity.

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?

Usage is implied by the tool name and schema actions (new, close, split, focus). No explicit guidance on when to use vs alternatives, such as ghostty_command or ghostty_list.

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.

7 tool updatesv1.0.0Jun 28, 2026
- First observedghostty_command
- First observedghostty_config
- First observedghostty_keybind
- First observedghostty_list
- First observedghostty_reload
- First observedghostty_theme
- First observedghostty_window

Install Server

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

TDQS

B3.3/5.0

Disambiguation5/5

Each tool targets a distinct aspect of Ghostty (commands, config, keybindings, listing, reload, theme, windows) with no overlap.

Naming Consistency5/5

All tools follow a consistent ghostty_<verb/noun> snake_case pattern, making them predictable.

Tool Count5/5

7 tools is a well-scoped set covering the major management areas of Ghostty without being excessive.

Completeness4/5

Covers core operations like command execution, configuration, keybindings, theming, and window management, though advanced features like fonts or profiles are absent.

Maintenance

ActivityInactive

ResponsivenessSyncing

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

slima
io.github.slima-ai
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
Developer Tools
21
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp-server
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
gainium-mcp
io.gainium
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
Cryptocurrency Finance
22

Related MCP Servers

interminal
Shell Access Command Line
QiuwenZheng
A
license
A
quality
A
maintenance
MCP server for SSH and local terminal access. Supports interactive commands, long-running processes, and TUI apps like tmux/zellij
Updated 2 months ago (2026-07-13 04:46 UTC)
6
3
MIT
Ryan's Tmux MCP Server
Command Line Shell Access
ryancnelson
F
license
Not graded
quality
D
maintenance
MCP server for tmux operations that provides comprehensive control over tmux sessions, windows, and panes.
Updated a year ago (2025-09-04 21:50 UTC)
1
-
MCPretentious
Command Line Shell Access
oetiker
A
license
A
quality
D
maintenance
MCP server for terminal control enabling AI to manage terminal sessions via iTerm2 or tmux, with features like screen reading, keyboard/mouse input, and background execution.
Updated 7 months ago (2026-02-14 11:59 UTC)
9
19
21
MIT
iterm2-agent
Shell Access Command Line
xjthy001
F
license
Not graded
quality
D
maintenance
MCP server for controlling iTerm2 terminal sessions, enabling screen reading, command execution, keystroke sending, and session management through natural language.
Updated 7 months ago (2026-02-13 03:54 UTC)
1
-

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/GitJuhb/ghostty-mcp'

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