Fleet-mem has 6 tools with complete input schemas and descriptions, but quality is uneven. Naming follows verb_noun convention (index_codebase, search_code, memory_store). Descriptions are present but brief (avg ~60 chars, below 194-char baseline). Parameters are typed and mostly described, but lack constraints (enums, ranges, patterns). Output schemas are not documented in the visible code. Error handling is absent, no recovery guidance or categorization. The memory_store tool conflates three distinct operations (store/search/list) into one enum-based tool, violating single-responsibility. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Security: index_codebase and index_files are WRITE operations but lack confirmation/dry-run patterns.

• Split memory_store into three separate tools: store_memory(agent_id, content), search_memory(agent_id, query, limit), list_memory(agent_id, limit). Each tool has one clear responsibility.
• Document output schemas for all tools. Example for search_code: {results: [{file: string, line: number, snippet: string, score: float}], total: int, next_cursor?: string}. Include chaining IDs (project, branch) so downstream tools can reference results.
• Add error handling with recovery guidance. Example: 'Project not found. Available projects: [list]. Call list_indexed_projects() to discover valid project names.'
• Add tool annotations via MCP protocol: mark index_codebase and index_files with destructiveHint=true; mark search_code and list_indexed_projects with readOnlyHint=true. Signals to LLMs which tools modify state.
• Add parameter constraints: extensions enum or pattern (e.g. '^\.[a-z0-9]+$'); limit with min=1, max=100; ignore_patterns with description of glob syntax (e.g. '**/*.test.py, node_modules/**').

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry