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., "@Proxychains MCP Server run curl ifconfig.me through the proxy chain"
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 server for proxychains-ng (proxychains4) - route commands through proxy chains via SSH to a remote Linux host (e.g., Kali Linux).
This MCP server provides tools to manage and use proxychains configurations dynamically. It executes commands through SSH on a remote host where proxychains4 is installed, allowing AI assistants to route network traffic through proxy chains for privacy, security testing, or accessing geo-restricted resources.
Related MCP server: SSH MCP Server
Tool | Description |
| Execute commands through the configured proxy chain |
| Get, set, or reset the full configuration |
| Add a proxy to the chain (SOCKS4, SOCKS5, HTTP, RAW) |
| Remove a proxy by index or host:port |
| Set chain mode (strict, dynamic, random, round_robin) |
| Configure DNS handling mode |
| Test proxy chain connectivity and latency |
| List all configured proxies |
| Import proxies from file or URL |
| Export configuration in various formats |
Node.js 18+
SSH access to a Linux host with proxychains4 installed
The SSH host should be configured in ~/.ssh/config or accessible by hostname
# Clone the repository
git clone https://github.com/schwarztim/sec-proxychains-mcp.git
cd sec-proxychains-mcp
# Install dependencies
npm install
# Build
npm run buildAdd to your Claude Desktop or MCP client configuration:
{
"mcpServers": {
"proxychains": {
"command": "node",
"args": ["/path/to/sec-proxychains-mcp/dist/index.js"],
"env": {
"PROXYCHAINS_KALI_HOST": "kali",
"PROXYCHAINS_SSH_TIMEOUT": "30000"
}
}
}
}Variable | Default | Description |
|
| SSH hostname for the remote host |
|
| SSH command timeout in milliseconds |
|
| Local config storage directory |
Mode | Description |
| All proxies must work, used in order specified |
| Skip dead proxies, at least one must work |
| Random proxy selection for each connection |
| Rotate through proxies sequentially |
Type | Description |
| SOCKS5 proxy (recommended) |
| SOCKS4 proxy |
| HTTP CONNECT proxy |
| Raw TCP forwarding |
Mode | Description |
| Route DNS through proxy (recommended, prevents leaks) |
| Legacy mode using proxyresolv |
| Daemon-based DNS resolution |
| No DNS proxying (may leak DNS queries) |
// Add a SOCKS5 proxy (e.g., Tor)
proxychains_add({ type: "socks5", host: "127.0.0.1", port: 9050 })
// Add an authenticated HTTP proxy
proxychains_add({
type: "http",
host: "proxy.example.com",
port: 8080,
user: "admin",
pass: "secret"
})
// Set dynamic chain mode (skip dead proxies)
proxychains_mode({ mode: "dynamic_chain" })// Test connectivity
proxychains_test({ verbose: true })
// Test against specific target
proxychains_test({ target: "https://api.ipify.org" })// Check your proxied IP
proxychains_run({ command: "curl https://httpbin.org/ip" })
// Run nmap through proxies
proxychains_run({ command: "nmap -sT -Pn target.com" })
// Custom timeout for long operations
proxychains_run({ command: "wget https://example.com/large-file", timeout: 120000 })// Import from URL
proxychains_import({
source: "https://raw.githubusercontent.com/example/proxies/main/list.txt",
defaultType: "socks5"
})
// Import from file on remote host
proxychains_import({ source: "/tmp/proxies.txt" })// Export as proxychains.conf format
proxychains_export({ format: "proxychains" })
// Export as JSON
proxychains_export({ format: "json" })
// Export as simple ip:port list
proxychains_export({ format: "ip:port" })The remote host (e.g., Kali Linux) needs proxychains4 installed:
# Debian/Ubuntu/Kali
sudo apt update
sudo apt install proxychains4 curl
# Verify installation
proxychains4 --versionEnsure SSH access works without password prompts:
# Test SSH connection
ssh kali "echo 'Connection successful'"SSH Keys: Use SSH key authentication instead of passwords
DNS Leaks: Use proxy_dns mode to prevent DNS leakage
Proxy Trust: Only use trusted proxies; traffic is visible to proxy operators
Authentication: Proxy credentials are stored locally in ~/.proxychains-mcp/config.json
┌─────────────────┐ SSH ┌─────────────────┐ Proxies ┌─────────────┐
│ MCP Client │─────────────▶│ Remote Host │────────────────▶│ Target │
│ (Claude, etc) │ │ (Kali Linux) │ │ │
└─────────────────┘ │ proxychains4 │ └─────────────┘
└─────────────────┘Contributions are welcome! Please feel free to submit a Pull Request.
Fork the repository
Create your feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add some amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
proxychains-ng - The proxychains implementation
Model Context Protocol - The MCP specification
Add a proxy to the chain. Supports SOCKS4, SOCKS5, and HTTP proxies.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Proxy host/IP address | |
| pass | No | Password for authentication (optional) | |
| port | Yes | Proxy port | |
| type | Yes | Proxy type | |
| user | No | Username for authentication (optional) | |
| position | No | Position in the chain (0-indexed). Defaults to end of list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It notes mutation ('Add') but fails to explain side effects (e.g., chain ordering, duplication, persistence, error handling) or prerequisites like the chain existing.
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 sentence that efficiently conveys purpose and supported types, with no wasted words, though it lacks structure like bullet points for clarity.
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 6 parameters, no output schema, and no annotations, the description is incomplete. It does not mention return values, error states, or the effect on the chain configuration, leaving significant gaps for an agent.
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 has 100% description coverage for all 6 parameters, so the baseline is 3. The tool description adds minimal value beyond the schema, merely echoing supported types already in the type enum.
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 action 'Add' and the resource 'proxy to the chain', and explicitly lists supported types (SOCKS4, SOCKS5, HTTP), which distinguishes it from siblings like proxychains_remove and proxychains_list.
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 for adding a proxy but does not provide explicit guidance on when to use this tool versus alternatives like proxychains_import or proxychains_config, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get or set the current proxychains configuration including chain mode, DNS settings, and proxy list.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: get current config, set new config, or reset to defaults | |
| config | No | Configuration object (required for 'set' action) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must reveal behavioral traits. It only states get/set/reset but does not disclose side effects (overwriting, merging, persistence) or prerequisites. The action 'reset' is not explained beyond schema.
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?
Single sentence with front-loaded action and resource, no unnecessary words. Efficiently conveys core functionality.
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?
Description covers basic purpose but does not explain output (get returns config), required parameters beyond action, or behavior of reset. With nested objects and no output schema, more detail would improve completeness.
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%, so baseline is 3. Description adds value by summarizing key config fields (chain mode, DNS, proxy list), helping agents understand the config object's purpose and contents.
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?
Description clearly states the tool's function with specific verb ('Get or set') and resource ('proxychains configuration'). It lists included aspects (chain mode, DNS, proxy list), distinguishing it from sibling tools like run or add.
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 guidance on when to use this tool versus alternatives (e.g., proxychains_mode, proxychains_dns). The description does not provide context for selection or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure DNS handling. proxy_dns (recommended): DNS through proxy. proxy_dns_old: legacy mode. proxy_dns_daemon: daemon mode. none: no DNS proxying.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | DNS mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains each mode's behavior (e.g., 'DNS through proxy'), but lacks details like persistence, scope, or side effects. This is adequate for a simple configuration tool.
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 extremely concise, with a short lead sentence and a single line for each mode. No extraneous words, every sentence adds value.
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 (one parameter, no output schema), the description covers all modes and offers a recommendation. It lacks details on return values or if changes persist, but these are not critical for a DNS mode setter.
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%, and description adds clarity by explaining the meaning of each enum value beyond the schema's bare list (e.g., 'proxy_dns (recommended)'). This provides actionable context.
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 configures DNS handling, providing a specific verb-resource pair. It lists distinct modes, distinguishing it from sibling tools like run or config.
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?
Description recommends 'proxy_dns' mode and explains each option, offering implicit guidance. However, it does not explicitly state when not to use this tool or compare with siblings beyond listing modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export current proxy configuration to a file.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format (default: proxychains) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether it overwrites files, what the default filename is, or any side effects. The simple phrase 'to a file' is insufficient for an export operation.
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, short sentence with no fluff. It is concise but could benefit from a bit more context without becoming verbose.
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 simplicity of the tool (1 optional parameter, no output schema), the description is incomplete. It does not specify the output file destination or behavior, leaving ambiguity for the agent.
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% with the single parameter 'format' having a clear description and enum values. The tool description adds no additional meaning beyond the schema, so 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 clearly states the tool exports the current proxy configuration to a file, which is a specific verb+resource. It distinguishes from siblings like import and list, but lacks detail on where the file is saved.
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 guidance on when to use this tool versus alternatives (e.g., import, list). No mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import proxies from a file or URL. Supports common proxy list formats.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Format of the proxy list (default: auto-detect) | |
| source | Yes | File path or URL containing proxy list | |
| defaultType | No | Default proxy type if not specified in list (default: socks5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states 'imports proxies' and 'supports common proxy list formats', omitting details like overwrite behavior, error handling, or authentication for URLs. The safety profile of this mutation tool is unclear.
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 very short (two sentences) and front-loaded with the primary action. While concise, it sacrifices useful details. However, it contains no redundant information.
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 three parameters and no output schema, but the description does not explain return values, side effects, or behavior on success/failure. Given the lack of annotations, the description is insufficient for fully understanding the tool's operation.
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% with descriptions for all three parameters. The description does not add any additional meaning or usage context beyond what the schema already provides, so baseline score applies.
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 verb 'Import' and the resource 'proxies', indicating a bulk operation from a file or URL. This distinguishes it from sibling tools like proxychains_add (individual addition) and proxychains_list (listing).
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 context (file or URL import) but does not explicitly guide when to use this tool vs. siblings like proxychains_add for individual proxies or proxychains_export for exporting. 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.
List all proxies currently configured in the chain.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly indicates a read-only list operation with no side effects, which is sufficient for this simple tool. It could mention if any state is read from a config file, but the chain is implied.
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, clear sentence with no wasted words. It is front-loaded and easy to parse.
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 parameterless tool with no output schema, the description adequately defines the action. It could be slightly more explicit about what the returned proxy list looks like, but given the simplicity, it is sufficiently complete.
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 tool has zero parameters and 100% schema description coverage, so the description adds no further parameter meaning. The baseline for 0 params is 4, and the description does not detract.
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 ('list') and clear resource ('proxies currently configured in the chain'), and it distinguishes well from sibling tools like proxychains_run or proxychains_add which have different actions.
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 guidance is provided on when to use this tool versus alternatives like proxychains_run or proxychains_config. The description only states what it does, without context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the chain mode. strict_chain: all proxies must work. dynamic_chain: skip dead proxies. random_chain: random order. round_robin_chain: rotate through proxies.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Chain mode to use | |
| chainLen | No | Number of proxies per connection (for random/round_robin modes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the behavioral differences between the four chain modes (strict, dynamic, random, round_robin) which is useful. However, it does not disclose other important behavioral traits such as whether the setting is persistent, requires a restart, or affects runtime state. Since annotations provide no additional info, the description carries full burden and is insufficient.
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 extremely concise: one introductory sentence followed by a list of modes and their behaviors. No unnecessary words. Every sentence earns its place, and the structure is clear and front-loaded.
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 description adequately explains the modes, but given the tool has two parameters and no output schema, more context is needed. It does not explain how 'chainLen' interacts with modes, nor does it describe the effect of changing the mode (e.g., does it update a config file or runtime state?). With many sibling tools, additional context would help differentiate usage.
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 description coverage is 100%, so baseline is 3. The description adds value by explaining what each enum value means, which goes beyond the schema's 'Chain mode to use'. However, the 'chainLen' parameter is not mentioned in the description, missing an opportunity to clarify its connection to random/round_robin modes. Overall, partial added meaning.
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 purpose is to set the chain mode for proxychains, with a specific verb ('Set') and resource ('chain mode'). It lists the four modes with brief explanations, differentiating from sibling tools like proxychains_run or proxychains_config that perform other actions. However, explicit sibling differentiation is missing.
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 guidance on when to use this tool versus alternatives. It only explains what each mode does, without indicating when each mode is appropriate or when not to use the tool. No 'when-to-use' or 'when-not-to-use' context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a proxy from the chain by index or by host:port.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Host of proxy to remove | |
| port | No | Port of proxy to remove (required if using host) | |
| index | No | Index of proxy to remove (0-indexed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only says 'Remove a proxy from the chain' without disclosing persistence, error behavior, or effects on active connections. It also does not clarify what happens if multiple proxies match the host:port criteria.
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 of 12 words with no redundancy. It is efficient, though slightly more detail (e.g., clarifying '0-indexed') could be added without sacrificing conciseness.
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 simple removal tool with no required parameters and no output schema, the description covers the essential functionality. It does not address edge cases like removing a non-existent proxy or returning confirmation, but these are minor omissions.
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%, so the baseline is 3. The description adds value by summarizing the two identification methods ('by index or by host:port'), which maps to the parameters. However, it does not explain that port is required when using host, nor that index is 0-indexed (though schema describes that).
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 action ('Remove') and the resource ('a proxy from the chain'), and specifies two distinct methods of identification (by index or by host:port). This distinguishes it from siblings like proxychains_add or proxychains_list.
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 guidance is provided on when to use this tool over alternatives (e.g., proxychains_edit or proxychains_config) or when to prefer removal by index versus host:port. The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a command through the proxy chain on Kali Linux. The command will be routed through all configured proxies.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The command to run through proxychains (e.g., 'curl https://example.com', 'nmap -sT target') | |
| timeout | No | Timeout in milliseconds (default: 60000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states that the command is routed through proxies, but omits security implications, permission requirements, error handling, or side effects of running arbitrary commands.
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?
Two sentences, front-loaded with the action verb, no redundant information. Every sentence is necessary and clear.
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?
No output schema is provided, and the description fails to explain what the tool returns (e.g., stdout/stderr, exit codes). For a command execution tool, this omission leaves the agent uncertain about expected outputs.
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% with descriptions for both parameters. The description adds no additional meaning beyond the schema, meeting the baseline but not exceeding it.
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 action 'Run' and the resource 'command through proxy chain'. It distinguishes this tool from siblings like proxychains_config, add, remove, etc., which manage configuration rather than execute commands.
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 guidance on when to use this tool versus alternatives such as proxychains_test or proxychains_dns. The description does not provide context for selection or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test the proxy chain by checking connectivity and measuring latency. Optionally test against a specific target.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | Target URL to test (default: https://httpbin.org/ip) | |
| verbose | No | Show detailed output including response body |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavior. It states connectivity check and latency measurement but omits whether the tool is read-only, what happens on failure, or any side effects. This is insufficient for a test tool.
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 extremely concise with two sentences, front-loading the core purpose and optional parameter. No superfluous text.
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 simple tool with two optional parameters and no output schema, the description adequately covers purpose and optionality. However, it could mention what the output (e.g., latency value) looks like, but overall completeness is good.
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?
Both parameters are fully described in the schema (100% coverage). The description adds only that testing can optionally target a specific URL, which matches the schema but does not add new meaning beyond it.
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 tests the proxy chain for connectivity and latency, distinguishing it from sibling tools like proxychains_run (which runs commands) or proxychains_config (which configures).
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 mentions optional target testing but provides no guidance on when to use this tool versus alternatives or when not to use it. The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: running commands, managing proxies, configuring modes, DNS, and testing. No overlaps.
All tools follow a consistent 'proxychains_verb' snake_case pattern, making them predictable and easy to use.
10 tools is well-scoped for managing proxychains – covers all essential operations without bloat or gaps.
Covers CRUD for proxies, configuration, execution, testing, import/export, and DNS – no obvious missing functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Manage your blockchain infrastructure across 80+ chains with your agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/schwarztim/sec-proxychains-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
