PMCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Host to bind HTTP transport. Only used when transport is 'http'. | 127.0.0.1 |
| port | No | Port to bind HTTP transport. Only used when transport is 'http'. | 3344 |
| debug | No | Enable debug logging. Set to 'true' or 'false'. | false |
| transport | No | Transport mode: 'stdio' or 'http'. Default is 'stdio'. | stdio |
| PMCP_CONFIG | No | Path to a custom config file. Can also be set via --config. | |
| PMCP_LOCK_DIR | No | Directory for the singleton lock file. Defaults to ~/.pmcp. Can also be set via --lock-dir. | |
| PMCP_AUTH_TOKEN | No | Bearer token for HTTP transport authentication. Can also be set via --auth-token. | |
| PMCP_RATE_LIMIT | No | Rate limit for HTTP transport, e.g., '10/second'. Applied per source IP. | |
| PMCP_LEGACY_MANIFEST_AUTOSTART | No | Set to '1' to enable legacy manifest autostart behavior. |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| gateway.auth_connectA | Store credentials for a server and make them available to provisioning. Use this when gateway.provision reports missing authentication. |
| gateway.cancelA | Cancel a pending tool invocation. By default, refuses to cancel healthy requests (recent heartbeat). Use force=true to cancel anyway. Use gateway.list_pending first to see request IDs and health status. |
| gateway.catalog_searchA | Search for available tools across all connected MCP servers. Returns compact capability cards without full schemas. Use filters to narrow results by server, tags, or risk level. Set include_offline=True to also discover provisionable servers not yet running. This is the primary tool discovery entry point. |
| gateway.config_statusA | Show read-only effective configuration and startup policy status with source attribution and non-secret diagnostics. |
| gateway.connect_serverA | Connect or start a known downstream MCP server by name. Resolves configured, provisioned manifest, and registered discovered servers. |
| gateway.describeA | Get detailed information about a specific tool, including its arguments and constraints. Use this before invoking a tool to understand its requirements. |
| gateway.disconnect_serverA | Disconnect a running downstream MCP server without changing persistent config. Refuses by default when that server has pending requests; set force=true to cancel them. |
| gateway.get_startup_policyA | Return persisted autoStart and legacy disableAutoStart entries grouped by config source. |
| gateway.healthA | Get the health status of the gateway and all connected MCP servers. Shows server status, tool counts, and last refresh time. |
| gateway.invokeB | Invoke a tool on a downstream MCP server. Arguments are validated against the tool schema before execution. Output is automatically truncated if too large. |
| gateway.list_pendingA | List all pending tool invocations with health status. Shows elapsed time, heartbeat age, and current state for each request. Use this to monitor long-running operations before deciding to cancel. |
| gateway.provisionA | Provision (install and start) a specific MCP server from the manifest. Use this after reviewing candidates from gateway.request_capability. Returns immediately with a job_id for tracking. Poll gateway.provision_status to check progress. Use gateway.request_capability instead if you don't know the exact server name. |
| gateway.provision_statusA | Check the status of a running server installation. Use after gateway.provision returns a job_id. Returns progress percentage, output log, and final tools when complete. |
| gateway.refreshA | Reload backend MCP server configurations and reconnect. Use this when new MCP servers have been configured or to recover from connection errors. Refuses by default while downstream requests are pending; set force=true to cancel them. |
| gateway.register_discovered_serverA | Register an externally-discovered MCP server package so it can be provisioned. Call this after gateway.search_registry to register the chosen package, then call gateway.provision to install and start it. |
| gateway.request_capabilityA | Recommend the right tool for a task — describe what you need in natural language. Examples: 'scrape a website', 'search Slack messages', 'query Postgres', 'browse the web'. Matches against installed CLIs and 90+ provisionable MCP servers and returns ranked candidates; it does NOT start anything — call gateway.provision to actually install/start the recommended server. Prefer this over gateway.provision when you don't already know the exact server name. |
| gateway.restart_serverA | Restart a known downstream MCP server without changing persistent config. Refuses by default when that server has pending requests; set force=true to cancel them. |
| gateway.search_registryA | Search the public MCP Registry for external servers not in the local manifest. Use this when gateway.request_capability returns not_available. Returns package names and metadata; call gateway.register_discovered_server then gateway.provision to install. |
| gateway.set_startup_policyC | Preview or explicitly apply an autoStart add/remove/set operation against one selected config source or path. |
| gateway.submit_feedbackA | Prepare and optionally submit a PMCP feedback issue to GitHub. By default returns an exact preview payload; set confirm_submission=true to submit. |
| gateway.sync_environmentA | Sync environment information from the host. Detects the platform (mac/wsl/linux/windows) and probes for installed CLIs. This information is used to prefer CLIs over MCP servers when matching capabilities. |
| gateway.tasks_cancelB | Cancel a downstream MCP task by opaque task ID. Use gateway.cancel only for PMCP request IDs from gateway.list_pending. |
| gateway.tasks_getC | Get current status for one downstream MCP task. |
| gateway.tasks_listA | List brokered downstream MCP tasks. MCP task IDs are opaque downstream task identifiers, not PMCP request IDs. |
| gateway.tasks_resultA | Fetch a downstream MCP task result and apply the same output redaction and truncation options as gateway.invoke. |
| gateway.update_serverA | Update a subordinate MCP server package to latest version and restart it so the new version is actually running. Call this to check for and apply an update -- the gateway does not volunteer update notices, so nothing will prompt you. Refuses to restart by default when the server has pending requests; set force=true to cancel them. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Code Execution Guide | Comprehensive guide for using PMCP with code execution patterns |
TDQS
Scored across 26 tools
Every tool has a clearly distinct purpose with descriptive names and detailed descriptions. Ambiguities like gateway.cancel vs gateway.tasks_cancel are explicitly resolved in the descriptions, so agents can reliably differentiate them.
All tools follow a consistent `gateway.` prefix with lowercase snake_case verbs and nouns (e.g., list_pending, config_status, search_registry). The naming pattern is uniform and predictable across the entire set.
With 26 tools, the count exceeds the recommended upper bound of 25 for a cohesive toolset. While the gateway domain is broad, several tools could be consolidated (e.g., merging status/check tools) to reduce cognitive overhead.
The tool surface covers core lifecycle operations: discovery, provisioning, invocation, task management, config, health, and feedback. Minor gaps exist (no explicit uninstall/remove server tool), but the common workflows are well-supported.