Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This MCP server exhibits significant quality gaps across nearly all definition dimensions. While tool names generally follow verb_noun convention, descriptions are inconsistent, parameter schemas are incomplete or missing, and critical documentation is sparse. Only 8 of 23 tools have visible, complete input schemas in the source code provided. Many parameter descriptions are vague or missing entirely. Output schemas are not documented. Error handling guidance is absent. The codebase imports tools from submodules (memory/session.py, memory/checkpoint.py, etc.) but the actual tool registration code and full schemas are not visible in the provided excerpt, making verification difficult. This pattern of incomplete visibility triggers the 'inferred tool' penalty: several tools appear to be defined in external modules without explicit schema registration visible here.
Tools (23)
adapt_to_toneread onlysource verified58/100
Busca um perfil de tom específico para adaptar comunicação
Five tools (save_workspace_context, restore_workspace, get_recent_workspaces, update_workspace_files, delete_workspace) have no visible input schema. The description field is also missing or trivial (<20 chars), violating the requirement that every parameter have a type and description.
get_active_conversation and delete_checkpoint have empty input schemas ({}), meaning they accept no parameters. However, there is no documented output schema for any tool. LLMs cannot plan downstream calls without knowing what fields will be returned.
Many parameter descriptions are generic or missing context. For example, 'Filtrar por usuário específico' (Filter by specific user) does not explain WHAT user information is expected (user_id vs user_email vs user_name), WHEN to use this parameter, or the format. 26 of 23 tools have at least one parameter with inadequate description.
Recommendations
Add complete input and output schemas to ALL tools. For tools currently without visible schemas (save_workspace_context, restore_workspace, etc.), provide JSON Schema with explicit type and description for each parameter. Example: {"type": "object", "properties": {"workspace_id": {"type": "string", "description": "The unique workspace identifier (alphanumeric, max 64 chars)"}}, "required": ["workspace_id"]}
Rewrite tool descriptions to follow the 50-200 character optimal range and include WHAT/WHEN/WHY guidance. Example instead of 'Salva snapshot': 'Saves a conversation snapshot (timestamp, last N messages, topic). Call this after major context shifts to preserve state before switching topics. Returns snapshot_id for later restore_from_checkpoint.'
Add format constraints and validation rules to all numeric and string parameters. Example for 'limit': 'Maximum results to return (integer, 1-100, default 20). Larger limits risk context window exhaustion.' Example for 'start_date': 'ISO 8601 date string (YYYY-MM-DD). Queries only within ±1 year of today.'
Document output schemas explicitly for each tool. Include example response structures showing field names, types, and meaning. This enables LLMs to plan chaining calls (e.g., if get_tone_profile returns tone_id, the LLM can pass it to adapt_to_tone without a lookup).
Add recovery guidance to error descriptions. For delete operations: 'If deletion fails, check if the resource is locked or in use elsewhere. Call list_*() to verify it still exists and try again. This operation is irreversible, consider a backup first.' For read operations: 'If not found, try a broader search with fewer filters or check resource name spelling.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No tool descriptions include error recovery guidance. For destructive operations (delete_checkpoint, delete_workspace), there is no mention of confirmation steps, dry-run modes, or what happens if the operation fails. This violates the pattern:confirmation-request and pattern:recovery-guide requirements.
Tool names like 'save_conversation_snapshot' and 'save_conversation_tone' are verbs, but parameter naming is inconsistent. 'conversation_id' is used in some tools, 'user_id' in others. There is no consistent pattern for resource identifiers, forcing LLMs to reason about field mappings and risking tool misuse.
No input validation constraints are documented. For example, 'limit' parameters lack min/max bounds (pattern: 'Número máximo de...'). 'start_date' and 'end_date' lack format specifications (ISO 8601 vs other formats). 'max_depth' is unbounded, risking expensive recursive queries.
Several tools perform state modifications but have descriptions in Portuguese without explicit WHAT/WHEN/WHY guidance. For example, 'Salva snapshot da conversa atual' (Saves snapshot of current conversation) does not explain WHEN to call this vs save_workspace_context, what triggers auto-save, or how snapshots differ from checkpoints.
Tools dealing with temporal relationships (link_memories_timeline, get_memory_timeline, get_causal_chain) lack clear documentation of return structure. There is no mention of pagination, result limits, or how deep causal chains can get. This risks context window exhaustion.
Consolidate parameter naming conventions across related tools. Use consistent suffixes: _id for system identifiers (conversation_id, checkpoint_id), _name for human-readable names (user_name, channel_name), _email for email addresses. Update all 23 tools to follow this pattern.
Add pagination support to list_* and search tools. Include 'limit' (1-100), 'offset' or 'cursor', and 'total_count' in responses. Document in the description: 'Results are limited to {limit} items. Use offset or next_cursor for pagination.'
Replace Portuguese descriptions with English and add context. Example: 'Create a checkpoint of the current working state (what you're solving, decisions made, next steps). Use this before major context shifts or branching work. Later, call restore_from_checkpoint with the checkpoint_id to resume exactly where you left off.'
Add enum constraints where values are limited. Example for 'energy_level': {"type": "string", "enum": ["low", "medium", "high"], "description": "Conversation energy level (low: passive, medium: engaged, high: very active)."}
For temporal tools (get_causal_chain, get_memory_timeline), add explicit depth/result limits and document them: 'Queries up to max_depth levels deep. Limit results to 50 items to avoid context exhaustion. Results are ordered by [temporal/causal relevance]. If truncated, use offset to page through remaining items.'