Which integrations are available for this server?

Enables GitHub Copilot CLI to perform VS Code operations such as file management and extension control. Enables Google Gemini CLI to perform VS Code operations such as file management and extension control.

How do I use vscode-mcp-server?

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., "@vscode-mcp-server List all installed extensions" 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.

vscode-mcp-server

by chaworld

Overview Schema Related Servers Score Discussions

Python

Local

VS Code MCP Server

GitHub Python MCP

一個可攜式的 Model Context Protocol (MCP) 伺服器,讓 AI 助手能夠操作 VS Code - 支援檔案管理、擴充套件控制和工作區自動化。

English | 繁體中文

繁體中文

🌟 特色

檔案操作: 讀取、寫入、建立、刪除檔案和目錄
擴充套件管理: 安裝、列出、啟用/停用 VS Code 擴充套件
可攜式設計: 使用 uvx/pipx 全域執行,無需絕對路徑
多客戶端支援:
- ✅ GitHub Copilot CLI
- ✅ Claude Desktop
- ✅ Google Gemini CLI
- ✅ 任何支援 MCP 的客戶端

📦 安裝

方法 1: 使用 uvx (推薦)

# 從專案目錄
git clone https://github.com/chaworld/vscode-mcp-server.git
cd vscode-mcp-server
uvx --from . vscode-mcp-server

方法 2: 全域安裝

# 使用 uv
git clone https://github.com/chaworld/vscode-mcp-server.git
cd vscode-mcp-server
uv tool install --editable .

# 或使用 pipx
pipx install --editable .

# 之後可直接執行
vscode-mcp-server

方法 3: 開發模式

git clone https://github.com/chaworld/vscode-mcp-server.git
cd vscode-mcp-server
uv pip install -e .
python -m vscode_mcp_server

🔧 客戶端配置

GitHub Copilot CLI

{
  "mcpServers": {
    "vscode_local": {
      "command": "uvx",
      "args": ["--from", "/path/to/vscode-mcp-server", "vscode-mcp-server"]
    }
  }
}

Claude Desktop

檔案位置: %APPDATA%\Claude\claude_desktop_config.json (Windows)

{
  "mcpServers": {
    "vscode_local": {
      "command": "uvx",
      "args": ["--from", "/path/to/vscode-mcp-server", "vscode-mcp-server"]
    }
  }
}

Google Gemini CLI

{
  "name": "vscode-mcp",
  "version": "0.1.0",
  "mcpServers": {
    "vscode_local": {
      "command": "uvx",
      "args": ["--from", "/path/to/vscode-mcp-server", "vscode-mcp-server"]
    }
  }
}

🛠️ 可用工具

read_file - 讀取檔案內容
write_file - 寫入檔案內容
create_directory - 建立目錄
list_directory - 列出目錄內容
install_extension - 安裝 VS Code 擴充套件
list_extensions - 列出已安裝的擴充套件

📖 文件

可攜式設定指南 - 詳細的可攜式安裝說明
全域安裝指南 - 5 種全域安裝方法比較
Claude Desktop 設定 - Claude Desktop 完整設定
Copilot CLI 設定 - GitHub Copilot CLI 設定
檔案結構說明 - 專案結構文件

🧪 測試

# 安裝開發依賴
uv pip install -e .

# 執行測試
pytest

# 執行測試並顯示詳細輸出
pytest -v

🤝 貢獻

歡迎提交 Issues 和 Pull Requests!

📄 授權

MIT License

Related MCP server: Code MCP Server

English

🌟 Features

File Operations: Read, write, create, delete files and directories
Extension Management: Install, list, enable/disable VS Code extensions
Portable Design: Run globally with uvx/pipx, no absolute paths needed
Multi-Client Support:
- ✅ GitHub Copilot CLI
- ✅ Claude Desktop
- ✅ Google Gemini CLI
- ✅ Any MCP-compatible client

📦 Installation

Method 1: Using uvx (Recommended)

# From project directory
git clone https://github.com/chaworld/vscode-mcp-server.git
cd vscode-mcp-server
uvx --from . vscode-mcp-server

Method 2: Global Installation

# Using uv
git clone https://github.com/chaworld/vscode-mcp-server.git
cd vscode-mcp-server
uv tool install --editable .

# Or using pipx
pipx install --editable .

# Then run directly
vscode-mcp-server

Method 3: Development Mode

git clone https://github.com/chaworld/vscode-mcp-server.git
cd vscode-mcp-server
uv pip install -e .
python -m vscode_mcp_server

🔧 Client Configuration

GitHub Copilot CLI

{
  "mcpServers": {
    "vscode_local": {
      "command": "uvx",
      "args": ["--from", "/path/to/vscode-mcp-server", "vscode-mcp-server"]
    }
  }
}

Claude Desktop

File location: %APPDATA%\Claude\claude_desktop_config.json (Windows)

{
  "mcpServers": {
    "vscode_local": {
      "command": "uvx",
      "args": ["--from", "/path/to/vscode-mcp-server", "vscode-mcp-server"]
    }
  }
}

Google Gemini CLI

{
  "name": "vscode-mcp",
  "version": "0.1.0",
  "mcpServers": {
    "vscode_local": {
      "command": "uvx",
      "args": ["--from", "/path/to/vscode-mcp-server", "vscode-mcp-server"]
    }
  }
}

🛠️ Available Tools

read_file - Read file contents
write_file - Write file contents
create_directory - Create directories
list_directory - List directory contents
install_extension - Install VS Code extensions
list_extensions - List installed extensions

📖 Documentation

Portable Setup Guide - Detailed portable installation guide
Global Install Guide - Comparison of 5 global installation methods
Claude Desktop Setup - Complete Claude Desktop configuration
Copilot CLI Setup - GitHub Copilot CLI configuration
File Structure - Project structure documentation

🧪 Testing

# Install dev dependencies
uv pip install -e .

# Run tests
pytest

# Run tests with verbose output
pytest -v

🤝 Contributing

Issues and Pull Requests are welcome!

📄 License

MIT License

🔗 Links

Available Tools

6 tools

create_fileA

Creates a new file with the given content. Fails if the file already exists.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`content`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description must disclose behavior on its own. It discloses the primary side effect (file creation) and a key edge case (fails if exists), but omits other behavioral traits such as whether parent directories are created, permission requirements, or error handling on partial writes.

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?

Two concise sentences with no filler or repetition. The action verb is front-loaded, and every word contributes meaning.

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 two-parameter file creation tool with an output schema, the description covers the core purpose and a key failure mode. It is slightly incomplete regarding directory creation or permissions, but these are not critical for basic file creation and the output schema likely covers return values.

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

Parameters2/5

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

The schema description coverage is 0%, so the description must compensate for parameter meaning. It only indirectly references 'content' and does not explain 'path' format or any constraints. Though parameter names are self-explanatory, the description adds minimal semantic value 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?

The description uses the specific verb 'Creates' and names the resource ('a new file') with content. It clearly distinguishes itself from the sibling tool 'overwrite_file' by stating it fails if the file already exists, making the purpose unmistakable.

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 failure condition ('Fails if the file already exists') provides implicit guidance to use this tool only for new files and to consider the sibling tool for overwriting. However, it does not explicitly name 'overwrite_file' as an alternative, so it lacks a fully explicit when-not-to-use statement.

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

install_extensionB

Installs a VSCode extension by its ID.

ParametersJSON Schema

Name	Required	Description	Default
`extension_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 carries the full burden of behavioral disclosure, but it only states the basic action. It does not disclose idempotency, network requirements, version resolution behavior, or potential side effects, which are important for an installation operation.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no redundancy. Every word contributes to conveying the basic purpose.

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

Completeness2/5

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

Despite having an output schema, the description leaves out essential context for a tool with no annotations: success/failure behavior, whether installation is idempotent, potential network dependencies, and how to obtain the extension ID. The description is too thin for a complete tool contract.

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

Parameters2/5

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

The schema has no description for extension_id, and the description's phrase 'by its ID' adds only minimal value beyond what the parameter name already implies. It fails to clarify the expected format, such as publisher.extension naming convention.

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 a specific verb ('installs') plus the resource ('VSCode extension') and the key scope ('by its ID'). It naturally distinguishes itself from sibling tools like uninstall_extension and list_extensions.

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 about when to use this tool versus alternatives such as uninstall_extension or list_extensions. There is also no mention of prerequisites like needing the exact extension ID or checking existing installations.

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

list_extensionsA

Lists all installed VSCode extensions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description must disclose behavioral traits itself. The verb 'Lists' implies a read-only operation, but the description does not explicitly confirm non-destructiveness, required environment, or output characteristics beyond the listing. It is minimally transparent but adequate for a simple listing tool.

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

Conciseness5/5

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

The description is a single sentence with no wasted words. It states the action and resource clearly, making it perfectly concise and appropriately sized.

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?

For a tool with no parameters and an output schema that presumably defines the return structure, the description is complete enough. It clearly indicates what the tool does, and the sibling tool relationship provides additional context for when to use it.

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, and the schema is empty with 100% coverage. The description correctly adds no parameter explanation that would be redundant. The baseline for zero parameters is 4, and the description does not need to elaborate.

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 the specific verb 'Lists' and clearly identifies the resource as 'all installed VSCode extensions.' This distinguishes it from sibling tools like install_extension and uninstall_extension, which perform mutations, and read_file, which accesses file content.

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 does not provide any explicit guidance on when to use this tool versus alternatives. It simply states what it does, leaving the usage context to be inferred. No exclusions or alternative tools are mentioned.

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

overwrite_fileA

Overwrites an existing file or creates a new one with the given content.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`content`	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 of behavioral disclosure. It explicitly states that the tool overwrites existing content, which is critical destructive behavior. However, it does not mention other important traits such as whether it creates parent directories, preserves permissions, or handles errors, making it minimally transparent but not richly detailed.

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, concise sentence that is front-loaded with the main action. It contains no wasted words and effectively communicates the tool's purpose and basic behavior.

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 two string parameters and an output schema, so the description does not need to explain return values. It covers the core behavior (overwrite or create) sufficiently. However, it could be more complete by mentioning the distinction from create_file or potential error conditions, but for a tool of this simplicity it is adequate.

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 schema has 0% description coverage, so the description must compensate for parameter meaning. The description mentions 'given content' which clearly maps to the 'content' parameter, and 'existing file' implies the 'path' parameter. However, it does not elaborate on path format, encoding, or any constraints, providing only basic clarity beyond the raw 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 action with a specific verb ('overwrites') and resource ('file'), and also indicates it can create a new file. This distinguishes it from sibling tools like create_file because it explicitly covers both overwriting existing files and creating new ones.

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 provides clear context on when to use the tool: when you need to overwrite an existing file or create a new one. However, it does not explicitly mention alternatives or when not to use it (e.g., when you want to create a file without risking overwriting an existing one, use create_file instead). This lacks explicit exclusion guidance.

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

read_fileB

Reads and returns the content of a file.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation but does not disclose potential errors, encoding, permissions, or side effects. The description adds little beyond the tool's name.

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?

A single sentence, front-loaded with the action, with no wasted words. It is appropriately concise and easy to parse.

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 an output schema exists and the tool is simple, the description covers the basic purpose but lacks usage and parameter context that would make it fully complete. It is minimally adequate but leaves gaps for an agent selecting among sibling tools.

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

Parameters2/5

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

The schema has a single 'path' parameter with no description, and the tool description does not elaborate on path format, required permissions, or accepted file types. Schema description coverage is 0%, so the description fails to compensate for the missing detail.

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 ('Reads') and resource ('file content'), clearly distinguishing it from sibling write-tools like create_file and overwrite_file. It is unambiguous about what the tool does.

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 regarding when to use this tool versus alternatives. The description only states what the tool does, leaving the agent to infer context from the name.

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

uninstall_extensionA

Uninstalls a VSCode extension by its ID.

ParametersJSON Schema

Name	Required	Description	Default
`extension_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/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 of behavioral disclosure. It does not mention side effects, permission requirements, whether the extension must already be installed, or the outcome of the operation beyond the action itself. For a destructive tool, this is a notable gap.

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

Conciseness5/5

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

The description is a single sentence that is front-loaded and contains no wasted words. It efficiently conveys the core action and parameter.

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?

The tool is simple with one parameter and a clear action, so the description covers the basic intent. However, since it is a destructive operation with no annotations or output schema information, additional context such as what happens on success, error cases, or installation prerequisites would make it more complete. The current description is minimally acceptable.

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 schema only provides the parameter name 'extension_id' with no description. The description adds that the extension is identified by its ID, which partially clarifies the parameter's semantics, but it does not define the expected format (e.g., 'publisher.name'). With 0% schema coverage, the description provides minimal but useful compensation.

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: 'Uninstalls a VSCode extension by its ID.' The verb is specific, the resource is identified, and the input mechanism is noted, distinguishing it from sibling tools like install_extension and list_extensions.

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 whenever an extension needs to be removed, but it does not explicitly state when to use it over alternatives or provide any context on prerequisites. No alternatives are mentioned, so the guidance is implied rather than explicit.

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.

6 tool updatesv0.1.0Aug 2, 2026
- First observedcreate_file
- First observedinstall_extension
- First observedlist_extensions
- First observedoverwrite_file
- First observedread_file
- First observeduninstall_extension

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct action on a specific resource: file operations (create, overwrite, read) and extension operations (install, uninstall, list). The descriptions clearly differentiate create_file from overwrite_file, so there is no ambiguity.

Naming Consistency4/5

Tool names follow a consistent verb_noun pattern (create_file, read_file, install_extension, list_extensions). There is a minor inconsistency with 'extension' singular in install/uninstall and 'extensions' plural in list, but the overall pattern is predictable.

Tool Count5/5

With 6 tools, the set is well-scoped and each tool earns its place. It covers two distinct functional areas without redundancy, fitting comfortably within the ideal 3-15 range.

Completeness4/5

The domain is a VSCode-focused server covering file and extension management. File operations include create, read, and update (via overwrite) but lack a delete operation. Extension management is complete with list, install, and uninstall. This is a minor gap that agents can work around.

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

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-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
KodyOAuth
io.github.kentcdodds
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
Developer Tools Code Execution Command Line
2514
docs
dev.continue
An MCP server for docs.continue.dev
Documentation Access Developer Tools Search
2

Related MCP Servers

vscode-mcp-server
Developer Tools Code Execution Command Line
juehang
A
license
A
quality
D
maintenance
MCP server to expose VS Code editing features to an LLM for AI coding
Updated 8 months ago (2026-01-07 15:40 UTC)
9
98
391
MIT
Code MCP Server
Developer Tools File Systems Version Control
agentics-ai
A
license
C
quality
D
maintenance
An experimental MCP server that enables AI assistants to interact with VS Code workspaces through file operations, code execution, and Git management. It also provides tools for Docker integration, project scaffolding, and secure command execution using project-specific configurations.
Updated 7 months ago (2026-01-26 09:53 UTC)
76
32
3
MIT
vscode-mcp
Developer Tools File Systems Shell Access
KloutDevs
F
license
A
quality
D
maintenance
An MCP server that gives Claude IDE capabilities inside VS Code and Cursor, enabling file operations, shell commands, and workspace management via natural language.
Updated 4 months ago (2026-05-08 08:31 UTC)
12
-
VS Claude
Developer Tools Version Control
badlogic
A
license
Not graded
quality
F
maintenance
MCP server that integrates with VS Code to enable file operations, git diffs, and line highlighting via MCP clients like Claude.
Updated a year ago (2025-08-11 19:17 UTC)
41
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/chaworld/vscode-mcp-server'

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