Aegis MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AEGIS_TARGETS | No | Absolute path to the targets.yaml configuration file. | |
| AEGIS_WORKSPACE | No | Absolute path to the .runtime workspace directory. | |
| AEGIS_ALLOW_APPLY | No | Set to 1 to allow target changes. Target changes also require allow_apply: true for the target. | 0 |
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 |
|---|---|
| get_hardening_guideB | Return the exact English subject and the ten-step confidentiality hardening guide. |
| list_targetsA | List operator-registered target IDs and capabilities. Does not connect to targets. |
| audit_targetB | Collect read-only Linux evidence and save a local audit snapshot. No target configuration changes. |
| create_hardening_planA | Build a sealed plan with exact diffs, supported actions, prerequisites and manual work. Does not modify the target. |
| apply_hardening_planA | Apply a reviewed, sealed plan to its registered target; requires explicit local write opt-ins and root access. Backs up, validates and collects after evidence. |
| rollback_hardening_planA | Restore the backed-up managed configuration for a successfully applied plan; rejects drift and collects after evidence. |
| compare_auditsB | Compare evidence status changes for the same target registration. |
| get_report_contextB | Get the compact ten-step evidence bundle, report director and narrative schema. The server handles design and tables; draft the narrative once. |
| render_reportB | Fill the supplied professional template and export offline HTML, Markdown and JSON. Narrative is escaped commentary; observed tables cannot be overridden. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| confidentiality_audit | Run a ten-step confidentiality hardening assessment on a registered target. |
| professional_report | Create the professional report in one drafting pass using the embedded template. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| guide | English subject and ten-step best-practice guide. |
| report_director | One-pass report-writing instructions for the connected AI. |
| report_template | The reusable Jinja report structure. No need to read it to use render_report. |
| standard_mappings | Suggested ISO identifiers and primary reference links; no copyrighted standard text. |
TDQS
Scored across 9 tools
Each tool maps to a distinct stage of the hardening workflow (guide, targets, audit, plan, apply, rollback, compare, report). The only mild overlap is between get_hardening_guide and get_report_context, both informational retrievals, but descriptions make their purposes clearly separable.
All nine tools follow a consistent snake_case verb_noun pattern (get_, list_, audit_, create_, apply_, rollback_, compare_, render_). No mixed conventions or stylistic deviations.
Nine tools are well-scoped for a focused Linux hardening and reporting workflow, with each tool earning its place at a distinct lifecycle stage. No redundant or trivially thin tools.
The surface covers a full lifecycle: guidance, target listing, audit, plan creation, apply, rollback, comparison, and reporting. The only apparent gap is a register/remove target operation, since targets are described as operator-registered out of band.