Production-ready MCP server with advanced LLM text generation, context memory, and shared memory collaboration. Features OpenAI standard function calling, 67% token reduction optimization, personality-driven consultants, associative memory, and experimental Step3 capability awareness system for enhanced AI workflows.
Static source inference · medium confidence · detected: Sampling
Deprecated protocol patterns detected
Summary
This server has 17 tools with basic Zod schema definitions and descriptions present for all tools. However, there are significant quality gaps: (1) naming is inconsistent and sometimes uses hyphens instead of underscores, mixing conventions; (2) descriptions, while present, are often vague and lack the actionable context needed for LLM tool selection (e.g., 'Enable specified persona to recognize own capabilities' doesn't clearly state WHEN to use this vs other persona tools); (3) parameter descriptions exist but are minimal (many under 30 chars); (4) output schemas are NOT documented anywhere in the provided code, only input schemas are defined; (5) error handling is not visible in the tool definitions; (6) several tools manipulate state (WRITE/DESTRUCTIVE risk levels) but descriptions do not make consequences explicit; (7) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present in the definitions. The code shows well-structured TypeScript and Zod usage, which is good, but the tool definitions themselves fall short of production baseline (194 chars avg description, 100% param annotation in A+ tools). This is a C-range server with competent implementation but mediocre design.
No output schemas documented for any tool. LLMs cannot predict response structure, plan downstream tool calls, or extract required fields for chaining. This violates pattern:tool and pattern:response-shaper.
WRITE and DESTRUCTIVE tools (persona-transfer-knowledge, rbac-create-hierarchy, rbac-update-permissions, shared-memory-create, shared-memory-update, shared-memory-delete) lack explicit state-modification language in descriptions. Descriptions must clearly state 'This modifies...' or 'This is irreversible' to guide agent decision-making. Pattern:command-tool requires this.
Recommendations
Document output schemas for all 17 tools. Use JSON Schema format and include field names, types, and descriptions. Example: 'Returns {id: string, created_at: ISO8601, permissions: Permission[]}'. This is critical for LLM reasoning and tool chaining.
Expand tool descriptions to 100-200 chars. Include WHEN to use (when to prefer this tool vs similar ones), WHAT changes (if WRITE/DESTRUCTIVE), and WHAT to expect (basic response shape). Example: 'Get this persona\'s assigned permissions including inherited ones from parent personas. Use this to verify authority before delegating. Returns effective permissions (inherited + direct).'
Expand parameter descriptions to 40+ chars with explicit constraints. Include format, range, or enum values inline. Example: 'Maximum results per page (1-100, default 20)' instead of 'Maximum results per page'. State mutual exclusivity: 'Either user_id or user_email, not both.'
Add readOnlyHint to all READ_ONLY tools and destructiveHint to DESTRUCTIVE/WRITE tools. This enables MCP clients to optimize retry logic and UX. Format: { readOnlyHint: true } in tool definition.
Implement confirmation pattern for shared-memory-delete: add a dry_run parameter (boolean, default true) so agents preview impact before committing. Or require explicit confirmation_token from a preceding check-before-delete tool.
Convert free-form string parameters to enums where value set is known. Specifically: 'action' in rbac-check-permission should be enum: ["read", "write", "execute", "admin"] with descriptions for each. Same for 'resource' or create a resource_type enum.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Sampling (deprecated) - integrate directly with the LLM provider API
Score history
Overall score trend
↓ 5 points across a rubric change (v1 → v2)
49/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
49
<=2025-11-25
v2
2026-03-09
D
54
-
v1
Create parent-child hierarchy relationship between personas with permission inheritance
shared-memory-delete lacks confirmation/dry-run pattern despite being irreversible (DESTRUCTIVE risk). This violates pattern:confirmation-request and invites accidental data loss when agents omit safeguards.
Parameters 'action' and 'resource' in rbac-check-permission are free-form strings with no enum constraints. Valid values should be declared (enum). Current design invites hallucinated invalid values (e.g., 'maybe', 'unknown') and wastes retry loops.
Pagination parameters (limit, offset) in shared-memory-search lack min/max bounds and guidance on default behavior. Unbounded numbers can cause timeout or memory exhaustion. Pattern:paginated-result requires explicit limits.
Tool descriptions average ~50 chars, well below production baseline of 194 chars. Many descriptions lack WHEN/WHY context needed for tool selection (e.g., 'Enable observer persona to observe...' is passive and vague). LLMs require explicit selection criteria per pattern:tool-description.
Parameter descriptions average ~20 chars, below production baseline of 72 chars. Many descriptions are minimal labels (e.g., 'ID of the memory entry') without format, constraint, or disambiguation. Pattern:tool-description requires 10-1024 char descriptions with actionable content.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present in any tool definition. MCP clients and agents cannot identify safe-to-retry tools or operations with side effects. Current spec rewards tool annotations, their absence limits client UX and safety.
Error handling is not visible in tool definitions. No guidance on retryable vs fatal errors, no actionable recovery steps, no invalid-input hints. Pattern:recovery-guide and pattern:error-classification require explicit error categorization.
Tool naming is inconsistent: hyphenated convention (persona-inspect-capabilities) does not match MCP SDK conventions (typically verb_noun with underscores). Inconsistency confuses LLM tool parsing and violates pattern:tool naming guidance.
Permission_level enum in shared-memory-create uses unclear values 'public' vs 'edit'. Descriptions do not explain what each level allows. LLMs cannot reason about permission differences and will guess wrong. Use explicit descriptions: 'public: readable by all' and 'edit: readable and writable by specified personas'.
shared-memory-createshared-memory-update
Add min/max constraints to numeric parameters. Example: 'limit (1-100, default 20)', 'max_depth (1-10)', 'offset (>=0)'. Update schema with minimum/maximum properties AND include in description.
Document what each permission_level value enables in shared-memory tools. Update description: 'permission_level: "public" = readable by any persona, "edit" = readable and editable by creator and specified personas.'
Add error guidance to tool descriptions. Include at least one recovery hint: 'Returns 404 if memory entry not found, verify ID via shared-memory-search first.' or 'Returns 403 if requester lacks edit permission, use rbac-check-permission to verify authority.'
Rename tools to underscore convention (verb_noun) for consistency: persona_inspect_capabilities, persona_evaluate_interaction, etc. This matches MCP SDK naming and improves LLM parsing.
Add partial-success handling for batch-like operations (group-get-capability-overview, shared-memory-search). Return per-item success/failure rather than all-or-nothing responses. Example: {results: [{id, success: true}, {id, success: false, error: '...'}], total: 10}.
Document pagination behavior for search/list tools. Include: 'Returns next_cursor for continuation if results > limit. Use cursor=null for first request, then cursor=response.next_cursor for subsequent requests. Example: GET /search?query=...&limit=20&cursor=abc123'.