GhostLink

by bgorzelic

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: v0.1.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.9/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under ISC 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?
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
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 ('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.
Usage Guidelines3/5
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.
Behavior3/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 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function 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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity 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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

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:

[![ghostlink MCP server](https://glama.ai/mcp/servers/bgorzelic/ghostlink/badges/card.svg)](https://glama.ai/mcp/servers/bgorzelic/ghostlink)

Score Badge

Copy to your README.md:

[![ghostlink MCP server](https://glama.ai/mcp/servers/bgorzelic/ghostlink/badges/score.svg)](https://glama.ai/mcp/servers/bgorzelic/ghostlink)

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/bgorzelic/ghostlink'

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