rolefence-scan
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_mcpA | Scan an MCP endpoint (and optionally the question server behind it, its database user and its Toolbox config) and return a plain-English report of what a model could reach. mcp_url: the gateway or question server address, e.g. http://127.0.0.1:3001/mcp token_env: name of an environment variable holding a bearer token for one role (optional) role: label for that role, used in the report text backend_url: the question server's own address behind the gateway, to test the bypass (optional) db_env: name of an environment variable holding the MongoDB URI the question server uses (optional) config_path: path to a Toolbox tools.yaml to check (optional) |
| scan_local_programA | Check the local-program ("stdio") MCP servers in an AI app's settings file: passwords or keys written there in plain text, and (with list_tools) what tools the program offers. settings_file: e.g. ~/Library/Application Support/Claude/claude_desktop_config.json, .mcp.json, ~/.claude.json, ~/.cursor/mcp.json, ~/.codex/config.toml server: check only the server with this name (required for list_tools) list_tools: start that server once the way the AI app does, ask for its tool list, and stop it. No tool is run. Ask the person before setting this. The report names settings, never their values. |
| list_checksA | List the checks rolefence-scan runs and what each needs. |
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 3 tools
The two scan tools target clearly different surfaces: scan_mcp covers remote MCP endpoints/backends and scan_local_program covers local stdio server configs, so an agent can pick between them. list_checks is a meta/discovery tool with a distinct purpose. The only mild risk is that both scan tools share the 'audit a surface' intent and an agent unsure whether a target is remote or local may hesitate.
All names are snake_case and readable, with scan_mcp and scan_local_program forming a coherent scan_<target> family. list_checks breaks the verb pattern but reflects a genuinely different action, and the shared scan_ prefix keeps the set predictable.
Three tools is on the lean side but each earns its place: two distinct scan surfaces plus a check-discovery tool that explains requirements. Nothing feels redundant or padded for this focused security-audit purpose.
Coverage spans remote endpoint scanning, local config scanning, and check introspection, which is solid for the stated purpose. However, the surface is asymmetric — scan_local_program offers list_tools enumeration for stdio servers, but there is no standalone way to enumerate tools on a remote endpoint, and no tool to retrieve or re-serialize a saved report.