MCP server that delegates private-data or large-output work to a local LLM, with a per-session context that compacts when the caller's does
Server has 5 tools with basic descriptions but critical gaps in schema visibility and parameter documentation. Tool names follow verb_noun pattern (local_llm_enable, local_llm_read, local_llm_run, local_llm_work, local_llm_disclosure) but descriptions are brief (20-80 chars) and lack actionable detail. No input schemas visible in provided source code, cannot verify parameter types, constraints, or output structures. The code shows sophisticated PII scrubbing and policy logic, but this complexity is not reflected in tool definitions accessible to LLMs. Descriptions do not explain WHEN to use each tool, what prerequisites exist, or what the LLM should expect in responses.
Set disclosure policy for identity and number values in ASSIST mode
Enable the local LLM server for this session (opt-in gate control)
Read and summarize files or directory trees with PII scrubbing
Run shell commands with policy approval and output scrubbing
Delegate work to local LLM with context management and compaction
No input schemas visible in source code. Cannot verify parameter types, constraints, enums, or descriptions. All 5 tools score 0 on schema dimension.
Tool descriptions are too brief (20-80 chars) and lack actionable context. Do not explain WHEN to use each tool, what prerequisites exist, or what output structure to expect. Descriptions should be 50-200 chars with clear intent.
No parameter descriptions visible. LLMs cannot infer what 'disclosure policy', 'policy approval', or 'context management' mean without explicit parameter-level documentation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | <=2025-11-25 | v2 |
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., does local_llm_read return file_path, content, summary, or all three?).
local_llm_run is marked WRITE risk but no confirmation/dry-run pattern documented. Destructive operations should support confirmation before execution.