mcp-gway
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_GWAY_ALLOW_REMOTE | No | Set to '1' to allow binding to non-loopback host (e.g., 0.0.0.0). Without this, `mcp-gway serve --host 0.0.0.0` exits with error. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| listToolFilesA | Lists the virtual .pyi stub files for connected CodeMode MCP servers (CodeMode VFS). Default server-level binding returns servers/.pyi per server (e.g., servers/filesystem.pyi); tool-level binding returns servers//.pyi per tool. The filename stem is the exact callable name for executeTool. Workflow: listToolFiles -> readToolFile -> (optional) getToolDocs -> executeTool. In code, call tools as Server.tool_name(param=value) (e.g., Filesystem.read_file(path=".")). CALL THIS FIRST when the user names a server, tool, or capability not in your visible tool list — connected MCP servers are only discoverable here. Do NOT claim a server or capability is unavailable until listToolFiles confirms it is unavailable, then offer the closest alternative from the visible list or explain that it is not connected. |
| readToolFileA | Reads a virtual .pyi stub: servers/.pyi for the full server signature list, or servers//.pyi for a single tool (both listed by listToolFiles). Matching is case-insensitive and the .pyi extension is optional. Returns the authoritative callable name and arguments for executeTool as Server.tool_name(param=value). If the compact signature is insufficient, use getToolDocs. Workflow: listToolFiles -> readToolFile -> (optional) getToolDocs -> executeTool. |
| getToolDocsA | Get detailed documentation for a specific tool including full parameter descriptions, types, and usage examples. Use this when the compact signature from readToolFile is not sufficient to understand how to use a tool. Requires both server name and tool name as parameters (e.g., server="filesystem", tool="read_file"). |
| executeToolA | Executes Python-like (Starlark) code in a sandboxed interpreter with MCP tool access as Server.tool_name(param=value) (e.g., result = Filesystem.read_file(path=".")). Final step of listToolFiles -> readToolFile -> (optional) getToolDocs -> executeTool; read the stub first and use the exact callable name shown. Security: L1 code validation (no imports/classes/file-IO/network primitives), L2 sandboxed runtime (no external modules, no filesystem/network/process access except via MCP tools, memory isolation), L3 bounded execution timeout, L4 Tool ACL (only tools_to_execute-allowed CodeMode servers/tools are visible). STARLARK RULES: no try/except/raise, no classes, no imports, no f-strings (use % formatting), no |
| callManyToolA | Runs up to 50 tool calls in one bounded fan-out (8 concurrent) and returns results in input order. Use it when several calls are independent - across servers or within one - and you want one round trip instead of N. Each item is {server, tool, arguments}; server and tool names are the ones readToolFile shows. A failed item returns ok=false with its error and never cancels its siblings, so a partial result is still usable. Do NOT use it when one call depends on another call's result: write an executeTool script for that. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool occupies a distinct step in the discovery-to-execution workflow: listing stubs, reading signatures, fetching detailed docs, executing a script, and fan-out execution. The boundaries between executeTool and callManyTool are explicitly clarified by dependency/fan-out guidance. No two tools appear to do the same thing.
All names use camelCase with a verb+object pattern (get, list, read, execute, call). There are minor deviations in object naming, such as singular/plural differences and the inserted 'Many' in callManyTool, but the convention is still readable and predictable.
Five tools is well-scoped for a gateway server that needs discovery, documentation inspection, single execution, and batch execution. Each tool has a clear role and none feels redundant or missing from the core workflow.
The surface covers the full gateway lifecycle: discover connected servers/tools, read authoritative callable signatures, fetch deeper documentation, execute a single script, and fan out independent calls. No obvious operational gap or dead end is apparent for the stated CodeMode gateway purpose.