Satori MCP has only 1 tool (manage_index) with a reasonable schema and description. However, the tool exhibits critical naming and composition issues. The name 'manage_index' violates verb_noun conventions and conflates multiple distinct operations (create, reindex, sync, status) into a single tool. The description (105 chars) is adequate in length but lacks clarity on when to use each action variant and what the tool returns. The input schema declares the 'action' enum properly but lacks descriptions for the enum values themselves, forcing the LLM to guess what 'sync' vs 'reindex' actually do. The 'path' parameter description is minimal (23 chars) and doesn't specify the expected format, validation rules, or error cases. Output schema is completely undocumented, there is no visibility into what fields are returned for each action. Error handling is absent from the visible code. The tool's risk is marked WRITE but there is no confirmation pattern, dry-run mode, or idempotency guarantee documented. The server is STDIO-only, which hard-caps protocol readiness at 50 and severely limits production utility.

• Split manage_index into 4 separate tools: (1) create_index(path), creates new index for a repository; (2) sync_index(path), incrementally updates index with recent changes; (3) reindex_repository(path), rebuilds entire index from scratch; (4) get_index_status(path), returns index health, size, last updated timestamp. Each tool should be a single verb_noun pair.
• Add explicit descriptions for each enum value. E.g., in manage_index, if keeping it: 'create' (creates new index if none exists; fails if index already present), 'sync' (incrementally updates with uncommitted changes; no-op if up-to-date), 'reindex' (full rebuild; overwrites existing index), 'status' (returns index metadata and health).
• Document the complete output schema for each action. Example: create_index should return {index_id, path, created_at, file_count, size_bytes}. sync_index should return {files_added, files_modified, files_deleted, sync_duration_ms, new_file_count}. Use these to demonstrate chaining capability.
• Add 'dry_run' boolean parameter (default false) to destructive operations. When true, report what would change without executing. E.g., 'Would reindex 2500 files, 145 MB'. This prevents irreversible mistakes by LLMs.
• Specify path validation rules in the 'path' description: 'Must be an absolute path to an existing directory containing a Git repository. Will fail if path does not exist, is not a directory, or is not a Git root.'
• Add error handling guidance in tool description. E.g., 'If index is locked, returns {status: "in_progress", wait_seconds: 30}. If path is invalid, returns {error: "not_found", suggestion: "verify path exists and is a Git root"}.'