GhostLink is an MCP server that gives AI coding agents safe, sandboxed access to a local Git repository through six policy-gated tools. All tools are confined to the repo root, return deterministic JSON ToolEnvelope structures, and are audit-logged.
Search repository files with ripgrep-powered regex and optional glob filtering, capped and deterministically ordered results.
Read files within the repository, with binary detection and size/truncation limits to prevent unbounded output.
Apply unified diff patches with sandbox validation, dry-run mode for testing, and atomic rollback on failure.
Run curated commands: a fixed set of allowlisted commands (test, lint, typecheck, build, smoke) with allowlisted arguments and timeouts, but no arbitrary shell access.
Get Git status: normalized branch info, ahead/behind tracking, and sorted file entries.
Get Git diffs: staged or unstaged diffs with optional path filtering and output size caps.
It integrates with any MCP client via STDIO transport.
Provides tools for inspecting local Git repository status and diffs, including staged/unstaged changes and path filtering.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GhostLink run the test suite and report failures"
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.
A security-hardened MCP server that gives AI coding agents safe, deterministic access to local repositories.
Add it to any MCP client that supports STDIO. For Claude Code, create .mcp.json in the target repo root:
{
"mcpServers": {
"ghostlink": {
"command": "npx",
"args": ["-y", "@bgorzelic/ghostlink"],
"env": {
"GHOSTLINK_REPO_ROOT": "/path/to/target/repo"
}
}
}
}Then run claude in that directory — six repo tools appear, all confined to GHOSTLINK_REPO_ROOT. Every tool call returns the same deterministic ToolEnvelope:
{
"ok": true,
"data": { ... },
"provenance": { "tool": "repo.search", "timestamp": "2026-02-24T...", "duration_ms": 42 }
}On error, "error": { "code": "...", "message": "..." } replaces "data". Full tool schemas: docs/TOOLS.md.
Tool | Description |
| Ripgrep-powered regex search with glob filtering, deterministic ordering, and output caps (max 200 results) |
| File read with size caps (max 10MB), binary detection, and truncation flags |
| Unified diff patching with dry-run mode, full sandbox validation, and atomic rollback on failure |
| Curated command execution (test, lint, typecheck, build, smoke) -- no arbitrary shell, allowlisted args only |
| Normalized git status with branch info, ahead/behind tracking, and sorted file entries |
| Staged or unstaged diff with path filtering, sandbox validation, and output caps (max 2MB) |
Related MCP server: projscan
GhostLink is a local-first Model Context Protocol server that exposes your codebase to AI coding agents through a small set of policy-gated tools. It solves a specific problem: AI agents need to search, read, patch, and verify code, but giving them raw shell access is a liability. GhostLink provides a sandboxed capability plane where every tool call is confined to a single repository root, every output follows a deterministic JSON shape, and every invocation is audit-logged.
Capability | What it means |
Secure local dev plane | Repo-root sandbox, no shell execution, JSONL audit trail on every tool call |
Deterministic output | Same input produces the same JSON envelope shape -- enables golden tests and predictable agent consumption |
Policy enforcement | Command allowlists, output caps, truncation flags, timeout enforcement -- the AI cannot do unbounded damage |
Agent loop foundation | Built for the search, read, patch, verify cycle that autonomous coding agents run in a loop |
Multi-server composition | One GhostLink instance per repo, composable with other MCP servers in the same client session |
Production-ready Phase 2 base | Transport abstraction, schema versioning, and auth hook seams are preserved in the architecture today |
GhostLink is a three-layer stack designed for extensibility without core changes:
flowchart TD
T["Transport -- src/index.ts<br/>STDIO now, HTTP/SSE in Phase 2"]
S["Server factory -- src/server.ts<br/>Transport-agnostic tool registration via MCP SDK + Zod schemas"]
TL["Tools -- src/core/tools/*<br/>Six tools, each returning ToolEnvelope<T>"]
P["Policy -- src/core/policy/*<br/>Sandbox enforcement, audit logging, output caps"]
T --> S --> TL --> PThe createServer() factory knows nothing about transport. Adding HTTP/SSE in Phase 2 means writing a new transport binding and auth middleware -- the server factory and all tool implementations remain unchanged. Phase 3 (agent runtime) adds memory resources and orchestration as consumers of GhostLink, not modifications to it.
Node.js 18+
ripgrep (brew install ripgrep)
A git repository to expose
From npm:
npm install @bgorzelic/ghostlinkOr from source:
git clone https://github.com/bgorzelic/ghostlink.git
cd ghostlink
npm install
npm run buildGhostLink speaks JSON-RPC 2.0 over STDIO. Test it directly:
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | \
GHOSTLINK_REPO_ROOT=/path/to/target/repo node dist/index.jsThis returns all 6 tools and their schemas.
GhostLink works with any MCP client that supports STDIO transport. The npx snippet at the top of this page works everywhere; a source checkout uses node with the built entry point instead:
{
"ghostlink": {
"command": "node",
"args": ["/absolute/path/to/ghostlink/dist/index.js"],
"env": {
"GHOSTLINK_REPO_ROOT": "/path/to/target/repo"
}
}
}Client | Where the config goes |
Claude Code |
|
Claude Desktop |
|
Cursor, Windsurf, Cline, others | Your client's MCP server configuration -- consult its documentation for the file location |
The transport is always STDIO. Ready-to-use .mcp.json and CLAUDE.md templates for target projects live in templates/.
GhostLink enforces defense-in-depth at every layer:
Repo-root sandbox -- All file operations confined to GHOSTLINK_REPO_ROOT. Path traversal, symlink escape, null bytes, and absolute paths outside the root are all rejected before any filesystem access.
No shell execution -- repo.run uses spawn with shell: false. Commands are limited to a fixed allowlist (test, lint, typecheck, build, smoke) with per-command argument allowlists. Environment is stripped to six safe variables.
Output caps -- Every tool that returns bulk data enforces hard maximums (200 search results, 10MB file reads, 200KB stdout/stderr, 2MB diffs). Truncation is flagged, never silent.
Atomic patch rollback -- repo.apply_patch validates all paths and computes all patches before writing anything. If any write fails, completed writes are rolled back to their original state.
Timeout enforcement -- repo.run kills processes at configurable timeouts (default 120s, hard cap 300s) with SIGTERM then SIGKILL.
Full threat model and mitigations: docs/SECURITY.md.
Every tool call produces a JSONL audit entry: {ts, tool, ok, duration_ms, error_code?, repo_root}.
| Behavior |
| JSONL audit lines written to stderr |
| JSONL written to |
| No logging |
Set via environment variable:
GHOSTLINK_LOG=file GHOSTLINK_REPO_ROOT=/path/to/repo node dist/index.jsdocs/PROMPTS.md contains ready-to-use prompts for high-autonomy agent operation, including orchestrator prompts, sub-agent role definitions (Protocol Engineer, Toolsmith, Security Reviewer, Test Engineer, Docs Engineer), and multi-instance coordination patterns.
npm install # Install dependencies
npm test # Run test suite (108 tests via Vitest)
npm run lint # ESLint
npm run typecheck # TypeScript strict mode check
npm run build # Compile to dist/
npm run dev # Dev mode with auto-reload (tsx watch)Full verification after edits:
npm test && npm run lint && npm run typecheck && npm run buildDocument | Description |
Canonical tool schemas (versioned public API) | |
Threat model and mitigations | |
Setup, smoke tests, and client configuration walkthrough | |
MCP Inspector manual testing guide | |
Agent prompts for orchestration and sub-agent roles | |
Full product roadmap with Phase 2 and Phase 3 deliverables | |
Strategic value proposition and architecture rationale | |
v0.1.0 ship report with milestone history and decision log | |
Ready-to-use CLAUDE.md and .mcp.json templates for target projects |
Deterministic tool surface, repo-root sandbox, curated command execution, 108 tests, JSONL audit logging, npm package published.
HTTP/SSE transport, OAuth 2.1 authentication, multi-user tenant separation, per-tenant rate limiting, schema versioning, structured audit logging with correlation IDs.
Persistent memory resources exposed via MCP, optional policy-gated memory write tools, orchestration layer (external to GhostLink), evaluation loops, sub-agent coordination framework.
ISC
Get diff output for staged or unstaged changes with optional path filtering
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No | Filter to specific file paths (sandbox validated) | |
| staged | No | Show staged (cached) changes (default false) | |
| max_bytes | No | Max output bytes (default 500KB, cap 2MB) |
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 only summarizes schema parameters (staged, paths) and does not disclose output format, truncation behavior (max_bytes), or behavior when there are no changes. The ambiguous 'staged or unstaged' could mislead about whether both are shown simultaneously.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, terse sentence that immediately conveys the core function with no fluff. All words are necessary and the description is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain return format and edge cases. It does not mention max_bytes truncation, default output style, or what happens when there are no changes. While the schema covers parameter definitions, the description leaves behavioral aspects incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for all three parameters. The description adds no new semantic detail beyond naming 'optional path filtering,' which duplicates the paths parameter description. Thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('diff output'), includes scope ('staged or unstaged') and optional path filtering. This distinguishes it from siblings like git.status (which shows status) and repo.apply_patch (which applies changes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use or alternatives, only an implied context of needing diff output. It gives a minor usage hint via 'optional path filtering' but lacks guidance on when to prefer this over git.status or repo.read_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get normalized git status with branch info, ahead/behind, and file entries
| Name | Required | Description | Default |
|---|---|---|---|
| max_entries | No | Max file entries to return (default 100, cap 500) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the output contents (branch info, ahead/behind, file entries) and hints at normalization, but does not explicitly state that it is read-only or non-destructive, nor does it describe any potential edge cases or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose and output summary without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter and no output schema, the description adequately covers the key return aspects (branch info, ahead/behind, file entries) and hints at normalization. It is complete enough for the agent to understand what it will receive, though it could marginally benefit from a note about when to use it relative to git.diff.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter (max_entries) with a clear description including default and cap. The tool description does not add any extra parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('git status') and enumerates the key content ('branch info, ahead/behind, and file entries'). It clearly distinguishes itself from sibling tools like git.diff by focusing on status summary rather than diffs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description and name: the tool is for retrieving git status. However, there is no explicit guidance on when to use it versus alternatives (e.g., git.diff for detailed changes) or any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a unified diff patch with validation, sandbox enforcement, and rollback
| Name | Required | Description | Default |
|---|---|---|---|
| patch | Yes | Unified diff patch string | |
| dry_run | No | Validate only without writing (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It goes beyond the tool name by mentioning validation, sandbox enforcement, and rollback, giving users insight into safety and error-handling behavior. However, it does not elaborate on specific failure modes or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action ('Apply a unified diff patch') and then lists key features. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature and lack of annotations/output schema, the description provides a solid overview with validation and rollback features. It could be more complete by specifying return values or exact behavior on failure, but it is sufficiently informative for a two-parameter tool with 100% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (patch and dry_run) with 100% coverage. The description adds minimal extra meaning, though it aligns with the dry_run parameter by mentioning validation. Baseline of 3 is appropriate since the schema already handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb: 'Apply a unified diff patch.' It also lists key features (validation, sandbox enforcement, rollback) that distinguish it from sibling tools like repo.search, repo.read_file, and git.diff, which are read-only or diff-generating operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the action, but it does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it. Sibling tools like git.diff generate patches, so it is inferred that apply_patch is for applying them, but no direct comparison or exclusion is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a file from the repository with size and binary guards
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path relative to repo root | |
| max_bytes | No | Max bytes to read (default 1MB, cap 10MB) |
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 mentions the existence of 'size and binary guards', which is useful, but does not explain what happens when these guards are triggered (e.g., error, truncation, rejection). The description adds some behavioral context but lacks specificity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (10 words) that front-loads the verb and resource. It includes a valuable qualifier ('with size and binary guards') without being verbose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, a fully documented schema, and no output schema, the description is adequate but incomplete. It does not describe the return format or behavior on guard violations, which the agent would need to know. The description covers the basic purpose but not the full context of use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with descriptions (path, max_bytes with default and cap), so schema coverage is 100%. The description's wording 'size and binary guards' somewhat aligns with max_bytes and binary detection, but it does not add meaningful parameter-specific detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Read'), a specific resource ('a file from the repository'), and additional scoping ('with size and binary guards'). This clearly distinguishes it from siblings like repo.search (searching) and repo.apply_patch (modifying).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, but the purpose is self-evident from the description. Alternatives are not mentioned, and there are no exclusion criteria. 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.
Run a curated command (test, lint, typecheck, build, smoke) with allowlisted args
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Optional allowlisted arguments | |
| command | Yes | Command to run | |
| timeout_ms | No | Timeout in ms (default 120000, max 300000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the curated/allowlisted nature, which is a behavioral constraint, but it does not mention side effects, output format, or error behavior. This is a moderate gap, as command execution can have side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the core action, and includes the full command list. It is concise with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters that are fully described in the schema, but the description does not explain expected return values, side effects, or how to interpret command output. Given the lack of an output schema and annotations, the description is adequate but incomplete for a command runner.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all parameters, so the baseline is 3. The description adds no extra meaning beyond the schema except the word 'allowlisted' which is already in the args description. It does not provide additional syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a curated command, listing specific commands (test, lint, typecheck, build, smoke). It uses a specific verb ('Run') and resource ('curated command'), and the sibling tools are all for repo/git operations, so this tool is unambiguously distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for running project commands, and the sibling tools (repo.search, git.status, etc.) are clearly different. However, there is no explicit when-not-to-use or alternative mention, so it relies on context rather than direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search repo files using ripgrep with output caps and deterministic ordering
| Name | Required | Description | Default |
|---|---|---|---|
| glob | No | File glob filter (e.g. "*.ts") | |
| pattern | Yes | Search pattern (regex) | |
| max_results | No | Max results to return (default 50, cap 200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It meaningfully discloses behavioral traits beyond the schema: output caps and deterministic ordering, which inform the agent about result limits and stability. It does not detail return format or whether hidden/binary files are included, but for a read-only search tool this is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Search repo files') and packs the most useful behavioral details—ripgrep, output caps, deterministic ordering—without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description is nearly complete. It lacks an explicit statement of the return format (e.g., matching file paths and line content), but the mention of output caps and deterministic ordering partly compensates for the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for pattern, glob, and max_results. The description adds only general context about output caps and deterministic ordering, but does not explain parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') with a clear resource ('repo files') and distinguishes itself from sibling tools like repo.read_file and repo.run by indicating content search with ripgrep and deterministic output. It clearly conveys what the tool does and its key scoping traits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when you need to search repository file contents via regex and glob filtering—and the sibling tool list reinforces its distinct role. However, it does not explicitly state when not to use it or name alternatives, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0git.diffgit.statusrepo.apply_patchrepo.read_filerepo.runrepo.searchEach tool has a clearly distinct purpose: repo.search scans file contents, repo.read_file reads individual files, repo.apply_patch modifies files, repo.run executes allowed commands, git.status reports repository state, and git.diff shows changes. There is no functional overlap or ambiguity between them.
All tool names follow the consistent pattern of a namespace prefix (repo or git) plus a verb or noun phrase in snake_case, such as repo.read_file and git.status. This uniform convention makes the toolset predictable and easy to navigate.
The server contains exactly 6 tools, which is well within the ideal range for a focused toolset. Each tool addresses a distinct need in repository inspection and git operations, without unnecessary bloat or fragmentation.
The toolset covers the core operations of searching, reading, modifying, and running commands in a repository, plus git status and diff for change inspection. It lacks explicit commit or branch management, but those are outside the apparent scope, so the gap is minor and workable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives your AI access to the source code and docs of all public github repos
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
MCP server teaching AI agents to implement TideCloak: auth, E2EE, IGA, security analysis
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bgorzelic/ghostlink'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
