Which integrations are available for this server?

Automatically configures git to use a URL-scoped proxy for specified hosts, allowing git commands (clone, fetch, pull, push, etc.) to work through a local proxy. Routes traffic to GitHub (and subdomains) through a local proxy, enabling git operations on repositories that would otherwise be unreachable due to network restrictions.

How do I use mcp-proxy-bridge?

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., "@mcp-proxy-bridge check if github.com is reachable" 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.

mcp-proxy-bridge

by xiaolaifeng

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Local

mcp-proxy-bridge

An MCP server + Claude Code hook that makes a target host (e.g. github.com) reachable through your local proxy — launching the proxy client if needed and configuring your tools to route through it.

License: MIT Node Zero dependencies

If you're behind a network where GitHub (or another host) only works through a local proxy like Clash / Clash Verge / v2rayN / sing-box, this bridge makes it just work for your AI coding assistant:

MCP server — tools to check reachability, start/stop the proxy, and orchestrate the whole flow.
PreToolUse hook — fires automatically on Bash commands that touch a configured host, brings the proxy up, and points git at it.

Zero dependencies (Node stdlib only) — deliberately, because a tool that fixes network problems must not need a network install.

How it works

Most local proxies run with system proxy and TUN off, so simply starting the proxy client doesn't route your traffic. The bridge:

Probes whether the target is reachable directly.
If not, checks the local proxy port; if closed, launches your proxy client and waits for the port.
Verifies the target through the proxy (HTTP CONNECT or SOCKS5 → TLS HEAD).
Sets a URL-scoped git proxy so only the configured host routes through the proxy — every other repo host is untouched. Idempotent and reversible.

Note: this is a local tool. It launches your proxy client and configures your machine. Each user runs their own copy next to their own proxy — it is not a shared hosted service.

Related MCP server: universal-dev-mcp

Install

Use without installing (npx)

# MCP server (spawned once by your client at startup — npx is fine here)
claude mcp add proxy-bridge -- npx -y mcp-proxy-bridge

Install globally (recommended for the hook, which runs on every Bash call)

npm install -g mcp-proxy-bridge

From source / GitHub

git clone https://github.com/xiaolaifeng/mcp-proxy-bridge.git
cd mcp-proxy-bridge
node src/server.mjs --print-config   # sanity check

Quick start (Claude Code)

Create a config (edit the result to match your proxy client):

mcp-proxy-bridge --init            # writes ~/.mcp-proxy-bridge.json
$EDITOR ~/.mcp-proxy-bridge.json   # set launch.command, ports, process.names
mcp-proxy-bridge --print-config    # verify

See examples/ for Clash Verge, v2rayN, sing-box, and SOCKS5.

Register the MCP server (user scope = all projects):

claude mcp add proxy-bridge --scope user -- npx -y mcp-proxy-bridge
# or, if installed globally:
claude mcp add proxy-bridge --scope user -- mcp-proxy-bridge

Register the hook in ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "mcp-proxy-bridge-hook" }
        ]
      }
    ]
  }
}

(Use npx -y mcp-proxy-bridge-hook instead if not installed globally, but global install is faster for a per-command hook.)

Restart Claude Code. Run a git pull that touches GitHub — the proxy comes up automatically.

Configuration

Config is layered, later wins: defaults < JSON file < environment variables.

File: ~/.mcp-proxy-bridge.json (override path with PROXY_BRIDGE_CONFIG).
Env: see table below.
CLI: --print-config, --init [path].

{
  "targets": ["github.com", "api.github.com", "raw.githubusercontent.com"],
  "checkPort": 443,
  "proxy": { "host": "127.0.0.1", "port": 7897, "scheme": "http" },
  "launch": { "command": "clash-verge", "args": [], "cwd": null, "waitPortMs": 40000 },
  "process": { "names": ["clash-verge", "verge-mihomo", "mihomo"] },
  "gitProxy": { "enable": true, "scope": null },
  "hook": { "matchTargets": true, "extraPatterns": ["\\bgit\\s+[^|;&\\n]*\\b(clone|fetch|pull|push|ls-remote|submodule)\\b"] }
}

Field	Meaning
`targets`	Hosts to verify.
`checkPort`	Port probed on each target (443 = HTTPS).
`proxy.host` / `proxy.port`	Your local proxy address.
`proxy.scheme`	`http` (HTTP CONNECT) or `socks5`.
`launch.command` / `launch.args`	Command to start your proxy client. `null` = you start it manually.
`launch.waitPortMs`	How long to wait for the port after launching.
`process.names`	Best-effort process names for `status` / `stop` (Windows auto-appends `.exe`).
`gitProxy.enable`	Hook sets URL-scoped git proxy for the targets.
`gitProxy.scope`	Override git URL prefixes (defaults to `https://<target>/` per target).
`hook.matchTargets`	Hook fires when a command mentions any target host.
`hook.extraPatterns`	Extra regexes that trigger the hook (default: git network verbs).

Environment variables

Var	Maps to
`PROXY_BRIDGE_CONFIG`	Config file path.
`PROXY_BRIDGE_TARGETS`	Comma-separated targets.
`PROXY_BRIDGE_CHECK_PORT`	Target port.
`PROXY_BRIDGE_PROXY_HOST` / `PROXY_BRIDGE_PROXY_PORT` / `PROXY_BRIDGE_PROXY_SCHEME`	Proxy endpoint.
`PROXY_BRIDGE_LAUNCH_CMD` / `PROXY_BRIDGE_LAUNCH_ARGS`	Launch command (args: JSON array or space-split).
`PROXY_BRIDGE_PROCESS_NAMES`	Comma-separated process names.
`PROXY_BRIDGE_SET_GIT_PROXY`	`0` disables git proxy.
`PROXY_BRIDGE_GIT_SCOPE`	Comma-separated git URL prefixes.
`PROXY_BRIDGE_HOOK_EXTRA`	Comma-separated extra trigger regexes.

MCP tools

Tool	Description
`ensure_access`	Check direct; if down, start proxy, wait for port, verify via proxy.
`check`	`useProxy` true/false reachability of a target.
`status`	Proxy process running? Port open? Targets?
`start_proxy` / `stop_proxy`	Launch / best-effort kill.
`proxy_info`	Proxy URL + env/git-config hints (and unset).
`set_git_proxy`	Apply the URL-scoped git proxy.
`show_config`	Resolved config + config path.

Platform notes

Windows: process detection via tasklist, stop via taskkill. Append .exe automatically.
macOS / Linux: process detection via pgrep, stop via pkill. Set launch.command to the app binary or open -a "Clash Verge" on macOS.
Port readiness is the primary "proxy is up" signal on all platforms.

Other MCP clients

Works with any MCP-capable client that speaks stdio (Claude Desktop, etc.). Point the client at:

npx -y mcp-proxy-bridge

The hook is Claude-Code-specific (PreToolUse). For other clients, call the ensure_access tool before GitHub operations, or use the git-proxy hint from proxy_info.

Troubleshooting

status shows proxyPortOpen: false: your proxy client isn't running or the port differs — check proxy.port and launch.command.
Proxy up but target still unreachable: the selected node/subscription in your proxy client can't reach the target — switch nodes, then retry.
processRunning: false even when running: add the right process.names (this field is best-effort; the port probe is authoritative).
Don't want the persistent git proxy: run git config --global --unset http.<scope>.proxy, or set PROXY_BRIDGE_SET_GIT_PROXY=0.
If you enable TUN or system proxy in your client, the explicit git proxy becomes unnecessary but stays harmless.

Manual testing

mcp-proxy-bridge --print-config
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}'$'\n''{"jsonrpc":"2.0","id":2,"method":"tools/list"}' | node src/server.mjs
echo '{"tool_input":{"command":"git pull origin main"}}' | node src/hook.mjs   # should emit context
echo '{"tool_input":{"command":"docker ps"}}' | node src/hook.mjs             # should be silent

Security & notes

The bridge only ever talks to 127.0.0.1 (your proxy) and the configured target hosts over TLS. No telemetry, no remote calls.
set_git_proxy / the hook modify global git config (http.<scope>.proxy) — reversible via the --unset commands in proxy_info.
MIT licensed.

For maintainers — publishing

npm:

npm version patch         # or minor / major
npm pack                  # inspect the tarball contents
npm publish               # publishes the files listed in package.json "files"

Before publishing, fill in package.json author, repository, homepage, bugs (already set: author Robin Lee, repo xiaolaifeng/mcp-proxy-bridge).

GitHub: push the repo, then users can npx github:xiaolaifeng/mcp-proxy-bridge.

MCP directories (for discovery): submit to mcp.so, Glama, Smithery, and the Anthropic MCP server list.

License

MIT

Available Tools

8 tools

checkB

Test HTTPS reachability of a target host. useProxy=true routes through the configured proxy; false=direct.

ParametersJSON Schema

Name	Required	Description	Default
`target`	No
`useProxy`	No

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are present, so the description must fully disclose behavioral traits. It only states the tool tests reachability and explains the useProxy parameter, but fails to mention side effects, error handling, or whether it is read-only.

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 two sentences long, each providing essential information without redundancy. It is well-structured and front-loaded.

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

Completeness3/5

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

For a simple tool with no output schema, the description covers purpose and parameter behavior but lacks details on return values, error conditions, and prerequisites (e.g., proxy configuration).

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 0%, so the description compensates partially. It explains the useProxy parameter's effect, but the target parameter is not elaborated beyond the schema's type.

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 tests HTTPS reachability of a target host, which is a specific verb and resource. It distinguishes itself from sibling tools like start_proxy and stop_proxy that manage proxy settings.

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. The description does not specify prerequisites, exclusions, or context for use.

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

ensure_accessA

Ensure the target host (default: first configured target) is reachable. Checks direct first; if it fails, launches the proxy, waits for the port, and verifies through the proxy. Returns status + proxy URL.

ParametersJSON Schema

Name	Required	Description	Default
`target`	No	Host to verify, e.g. github.com. Defaults to first configured target.

TDQS

A4/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It clearly explains the two-step behavior: direct attempt first, then proxy launch and verification. It also mentions the return values (status + proxy URL). However, it does not detail any potential side effects or authentication 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?

Two sentences only. The first sentence states the primary purpose, the second explains the failover algorithm. No unnecessary words, front-loaded with the key action.

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 tool with one optional parameter and no output schema, the description explains the core behavior (direct then proxy) and return values. It lacks details on the exact format of 'status' and 'proxy URL', but is otherwise sufficient for an agent to understand what to expect.

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% with the single 'target' parameter already described. The description adds context about defaulting to first configured target, which reinforces the schema but does not add new semantic value beyond it.

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 ('Ensure') and resource ('target host is reachable'), and describes the specific fallback logic (direct check then proxy). This distinguishes it from siblings like 'check' which might just do a basic check.

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 the tool should be used when one wants to verify host reachability with automatic proxy fallback, but it does not explicitly state when to use this tool versus alternatives like 'check', 'proxy_info', or 'status'.

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

proxy_infoA

Return the proxy URL plus copy-paste hints for HTTPS_PROXY env vars and URL-scoped git config (and how to unset).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

With no annotations, the description falls short in disclosing behavioral traits. It does not confirm the tool is read-only, has no side effects, or is safe to call repeatedly. The description only states what is returned, not how it behaves.

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 efficiently conveys the tool's output without unnecessary words. It is front-loaded with the key action 'Return the proxy URL'.

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 tool with zero parameters and no output schema, the description adequately explains the return value (proxy URL and hints). It could specify the format or structure of hints, but is reasonably complete for the tool's simplicity.

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?

There are no parameters, so the schema covers everything. Baseline score of 4 applies; the description is not required to add parameter semantics.

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 returns the proxy URL and copy-paste hints for environment variables and git config. It uses specific verbs ('Return') and resources ('proxy URL', 'env vars', 'git config'), distinguishing it from sibling tools that perform actions like setting or starting proxies.

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 when the agent needs to view proxy information or configuration hints, but lacks explicit guidance on when to use this tool versus siblings like 'show_config' or 'set_git_proxy'. No exclusions or alternatives are mentioned.

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

set_git_proxyA

Apply the URL-scoped git http proxy for the configured targets (idempotent). Useful after the proxy is up.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full behavioral disclosure. It mentions idempotency but omits side effects, permissions, or what exactly is modified (e.g., git config).

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 two concise sentences. The first states the core functionality, and the second provides a usage context. No redundant or unnecessary 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?

Given no parameters and no output schema, the description adequately covers the basic action but does not explain what 'configured targets' refers to or what the tool returns. More detail would improve completeness.

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 input schema has zero parameters with 100% coverage. Per guidelines, 0 parameters merits a baseline score of 4; the description adds no param info but none is needed.

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: 'Apply the URL-scoped git http proxy for the configured targets.' It also notes idempotency, and the tool is distinct from siblings like start_proxy which starts a proxy server.

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 phrase 'Useful after the proxy is up' gives a usage hint but does not explicitly state when not to use it or list alternatives. There is no exclusionary guidance.

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

show_configA

Return the resolved configuration and the config file path (for debugging).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

Description states it returns configuration, implying no side effects, but does not explicitly declare non-destructive behavior. With no annotations, the description is adequate but could be clearer about lack of mutation.

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?

Single sentence, directly front-loaded with the action and output. No wasted words.

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 simple config retrieval tool with no parameters and no output schema, the description is complete enough. It specifies what is returned (resolved config and path) and the purpose (debugging).

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?

No parameters defined, so schema covers everything. Description adds context about returning resolved config and path, which is sufficient for this zero-parameter tool.

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 it returns the resolved configuration and config file path. 'Return' and 'for debugging' specify the exact output and purpose. The tool is distinct from siblings like 'check' or 'proxy_info'.

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 or avoid. The description implies debugging use but does not mention alternatives or when not to use this tool.

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

start_proxyA

Launch the configured proxy client (detached). Returns whether it was launched vs. already running.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It mentions launching in detached mode and return value, but omits details about configuration, permissions, side effects, or error conditions.

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 extremely concise, with two short sentences that front-load the action and return information. No unnecessary words.

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

Completeness3/5

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

For a zero-parameter tool, the description is somewhat complete but lacks context on what 'configured' means and any prerequisites, leaving potential gaps for the agent.

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?

There are no parameters, so the description need not elaborate on them. The baseline of 4 is appropriate as it adds no confusion.

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 explicitly states the action 'Launch the configured proxy client' and specifies the return value, distinguishing it from sibling tools like stop_proxy and status.

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 when the proxy client should be launched, but provides no explicit guidance on when to use this tool versus alternatives like check or status.

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

statusB

Report whether the proxy process is running (best-effort), the proxy port is open, and the configured targets.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

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

The description mentions 'best-effort' for the running check, indicating potential inaccuracy, and lists the three reported aspects. However, with no annotations, it does not explicitly state read-only behavior or other traits like performance impact.

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, concise, and front-loaded with the purpose. Every word serves a clear function with no redundancy.

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 no output schema, the description could have elaborated on the return format or interpretation of results (e.g., what 'configured targets' means). It is adequate but lacks details that would help an agent fully use the output.

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 description coverage is 100%. The description does not need to add parameter information, and the baseline for no parameters is 4.

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 reports proxy status including process running status, port openness, and configured targets. It specifies a verb ('report') and resource ('proxy status'), but does not explicitly differentiate from sibling tools like 'proxy_info' or 'check'.

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 such as 'check' or 'proxy_info'. The description only states what it does without usage context.

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

stop_proxyA

Best-effort kill of the configured proxy process(es).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

The description uses 'best-effort kill', which transparently indicates the operation may not be guaranteed. However, it does not disclose other behavioral aspects like side effects (e.g., terminating connections) or required permissions, and there are no annotations to supplement.

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, compact sentence that conveys the core action and its nature (best-effort). No unnecessary words, and the key information is front-loaded.

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 has no parameters and no output schema, the description is mostly complete. It lacks details on what 'configured proxy' refers to, but with sibling context, it is adequate.

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, so the description does not need to add parameter meaning. The baseline for 0 parameters is 4, and the description appropriately focuses on the tool's purpose.

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 that the tool performs a 'best-effort kill of the configured proxy process(es)', using a specific verb ('kill') and resource ('proxy process'). It distinguishes from sibling tools like start_proxy (start) and proxy_info (info).

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 when one wants to stop a proxy, but provides no explicit guidance on when to use this tool versus alternatives like set_git_proxy or check. No exclusions or prerequisites are mentioned.

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.

8 tool updatesv0.1.0Jul 16, 2026
- First observedcheck
- First observedensure_access
- First observedproxy_info
- First observedset_git_proxy
- First observedshow_config
- First observedstart_proxy
- First observedstatus
- First observedstop_proxy

Install Server

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

TDQS

A3.7/5.0

Scored 2026-07-16 10:11 across 8 tools

Disambiguation4/5

Most tools have distinct purposes, but 'check' and 'ensure_access' both test reachability; 'ensure_access' is a higher-level operation that may also launch the proxy, causing slight ambiguity.

Naming Consistency3/5

Tool names use a mix of conventions: some are verbs only ('check'), some are verb_noun ('start_proxy'), and some are noun_only ('status') or noun_info ('proxy_info'), lacking a consistent pattern.

Tool Count5/5

With 8 tools, the set is well-scoped for managing a proxy bridge, covering essential operations without unnecessary bloat.

Completeness4/5

The tool set covers core proxy lifecycle (start/stop/status), reachability testing, configuration access, and git proxy setup. Missing direct tool for managing proxy targets, but config editing may be external.

Maintenance

ActivityStale

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

Sentry AOAuth
dev.sentry.mcp
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Monitoring Developer Tools Observability
3
Occludra — MCP Gateway (AI Security Gateway)
ai.occludra
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
Security Agent Orchestration
1
Hextrap MCP A
com.hextrap
Hextrap's MCP Connector protects your LLM coding sessions from installing malicious dependencies, typosquats, unpopular packages, and enforces your strict allow and deny lists. No setup means your LLM uses MCP to configure itself to use Hextrap's proxy's automatically, enforcing your firewall rules immediately. Manage your allow and deny lists right from your favorite LLM.
Developer Tools Security Code Execution
102
OpenRouter AOAuth
ai.openrouter.mcp
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
AI & Machine Learning
221

Related MCP Servers

JetBrains MCP Proxy Server
Developer Tools Code Execution Autonomous Agents
admmkk
-
license
Not graded
quality
Not graded
maintenance
A proxy server that enables communication between clients (like Claude AI or VS Code) and JetBrains IDEs, allowing AI assistants to access IDE functionality.
Updated a year ago (2025-07-03 04:42 UTC)
0
-
universal-dev-mcp
Developer Tools File Systems Command Line
rj9884
A
license
A
quality
C
maintenance
Connects AI tools to local dev servers, enabling them to view pages, call APIs, read/edit files, and run commands with safety guardrails.
Updated 2 months ago (2026-07-10 02:33 UTC)
13
MIT
Claude GPT Launcher
Coding Agents Developer Tools Command Line
Bennyyy28
A
license
Not graded
quality
A
maintenance
Enables Codex chat to use the Claude Code harness for repository consultation and editing, routing through GPT models via a local proxy.
Updated 2 months ago (2026-07-12 21:46 UTC)
5
MIT
AI Service Gateway MCP
Security Shell Access
Yormede
A
license
Not graded
quality
C
maintenance
Enables AI agents to securely access authenticated services (HTTP, SSH, SMTP) without exposing secrets, by acting as a server-side proxy that injects authentication.
Updated 2 months ago (2026-07-13 14:30 UTC)
MIT