constellation-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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| gavaza_assessA | Run the POPIA compliance questionnaire from a JSON answers file.
|
| gavaza_generateB | Generate POPIA compliance documents.
|
| gavaza_breach_addA | Log a breach in the register and print the 72-hour checklist.
|
| gavaza_breach_listB | List all breaches logged in the register. |
| gavaza_reportA | Render the POPIA assessment report as JSON (default), Markdown or HTML. The JSON output of the CLI is passed through untouched. |
| gavaza_conditionsA | List the eight POPIA conditions and their compliance checklists. |
| gavaza_sectionsA | List the additional POPIA sections (special information, children, cross-border, automated decisions, direct marketing, DSR rights).
|
| gavaza_gdpr_mapA | Print the POPIA to GDPR mapping table. |
| gavaza_requests_newA | Log a data subject request with a 30-day response deadline.
|
| gavaza_requests_listA | List data subject requests, optionally filtered by status. |
| gavaza_requests_statusA | Update the status of a data subject request.
|
| gavaza_evidence_addB | Attach an evidence file to a checklist item (hashed, local copy). |
| gavaza_evidence_listA | List recorded evidence, optionally filtered by item id. |
| gavaza_evidence_removeB | Remove an evidence entry and its copied file. |
| nyarhi_add_nodeB | Add a typed node to the knowledge graph.
|
| nyarhi_add_edgeB | Add a typed edge between two nodes.
|
| nyarhi_findA | Find nodes in the knowledge graph.
|
| nyarhi_neighborsB | List the direct neighbors (nodes and edges) of |
| nyarhi_pathB | Find the shortest path between two node ids in the graph. |
| nyarhi_searchA | Full-text search over the graph's nodes.
|
| nyarhi_timelineB | Print the mutation timeline (every recorded change, newest last). |
| nyarhi_undoB | Reverse the mutation with timeline sequence number |
| nyarhi_schema_showB | Print the active typed schema of the graph as JSON. |
| nyarhi_xavani_importA | Import local Xavani home data (memories and sessions) into the graph. The import is read-only and sync-only; nothing leaves the machine. |
| nyarhi_statsB | Print knowledge graph statistics (node/edge counts, types). |
| mhangani_auditA | Run a web security audit against The target must be authorized first (see |
| mhangani_authorizeA | Record explicit authorization for a target host. Run this before auditing a host for the first time. |
| mhangani_authorizations_listA | List all recorded authorizations. |
| mhangani_authorizations_removeA | Remove the authorization for a target host. |
| mhangani_reportA | Render the last audit as JSON (default), Markdown, HTML, or exec. The JSON output of the CLI is passed through untouched. |
| mhangani_historyA | List previous audits stored in ~/.mhangani (newest first). |
| mhangani_baseline_setA | Snapshot the latest audit as the posture baseline. |
| mhangani_baseline_showA | Print the stored posture baseline. |
| mhangani_baseline_diffA | Compare the latest audit with the stored baseline. |
| mhangani_trendC | Show how the posture score moved across the audit history. |
| mhangani_checklistA | Print the OWASP-aligned check catalogue. |
| mhangani_clearA | Delete all stored audits and history in ~/.mhangani. |
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 37 tools
All tools are cleanly separated by domain prefixes (mhangani_, gavaza_, nyarhi_) and each tool has a distinct purpose. Even similar operations like find vs search or report vs report are clearly differentiated by prefix and detailed descriptions, leaving no ambiguity.
Every tool name follows a consistent lowercase snake_case pattern with a domain prefix and a verb or verb+noun structure (e.g., mhangani_audit, gavaza_breach_add, nyarhi_add_node). No mixed conventions or inconsistent verb styles are present.
With 37 tools, the server is far beyond the typical well-scoped range of 3-15. While the tools are organized into three distinct domains, combining them makes the surface overly heavy and likely to overwhelm agents. Each domain would be better served as a separate server.
The audit and compliance domains have strong lifecycle coverage (authorize, audit, report, baseline, breach, requests, evidence). However, the knowledge graph domain lacks direct update and delete operations, relying only on undo, which is a notable gap for full graph management.