A
licenseB
qualityD
maintenanceProduction-grade MCP server that gives AI agents safe access to your local dev environment: filesystem, databases, processes, and OpenAPI specs.
15
67
3
MIT
s-gw MCP server
by sgateway
The s-gw MCP server is a local credential gateway that lets coding agents perform secret-backed operations without ever exposing raw credential values. All secrets are kept in a secure local store; agents interact only with handles and receive sanitized output.
Scan files for secrets (
sgw_scan_file): Analyze a local file for embedded secrets and return tokenized content with local handles instead of raw values; optionally persist discovered secrets.Scan arbitrary text for secrets (
sgw_scan_text): Detect secrets in any supplied text and return tokenized output; usepersist=falseto preview handle assignments without enrolling secrets into the store.List credential handles (
sgw_list_handles): Retrieve all known local secret handles along with their non-secret metadata.Describe a specific handle (
sgw_describe_handle): Fetch non-secret metadata for a single credential handle (e.g., name, type, allowed commands) without revealing the underlying secret value.Request secret-backed command execution (
sgw_request_execution): Create a pending execution manifest that injects one or more secrets as environment variables into a specified command — supports multiple handles/env vars, arguments, reason, timeout, and working directory — subject to operator approval before running.Request an SSH session (
sgw_request_ssh_session): Create an approval request for an SSH command that s-gw runs over its own managed ControlMaster session, keeping SSH key material out of the agent's context.Execute an approved request (
sgw_execute_request): Run a previously approved request and receive sanitized output, with any detected credential values replaced by their handles before being returned to the agent.
Integrates with 1Password as a credential store, enabling secure resolution of typed handles to secrets stored in 1Password without exposing raw credentials.
Provides agent-specific configuration for GitHub Copilot, allowing it to interact with s-gw for credential handling via typed handles and scoped action requests.
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., "@s-gw MCP servershow me available credential handles"
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.
Stop handing raw credentials to coding agents. s-gw gives agents typed handles, asks you to approve bounded local actions, resolves the credential inside a constrained process on your machine, and returns sanitized output instead of secret values.
IMPORTANT
s-gw is an early preview. Storage formats and interfaces may change, Windows and Linux desktop support is still experimental, and the project has not completed an independent security audit. Do not treat it as a replacement for endpoint security or a hardened enterprise secrets platform yet.
The TypeScript broker, clients, and documentation in this repository are Apache-2.0 licensed. Distributed packages also contain a proprietary compiled Rust execution core whose source is maintained separately.
The Short Version
Agent sees:
s-gw:credential:prod-readonlyYou approve: agent, command, handle, environment binding, working directory, and target
s-gw runs: the command locally with the credential injected only into that child process
Agent receives: sanitized output, audit evidence, and no raw secret
If s-gw helps your agent workflow, star the project. It makes the preview easier for other developers to find.
Related MCP server: projscan
See It In Action
The local console shows the approval queue, credential inventory, policy state, usage flow, and activity history without exposing secret values.
Public demo: s-gw.com.
What It Does
Govern | Approve | Execute | Audit |
Turn secrets into typed local handles that agents can reference safely. | Review the requesting agent, handle, command, environment binding, working directory, and target before access is granted. | Inject the credential only into the approved child process on the same machine. | Record request, approval, execution, policy, and destination evidence without storing returned raw secrets. |
Why Teams Use It
Local custody: raw values stay in macOS Keychain, Linux Secret Service, Windows Credential Manager, 1Password, or the encrypted local ledger.
Action-scoped access: grants bind to the agent, handle, command, environment variable, working directory, target, approval mode, and optional time window.
Useful handles: agents can request real work with stable handle names instead of seeing keys, passwords, tokens, or SSH material.
Output sanitization: command output is scanned before it returns to the agent, replacing detected credential values with handles.
Agent-aware setup: Codex, Claude Code, Cursor, OpenCode, Gemini CLI, GitHub Copilot, VS Code, and other MCP clients get profile-specific configuration.
Local operator UI: native desktop apps, tray or menu helpers, the CLI, and the web console show approvals, credential inventory, policies, usage flow, activity, and audit history.
How It Works
flowchart LR
A["Coding agent"] -->|"Handle + action request"| G["s-gw local gateway"]
G --> U["Local approval"]
U --> R["Constrained runner"]
K[("Keychain / Credential Manager / encrypted store")] --> R
R -->|"Sanitized output"| G
G --> AThe agent never needs the unlock passphrase or raw credential. Approval is scoped to the requested operation rather than granting general access to the store.
Core Surfaces
Surface | Purpose |
| Setup, credential enrollment, approvals, policies, agent snippets, guard mode, and diagnostics. |
| Stdio MCP server for agent-facing handle discovery and request creation. |
Native macOS app | Approval queue, credential inventory, policy rules, usage flow, activity, and audit review. |
Windows and Linux desktop apps | Installed preview apps with a native window, tray controls, and a bundled local runtime. |
Menu-bar helper | Fast visibility into pending approvals and local daemon status. |
Local web console | Browser backup bound to |
Guard mode | Launch agents with credential-looking environment values replaced by s-gw handles. |
Quick Start
The public npm package is the recommended installation path on macOS, Windows 10/11, and Linux. Install Node.js 20 or newer, then run:
npm install -g @s-gw/s-gw
s-gw setup
s-gw statusOn Windows, run the same commands in PowerShell. Windows support is preview software: the npm package uses the TypeScript execution path and includes the PowerShell client, tray helper, and local web console.
On Linux, install secret-tool first (sudo apt install libsecret-tools on Ubuntu/Debian). An unlocked desktop Secret Service is the normal persistent unlock provider; s-gw setup also installs and starts an owner-level systemd --user console service for the graphical session. A headless host without Secret Service can use an explicitly supplied SGW_MASTER_PASSPHRASE with s-gw setup --no-service --no-open-app, but s-gw never copies that value into a unit file or background-service environment.
Windows x64 and Linux x64 also have installable desktop-app builds. The Rust app draws its management interface directly in a native window; it does not embed a browser, WebView, or localhost page. It packages its own pinned Node runtime and s-gw CLI, so the installed app does not require host Node.js or npm. When the native executable is installed, s-gw app open uses it. Use s-gw app open --browser to start and open the separate loopback browser backup explicitly.
These Windows NSIS and Linux Debian packages are currently unsigned CI previews, not supported public release downloads. Windows does not require WebView2. Linux requires a graphical session and an unlocked Secret Service keyring; the Debian package declares its GTK 3, AppIndicator, libxdo, and libsecret-tools runtime dependencies. See deployment and packaging for build and install details.
For an Apple Silicon Mac desktop bundle, GitHub Releases also provides a self-contained s-gw.dmg. Drag s-gw.app to Applications, then open it and complete setup. The app includes its own Node runtime, CLI, MCP server, native helpers, and menu-bar helper; it does not require Node.js or npm on the host. Setup is intentionally blocked until the app is in /Applications or ~/Applications.
An unsigned DMG requires a Gatekeeper override. Use the npm installation above instead if you do not want to use that override.
The public source builds the TypeScript compatibility path and the native-rendered Windows/Linux Rust desktop app. Building the native macOS surfaces also requires a Swift toolchain. Windows and Linux desktop builds require Rust and their ordinary native graphics and tray development libraries. Maintainer release builds additionally require access to the private Rust core checkout.
The Apple Silicon Mac DMG is a self-contained desktop alternative. Published macOS DMGs are either Developer ID signed and notarized or explicitly documented as unsigned; unsigned builds require a Gatekeeper override but retain the standard release tag and update path. Local npm run build:installers output is ad-hoc signed for local verification. The npm package is the primary install and includes the native app, menu helper, Keychain helper, metadata-only Keychain inspector, and Rust core for Apple Silicon Macs. Linux and Windows use the TypeScript execution path when a matching native core is not packaged. Intel Macs must build the native Keychain and desktop surfaces from source for now; packaged arm64-only helpers are rejected before launch.
git clone https://github.com/sgateway/s-gw.git
cd s-gw
npm ci
npm run build
npm link
s-gw setup
s-gw statuss-gw setup generates local unlock material, stores it in the operating system credential store, initializes the encrypted ledger, starts the local UI surfaces available on the current platform, and safely connects detected supported agents. The self-contained macOS app and the Windows/Linux desktop previews run their bundled runtimes in place; npm installs copy the thin macOS app into /Applications, falling back to ~/Applications when needed. Setup backs up existing agent config, preserves unrelated settings, installs the packaged s-gw skill where supported, and reports per-agent conflicts. Use --no-agents to skip agent registration.
Add a credential from your terminal without placing the value in chat or a process argument:
printf '%s' "$MY_API_TOKEN" | s-gw secret add-keychain \
--name demo-token \
--type api-token \
--value-stdin \
--inject-env API_TOKEN \
--allow-command "$(command -v printenv)"Then inspect the non-secret handle metadata:
s-gw secret listThe end-to-end trust loop walks through a disposable request, local approval, execution, and output sanitization without touching a real credential.
Try The Trust Loop
Use a disposable local token to see the full flow:
printf '%s' 'demo-secret-value' | s-gw secret add-keychain \
--name demo-printenv-token \
--type api-token \
--value-stdin \
--inject-env DEMO_TOKEN \
--allow-command "$(command -v printenv)"
s-gw request env-command <returned-handle> \
--command "$(command -v printenv)" \
--inject-env DEMO_TOKEN
s-gw approve <request-id>
s-gw execute <request-id>The execution output should show a handle token instead of demo-secret-value.
Agent Integration
List the known agent profiles and render the configuration for one client:
s-gw agent list
s-gw agent mcp-snippet codex
s-gw agent mcp-snippet claude-code
s-gw agent mcp-snippet opencodeReview or manage detected connections:
s-gw agent status
s-gw agent install codex --dry-run
s-gw agent install codex
s-gw agent uninstall codexManual profiles and config formats without a safe merge path continue to use the generated snippet. npm installation itself never edits agent configuration.
s-gw setup can safely manage detected Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot CLI, OpenCode, and default-profile VS Code installations on macOS, Windows, and Linux. On Windows, it launches the packaged MCP server through node.exe, not an npm .cmd shim.
For CLI agents, guard mode can replace credential-looking launch environment values with s-gw handles before the agent starts:
s-gw run codex --dry-run -- -v
s-gw run codex -- --ask-for-approval neverMCP registration does not intercept every prompt, file read, shell, or environment variable. See agent integration and the agent profile matrix for the supported paths and current limitations.
Example Request Flow
An agent sees
s-gw:credential:prod-readonlyand asks to runaws sts get-caller-identity.s-gw creates a pending request with the agent name, command, handle, environment binding, working directory, target, and policy result.
You approve once, for a time window, for the login session, or deny it.
s-gw starts the approved local process with the credential injected into the requested environment variable.
s-gw scans the process output before it returns to the agent.
The model can complete the task without receiving the raw access key.
Platform Status
Platform | Status | Credential store | User interface |
macOS 14+ on Apple Silicon | Primary development platform | Keychain | Native app, menu helper, local web console |
macOS 14+ on Intel | Build-from-source candidate; not QA-tested | Source-built Keychain helper | Source-built native surfaces or local web console |
Windows 10/11 x64 | Unsigned desktop preview | Credential Manager | Native desktop app and tray; PowerShell client and browser backup |
Linux x64 desktop | Unsigned desktop preview | Secret Service; explicit environment fallback | Native desktop app and tray; systemd user service and browser backup |
Linux arm64 | npm preview | Secret Service; explicit environment fallback | systemd user service and browser backup |
Published Apple Silicon macOS DMGs are self-contained. Releases are Developer ID signed and notarized when credentials are available; otherwise the release notes and DMG README state that a Gatekeeper override is required. Windows NSIS and Linux Debian desktop packages are currently unsigned CI artifacts and are not uploaded as supported release downloads. Build either one on its target operating system with npm run build:desktop-app; build the existing release artifacts with npm run build:installers.
Security Model
s-gw is designed to reduce accidental credential exposure to coding agents. It does not protect against a compromised operating system account, a malicious approved executable, screen capture, kernel-level access, or every transformed derivative of a secret.
Read the threat model before relying on s-gw for sensitive workflows. Report suspected vulnerabilities through GitHub private vulnerability reporting, not a public issue.
Project Status
The public broker and client source distribution is preview quality; the compiled Rust execution core is proprietary.
macOS is the primary development and test platform.
Windows Credential Manager support and the Windows x64 desktop app are present but still need broader native QA and code signing.
Linux uses Secret Service for persistent unlock material and a hardened systemd user service. The Linux x64 desktop app is an unsigned preview; environment unlock is a non-persistent headless fallback only.
Windows and Linux desktop installers are CI previews until they are signed and validated on supported target systems. macOS releases without Developer ID signing are marked unsigned in their release notes and require a Gatekeeper override.
The repository is prepared for open-source collaboration, but security-sensitive changes should come with focused tests and threat-model updates when behavior changes.
Documentation
Contributing
Issues and focused pull requests are welcome. Start with CONTRIBUTING.md, browse good first issue, and use SECURITY.md for anything that may expose credentials or bypass approval.
Planning a launch, write-up, or community post? The maintainer notes in docs/community-launch.md keep the public wording consistent and honest.
License
Source in this repository is Apache-2.0. See LICENSE and NOTICE. The separately maintained Rust core and its compiled binaries are proprietary and are not licensed under Apache-2.0. Third-party names and artwork remain the property of their respective owners and are documented in TRADEMARKS.md and the third-party notices.
Available Tools
7 toolssgw_describe_handleDescribe HandleB
Show non-secret metadata for one local secret handle.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only discloses that it shows 'non-secret metadata' for a 'local secret handle'. It does not specify behavior if handle is invalid, required permissions, or side effects. Important aspects are missing.
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 with 7 words, perfectly concise and front-loaded. No wasted words; every part contributes directly to understanding the tool's purpose.
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 the tool's simplicity (1 parameter, no output schema), the description is minimally adequate but lacks details on error conditions, case sensitivity, or metadata structure. It could be more complete without becoming verbose.
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 single parameter 'handle' lacks schema description (0% coverage). The description adds context that it is a 'local secret handle', providing minimal additional meaning beyond type and minLength. More detail on format or allowed values would be beneficial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Show' and the resource 'non-secret metadata for one local secret handle'. It effectively distinguishes from sibling tools like sgw_list_handles (which lists handles) and sgw_execute_request (which executes requests).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as sgw_list_handles or sgw_scan_file. There is no mention of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sgw_execute_requestExecute Approved RequestC
Execute a previously approved local request and return sanitized output.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| requestId | Yes |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It mentions 'sanitized output' but does not explain side effects, reversibility, or security implications of executing a request. Significant gaps remain.
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 sentence of 8 words that is front-loaded and contains no filler. Every word contributes meaning, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity (1 parameter), the description does not explain how to obtain a valid requestId, what 'previously approved' entails, or the structure of the sanitized output. Critical gaps remain for a potentially destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the only parameter, 'requestId'. The description provides no additional meaning or format guidance, leaving the parameter completely ambiguous.
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 specifies the action ('Execute'), the resource ('previously approved local request'), and the nature of the output ('sanitized output'). It distinguishes from siblings like sgw_request_execution, which likely handles the approval workflow.
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 given on when to use this tool versus alternatives, how to obtain a requestId, or prerequisites such as the request being approved. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sgw_list_handlesList HandlesA
List known local secret handles and non-secret metadata.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.5/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 fully disclose behavioral traits. It describes a listing operation, which is read-only by nature, but does not explicitly confirm idempotency, side effects, or resource requirements. The description does not address potential limitations like pagination, rate limits, or server load implications.
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, succinct sentence that immediately communicates the purpose. There is no extraneous information; every word is meaningful. It front-loads the verb 'List' and specifies the objects being listed. This is an ideal length for a simple tool.
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 the tool has no parameters and no output schema, the description is minimally sufficient. It tells what is returned ('handles and non-secret metadata') but omits details like whether the list is sorted, paginated, or limited. For a tool with zero complexity, a score of 3 acknowledges that it conveys the core functionality but lacks supplementary context that might aid an 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 zero parameters, and the schema coverage is 100% by default. The description adds no parameter-specific information because none exist. With 0 parameters, the baseline score of 4 is appropriate; the description does not detract but also does not need to compensate.
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 ('List') and the resource ('known local secret handles and non-secret metadata'). It distinguishes this tool from siblings such as 'sgw_describe_handle' which focuses on a single handle, and 'sgw_execute_request' which uses handles. The specificity of 'local secret handles' prevents confusion with global or non-secret handles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as requiring prior knowledge of a handle, or indicate that this tool is appropriate for getting an overview before drilling down with 'sgw_describe_handle'. The lack of usage context means the agent must infer appropriateness from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sgw_request_executionRequest Secret-Backed ExecutionC
Create a pending local manifest for a command that needs one secret injected as an environment variable.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | ||
| args | No | ||
| handle | Yes | ||
| reason | No | ||
| command | Yes | ||
| injectEnv | Yes | ||
| timeoutMs | No | ||
| workingDir | No |
TDQS
C2.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool creates a 'pending' manifest, implying the command is not executed immediately. However, it does not disclose any other behavioral traits such as authentication requirements, rate limits, state mutation details, or whether it returns a handle for later execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 15-word sentence, very concise and front-loaded with the key action. However, the brevity comes at the cost of omitting important details about parameters and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no output schema, no annotations), the description is severely incomplete. It does not explain the purpose of most parameters, the workflow (e.g., how to later execute the pending manifest), or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 8 parameters, the description only hints at 'command' and 'injectEnv', ignoring the required 'handle' parameter and others like 'env', 'args', 'reason', 'timeoutMs', and 'workingDir'. This leaves critical parameter meaning ambiguous.
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 creates a pending local manifest for a command requiring secret injection. The verb 'create' and resource 'pending local manifest' are specific, and it distinguishes from the sibling 'sgw_execute_request' which likely executes the manifest. However, the term 'pending local manifest' may be jargon.
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 on when to use this tool versus alternatives like sgw_execute_request or sgw_describe_handle. It implies it's for commands needing secret injection, but does not specify prerequisites, exclusions, or alternative contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sgw_request_ssh_sessionRequest s-gw-Owned SSH SessionC
Create a local approval request for an SSH command that s-gw will run over its own persistent ControlMaster session.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | ||
| port | No | ||
| handle | Yes | ||
| reason | No | ||
| target | Yes | ||
| injectEnv | No | ||
| timeoutMs | No | ||
| workingDir | No |
TDQS
C2.4/5.0
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 mentions 'local approval request', implying the tool does not execute the command immediately, but it does not disclose side effects, permissions needed, or post-creation steps. The behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and free of fluff. However, it could be expanded slightly to improve clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no output schema, no annotations), the description is severely incomplete. It does not explain the return value, approval flow, prerequisites (e.g., ControlMaster session), or parameter roles, leaving large gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no explanation of the 8 parameters (handle, target, args, etc.). For a tool with 0% coverage, the description must compensate, but it fails to provide any parameter context, leaving the agent to guess their meaning.
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 creates a local approval request for an SSH command, specifying it runs over s-gw's persistent ControlMaster session. However, it does not explicitly differentiate from the sibling tool sgw_request_execution, which may have a similar purpose.
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?
There is no guidance on when to use this tool versus alternatives like sgw_request_execution, nor any mention of prerequisites or context. The description implies SSH-specific usage but lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sgw_scan_fileScan Local FileA
Scan a local file for secrets and return tokenized text plus local handles. Raw values are not returned.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| persist | No |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explicitly states that raw values are not returned, which is key. However, it does not mention if the file is modified, permissions needed, or any side effects. The 'local handles' concept is introduced but not explained.
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 and front-loaded. It uses two short sentences with no redundant information, efficiently conveying the core purpose and a key constraint.
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 two parameters, no output schema, and no annotations, the description covers the basic purpose and a behavioral constraint. However, it fails to explain the 'local handles' concept or how the output relates to other tools like sgw_describe_handle, leaving some gaps for the agent.
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 0%, so the description must compensate. The description implies 'path' is the file location, but 'persist' is not explained. It adds some context for the path but not enough for the optional boolean parameter.
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 ('scan a local file' for secrets) and the output ('tokenized text plus local handles'). It distinguishes from sibling sgw_scan_text by focusing on files, implying a specific use case.
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 use when scanning local files, but does not explicitly state when to prefer this over sgw_scan_text or other siblings. No exclusion criteria 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.
sgw_scan_textScan TextB
Scan supplied text and return tokenized text. Persist=false previews handles without enrolling secrets.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| source | No | ||
| persist | No |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It hints at persist controlling secret enrollment but does not clarify side effects, destructive potential, or read-only nature. The behavior of 'return tokenized text' is vague without format details.
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 sentences. The first sentence delivers the core purpose immediately, and the second adds critical parameter behavior without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 3 parameters, the description is insufficient. It does not explain return format, parameter semantics for 'source', or how this tool differs from sibling 'sgw_scan_file'. An agent lacks information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only adds meaning for 'persist' (preview vs enroll). Parameters 'text' and 'source' remain unexplained. The description thus partially compensates but leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'scan' and resource 'text' and specifies the output as 'tokenized text'. It also distinguishes from sibling 'sgw_scan_file' by focusing on text input, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'sgw_scan_file'. The description mentions 'Persist=false' but does not explain the context for using this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
B3.2/5.0
Disambiguation4/5
Tools have distinct purposes, but there is potential confusion between sgw_request_execution and sgw_execute_request (create vs. execute), and the names are similar. However, descriptions clarify the difference, and other tools are clearly distinct.
Naming Consistency5/5
All tool names follow a consistent 'sgw_verb_noun' pattern using snake_case. Each name clearly indicates the action and target, with no deviations.
Tool Count5/5
With 7 tools covering scanning, handle management, execution requests, and SSH sessions, the count is well-scoped for a security-focused server. Each tool has a clear role.
Completeness3/5
The set covers core workflows (scan, request, execute, list handles) but lacks tools for managing pending requests (e.g., list, approve, cancel) or SSH sessions after creation (e.g., list, end), leaving notable gaps.
Maintenance
ActivityActive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceAn MCP server that provides AI coding agents with AST-accurate, context-budget-aware codebase querying, safety gates, and team policy integration via structured tools and a local plugin layer.5624MIT
- AlicenseNot gradedqualityBmaintenanceA local macOS MCP server for AI Agents that exposes safe endpoints for shell commands, files, processes, macOS automation, browser control, and more.2MIT
- AlicenseNot gradedqualityBmaintenanceA self-hosted MCP server that enables AI coding agents to read, edit, search, and run code in local projects with human review loops and policy controls.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/sgateway/s-gw'
If you have feedback or need assistance with the MCP directory API, please join our Discord server