MCP File Editor Server

by pwilkin

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity. For example, 'delete_from_file' removes content between lines, 'insert_into_file' adds content at a line, 'replace_in_file' handles regex-based replacements, and 'replace_lines_in_file' targets specific line ranges, making them easily distinguishable. The search tools ('search_directory' vs. 'search_file') also serve different scopes without overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case, such as 'delete_from_file', 'insert_into_file', and 'search_directory'. This uniformity makes the tool set predictable and easy to understand, with no deviations in naming conventions across the eight tools.
Tool Count5/5
With 8 tools, the server is well-scoped for file editing operations, covering essential actions like reading, writing, deleting, inserting, replacing, and searching. Each tool earns its place by addressing specific needs in file manipulation, avoiding both bloat and insufficiency for the domain.
Completeness5/5
The tool set provides complete coverage for file editing, including CRUD-like operations (read, insert, delete, replace) and search functionalities at both file and directory levels. There are no obvious gaps, as all core workflows for editing and managing files are supported without dead ends.
Average 3.2/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action without disclosing critical behavioral traits. It doesn't mention whether the deletion is permanent, requires file permissions, handles errors (e.g., invalid line numbers), or affects file structure. This leaves significant gaps for a destructive 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, clear sentence that efficiently conveys the core functionality without unnecessary details. It is front-loaded and wastes no words, making it easy to understand at a glance.
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 complexity of a destructive file operation with no annotations and no output schema, the description is inadequate. It lacks information on outcomes (e.g., success/failure indicators), error handling, or safety considerations, leaving the agent under-informed for proper tool 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?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal value by implying line-based deletion but doesn't provide additional context beyond what the schema already covers, such as how 'line_start_contents' verification works or edge cases.
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 action ('Delete content') and resource ('from a file'), specifying the scope ('between specified line numbers'). It distinguishes from siblings like 'replace_in_file' or 'insert_into_file' by focusing on deletion rather than modification or addition, though it doesn't explicitly name alternatives.
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 versus alternatives like 'replace_in_file' or 'replace_lines_in_file' for similar line-based operations. The description implies usage for deleting content between lines but lacks context on prerequisites, exclusions, or specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the action but doesn't mention important behavioral aspects like whether it requires specific permissions, how it handles non-existent directories, what the return format looks like (e.g., list structure, pagination), or any rate limits. This leaves significant gaps for an agent to understand the tool's behavior.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded with the core functionality, making it easy for an agent to parse quickly.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., format, structure), error conditions, or behavioral constraints. Given the complexity of file system operations and the lack of structured data, more context is needed for an agent to use this tool 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?
The schema description coverage is 100%, with the single parameter 'directory_path' clearly documented as 'Absolute path to the directory to list'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage but doesn't add extra value.
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 ('List') and resource ('all files and subdirectories') with the scope ('in a given directory'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_directory' which might also list files but with filtering capabilities.
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 like 'search_directory' or 'search_file'. It mentions the directory scope but doesn't indicate whether this is for unfiltered listing versus searching, or any prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the core action but omits critical details: whether the operation is destructive (likely yes, but not confirmed), what happens if line numbers are invalid, how 'line_start_contents' verification works, if changes are atomic or reversible, or what the tool returns. This is a significant gap for a file mutation 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, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and avoids redundancy, making it easy to parse quickly.
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 destructive file operation with 5 parameters and no annotations or output schema, the description is inadequate. It lacks information about behavioral traits (safety, error handling), output format, and differentiation from sibling tools. The agent would struggle to use this correctly without trial and error.
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 parameters are fully documented in the schema. The description adds no additional semantic context beyond implying line-based replacement, which is already clear from parameter names. It doesn't explain interactions between parameters (e.g., how 'line_start_contents' relates to 'line_start') or provide usage examples.
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 action ('Replace content') and target ('between specific line numbers in a file'), making the purpose understandable. It distinguishes from siblings like 'replace_in_file' (likely pattern-based) by specifying line-based replacement, but doesn't explicitly contrast with 'delete_from_file' or 'insert_into_file' which are also line-oriented operations.
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 like 'replace_in_file', 'delete_from_file', or 'insert_into_file'. It doesn't mention prerequisites (e.g., file must exist), error conditions, or typical use cases, leaving the agent to infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions 'search' but doesn't clarify whether this is read-only (likely, given the verb), what happens with large directories (performance implications), whether results are paginated, or what the output format looks like. The description provides basic intent but lacks critical operational details needed for effective tool invocation.
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, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized for a search tool and front-loads the essential information. Every word earns its place in this concise formulation.
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 7-parameter search tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns (e.g., match locations, context lines, file paths), how results are structured, or any limitations (e.g., maximum directory size, performance considerations). The agent lacks sufficient context to understand the tool's behavior and output.
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 all parameters are documented in the schema. The description adds minimal value beyond the schema by mentioning 'regex patterns' and 'all files in a directory,' which aligns with 'regexp' and 'directory_path' parameters. However, it doesn't explain parameter interactions or provide additional context beyond what's already in the structured schema descriptions.
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's purpose with a specific verb ('Search') and resource ('regex patterns across all files in a directory'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_file' (which likely searches within a single file) or 'list_files' (which lists files without pattern matching), leaving some ambiguity about when to choose this tool over those alternatives.
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 siblings like 'search_file' (for single-file searches) and 'list_files' (for file listing without regex), the agent must infer usage context from tool names alone. No explicit when/when-not statements or prerequisite information is included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic operation. It doesn't disclose whether this is a destructive mutation, what permissions are needed, how errors are handled, or what happens if the file doesn't exist. For a file modification tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for a tool with this level of complexity and gets straight to the point.
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 file mutation tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens on success/failure, return values, error conditions, or how it differs from similar tools. The agent would need to guess too much about this tool's 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 description coverage is 100%, so all parameters are documented in the schema. The description adds no parameter-specific information beyond what's already in the schema descriptions. The baseline of 3 is appropriate when the schema does all the parameter documentation work.
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 specific action ('Insert content'), target resource ('into a file'), and precise positioning ('at a specific line position'). It distinguishes from siblings like 'replace_in_file' or 'delete_from_file' by focusing on insertion rather than replacement or deletion.
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 like 'replace_in_file' or 'replace_lines_in_file'. It doesn't mention prerequisites, error conditions, or typical use cases, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic operation. It doesn't disclose critical behavioral traits like whether the operation is atomic, what happens on failure, if backups are created, or permission requirements. The description doesn't contradict annotations, but provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a tool with good schema documentation and gets straight to the point.
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 file modification tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens on success/failure, whether the operation is destructive, what permissions are needed, or what the return value might be. Given the complexity of file system operations, more context is needed.
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 schema fully documents all parameters. The description adds no additional parameter semantics beyond what's in the schema - it mentions 'regex pattern' and 'target string' which are already covered by schema descriptions for regex_source and target parameters.
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 specific action ('Replace all occurrences'), resource ('in a file'), and mechanism ('regex pattern with a target string'). It distinguishes from siblings like 'replace_lines_in_file' by focusing on pattern-based replacement rather than line-based operations.
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 regex-based file modifications but doesn't explicitly state when to use this versus alternatives like 'replace_lines_in_file' or 'delete_from_file'. No guidance on prerequisites, file permissions, or error conditions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks important behavioral details. It doesn't disclose whether the tool requires file read permissions, how it handles large files, error conditions (e.g., missing files), or output format specifics beyond 'matching lines with context'. The description is minimal but doesn't contradict annotations.
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, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes essential details about pattern type and output format. Every element earns its place.
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 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the output looks like (structure, format), error handling, performance considerations, or important constraints. The 100% schema coverage helps with parameters but doesn't compensate for missing behavioral context.
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 schema already documents all four parameters thoroughly. The description adds minimal value by mentioning 'context' (which relates to lines_before/lines_after) but doesn't provide additional syntax, format, or usage details beyond what the schema specifies.
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 specific action ('search for regex patterns'), target resource ('in a file'), and outcome ('show matching lines with context'). It distinguishes from siblings like list_files (listing), read_file (full content), and search_directory (directory-level search) by focusing on pattern matching within a single file.
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 regex-based file content searching, but doesn't explicitly state when to use this versus alternatives like search_directory (for directory-wide searches) or read_file (for full file content). No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions reading capabilities but fails to disclose critical traits such as file size limits, encoding handling, error conditions (e.g., if the file doesn't exist or is unreadable), or performance implications. This leaves significant gaps in understanding the tool's behavior beyond basic functionality.
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 the core purpose in the first sentence and adds useful detail in the second sentence without redundancy. It is appropriately sized with zero waste, making it easy to scan and understand quickly.
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 complexity of file operations and lack of annotations and output schema, the description is incomplete. It does not address error handling, return format (e.g., whether output is raw text or structured), or limitations (e.g., large files), which are crucial for an AI agent to use the tool effectively in varied contexts.
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 schema already documents all parameters thoroughly. The description adds minimal value by implying line-range functionality but does not provide additional semantics beyond what the schema specifies (e.g., it doesn't clarify format or constraints for 'file_path' or interactions between parameters). Baseline 3 is appropriate as the schema handles most parameter documentation.
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 ('Read') and resource ('contents of a file'), specifying the action and target. It distinguishes from siblings like 'delete_from_file', 'insert_into_file', and 'replace_in_file' by focusing on reading rather than modifying files, and from 'list_files' by reading file contents instead of listing files.
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 for usage by mentioning 'entire file or specific line ranges', which helps understand when to use different parameter combinations. However, it does not explicitly state when to use this tool versus alternatives like 'search_file' for content searching or 'list_files' for file metadata, leaving some sibling differentiation implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-file-edit MCP server](https://glama.ai/mcp/servers/pwilkin/mcp-file-edit/badges/card.svg)](https://glama.ai/mcp/servers/pwilkin/mcp-file-edit)

Score Badge

Copy to your README.md:

[![mcp-file-edit MCP server](https://glama.ai/mcp/servers/pwilkin/mcp-file-edit/badges/score.svg)](https://glama.ai/mcp/servers/pwilkin/mcp-file-edit)

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/pwilkin/mcp-file-edit'

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