beam-mcp
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| beam_scan_contentA | Run Beam's offline heuristic risk scanner over inline text — an agent skill/instruction file or an MCP server config (JSON). Runs entirely locally: nothing is sent over the network, and the collector does not need to be running. Returns a list of findings (severity, title, explanation, matched evidence). |
| beam_scan_pathA | Run Beam's offline heuristic risk scanner over a file already on disk — an agent skill/instruction file or an MCP server config. Read-only: the file is never modified. Runs entirely locally. |
| beam_list_rulesA | List every active Beam detection rule, grouped by category: built-in rules, any custom rules loaded from ~/.beam/rules.json, and cross-event sequence rules. Use this to know what patterns Beam actually looks for before relying on a scan result. Read-only, runs entirely locally. |
| beam_list_supported_agentsA | List the coding agents Beam knows how to capture activity from (e.g. claude-code, codex, cursor), whether each one's hook config is installable, and whether its hook payload shape has been verified against that agent's own docs. Read-only, runs entirely locally. |
| beam_collector_statusA | Check whether Beam's local collector is running (it only ever binds to 127.0.0.1) and return its health summary: mode, event count, retention limit. Does not start, stop, or configure anything. Uses the same local credentials as the |
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
Each tool targets a clearly distinct operation: scanning inline content, scanning a file, listing rules, listing supported agents, and checking collector status. There is no meaningful overlap or ambiguity between them.
All tools share a consistent beam_ prefix and most follow a verb_noun pattern (scan_content, scan_path, list_rules, list_supported_agents). beam_collector_status is a minor deviation since it uses a noun phrase rather than an explicit verb, but it remains predictable.
Five tools is well-scoped for a focused read-only security scanning utility. Each tool earns its place and there is no bloat or redundancy.
The tool surface covers the core read-only workflow: scanning content or paths, understanding available detection rules, knowing which agents are supported, and checking collector health. Since the server is explicitly read-only, there are no obvious missing operations.