Multi-modal MCP server with SOC (Security Operations Center) pipeline, threat intelligence, decision logging, and multi-stage event correlation. Implements SENTINEL AI framework with Secret Scanner, playbook engine, and compliance reporting (EU AI Act Article 15).
GoMCP presents a severely underdeveloped tool definition landscape despite registering 35 tools. Only tool name and risk classification are visible in the provided schema; actual input parameter schemas, output schemas, and parameter descriptions are INFERRED from the provided summary table, not directly visible in source code. The Dockerfile and Makefile contain no tool definitions. The single code excerpt (soc_tools.go header) is truncated and shows no tool registration logic. Critical gaps: (1) Input schemas lack required validation constraints (enums, min/max bounds), (2) Parameter descriptions are generic and undifferentiated across similar tools, (3) Output schemas are completely undocumented, LLMs cannot plan downstream tool calls or extract structured data, (4) Error handling is not specified anywhere, (5) Tool descriptions omit WHEN to use each tool vs similar alternatives (e.g., why call 'soc_ingest' vs 'soc_events'?), (6) Security-critical tools like 'execute_attack_chain' and 'extract_raw_intent' reference undefined operational modes ('ZERO-G mode') with no formal definition, (7) Dependencies between parameters are undocumented (e.g., 'sensor_key' in soc_ingest, is this always required or only when sensor_id is absent?). The tool portfolio itself signals design debt: 'add_fact' + 'update_fact' + 'delete_fact' + 'list_facts' + 'search_facts' is basic CRUD; 'get_cold_facts' + 'get_stale_facts' are specialized variants that could be unified. 'synthesize_threat_model' and 'extract_raw_intent' reference undefined internal modules ('Code Crystals', 'Shadow Memory') with no public schema.
Accept a pending synapse (PENDING → VERIFIED). Only verified synapses influence context ranking.
Add a new hierarchical memory fact (L0-L3)
Add an immutable genome fact (survival invariant, L0 only). Once created, a gene cannot be updated or deleted.
Archive multiple facts and create a summary. AI provides fact_ids and summary text. Genes are protected.
Delete a fact by ID
Export facts created after a given timestamp. Use for incremental sync between peers. Returns only new/modified facts.
Start an autonomous multi-step attack chain using the Pivot Engine (Module 10). ZERO-G mode REQUIRED. Returns FSM chain with recon→hypothesis→action→observe cycle.
Input parameter schemas are INFERRED from summary table, not directly visible in source code. The soc_tools.go excerpt is truncated; Dockerfile and Makefile contain no tool definitions.
Output schemas completely missing for all 35 tools. LLMs cannot plan multi-step sequences or extract structured data if they don't know what fields each tool returns. Example: 'soc_ingest' has no documented output, does it return incident_id, event_id, verdict, or all three?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
Extract encrypted Shadow Memory data. ZERO-G mode required (double-verified). Returns base64 AES-GCM encrypted threat report.
Get fact store statistics
Get stale facts for review (hit_count=0, >30 days old). Genes excluded. Use for memory hygiene.
Retrieve a fact by ID
Get all L0 (project-level) facts — always-loaded context
Get stale facts for review
Correlate detected threat patterns into meta-threats. ZERO-G mode required. Identifies systemic vulnerabilities from individual findings.
Run self-diagnostic checks: SQLite integrity, genome verification, leash mode, permissions, decision log. Returns HEALTHY/DEGRADED/CRITICAL.
List all unique fact domains
List facts by domain or level
List all genome facts (immutable survival invariants)
Get orchestrator runtime status: cycle, config, last heartbeat, module 9 synapse scanner state.
Process expired TTL facts (mark stale, archive, or delete)
Generate auto-documentation from L0/L1 facts. Returns structured markdown with project overview grouped by domain.
Reject a pending synapse (PENDING → REJECTED). Removes from ranking consideration.
Search facts by content text
Generate EU AI Act Article 15 compliance report with requirement status and evidence (§12.3).
Get SOC dashboard KPIs: events, incidents, sensor health, decision chain integrity (§12.2).
List recent SOC events. Returns events sorted by timestamp descending.
List SOC incidents with optional status filter.
Ingest a security event into the SOC pipeline. Runs Secret Scanner (Step 0), rate limits, decision logging, correlation, and playbook matching.
Manually execute a playbook against an incident (§10, §12.1).
List all registered SOC sensors with status and heartbeat info.
Update an incident status (manual analyst verdict).
Show pending semantic connections between facts for Architect review.
Scan Code Crystals for security threats (hardcoded secrets, weak configs, logic holes). ZERO-G only.
Update an existing fact
Verify genome integrity via Merkle hash of all genes
Parameter descriptions are generic (5-20 words) and underdifferentiated. Examples: 'level' (Hierarchy level: 0=project, 1=domain, 2=module, 3=snippet) lacks WHEN to use each level; 'severity' in soc_ingest lacks guidance on threshold for automated vs manual response; 'status' in soc_verdict lacks description of state transitions.
Security-critical tools reference undefined operational modes without formal definition: 'extract_raw_intent' requires 'ZERO-G mode (double-verified)'; 'synthesize_threat_model' is 'ZERO-G only'; 'execute_attack_chain' is 'ZERO-G mode REQUIRED'. These modes are mentioned in descriptions but never defined as enum constraints, parameters, or configuration.
Destructive/irreversible tools (delete_fact, execute_attack_chain) lack confirmation or dry-run patterns. 'execute_attack_chain' has IRREVERSIBLE risk classification but no confirmation mechanism documented. Per pattern:confirmation-request, agents should not execute irreversible ops without explicit consent.
Error handling guidance is absent for all tools. No documentation of error codes, recovery steps, or how the agent should respond to failures. Example: 'soc_ingest' with sensor_key authentication, what happens if auth fails? Retry? Ask user to verify key?
Parameter dependencies undocumented. Example: 'soc_ingest' with 'sensor_id' and 'sensor_key', are both required? If sensor_id is empty, does it auto-assign? Does sensor_key always apply or only when sensor_id is missing? Undocumented param relationships cause silent misuse.
Internal references without public definitions. Tools reference 'Code Crystals', 'Shadow Memory', 'Pivot Engine', 'Module 9' with no explanation. LLMs cannot understand when to invoke 'synthesize_threat_model' if 'Code Crystals' is undefined.
Overlapping CRUD tools. 'add_fact', 'update_fact', 'delete_fact', 'list_facts', 'search_facts' + 'get_cold_facts', 'get_stale_facts', 'get_l0_facts' suggest a monolithic fact store with multiple read paths. No guidance on which query tool to use when. Baseline pattern:tool-chain recommends composable, non-overlapping tools.
Sensor authentication via tool parameter. 'soc_ingest' exposes 'sensor_key' as a parameter (§17.3 T-01 reference in description). Per pattern:secret-injection, credentials must NEVER be tool parameters, they are logged in traces and prompt history. Requires server-side secret injection.