Single tool 'list_projects' has a basic description but lacks critical schema documentation. No input parameters are visible in the source code provided, and no output schema is documented. The tool description ("Lists all indexed projects with filtering applied based on user scope") is 82 characters, adequate length but lacks actionable detail about what fields are returned, pagination behavior, or how filtering works. The code shows sophisticated filtering logic (filterListProjectsResult, stripProjectList) but this complexity is not exposed in the tool definition. No parameter descriptions, no enum constraints, no error recovery guidance. The tool is READ_ONLY (good security posture) but this is not declared via toolAnnotations.

• Add explicit input schema to list_projects with parameters: project_filter (optional string), limit (optional integer, default 20, range 1-100), offset (optional integer, default 0). Include descriptions for each.
• Document output schema: return object with fields 'projects' (array of {id, name, path, size_bytes, indexed_at}), 'total_count' (integer), 'has_more' (boolean). Specify which fields are always present vs. optional.
• Expand tool description to 150-200 chars: 'Lists all indexed projects accessible to the current user, with optional filtering by name. Returns paginated results (default 20 per page). Use limit and offset for pagination. Filters are applied server-side based on user scope.'
• Add readOnlyHint: true to tool definition to signal this is a safe, idempotent read operation.
• Document error cases: 'If filtering fails due to malformed project metadata, returns empty projects array with error note. If user has no accessible projects, returns empty array with total_count=0.'

Inferred effective spec: 2025-06-18+.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained