toolmoat
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_pathA | Scans one file or directory (a skill folder, plugin, hook script, MCP server source or MCP config) for malicious or risky content, such as prompt injection, hidden text, credential theft and data exfiltration. Useful before a skill, plugin or server is installed, enabled or run. Read-only and offline: nothing is executed, written or sent anywhere. |
| scan_installedA | Scans the agent setup already on this machine, like |
| scan_textB | Scans content passed inline, such as a SKILL.md, an MCP tool description or an MCP config fetched from the web, without writing it to disk. Set kind to say what the content is. Read-only and offline. |
| list_rulesA | Lists the detection rules toolmoat applies, with id, severity, category, the file kinds each covers, what it detects and how to fix it. |
| list_pinsA | Shows the MCP servers pinned by toolmoat proxy, how many tools each has pinned and which tool changes are waiting for review. This view is read-only; only the user can accept changes, in a terminal. |
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
The three scan tools are cleanly separated by input source: a filesystem path (scan_path), the already-installed agent environment (scan_installed), and inline content (scan_text). list_rules and list_pins cover reporting and proxy pin state respectively, so no two tools could plausibly be mistaken for each other.
Every tool follows a strict snake_case verb_noun pattern (scan_path, scan_installed, scan_text, list_rules, list_pins). The verbs are used consistently: scan_* for detection runs, list_* for read-only enumerations.
Five tools is well-scoped for a read-only security scanner: three input modes, one rule catalog, one pin-status view. Each tool earns its place and none appear redundant or bolted on.
The core lifecycle (scan a path, scan the installed environment, scan untrusted inline content) plus rule discovery and pin status is covered with no dead ends for a read-only tool. Minor gaps remain, such as retrieving a single rule by id or explaining a specific finding, but these are workable from list_rules output.