MCP ToolHub
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TOOLHUB_STATE_ROOT | No | Optional. Absolute path to the directory containing trusted state files (workspace-binding.json, approvals.json, audit.jsonl). Must be absolute when provided. If unset, ToolHub uses the platform-appropriate per-user state directory. | |
| TOOLHUB_WORKSPACE_ROOT | Yes | Required. Absolute path to an existing directory that serves as the workspace root. ToolHub canonicalizes the path once and freezes it for the lifetime of the process. |
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 |
|---|---|
| toolhub.pingB | Check whether MCP ToolHub is running correctly. |
| filesystem.read_fileB | Read a UTF-8 text file inside the ToolHub workspace. |
| filesystem.list_directoryB | List files and directories inside the ToolHub workspace. |
| filesystem.write_fileA | Create a PENDING approval request for writing a UTF-8 text file. The write happens only after a trusted administrator approves the request out-of-band and filesystem.write_file_approved executes the stored snapshot. |
| filesystem.apply_patchA | Create a PENDING approval request for a narrowly-scoped patch. The patch may modify only the requested file, and is applied only after out-of-band approval via filesystem.apply_patch_approved. |
| filesystem.write_file_approvedA | Execute exactly the file write stored in an APPROVED request. Takes only a request_id; the path/content/hash snapshot captured at request time is used. Single-use. |
| filesystem.apply_patch_approvedA | Execute exactly the patch stored in an APPROVED request. Takes only a request_id; the stored snapshot is used. Single-use. |
| shell.runA | Run a structured subprocess inside the ToolHub workspace. Only LOW-risk commands execute automatically. MEDIUM/HIGH commands create a PENDING approval request that a trusted administrator must approve out-of-band before it can be run via shell.run_approved. |
| shell.run_approvedA | Execute a previously-APPROVED command exactly as stored. Takes only a request_id; the program, args, and cwd are always the originals captured when the request was created. Approvals are single-use, so a request cannot be replayed. |
| git.statusA | Read-only git status of the ToolHub workspace repository. |
| git.diffA | Read-only git diff. Never modifies repository state. Args: path: Optional repository-relative path to filter the diff. staged: Show staged changes (git diff --cached) instead of unstaged ones. |
| toolhub.audit_recentA | Return the most recent sanitized audit events (max 100). Read-only: returns bounded metadata summaries. Event contents are already sanitized at write time; no raw stdout/stderr or secrets are included. |
| toolhub.capabilitiesC | Return the versioned public ToolHub execution contract. |
| toolhub.request_statusA | Observe an approval request without approving, rejecting, or consuming it. |
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 14 tools
Tools are cleanly partitioned into namespaces (filesystem, shell, git, toolhub) and actions. The approval-request tools and their _approved counterparts have clearly distinct purposes, and descriptions explicitly explain the two-step approval flow, so an agent can reliably choose the right tool.
All tool names follow a consistent namespace.action pattern using dot separators and snake_case actions. The _approved suffix is applied uniformly to the three post-approval execution tools, making the naming predictable throughout.
The 14 tools are well-scoped for a secured execution hub: read/list, write/patch requests, shell requests, their approved counterparts, read-only git, and lightweight diagnostics/audit. No tool appears redundant, and the count stays within a reasonable range.
Core lifecycle operations for workspace inspection, file reading, controlled writes/patches, shell execution, git status/diff, and audit/request observation are covered. Minor gaps exist—no filesystem delete/move, no direct git history/log tools, and no pending-request listing—but agents can largely work around these via shell.run or request_status.