mcp-hub
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CONFIG_FILE | No | Comma-separated paths to configuration files. Defaults to ~/.config/mcp-hub/servers.json, ~/.config/mcp-hub/servers.yml, ./.mcp.local.json, ./.mcp.local.yml. | |
| XDG_STATE_HOME | No | Directory for state files such as learned-auth.json. Defaults to ~/.local/state. | |
| MCP_HUB_LOG_FILE | No | Path to the log file. Defaults to ~/Library/Logs/mcp-hub.log. |
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
} |
| logging | {} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_serversA | List configured MCP servers with their descriptions and tags. Optionally filter by substring match on name/description/tags. |
| get_server_toolsA | Get tools from a specific server. Lazily connects if not already connected. Use summary_only=true for cheap discovery (~100 tokens), then fetch full schemas for specific tools you plan to call. |
| call_toolA | Call a tool on a specific server. The server is spawned on first call. The tool must exist on the server — use get_server_tools to discover first. |
| searchA | Search all configured servers and their known tools for a keyword. Returns ranked hits across server metadata and tool descriptions. Only searches servers whose tools have been loaded via get_server_tools or call_tool — server-level metadata is always searched. |
| reloadA | Reload mcp-hub: re-reads config files and reconciles the server set (added/removed/changed), tears down stale child connections, and drops cached tool schemas. Use after editing the hub's config, or after a child server's tools have changed (code edits, new tool registered). If |
| authenticateA | Authenticate a server by collecting and storing its required secrets in macOS Keychain. If the server has no auth schema, asks Claude to infer it. Uses MCP elicitation so secrets never enter the assistant's context. After storing, the server session is refreshed automatically. Set force=true to re-collect and overwrite secrets that are already stored (e.g. rotated or expired keys). |
| auth_statusA | Show authentication status for one or all servers with auth schemas. Returns per-server status: authenticated, partial, or unauthenticated. |
| recommend_serversA | Given a natural-language task description, asks the host's LLM (via MCP sampling) to rank configured servers by relevance. Returns up to max_results recommendations with scores and rationale. Falls back to a raw catalog dump if the host doesn't support sampling. Use this when the user's request spans domains and you're not sure which server(s) to reach for. |
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 8 tools
Each tool targets a distinct action: discovery (search/recommend_servers/list_servers), tool introspection (get_server_tools), execution (call_tool), lifecycle (reload), and auth (authenticate/auth_status). While search, recommend_servers, and list_servers all support discovery, their input modes and outputs are clearly differentiated. No two tools appear to do the same thing.
Most tools follow a clear verb_noun pattern: recommend_servers, list_servers, get_server_tools, call_tool. Minor deviations exist: search, reload, and authenticate are bare verbs, and auth_status is a noun phrase rather than get_auth_status, but overall the names are predictable and readable.
Eight tools is a well-scoped size for an MCP hub, covering discovery, introspection, execution, reload, and authentication. Every tool addresses a distinct operational need with no redundant helpers or filler.
The tool surface covers the core hub lifecycle: discover servers, inspect tools, call tools, reload configuration, and manage authentication. Minor gaps exist, such as no explicit deauthentication/credential removal or direct server config editing, but these are reasonably handled via the host's config files and OS keychain.